# Authoritative vs Internal relay: which accepted domain type should you use in Microsoft 365?

URL: https://iblockspam.com/blog/microsoft-365-accepted-domains-authoritative-internal-relay
Last updated: 2026-10-22
Published: 2026-10-22
Topic: Setup guides
Author: iBlockSpam Team

> Authoritative or Internal relay? What each Microsoft 365 accepted domain type does, how DBEB fits in, how to change it, and how to fix 550 5.4.1 and 5.4.14.

## Short answer

Use Authoritative when every recipient for the domain exists in Microsoft 365. It's the default, and it turns on Directory-Based Edge Blocking, which rejects unknown addresses with 550 5.4.1. Use Internal relay only when some recipients live on another mail system, such as on-premises Exchange during a migration, and you have an outbound connector to it.

Every domain you add to Microsoft 365 becomes an **accepted domain**, and each one has a type that decides what Exchange Online does with mail for addresses it doesn't recognize. Get it right and mail to made-up addresses is refused at the door. Get it wrong and you either bounce real colleagues on another mail system, or invite spam to every guessed address. This guide explains both types, when to use each, and how to change and troubleshoot them, as documented at the time of writing (October 2026).

## What is an accepted domain in Microsoft 365?

An accepted domain is any domain Exchange Online will send and receive mail for. Microsoft says: "When you add your domain to Microsoft 365 or Office 365, it's called an accepted domain" ([Microsoft Learn](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains)). You add the domain in the Microsoft 365 admin center. You then view it and set its type in the Exchange admin center (EAC).

The type matters only for recipients Exchange Online doesn't know. Mail for a mailbox, group or contact that exists in your tenant is delivered either way.

## What is the difference between Authoritative and Internal relay?

**Authoritative** means every recipient for the domain is in Microsoft 365. **Internal relay** (also called non-authoritative) means some recipients for the domain live on another mail system you control.

| | Authoritative | Internal relay |
|---|---|---|
| Default? | Yes (`DomainType` default) | No |
| Mail for known recipients | Delivered in Microsoft 365 | Delivered in Microsoft 365 |
| Mail for unknown recipients | Rejected: "Emails for unknown recipients are rejected" | Relayed to your own email server |
| Directory-Based Edge Blocking | On | Off |
| Needs an outbound connector | No | Yes, to the other mail server |
| Allows "Accept mail for all subdomains" | No | Yes |
| Typical use | Cloud-only tenants | Hybrid, staged migrations, coexistence, mail-enabled public folders |

The quotes and behavior come from Microsoft's [accepted domains article](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) and the [Set-AcceptedDomain reference](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-accepteddomain?view=exchange-ps), which lists Authoritative as "the default". A third type, ExternalRelay, exists only in on-premises Exchange.

## What is Directory-Based Edge Blocking (DBEB)?

Directory-Based Edge Blocking rejects mail for addresses that don't exist in your tenant before any filtering runs. Microsoft says that if an address doesn't exist, "the service blocks the message before filtering even occurs" and the sender gets this NDR ([Microsoft Learn](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-directory-based-edge-blocking)):

```
550 5.4.1 Recipient address rejected: Access denied
```

That's useful for security. Dictionary attacks against guessed addresses such as `info@`, `accounts@` or `j.smith@` are refused at the edge instead of reaching your filters. If all your recipients are in Exchange Online, Microsoft says "DBEB is already in effect, and you don't need to do anything."

DBEB has limits Microsoft calls out. In hybrid setups it only works when your MX points to Microsoft 365 first. On-premises dynamic distribution groups don't sync, so DBEB blocks them unless you create a matching mail contact. And Microsoft notes "infrequent instances" where unknown addresses are allowed through.

## What happens to mail for an unknown address on each type?

The difference shows up in what a sender sees. Take a message from outside to `old.employee@example.com`, an address that no longer exists in Microsoft 365, with the MX pointing at Microsoft 365.

| Step | Authoritative | Internal relay |
|---|---|---|
| Microsoft 365 receives the message | Looks up the recipient; not found | Looks up the recipient; not found |
| What happens next | DBEB rejects it before filtering | Relays it to your other mail server through the outbound connector |
| What the sender sees | `550 5.4.1 Recipient address rejected: Access denied` | Whatever your other server returns: delivery, or its own bounce |
| What happens without a connector | Not applicable | Microsoft says recipients not hosted in Microsoft 365 "won't be able to receive mail on your own email servers" |

On Internal relay, the other server becomes responsible for unknown addresses. The [Set-AcceptedDomain reference](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-accepteddomain?view=exchange-ps) says the external system "is responsible for generating NDRs for unresolved recipients." If that server accepts everything, or no longer exists, spam to guessed addresses has somewhere to go, and a misrouted relay can loop back to Microsoft 365.

## When should you use Internal relay?

Use Internal relay only when Microsoft 365 isn't the only place recipients for that domain live. Microsoft's own warning is direct: "You should not select this option if all of the recipients for this domain are in Microsoft 365 or Office 365."

Legitimate reasons:

- **Hybrid or coexistence.** Some mailboxes are on on-premises Exchange or another system, and they don't all exist in Microsoft 365 as mail users. (Microsoft says Authoritative can still work with recipients on your own servers if you add them to Microsoft 365 as recipients.) With Internal relay, Microsoft says you "must create a connector" from Microsoft 365 to that server, or its recipients won't get mail.
- **A staged migration.** For example, a [move from Google Workspace to Microsoft 365](https://iblockspam.com/blog/migrate-google-workspace-to-microsoft-365-email). Microsoft recommends you "temporarily set the accepted domain type to Internal Relay" until every recipient exists in Exchange Online, then switch to Authoritative ([Microsoft Learn](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/non-delivery-reports-in-exchange-online/fix-error-code-550-5-4-1-in-exchange-online)).
- **Subdomain routing.** The **Accept mail for all subdomains** option (`MatchSubDomains`, default `$false`) needs Internal relay. Microsoft says it's for hybrid setups where subdomains exist only on-premises, and recommends adding known subdomains as accepted domains instead ([Microsoft Learn](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/enable-mail-flow-for-subdomains)).
- **Public folders.** Microsoft says domains with recipient addresses on public folders need Internal relay, because "Directory-Based Edge Blocking cannot be used for public folders."

A bad reason is a catch-all mailbox. Our [catch-all guide](https://iblockspam.com/blog/catch-all-email-address-spam) explains why switching to Internal relay to catch every address mostly catches spam.

## How do you check and change the accepted domain type?

### In the Exchange admin center

1. Open the EAC at `https://admin.exchange.microsoft.com` and go to **Mail flow** > **Accepted domains**.
2. Read the **Domain Type** column. You can sort by it.
3. Select a domain to open its details.
4. Under **This accepted domain is**, select **Authoritative** or **Internal relay**.
5. If you select **Authoritative**, confirm that you want to enable Directory-Based Edge Blocking.
6. Select **Save**. Microsoft notes the **Save** button only appears for admins with permission to change the domain type.

### In Exchange Online PowerShell

```powershell
# See every accepted domain and its type
Get-AcceptedDomain | Format-Table Name,DomainType,MatchSubDomains,Default

# Make a cloud-only domain Authoritative (turns on DBEB)
Set-AcceptedDomain -Identity example.com -DomainType Authoritative

# Hybrid or migration: relay unknown recipients to your own server
Set-AcceptedDomain -Identity example.com -DomainType InternalRelay
```

`MatchSubDomains` and `OutboundOnly` are also on `Set-AcceptedDomain`. Microsoft uses `OutboundOnly` only for hybrid organizations whose on-premises side uses cloud email protection.

## How do you move a domain from Internal relay to Authoritative safely?

Do this at the end of a migration, or when you find a cloud-only domain left on Internal relay. Microsoft's DBEB procedure follows the same order.

1. **Confirm the domain is cloud-only.** No mailboxes, public folders or apps on another server should still receive mail for it.
2. **Make sure every recipient exists in Exchange Online.** That means users, shared mailboxes, groups, contacts and aliases. Anything missing will start bouncing with 550 5.4.1.
3. **Check connectors.** Remove or rescope any outbound connector that only existed to relay this domain to an old server. Our guide to [Microsoft 365 connectors](https://iblockspam.com/blog/microsoft-365-connectors-explained) covers the types.
4. **Check mail flow rules** that redirect mail for non-members to a single mailbox. Disable them.
5. **Switch the type** to Authoritative and confirm DBEB.
6. **Test from outside.** Send to a real address, which should arrive, and to a made-up address, which should bounce with 550 5.4.1.
7. **Watch message trace** for a few days. Our [message trace guide](https://iblockspam.com/blog/microsoft-365-message-trace) shows how to filter for failed deliveries.

## How do you fix 550 5.4.1 and 5.4.14 errors tied to accepted domains?

Start from the code in the bounce.

### 550 5.4.1 Recipient address rejected: Access denied

DBEB rejected the address. Microsoft's [fix article](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/non-delivery-reports-in-exchange-online/fix-error-code-550-5-4-1-in-exchange-online) lists these steps, in this order:

1. Check the spelling of the address in the NDR.
2. Find out whether one recipient or the whole domain is affected.
3. If the whole domain is affected, resync it: in **Mail flow** > **Accepted domains**, switch the type from Authoritative to Internal relay, then back to Authoritative.
4. For one on-premises mailbox in a hybrid setup, reset its SMTP proxy address to a temporary value and back. Allow up to 24 hours for DBEB to update.
5. For an on-premises mail-enabled public folder, sync it to Exchange Online. For an on-premises dynamic distribution group, create a mail contact with the same address.

Our [550 5.4.1 reference](https://iblockspam.com/smtp-errors/550-5-4-1) has the sender-side view, and our guide to [Microsoft 365 non-delivery reports](https://iblockspam.com/blog/microsoft-365-ndr-message-not-delivered) covers reading the rest of the NDR.

### 5.4.14 Hop count exceeded - possible mail loop

Exchange Online accepted the message but couldn't route it, so it went round in a loop. Microsoft says 5.4.14 is "likely caused by accepted domain configuration issues", or by misconfigured connectors in hybrid setups ([Microsoft Learn](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/non-delivery-reports-in-exchange-online/fix-error-code-5-4-6-through-5-4-20-in-exchange-online)). Its first check is whether the recipient's domain is set up as an Authoritative accepted domain. In hybrid, check that the connector to on-premises uses smart host routing, not DNS routing, or rerun the Hybrid Configuration Wizard. The [554 5.4.6 reference](https://iblockspam.com/smtp-errors/554-5-4-6) covers loops in general.

## Does a filtering gateway change the accepted domain type?

No. A gateway changes where your MX record points. The accepted domain type is about where recipients live. If every recipient is in Microsoft 365, keep the domain Authoritative. Then configure the inbound connector from the gateway, Enhanced Filtering for Connectors, and a rule that only accepts mail from the gateway. Our guide to [using a third-party spam filter with Microsoft 365](https://iblockspam.com/blog/microsoft-365-third-party-spam-filter-enhanced-filtering) walks through those steps. iBlockSpam's [Microsoft 365 setup](https://iblockspam.com/platforms/microsoft-365) uses the same pattern: an inbound Partner connector with Enhanced Filtering for Connectors.

## Next steps

1. Run `Get-AcceptedDomain` and list any domain set to Internal relay.
2. For each one, confirm there's still another mail system behind it. If not, follow the checklist above and switch it to Authoritative.
3. Send a test to a made-up address and confirm the 550 5.4.1 bounce.
4. Check where each domain's MX points with the [MX Lookup](https://iblockspam.com/tools/mx-lookup).

Browse more [setup guides](https://iblockspam.com/blog/topic/setup).

## Frequently asked questions

### What is the default accepted domain type in Exchange Online?

Authoritative. Microsoft's Set-AcceptedDomain reference lists Authoritative as the default value of DomainType. Microsoft also says that if all recipients for your domain are in Exchange Online, Directory-Based Edge Blocking is already in effect and you don't need to do anything.

### Does setting a domain to Internal relay turn off Directory-Based Edge Blocking?

Yes, in effect. Microsoft ties DBEB to the Authoritative type: selecting Authoritative asks you to confirm that you want to enable it. With Internal relay, Microsoft 365 delivers mail for known recipients and relays the rest to your other mail server, so unknown addresses are no longer rejected at the edge.

### Can I use Internal relay to build a catch-all mailbox in Microsoft 365?

Some admins do, combining Internal relay with a redirect rule, but Microsoft says not to select Internal relay if all recipients for the domain are in Microsoft 365. It removes edge rejection of invalid addresses, so every guessed address reaches filtering. Use real aliases or a shared mailbox for addresses you actually need.

### How long does a change to the accepted domain type take to work?

Microsoft gives no general timing for the type change itself, so test after saving. For hybrid recipients, Microsoft says to allow up to 24 hours for Directory-Based Edge Blocking to fully update after changes to an on-premises mailbox. Test with a made-up address from an outside account before and after.

### Should I change the accepted domain type when I add a spam filtering gateway?

Usually not. A filtering gateway changes where your MX record points, not where your mailboxes live. If every recipient is in Microsoft 365, keep the domain Authoritative so invalid addresses are still rejected, and set up the inbound connector and Enhanced Filtering for Connectors as the gateway's setup guide describes.

## Sources

- [Microsoft Learn: Manage accepted domains in Exchange Online](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains)
- [Microsoft Learn: Use Directory-Based Edge Blocking to reject messages sent to invalid recipients](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-directory-based-edge-blocking)
- [Microsoft Learn: Set-AcceptedDomain](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-accepteddomain?view=exchange-ps)
- [Microsoft Learn: Enable mail flow for subdomains in Exchange Online](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/enable-mail-flow-for-subdomains)
- [Microsoft Learn: Fix error code 550 5.4.1 in Exchange Online](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/non-delivery-reports-in-exchange-online/fix-error-code-550-5-4-1-in-exchange-online)
- [Microsoft Learn: Fix NDR error 5.4.6 or 5.4.14 in Exchange Online](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/non-delivery-reports-in-exchange-online/fix-error-code-5-4-6-through-5-4-20-in-exchange-online)

## Free tools for this guide

- [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts.
- [SMTP Error Code Lookup](https://iblockspam.com/tools/smtp-error-codes): Paste a bounce or type a code like 550 5.7.26: plain-English meaning, likely causes and fixes, with sources.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.

---

Source: iBlockSpam, https://iblockspam.com/blog/microsoft-365-accepted-domains-authoritative-internal-relay (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt