DMARC setup for Microsoft 365 and Office 365

Three protocols, three different control panels

SPF lists which servers are allowed to send mail for your domain. DKIM adds a cryptographic signature to each message so the recipient can tell it was not altered. DMARC ties both back to the From address your recipients actually see, and tells receiving servers what to do when neither lines up.

Microsoft handles exactly one of those three inside its own products. DKIM signing is configured in the Microsoft Defender portal. For SPF and DMARC on a custom domain, Microsoft's documentation says it directly: there are no admin portals or PowerShell cmdlets in Microsoft 365 for you to manage those records. You create them at your registrar.

Before you start, the domain has to already be added and verified in Microsoft 365. If it is not on the Domains list in the admin center, nothing below will appear.

Where each record actually lives

DKIM lives in the Defender portal at security.microsoft.com. Go to Email & collaboration, then Policies & rules, then Threat policies, then Email authentication settings. The direct link is https://security.microsoft.com/authentication. That page has a DKIM tab and an ARC tab. There is no DMARC tab that writes records for you.

DMARC and SPF for a custom domain live at your registrar or DNS host. GoDaddy, Cloudflare, Namecheap, Route 53, wherever your nameservers point.

There are two exceptions worth knowing.

• Your *.onmicrosoft.com domain (Microsoft calls it the MOERA domain) sits in a zone Microsoft owns. Publish its DMARC record at admin.microsoft.com under Show all, Settings, Domains. Click the domain row, open the DNS records tab, select Add record, set Type to TXT (Text), TXT name to _dmarc, TXT value to v=DMARC1; p=reject, and leave TTL at 1 hour.
• If you pointed your nameservers at Microsoft, that same DNS records tab manages your custom domain too. If your nameservers still point at your registrar, that tab is reference only. Records you add there will never resolve.

Enable DKIM: the step that looks like a failure

On the DKIM tab, your custom domain shows a Status of NoDKIMKeys and a Toggle set to Disabled.

Slide that toggle to Enabled. You will get a Client error dialog. This is supposed to happen. The failed attempt is what makes Microsoft generate the key pair for your domain. Select OK, and the Status changes to CnameMissing.

Now click anywhere in that row except the checkbox or the toggle. A details flyout opens with a Publish CNAMEs section holding your two real values and a Copy button. That is the only place the correct values exist.

If you prefer PowerShell, connect to Exchange Online and run New-DkimSigningConfig -DomainName yourdomain.com -Enabled $false, then read the values back with Get-DkimSigningConfig -Identity yourdomain.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME. Add -KeySize 2048 if you want a stronger key than the 1024-bit default.

The two CNAMEs you cannot copy from a template

Microsoft 365 uses CNAME records for DKIM, not TXT. Most other mail providers hand you a long public key to paste. Microsoft hands you a pointer to a key it keeps.

The host names are identical for every tenant on earth: selector1._domainkey and selector2._domainkey. The values are not. They follow this shape:

selector1-<your-domain-with-dashes>._domainkey.<initial-domain-prefix>.<partition>-v1.dkim.mail.microsoft

Your domain's dots become dashes, so contoso.com becomes contoso-com. The initial domain prefix is whatever sits in front of .onmicrosoft.com in your tenant. The partition is a single character Microsoft assigns from its own routing logic. It is commonly r or n, it differs between domains inside the same tenant, and it is not configurable.

Domains onboarded before May 2025 use the older format that ends in .onmicrosoft.com instead. The two formats cannot coexist for the same selector. This is the whole reason you must copy from your own tenant rather than from any example, including the ones in this article.

Create both records even though only one selector is active. Selector2 is what a future key rotation moves onto. Skip it and DKIM works fine today, then rotation fails months later with no obvious cause.

The DMARC record, and the host field that silently breaks it

The host or name field takes exactly one value: _dmarc. Nothing else.

Most DNS panels append your zone automatically. GoDaddy does. If you type _dmarc.yourdomain.com you end up with a record at _dmarc.yourdomain.com.yourdomain.com. The panel saves it without complaint, no error appears anywhere, and no receiving server will ever find it. This is the single most common silent failure in the whole process, and it hits the DKIM selector hosts the same way. Microsoft documents this exact double-domain mistake.

Roll the policy out in stages rather than jumping to enforcement:

• Monitor: v=DMARC1; p=none; pct=100; rua=mailto:dmarc@yourdomain.com
• Then quarantine: v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com, stepping pct through 10, 25, 50, 75 first if your volume is high
• Then reject: v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com
• SPF, one record only: v=spf1 include:spf.protection.outlook.com -all (GCC High and DoD use spf.protection.office365.us; 21Vianet uses spf.protection.partner.outlook.cn)

Delegated access: how someone helps without your password

Microsoft 365 has genuine delegation built in. There is never a reason to share a password to get this work done.

The straightforward route is to add the person as a user or guest, then assign a role. In the admin center go to Roles, then Role assignments, pick the role, open the Assigned tab and select Add users. Or open Users, Active users, select the person, and choose Manage roles.

Choosing the role is where people get caught. Microsoft's own documentation states that the Entra Security Administrator role cannot access the email authentication settings in the Defender portal. What works is Global Administrator in Entra, or membership in the Organization Management or Security Administrator role group in Exchange Online. The Exchange Online role group is the least-privilege option and the one to prefer. Global Administrator is the sledgehammer, and Microsoft's guidance is to keep it for emergencies.

Domain Name Administrator in Entra covers domain management, and Global Reader is enough for someone doing a read-only verification pass. Microsoft partners can also use GDAP through Partner Center, where you approve a specific list of Entra roles for a fixed period that expires on its own.

One honest limit: none of this reaches your registrar. If your DNS lives at GoDaddy or Cloudflare, you delegate there separately using that provider's own access controls. Remove the role assignment once the work is finished.

The gotchas that eat an afternoon

Most of these are specific to how Microsoft's records behave, and none of them announce themselves.

• TTL too low. Microsoft asks for at least 3600 seconds on SPF and both DKIM CNAMEs. Values like 60 or 300 produce intermittent dkim=temperror on the receiving side.
• Cloudflare proxy on. Set both DKIM CNAMEs to DNS only, the grey cloud. With the orange cloud, lookups return Cloudflare IP addresses instead of the CNAME target and DKIM verification fails every time.
• Trailing dot. Some panels need a trailing dot on the CNAME target to mark it fully qualified. Others add one for you, and typing your own creates a double dot Microsoft cannot see.
• A TXT record where a CNAME belongs. Pasting a DKIM public key as TXT leaves the status stuck on CnameMissing. Microsoft does not support TXT-based DKIM for its own signing.
• Long-record splitting mostly does not apply here, which is a genuine relief compared to other providers. DKIM is a CNAME, so there is no long public key to break across 255-character strings, and DMARC records are short. If SPF grows unwieldy, your real constraint is the 10 DNS lookup limit, not character count.
• Key rotation takes 96 hours to take effect, and you cannot start a second rotation while one is running.
• The Defender toggle only flips once Microsoft detects your CNAMEs in public DNS. Propagation runs from a few minutes to 48 hours, and Microsoft's detection sweep is a separate clock.

How to verify it actually worked

A Status of Valid in the Defender portal means Microsoft found your CNAMEs. It says nothing about whether DMARC passes. Check it yourself.

Query DNS directly. On Windows: nslookup -type=CNAME selector1._domainkey.yourdomain.com, the same for selector2, and nslookup -type=TXT _dmarc.yourdomain.com. On macOS or Linux use dig with +short. If a selector returns nothing, the host field trap above is your first suspect.

Then send a real message to an external mailbox, with two rules. Do not send to another mailbox in your own tenant: Microsoft omits the DKIM signature entirely when sender and recipient belong to the same organization, and you will see dkim=none (message not signed) and assume you broke something. Do not test against AOL either, because Microsoft warns it may skip the DKIM check when SPF passes.

Open the raw headers and read Authentication-Results. You want spf=pass, dkim=pass and dmarc=pass. Then do the check that actually matters: compare the header.d= value from the DKIM signature against header.from=. If those two domains do not match, DKIM passed and DMARC still failed on alignment. That is the most common way a Microsoft 365 rollout looks finished and is not.

The Message Header Analyzer at mha.azurewebsites.net parses headers for you, and the Remote Connectivity Analyzer at testconnectivity.microsoft.com validates the records. After that, wait for your first aggregate reports. They are the only view you get of everything else sending under your name.

What Microsoft 365 cannot do

Being clear about the ceiling saves you from chasing settings that do not exist.

• It will not publish SPF or DMARC for a custom domain. No portal, no cmdlet, no exceptions.
• It never sends DMARC forensic reports, even if you publish a valid ruf address. Other providers may still send them to you.
• It only sends aggregate reports about mail it receives when your MX record points directly at Microsoft 365. Put a security gateway in front, or route through on-premises in a hybrid setup, and Microsoft sends nothing.
• It does not parse DMARC reports. You get compressed XML attachments in a mailbox. Send them to a shared mailbox or a Microsoft 365 Group, never a person's inbox, and use a reporting service if the volume is real.
• It cannot sign mail sent by your other platforms. Anything sending as your domain from elsewhere needs DKIM configured at that service.
• Once your domain publishes p=reject or p=quarantine, outbound Microsoft 365 mail that fails DMARC at the destination is routed through the high-risk delivery pool. Microsoft states there is no override for this.

Microsoft's bulk sender rules

Since 5 May 2025, domains sending more than 5,000 messages a day to Outlook.com, Hotmail.com and Live.com consumer mailboxes must pass SPF and DKIM and publish DMARC at a minimum of p=none, aligned to one of the two. Microsoft began by routing non-compliant mail to Junk, then moved to outright rejection with 550; 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.

That threshold counts consumer Outlook mailboxes only. Most tenants never approach it from Exchange Online. Your marketing platform can, easily, and that mail carries your From domain, so your domain is what gets judged. Microsoft also expects a valid From and Reply-To, a working unsubscribe link, and real list hygiene.

The practical move is to send bulk mail from a subdomain such as news.yourdomain.com, with its own SPF, DKIM and DMARC records. A deliverability problem there stays contained, and each subdomain gets its own budget against the 10 DNS lookup limit.

Doing it yourself, or working with us

If you have admin access, your registrar login, and an afternoon, you can do all of this. The steps above are the whole job. Most of the difficulty is not conceptual, it is the handful of places where a wrong value saves cleanly and fails silently.

What we do at Verified Everywhere is run it end to end without ever holding a password. You assign an Exchange Online role group in your own admin center, delegate at your registrar through their access controls, and revoke both when we are done. We never take passwords, government IDs or card numbers, and we do not make promises about what any receiving provider will decide. What we can tell you is exactly what your headers say and what your DMARC reports show.