---
title: "Understand domain restrictions"
slug: "understand-domain-restrictions"
description: "Understand domain restrictions for self-registration on your knowledge base, including Allow and Block types, and how reader group mapping affects access."
updated: 2026-06-19T07:41:35Z
published: 2026-06-19T07:41:35Z
canonical: "docs.document360.com/understand-domain-restrictions"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.document360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Understand domain restrictions

Domain restrictions determine whether readers from specific email domains can self-register on your knowledge base site. The outcome depends on two factors: the **restriction type** (Allow or Block) set when the domain was added, and the domain's current **status** (Active or Inactive). Understanding how these two settings interact helps you configure self-registration access precisely.

---

## Restriction type and status combinations

| Restriction type | Domain status | Outcome | Example |
|---|---|---|---|
| **Allow** | **Active** | Readers from the domain can self-register | A company adds `@examplecorp.com` to the Allow list with status Active. Employees with `@examplecorp.com` can self-register. |
| **Allow** | **Inactive** | Readers from the domain cannot self-register | The domain `@examplecorp.com` is set to Allow, but its status is Inactive. Employees with this domain cannot self-register. |
| **Block** | **Active** | Readers from the domain cannot self-register | A general email domain like `@genericmail.com` is added to the Block list with status Active. Users with this domain cannot self-register. |
| **Block** | **Inactive** | Readers from the domain can self-register | The domain `@genericmail.com` is in the Block list but its status is Inactive. Users with this domain can self-register. |

---

## How Allow and Block work

- **Allow**: Only readers from the specified domains can self-register. All other domains are blocked.
- **Block**: Readers from the specified domains are prevented from self-registering. All other domains can self-register.

Setting a domain's status to **Inactive** effectively reverses the restriction without removing the domain entry. This allows you to temporarily suspend or reinstate a restriction without deleting and recreating it.

---

## How reader group mapping works with domain restrictions

When a domain restriction is set to **Allow** and a reader group is mapped to that domain, readers who self-register with that domain are automatically added to the mapped reader group.

If no reader group is mapped to the domain, the default reader group set in the **Content permission** section of the self-registration page applies. If no default group is set either, self-registered readers from that domain will have unrestricted access to the entire knowledge base.

If both a default content permission reader group and a domain-specific reader group are configured, the domain-specific reader group takes precedence.

---

## FAQ

<div class="faq-wrapper" data-type="details-wrapper">
  <details open>
    <summary><p>What happens if no default reader group is selected?</p></summary>
    <div data-type="details-content">
      <p>If no default reader group is selected, self-registered readers will have unrestricted access to the entire knowledge base, without any group-specific restrictions.</p>
    </div>
  </details>
  <button class="details-arrow" type="button"></button>
</div>

<div class="faq-wrapper" data-type="details-wrapper">
  <details open>
    <summary><p>What access do readers with multiple group memberships get?</p></summary>
    <div data-type="details-content">
      <p>When a reader is part of multiple groups, the highest level of access for each content item is granted.</p>
      <p>For instance, if a reader belongs to Group A (which has access to all languages in workspace 'V1') and Group B (which has access to only English in 'V1'), the reader will receive access to all languages in workspace 'V1'.</p>
    </div>
  </details>
  <button class="details-arrow" type="button"></button>
</div>

<div class="faq-wrapper" data-type="details-wrapper">
  <details open>
    <summary><p>Does individual content access override reader group access?</p></summary>
    <div data-type="details-content">
      <p>No, individual content access does not override group access. The reader always receives the highest privilege from both individual and group settings.</p>
      <p>For example, if a reader is individually set to access only English in workspace 'V2' but is also part of a group that has access to all languages in 'V2', the reader will have access to all languages in 'V2'.</p>
    </div>
  </details>
  <button class="details-arrow" type="button"></button>
</div>

<div class="faq-wrapper" data-type="details-wrapper">
  <details open>
    <summary><p>How is reader access prioritized?</p></summary>
    <div data-type="details-content">
      <p>Access is determined by the highest privilege assigned at each content level. Readers only gain access to the content they have been specifically granted.</p>
    </div>
  </details>
  <button class="details-arrow" type="button"></button>
</div>