How to Set Up DMARC for Microsoft 365

Most UK businesses send email through Microsoft 365, and most have never finished setting up its email authentication. Here is the complete sequence for SPF, DKIM and DMARC on Microsoft 365, in the order that works, with the mistakes to avoid at each step. If any of the terminology is new, start with SPF, DKIM and DMARC Explained in Plain English and come back.

Before you start: list your senders

Microsoft 365 is almost never the only thing sending as your domain. CRMs, accounting software, helpdesk tools, marketing platforms and website contact forms all send email with your name on it. Write down every one, because each needs to pass authentication or its mail will suffer once you enforce. Miss one and you'll discover it the hard way when its emails stop arriving.

Step 1: SPF

Your domain needs exactly one SPF record, a TXT record at the root of the domain. For Microsoft 365 alone it looks like this:

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

Add an include for each third-party sender from your list (your provider's documentation gives the value). Two rules: never create a second SPF record (two records means both fail), and stay under 10 DNS lookups in total. If your accumulated includes push past 10, the record breaks silently, a surprisingly common cause of the problems described in why emails go to spam.

Step 2: DKIM

DKIM is not enabled by default for custom domains in Microsoft 365. In the Defender portal (security.microsoft.com), go to Email & collaboration settings, then Email authentication, then DKIM. Select your domain and Microsoft shows you two CNAME records (selector1 and selector2). Publish both in your DNS, wait for them to resolve, then flip the Enable toggle. If the toggle throws an error, the CNAMEs haven't propagated yet; give it an hour.

Repeat the DKIM exercise inside each third-party platform on your sender list. Almost all reputable ones support it.

Step 3: publish DMARC in monitoring mode

Create a TXT record named _dmarc.yourdomain.co.uk with a starting value of:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.co.uk

p=none changes nothing about delivery yet. The rua address is where aggregate reports arrive, daily, from every major provider, as XML attachments. Use a dedicated mailbox; the volume adds up.

Step 4: read the reports and fix what fails

This is the step that separates protected domains from decorative DMARC records. The reports show every source sending as your domain and whether each passed. Raw XML is painful to read manually, which is why most businesses use a reporting tool or a managed service. Work through the failures: usually a forgotten sender needing an SPF include or DKIM enabling. Expect two to six weeks of monitoring for a typical business.

Step 5: enforce

Once every legitimate sender passes consistently, tighten the policy. Move to p=quarantine (optionally staged with pct=25, then 50, then 100), watch the reports for casualties, then finish at p=reject. At p=reject, spoofed email claiming to be your domain is refused by receiving servers worldwide. That is the destination; a domain parked at p=none is not protected, as we explain in What is DMARC?

The five mistakes we see most

• Two SPF records on one domain.
• SPF over the 10-lookup limit.
• DKIM never enabled for the custom domain, only onmicrosoft.com.
• DMARC published at p=none and left there permanently.
• Nobody reading the reports, so enforcement never happens.

Or have it managed

Every step above, including the weeks of report-watching and the careful move to enforcement, is exactly what Flo Verified Mail does for you. We set it up, check reports daily and take your domain to full protection, then keep it there as your tools change. For the wider context on why this matters, see the complete email deliverability guide.