Provider guides
DMARC setup for Microsoft 365
Configure Exchange Online SPF and DKIM, then move a custom domain safely toward DMARC enforcement.
What Microsoft 365 handles
Exchange Online handles mailbox delivery and can sign outbound mail for accepted custom domains once DKIM is enabled.
The Microsoft 365 tenant does not necessarily host authoritative DNS. Use the domain setup information for routing, then publish records at the actual DNS host.
Configure SPF without creating a second record
For domains that send only through Exchange Online, Microsoft documents the include spf.protection.outlook.com. Keep one SPF record and add other legitimate senders deliberately.
A domain must publish one SPF record. If another service already sends mail, merge its authorization into the existing record and evaluate the complete DNS lookup count.
Illustrative structure
v=spf1 include:provider.example include:approved-sender.example -allEnable and confirm DKIM
Microsoft supplies two selector CNAME targets for each custom domain. Publish both, then enable DKIM for the domain in the tenant. Avoid hard-coding a changing admin-screen path; use the current DKIM settings for the accepted domain.
Send from the custom domain and confirm a passing DKIM result with the expected signing domain. Initial publication may take time to become visible across DNS.
DKIM is selector-specific. Confirm the selector shown by the provider resolves in public DNS and then send a message to a mailbox where you can inspect Authentication-Results.
Add DMARC on top
DMARC checks whether SPF or DKIM passes and aligns with the domain visible in the From address. Start with reporting while legitimate services are still being identified.
Move to quarantine and reject only after reports show that real senders authenticate correctly. Use pct for a controlled rollout, and review the sp policy when subdomains send mail.
Monitoring example
v=DMARC1; p=none; rua=mailto:[email protected]Enforcement target
v=DMARC1; p=reject; pct=100Account for third-party senders
Printers, business applications and SaaS senders may relay through Microsoft 365 or send independently. Document the path for each source and prefer aligned DKIM where supported.
- List marketing, invoicing, support, recruitment and transactional systems.
- Confirm whether each service supports aligned DKIM, aligned SPF, or both.
- Use a dedicated subdomain where separation improves control.
- Do not authorize an entire provider when a narrower account-specific option exists.
Typical mistakes
Provider authentication covers that provider, not every system using the same visible From domain.
- Leaving the tenant's default domain as the DKIM signing identity for a custom From domain
- Publishing selector records at the mail provider instead of the authoritative DNS host
- Adding a second SPF record for a marketing platform
- Assuming Microsoft 365 authentication covers devices, applications or third-party platforms
Verify the result and keep it healthy
Check DNS from outside the provider dashboard, send representative messages and inspect both SPF and DKIM alignment. Then monitor aggregate DMARC reports as real traffic arrives.
Orillon groups sender evidence into recognizable services, explains failures and guides policy forward without treating a DNS record as proof that mail is protected.
- Confirm MX points to the intended Exchange Online protection host
- Resolve both Microsoft-provided DKIM selectors
- Inspect Authentication-Results on test messages
- Review DMARC reports before increasing policy