Microsoft 365 domain
Shows tenant verification and service setup. It also affects sign-in names and domain-removal dependencies. Verification alone does not set Exchange routing behavior.
Exchange namespaces, recipient authority, routing, DNS, and evidence
Exchange Online Accepted Domains Documentation Guide
Treat every email namespace as a governed mail-flow dependency. Record why the domain exists, whether Exchange Online is authoritative or relays unresolved recipients, which systems own delivery, how MX and connectors route messages, whether valid recipients are represented, how senders authenticate, and what evidence proves a safe change.
Authoritative and internal-relay decisionsDBEB, connectors, recipients, subdomains, and hybrid routingDNS, SPF, DKIM, DMARC, testing, ownership, and retirement
Operating objective
Know exactly where Exchange should deliver, reject, or relay mail for every namespace
An accepted domain tells Exchange Online that the tenant receives messages for an SMTP namespace. It is not, by itself, proof that the domain is verified in Microsoft 365, that MX points to Microsoft 365, that all recipients exist in the cloud, that a connector can reach a downstream system, or that SPF, DKIM, and DMARC are correct. Those are related controls with separate evidence.
Authoritative means Exchange Online is responsible for all recipients in the namespace and returns non-delivery responses for unresolved addresses. Internal relay means Exchange Online receives the message, delivers to known cloud recipients, and routes unresolved recipients to an email system under the organization’s control. Exchange Online does not offer the on-premises-only external-relay type.
Documentation should reconcile the Microsoft 365 domain record, Exchange accepted-domain object, all recipient proxy addresses, inbound gateway, outbound senders, connectors, transport rules, hybrid configuration, and public DNS. One export is a starting point, not an operating record.
Control statement: Do not change domain type, MX, connector scope, subdomain matching, or send/receive restrictions until the recipient population, next hop, failure behavior, test cases, rollback trigger, and responsible owners are documented.
Keep control planes separate
Six records must agree before mail flow is considered healthy
Exchange accepted domain
Defines authoritative or internal-relay handling and related cloud flags. Capture the object identity and exported settings, not just a screenshot.
Recipients and aliases
Determines which SMTP addresses Exchange recognizes. Reconcile users, shared/resource mailboxes, groups, contacts, mail users, public folders, and synchronized objects.
Inbound and downstream routes
MX, third-party gateways, connectors, certificates, smart hosts, route-all settings, and hybrid topology determine where the message actually travels.
Sender authorization
SPF, DKIM, DMARC, application relays, marketing platforms, devices, and partner senders govern spoofing resistance and delivery reputation.
Ownership and lifecycle
Business purpose, registrar/DNS control, technical owners, acquisitions, divestitures, aliases, parked status, renewal, incident escalation, and retirement must be explicit.
Domain-type decision record
Choose behavior from the recipient boundary—not from migration habit
| Scenario | Expected type or flag | Required dependencies | What to test | Evidence and exit condition |
|---|---|---|---|---|
| All production recipients are represented in Exchange Online | Authoritative | Complete recipient directory; correct MX/gateway path; no unresolved downstream population. | Valid users, aliases, groups and resources deliver; invented recipients receive the expected rejection/NDR; message trace is clean. | Recipient reconciliation, accepted-domain export, MX path, traces, NDR sample, and owner approval. |
| Shared namespace during migration or coexistence | Internal relay | Known cloud recipients plus a working downstream connector/route for unresolved recipients; documented next-hop ownership. | Cloud recipient, downstream recipient, unknown recipient, reply path, loop protection, TLS, and failure handling. | Population split, connector validation, route diagram, test matrix, migration completion criteria, and rollback. |
| Hybrid domain represented by synchronized mail-enabled objects | Usually internal relay during coexistence; change only from the validated hybrid design | Directory synchronization, remote recipients/mail users, connectors, certificate/TLS, centralized or decentralized routing decision. | Both directions, free/busy dependencies where applicable, expansion targets, public folders, application relay, and trace correlation. | Hybrid configuration, sync health, object samples, connector state, route owner, and topology review. |
| Migration population is fully represented before cutover | Temporary internal relay followed by deliberate authoritative cutover | All valid SMTP addresses present and replicated; MX to Microsoft 365 when DBEB is expected; downstream exception plan closed. | DBEB behavior, aliases, contacts, groups, on-premises dynamic groups/workarounds, legacy applications, and negative-address test. | Completion certificate, pre/post exports, trace results, change window, acceptance criteria, and rollback trigger. |
| Legacy domain may receive but must not originate new mail | Document whether SendingFromDomainDisabled is appropriate | Validated business/legal need, recipient aliases still present, notification plan, exception inventory, supported client/application behavior. | Inbound alias delivery; blocked sender scenarios; approved exceptions; replies and automated systems. | Risk approval, before/after test, exception owner, monitoring query, and retirement date. |
| Delivery to a namespace must be disabled | Document whether SendingToDomainDisabled is appropriate | Incident/change authority, business impact approval, alternate route or communication plan, and tested recovery. | Expected rejection, internal/external sender behavior, affected rules/connectors, and restoration. | Incident/change ID, timestamps, test message IDs, business signoff, and restoration evidence. |
| Subdomains should use inherited relay handling | Internal relay with MatchSubDomains only when explicitly designed | Known subdomain owners, recipient/route model, connector coverage, sender-authentication boundaries, and wildcard risk review. | Named subdomains, unexpected subdomain, most-specific connector selection, loops, and DNS paths. | Approved namespace list, flag export, connector precedence proof, negative tests, and review date. |
| Domain retirement or tenant transfer | Remove only after all dependencies are cleared | Alternative admin sign-in, moved UPNs/proxy addresses, mailboxes, contacts, groups/Teams, apps, DNS, connectors, rules, and retention decisions. | Inbound/outbound mail after transition, old aliases, external systems, sign-in, rollback, and removal result. | Dependency-zero report, DNS/registrar plan, communications, final traces, removal record, and failback window. |
Twelve-step operating runbook
Inventory, reconcile, change, validate, and preserve rollback evidence
Define the business outcome
Record whether the request is onboarding, migration, acquisition, shared namespace, hybrid operation, sender-only/receive-only use, incident containment, brand retirement, or tenant transfer. Name the business and technical owners.
Export before state
Capture Get-AcceptedDomain output and detailed properties, Microsoft 365 domain state, current connectors, mail-flow rules, recipient counts, relevant hybrid configuration, and DNS records. Store exact timestamps and tenant identity.
Reconcile the recipient population
Query every proxy address across users, shared/resource mailboxes, Microsoft 365/distribution/mail-enabled security groups, contacts, mail users, synchronized objects, and relevant public folders. Find duplicates and unresolved legacy addresses.
Map inbound mail
Trace MX through any third-party security gateway to Exchange Online. Record hostnames, priorities, certificates, TLS expectations, filtering bypasses, IPs, connector validation, Enhanced Filtering considerations, and operational owners.
Map unresolved-recipient routing
For internal relay, identify the exact downstream system and connector. Record connector selection, smart host/DNS route, scope, wildcard or all-accepted-domain behavior, loop prevention, failure queue, monitoring, and escalation.
Review domain flags
Validate DomainType and explicitly record MatchSubDomains, OutboundOnly, SendingFromDomainDisabled, and SendingToDomainDisabled when present. Do not copy values between tenants without understanding topology and coexistence purpose.
Reconcile DNS and sending sources
Capture registrar, DNS provider, nameservers, TTL, MX, SPF, DKIM selectors, DMARC, Autodiscover and required service records. Reconcile applications, devices, vendors, bulk senders, and indirect SPF includes with accountable owners.
Assess DBEB readiness
When all valid recipients should exist in Exchange Online, verify they are represented and replicated before making the domain authoritative. Remember that DBEB requires mail to reach Microsoft 365 first and has special hybrid/public-folder considerations.
Design tests and rollback
Predefine valid cloud, valid downstream, alias, group, resource, application, reply, unknown-recipient, subdomain, TLS, and outage tests. Record expected SMTP/NDR results, trace points, abort thresholds, rollback command, and restoration owner.
Make one controlled change
Use least-privileged Exchange administration, an approved ticket, and a maintenance window appropriate to risk. Preserve exact commands or GUI actions and after-state exports. Avoid simultaneous MX, connector, domain-type, and recipient changes.
Validate both delivery paths
Test external-to-cloud, external-to-downstream, cloud-to-downstream, downstream-to-cloud, outbound and reply behavior. Correlate message IDs, traces, gateway logs, connector events, NDRs, headers, and timestamps rather than relying on a single inbox.
Close and schedule review
Reconcile desired and actual state, close exceptions, attach evidence, update diagrams and owners, record metrics and monitoring, confirm URL/DNS/registrar lifecycle, and set the next review or migration exit milestone.
Recipient authority and DBEB
Authoritative cutover is an address-completeness decision
What DBEB does
Directory-Based Edge Blocking rejects messages for invalid recipients at Microsoft 365’s service edge before later filtering layers. For a fully cloud-hosted authoritative domain, it reduces backscatter and processing for nonexistent addresses—but only addresses known to the service are treated as valid.
Why internal relay persists
During coexistence, unresolved recipients must continue to a controlled downstream system. Internal relay is not a permanent substitute for recipient inventory. Without a valid connector and next hop, it can create loops, queues, ambiguous NDR ownership, or unexpected delivery.
Cutover gate
Before authoritative conversion, prove all valid SMTP addresses are represented in Exchange Online, replication is complete, MX reaches Microsoft 365 when DBEB is expected, special public-folder/dynamic-group cases are addressed, and positive/negative tests meet acceptance criteria.
Migration safeguard: Microsoft’s DBEB guidance deliberately uses internal relay while valid recipients are populated and changes to authoritative only after the directory is ready. Preserve the change window, population evidence, negative-recipient test, and rollback path.
DNS, authentication, and connector evidence
Document the route and the right to send—not just the accepted-domain object
| Control | Question | Failure mode | Evidence to retain | Review action |
|---|---|---|---|---|
| MX and inbound gateway | Where does Internet mail first arrive, and who owns that service? | Bypass, outage, filtering gap, split delivery, or DBEB not operating where assumed. | DNS result, priorities, gateway tenant/config, connector, TLS/certificate, trace, owner, and diagram. | Test each published MX route and confirm the observed header/trace chain. |
| Connector selection | Which connector wins for each recipient domain? | A broad all-accepted-domain or wildcard connector captures traffic intended for a more specific route, or a specific connector silently changes the next hop. | Connector scopes, exact domains, wildcards, all-domain settings, validation results, smart hosts, and route tests. | Evaluate exact-domain, all-accepted-domain, then wildcard behavior and document the selected path. |
| SPF | Which systems may send using the domain? | Unauthorized sources pass through stale includes, legitimate sources fail, or DNS lookup complexity breaks evaluation. | TXT record, flattened sender inventory, include owners, validation output, headers, and change record. | Remove stale sources and align each authorized platform with an owner and retirement date. |
| DKIM | Which platform signs and where are selectors published? | Unsigned or misaligned mail weakens DMARC and reputation; stale selectors obscure ownership. | Exchange/third-party signing state, selector CNAME/TXT, signed headers, key rotation owner, and last test. | Verify both selectors/platforms and a real signed message for every active sender class. |
| DMARC | What alignment and enforcement outcome is intended? | Monitoring never progresses, legitimate sources remain misaligned, reports go unread, or reject is enabled without inventory. | Policy, alignment modes, aggregate/forensic destinations, report workflow, exceptions, and staged-enforcement approval. | Use reports to reconcile senders; move policy only through measured acceptance gates. |
| Registrar and DNS authority | Who can renew, transfer, recover, and change the domain? | Mail-flow teams cannot restore DNS, attackers change routing, or a domain expires. | Registrar/DNS providers, role holders, MFA/recovery controls, renewal status, lock state, and escalation contacts. | Review privileged access and recovery paths independently from Exchange administration. |
Top accepted-domain risks and misconfigurations
Changes that cause rejection, silent relay, loops, spoofing exposure, or lockout
Authoritative before recipient completeness
Valid downstream or unsynchronized addresses are rejected because Exchange Online believes the cloud directory is complete.
Internal relay without a controlled next hop
Unresolved recipients queue, loop, route to an obsolete system, or generate NDRs in an unexpected place.
DBEB assumptions ignore MX path
Mail reaches a different gateway first, so edge rejection and trace behavior do not match the documented design.
Connector precedence is undocumented
Exact-domain, all-accepted-domain, and wildcard scopes produce a different route from the one operators expect.
MatchSubDomains is treated as harmless
Unexpected subdomains inherit mail-flow behavior without recipient, DNS, connector, sender, or owner review.
Recipient aliases are missed
Users appear migrated while shared mailboxes, groups, contacts, resources, public folders, or application addresses still depend on the domain.
Accepted means authenticated
Teams document the Exchange object but leave SPF, DKIM, DMARC, vendors, devices, or bulk senders unmanaged.
Send/receive disable flags lack runbooks
Legacy-domain or incident controls block valid business traffic with no exception list, monitoring, or tested restoration.
Domain removal starts with DNS
MX or nameservers move before identities, aliases, groups, apps, connectors, rules, and rollback dependencies are cleared.
No evidence beyond screenshots
Operators cannot compare objects, reproduce the change, correlate trace results, or prove the correct tenant and timestamp.
Evidence and operating cadence
Make namespace governance measurable and audit-ready
Configuration evidence
- Accepted-domain summary and detailed properties
- Microsoft 365 verification and dependency state
- Recipient counts by type and source of authority
- Connector, rule, hybrid, gateway, and certificate evidence
- MX, SPF, DKIM, DMARC, DNS provider, and registrar record
Change and validation evidence
- Request, approval, business outcome, and owners
- Before/after exports and exact commands/actions
- Positive and negative test matrix
- Message IDs, traces, headers, gateway logs, NDRs, and timestamps
- Rollback trigger, execution record, exceptions, and closure
Useful metrics
- Domains with complete owner and purpose records
- Authoritative domains with reconciled recipient populations
- Internal-relay domains with tested downstream routes
- Domains with passing SPF/DKIM and monitored DMARC
- Open exceptions, stale sending sources, and overdue reviews
Daily/event-driven
Investigate rejection spikes, queue/connector failures, DNS alerts, security incidents, and migration cutovers.
Weekly
Review route failures, unresolved-recipient trends, certificate warnings, sender exceptions, and open changes.
Monthly/quarterly
Reconcile domains, recipients, owners, connectors, senders, DNS/authentication, parked/legacy use, and review dates.
Lifecycle events
Require a full dependency and failback review for acquisition, divestiture, tenant migration, domain transfer, or retirement.
Authoritative resources and related guidance
Connect domain ownership to recipient, DNS, authentication, and change controls
Microsoft implementation sources
IT Perfection ecosystem
Frequently asked questions
Exchange Online accepted domains FAQ
What is the difference between a verified Microsoft 365 domain and an Exchange accepted domain?
Verification proves control of the domain to Microsoft 365 and enables service configuration. The Exchange accepted-domain object defines how Exchange Online handles the SMTP namespace. MX, recipients, connectors, SPF, DKIM, DMARC, and business ownership remain separate dependencies.
When should a domain be authoritative?
When Exchange Online is responsible for all recipients in the namespace and the directory represents every valid SMTP address that must receive mail. Validate aliases, groups, resources, shared mailboxes, contacts, synchronized objects, public-folder cases, and negative-recipient behavior before conversion.
When is internal relay appropriate?
During a controlled shared-namespace, migration, or hybrid design where some recipients are outside Exchange Online but under the organization’s control. Internal relay needs a documented connector/next hop, monitoring, loop prevention, failure ownership, testing, and an exit condition.
Does an authoritative domain automatically enable useful invalid-recipient rejection?
DBEB is designed to reject invalid recipients at the Microsoft 365 edge for fully cloud-hosted domains. Mail must route through Microsoft 365 first, all valid recipients must be represented, and hybrid/public-folder exceptions must be evaluated. Test rather than assume.
Does MatchSubDomains replace explicit subdomain documentation?
No. It broadens behavior for subdomains and therefore increases the need to document namespace owners, recipient and connector routes, DNS, authentication, negative tests, and change boundaries. Enable it only for an intentional design.
What must be cleared before removing a custom domain?
At minimum, move UPNs and proxy addresses from users, administrators, shared/resource mailboxes, contacts, Microsoft 365 groups, Teams-connected groups, distribution lists, and other dependencies; update apps, connectors, rules, DNS, mail-flow, retention and communications; then test and preserve a rollback window.
Make every mail namespace accountable
Build accepted-domain records that prevent outages and accelerate recovery
IT Perfection helps Orange County and Southern California organizations inventory Exchange Online domains, reconcile recipients and aliases, document authoritative and internal-relay behavior, validate DBEB and connectors, map DNS and sender authentication, improve migration and retirement controls, and preserve evidence for Microsoft 365 operations, security, and compliance.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience. This guide is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, legal/compliance review, DNS/registrar review, licensing review, migration plan, or tested recovery plan.
