How to Set Up DMARC for Office 365 | SimpleDMARC

Why Office 365 Needs DMARC

If someone can send mail that looks like it came from your domain, they will, eventually. DMARC is what stops that: it tells receiving mail servers what to do with messages that fail SPF or DKIM, and it hands you reports showing exactly who's sending as your domain — including services you forgot you'd connected.

Office 365 setups get complicated fast. Most tenants aren't just Exchange Online — there's usually a CRM, a marketing tool, sometimes a helpdesk platform, and in larger organizations, an on-premises Exchange server that never quite got decommissioned. If your tenant handles more than one domain (a lot do — a main brand plus an acquired product or a regional site), each of those needs its own record. This guide covers the straightforward path and the parts that trip people up on real tenants.

Start with p=none. You want to see what's actually sending mail before you risk blocking any of it.

Step 1Generating Your DMARC Record

Create a TXT record at _dmarc.yourdomain.com in monitor mode. Swap in your real domain and a reporting address you control.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-reports@yourdomain.com; fo=1; adkim=r; aspf=r; pct=100

What each part is doing:

• p=none — monitor only, nothing gets blocked
• rua / ruf — where your aggregate and forensic reports land
• adkim=r / aspf=r — relaxed alignment, which you want while you're still figuring out what's sending mail

If your tenant has more than one accepted domain sending real mail, repeat this for each one. A DMARC record on company.com protects nothing on companybrand.io — DMARC doesn't inherit across domains in the same tenant, even though it feels like it should.

Step 2Configure SPF for Office 365

Microsoft needs to be authorized in your SPF record:

v=spf1 include:spf.protection.outlook.com ~all

Almost nobody's tenant sends through Exchange Online alone. If you've got Mailchimp, Salesforce, or anything else sending as your domain, add it:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ~all

Never publish two SPF records on the same host — merge them into one. And if a secondary domain in your tenant only sends through Exchange Online with nothing else attached, don't just copy your primary domain's SPF record onto it. Check what that specific domain actually sends before assuming.

Step 3Publish DMARC and Enable DKIM

DMARC lives in DNS, not in the Microsoft 365 admin center — add a TXT record with your DNS host the same way you would any other record. Host: _dmarc (some panels want the full _dmarc.yourdomain.com — check which one applies).

DKIM is where Office 365 gets genuinely confusing, because Microsoft has moved this setting around over the years. Look in the Microsoft 365 Defender portal first — Email & collaboration → Policies & rules → Threat policies → Email authentication settings. Some older tenants still reference DKIM through the legacy Exchange admin center instead, so if you don't see it in Defender, check there.

Generate the DKIM key, publish the two CNAME records Microsoft gives you, then go back and actually turn signing on. Publishing the records isn't enough — there's a separate toggle, and it's easy to miss.

Step 4Wait for Enforcement (Monitor First)

Give it one to two weeks of normal sending before touching your policy. Watch for:

• Sources you don't recognize failing authentication
• Legitimate tools that need adding to SPF or their own DKIM setup
• What percentage of your mail is already passing cleanly

If you're running hybrid Exchange, expect on-premises mail to show up failing DKIM in reports even when it's completely legitimate — that's the SPF-only alignment mentioned above playing out in the data. Once you're confident, move to p=quarantine, then eventually p=reject, by updating the same TXT record. On multi-domain tenants, move each domain up independently as its reports look clean — there's no reason to wait for the slowest one.

Step 5Verify Your Setup

• Look up _dmarc.yourdomain.com with the DMARC Checker — check every accepted domain separately, not just your primary one
• Confirm SPF with the SPF Checker
• Send a real test message to an external inbox and look at the authentication results

Once DMARC, SPF, and DKIM line up, you're in position to tighten policy — and if brand logos in supporting inboxes matter to you, BIMI is worth planning once enforcement is solid.