To set up DMARC for a Microsoft 365 custom domain, establish the domain's sending routes, configure the appropriate SPF policy, enable custom-domain DKIM and verify an aligned result on received mail. Publishing a DMARC TXT record is one step in that sequence.
This guide covers custom-domain sending through Microsoft 365. Confirm the Microsoft cloud environment and any hybrid, relay or outbound gateway arrangements before using the examples. Applications sending outside Microsoft 365 need their own supported authentication configuration, even when they use the same visible From domain.
Confirm the domain, DNS host and Microsoft environment
Confirm the custom domain, its authoritative DNS host, the Microsoft 365 environment and the permission needed to manage signing. Save the existing SPF, DKIM and DMARC records before changing them.
Do not confuse public DNS administration with the tenant's domain list. The registrar may also be the DNS host, but it need not be. Check the delegated name servers before editing a zone.
List every route that uses the domain. In particular, distinguish ordinary Exchange Online sending from applications using relay, direct send, another SMTP provider or an outbound gateway. The product name alone does not identify the final signer.
Map employee mail and application mail
A move to Microsoft 365 does not automatically move the invoicing application, website contact form or recruitment platform. Those services may still display your domain while sending through a different provider.
Ask for a simple service map: employee mail, application mail and outsourced communications, with an owner beside each route. Require a received-message test for critical flows such as password resets and billing notices. The deliverable is working, accountable communication, not a screenshot of an enabled tenant setting.
Configure the applicable SPF policy
Microsoft's documented example for a domain sending **only through its standard Microsoft 365 service or GCC** is:
v=spf1 include:spf.protection.outlook.com -allThis is a scoped example, not a replacement for an existing mixed-service policy. Microsoft documents different include domains for GCC High/DoD and for its service operated by 21Vianet. Follow the current instructions for your environment.
Publish one applicable SPF policy at the evaluated domain. If a valid policy already exists, review and update that policy rather than adding another SPF record. Include only justified sending permissions and check the full dependency path against SPF limits.
Publish both tenant-generated DKIM CNAMEs
Microsoft 365 custom-domain DKIM uses two CNAME records. Obtain their exact values from the Defender portal's DKIM configuration or Exchange Online PowerShell. Do not build a target from an old naming template: Microsoft documents more than one target format, and generated values can contain a tenant-specific component.
In an authorised Exchange Online PowerShell session, this read-only check retrieves the configured targets:
Get-DkimSigningConfig -Identity example.com |
Format-List Enabled,Status,Selector1CNAME,Selector2CNAMEIf the domain has no signing configuration, use Microsoft's documented initial-configuration procedure before expecting those properties to exist. In the Defender portal, the relevant area is Email authentication settings, then DKIM.
Publish **both** generated CNAME records, verify their public answers and enable custom-domain signing through the supported tenant procedure. A CNAME record delegates verification-key management; it is not a request to paste a private key or an invented TXT key.
Check DNS editor behaviour carefully. A panel that appends the zone name can turn a fully entered hostname into a duplicated name. Preserve the exact published owner and target values in the change record.
Add the intended DMARC policy and reporting destination
If the domain is beginning a monitored deployment, an illustrative record at _dmarc.example.com is:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comThe example assumes a working report destination at the same domain. Replace it with the approved address and verify collection. External destinations can require additional reporting permission. Do not weaken an existing enforcement policy merely to match this example.
Use the record creation guide for the publishing and verification sequence, and the DMARCbis readiness guide when reviewing legacy rollout settings.
Verify messages after the full sending route
Send a controlled message to a separate external recipient and inspect the original message there. Record the visible From, SPF-evaluated identity, every relevant DKIM d= domain and the trusted DMARC result.
Repeat the test through critical applications and any final outbound gateway. If the visible From is your custom domain but the only passing signature uses an unrelated tenant identity, investigate custom-domain signing and the actual route. If a gateway modifies signed content, verify the result after that gateway.
- Check: SPF policy; Evidence to retain: Authoritative answer and evaluated sending route
- Check: DKIM delegation; Evidence to retain: Both exact CNAMEs and tenant configuration state
- Check: Live signing; Evidence to retain: Received signature and trusted verification result
- Check: DMARC; Evidence to retain: A passing aligned path and observed policy context
- Check: Business coverage; Evidence to retain: Tests for the applications the organisation actually uses
- Record acceptance and ongoing ownership
Approve the implementation against a named service inventory. Record the change approver, DNS ownership, critical-flow results and remaining exceptions. A tenant's valid signing status does not demonstrate that every external application is covered.
Keep the cloud environment explicit in operating documentation. A standard-cloud example must not quietly become a government-cloud instruction. Assign periodic checks for abandoned services and delegated selectors as well as failures in current traffic.
Retain the ability to restore the prior approved state when a change fails, while preserving the incident evidence. A final review should explain the remaining risks of compromised accounts and authenticated malicious mail, rather than promising that a DMARC pass makes every message safe.
The practical takeaway
The setup is complete when the published records, tenant signing state, received-message identities and reporting path agree. Retain the service inventory and exceptions with the change record; they are the baseline for the next application or gateway change.
Separate employee-mail evidence from a CRM exception
Written case M365-01 assumes employee mail from staff@example.org has a trusted passing DKIM signature with d=example.org. The billing CRM uses billing@example.org, but its only recorded signature is from an unrelated provider domain and its SPF result is unknown. Employee-mail evidence does not establish the CRM result, and the partial CRM evidence cannot justify a complete DMARC verdict. The CRM owner must identify its supported aligned identity and collect a controlled external message before the domain owner evaluates enforcement readiness. These are fictional identities and outcomes; no tenant, DNS change or mail send occurred.