DMARC (RFC 7489) tells receiving mail servers what to do when a message claiming to be from your domain fails SPF or DKIM. You publish exactly one DMARC record at `_dmarc.<your-domain>`, regardless of which ESP you use — DMARC is a domain-level policy, not a per-sender configuration. Microsoft 365 doesn't run DMARC for you, but their SPF + DKIM setup is what makes your DMARC checks pass.
Start every domain at `p=none` with a `rua` (aggregate report) address pointing somewhere you actually read. Watch the reports for two to four weeks to confirm 100% of legitimate mail is aligned, then progress to `p=quarantine` and finally `p=reject`. Skipping the monitoring step is the single most common way founders accidentally block their own mail.
Publish these DNS records
Add the following record(s) to your domain's DNS zone. Most registrars (Cloudflare, Route 53, Namecheap, GoDaddy) accept values exactly as shown.
- Type
TXT- Host
_dmarc- Value
v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com
- Microsoft's default DKIM uses relaxed alignment, which works with the default `adkim=r`. Don't tighten to strict unless you've confirmed every legitimate sender aligns.
- Microsoft 365 publishes its own aggregate reports as the receiver — your `rua` address will receive both inbound (Microsoft as receiver, reporting on mail TO you) and outbound (third parties reporting on mail FROM you) reports.
Where in Microsoft 365
The DMARC configuration lives in Microsoft 365 Defender → Policies & rules → Threat policies → Email authentication settings.
Verify the records
Once published, run the DMARC Checker on your apex domain to confirm the record parses, reporting URIs are valid, and the policy is what you intended.
dig +short TXT _dmarc.your-domain.comCommon pitfalls
- Forgetting to enable DKIM signing in the Defender portal after publishing the CNAMEs is the single most common Microsoft 365 setup error.
- Older Microsoft documentation references `selector1` only — both `selector1` and `selector2` are required as of 2023.
- If you use Microsoft 365 as your inbound mail (MX) and a separate ESP for marketing, the SPF record above is for outbound through Microsoft only. Marketing mail needs its own `include:` merged in.
- The `<tenant>` value is your initial `*.onmicrosoft.com` name (set when the tenant was created), not your custom domain. To confirm it, run `Get-DkimSigningConfig -Identity your-domain.com | Format-List Selector1CNAME,Selector2CNAME` in Exchange Online PowerShell — the right-hand side of those values is exactly what to paste into DNS.
- If you previously published `selector1._domainkey` as a TXT record (some old guides used raw keys), delete it before publishing the CNAME. A CNAME at a host with any other record type is invalid and DNS providers will reject or silently drop one of them.
Frequently asked questions
What DMARC record should I use with Microsoft 365?
Start with: v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com — published at _dmarc.your-domain.com. The p=none policy collects aggregate reports without affecting mail delivery. Replace the rua= address with one you read. Omit adkim= and aspf= to leave alignment at the relaxed default, which is appropriate for Microsoft 365 because Exchange Online uses relaxed DKIM alignment by default.
How does DMARC work with Microsoft 365's two DKIM selectors?
Microsoft 365 rotates between selector1 and selector2 for signing. Both selectors sign with the same domain (your custom domain), so DKIM alignment with the From: header domain passes regardless of which selector is active. You do not need to do anything special in your DMARC record to accommodate the rotation — the alignment check is against the d= domain in the signature, not the selector.
Should I use strict or relaxed DMARC alignment for Microsoft 365?
Relaxed (the default, equivalent to adkim=r; aspf=r) is appropriate for most Microsoft 365 deployments. Strict alignment requires the From: header domain to exactly match the DKIM d= or SPF Return-Path domain. Some Microsoft 365 configurations use a subdomain in the Return-Path that doesn't match the From: apex domain — strict SPF alignment would fail these. Unless you have a specific reason for strict alignment, leave it at the default.
Does Microsoft 365 send DMARC aggregate reports?
Yes. Microsoft (Outlook, Hotmail, Live) generates aggregate DMARC reports for mail received at Microsoft-hosted addresses. Your rua= address will receive XML reports from Microsoft within 24 hours of publishing your DMARC record. Microsoft is one of the most consistent report senders — expect daily reports as long as there is inbound mail volume to your domain.
My DMARC reports show Microsoft 365 mail as failing — what does that mean?
If your own Microsoft 365 outbound mail appears as failing DMARC in reports, the most likely causes are: DKIM signing is not enabled (you published the CNAMEs but didn't toggle the switch in Defender), or the SPF record doesn't include spf.protection.outlook.com. Check both. A DMARC failure for your own sending domain means some of your mail is landing in spam or being rejected at enforcement.
Want to know if it actually keeps working?
MailerMonk continuously watches your DMARC record, aggregate DMARC reports, and inbox placement — and pings you the moment something drifts. Free for the first domain.
Start free trialAbout the author
Other records for Microsoft 365
DMARC setup for other ESPs
- workspace.google.comDMARC for Google Workspace
- sendgrid.comDMARC for SendGrid
- mailgun.comDMARC for Mailgun
- aws.amazon.comDMARC for Amazon SES