THE CONNECTIONS BEHIND YOUR BUSINESS
Understanding MX, SPF, DKIM and DMARC for Microsoft 365
Check Microsoft 365 routing and authentication with tenant-specific DNS values, alignment and safe rollout steps.
Microsoft 365 uses DNS records to route mail and authenticate sending domains. Understand the different roles of MX, SPF, DKIM and DMARC, then validate the values required by your own tenant.
Start here: routing and authentication solve different problems
MX directs incoming email. SPF authorizes envelope senders, DKIM signs messages, and DMARC checks whether a passing SPF or DKIM identity aligns with the visible From domain. Authentication does not guarantee an Inbox placement.
Use this guide for Microsoft 365 configuration. The provider-neutral SPF/DKIM/DMARC guide explains the concepts; this one focuses on tenant-specific records and validation.
1. Confirm the domain and all senders
Inventory Exchange Online, website forms, billing systems, newsletters and third-party services sending as your domain. Confirm the domain is configured in the correct tenant. Keep existing records and an approved rollback plan before editing DNS.
Use the admin center’s domain setup instructions for the exact MX target. Do not infer it from a company name or copy a sample target into production.
2. Review one SPF policy
For a domain sending only through standard Microsoft 365 commercial services, Microsoft’s documentation commonly uses include:spf.protection.outlook.com. Your complete policy must also account for any other authorized senders and your actual environment.
Do not add a second v=spf1 record. Review the DNS lookup limit and vendor instructions before merging policies. An SPF pass authenticates the envelope domain; it may not align with the visible From domain.
3. Publish the actual DKIM selector values
Open the custom domain’s DKIM configuration in Microsoft Defender and copy both CNAME records it provides. Newer tenant configurations can use dynamically partitioned target names; do not construct selector targets from an old tutorial.
Publish the records as ordinary DNS CNAMEs, verify their resolution, then enable signing through the supported domain configuration. A visible selector record alone does not prove that outgoing messages are being signed.
Resolve-DnsName -Name selector1._domainkey.your-domain.example -Type CNAME
Resolve-DnsName -Name selector2._domainkey.your-domain.example -Type CNAMEExpected result: both answers match the values displayed for your domain in Microsoft 365. If not, check authoritative DNS, copied names, suffix duplication and caching. Do not guess a replacement target.
4. Introduce DMARC with visibility
After SPF and DKIM are understood, publish a reviewed DMARC policy at _dmarc. A monitoring policy such as p=none provides observation without requesting quarantine or rejection. It does not fix missing authentication.
Use a reporting address or service you are authorized to operate and consider report privacy. Review all legitimate sending streams before stronger enforcement; an immediate reject policy can disrupt real business mail.
5. Validate a received message
Send a harmless message to an external account you control. Inspect the receiving system’s trusted Authentication-Results: identify SPF result and domain, DKIM result and d= domain, and DMARC result for the visible From domain.
A pass from an unrelated domain is not necessarily aligned. DMARC can pass through either aligned SPF or aligned DKIM; both are not mandatory. Forwarding can alter the picture, so compare a direct test with a forwarded message.
If DNS is correct but signing or alignment fails, preserve sanitized headers and ask the tenant administrator to check the sending path. Do not weaken filtering or create broad allow rules to hide the symptom.
Official references
Documentation checked 2026-10-18. Examples use reserved names and addresses; replace placeholders only for systems you are authorized to manage. Interfaces and included features depend on your provider and account.