SPF, DKIM, and DMARC are the three DNS records that tell the rest of the internet which email really comes from your domain. Get them right and spoofed messages pretending to be you get rejected. Get the order wrong and your own invoices start landing in clients’ junk folders. This guide gives you a DMARC Microsoft 365 setup order that protects your domain without breaking legitimate mail.
You do not need to understand every technical detail. You do need to follow the steps in sequence and give each one time before moving on.
What each record does, in plain English
SPF (Sender Policy Framework): a TXT record listing the servers and services allowed to send email for your domain. Receiving servers check whether a message came from one of them.
DKIM (DomainKeys Identified Mail): a digital signature added to every outgoing message. Receivers use a public key in your DNS to confirm the message was not altered and really came from your domain.
DMARC (Domain-based Message Authentication, Reporting, and Conformance): a policy that tells receivers what to do when a message claiming to be from your domain fails SPF and DKIM alignment. It also sends you reports so you can see who is sending as you.
DMARC depends on the other two. A message passes DMARC if SPF or DKIM passes and the domain it validated aligns with the domain in the visible From address. That is why the order matters.
Step 0: list everything that sends email as you
This is the step people skip, and it is the reason DMARC rollouts break things. Before touching DNS, write down every system that sends email using your domain in the From address:
Microsoft 365 (staff mailboxes and shared mailboxes)
Your marketing or newsletter platform
Your accounting, invoicing, or payroll system
Your CRM, help desk, or booking tool
Website contact forms
Scanners, copiers, and line-of-business applications
For bulk email services you do not directly control, Microsoft recommends using a subdomain, such as news.yourdomain.com, so problems with those services do not hurt the reputation of your main domain.
Step 1: get SPF right
Your SPF record lives at your domain registrar or DNS host, not in Microsoft 365. There is no Microsoft 365 portal for it. Microsoft 365 setup will already have asked you to add include:spf.protection.outlook.com.
Check that you have exactly one SPF TXT record for the domain. Two SPF records is an error and causes failures.
Add an include: entry for each legitimate service from your Step 0 list, using the value each vendor publishes.
Keep the total number of DNS lookups to 10 or fewer, which is the SPF standard’s limit. Each include: counts, and so do the lookups inside it.
End the record with -all (hard fail) once you are confident every sender is listed. ~all (soft fail) is a reasonable interim choice while you confirm.
A typical record looks like: v=spf1 include:spf.protection.outlook.com include:servers.example-mailer.com -all
Step 2: turn on DKIM signing for your custom domain
Microsoft 365 automatically signs mail for your *.onmicrosoft.com domain, but not for your custom domain. You need to enable it.
In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings and open the DKIM tab.
Select your custom domain. The portal shows two CNAME records, for selector1._domainkey and selector2._domainkey.
Create those two CNAME records at your DNS host exactly as shown.
Wait for DNS to update, then return to the portal and turn on Sign messages for this domain with DKIM signatures.
Send a test message to an external mailbox and check the headers for dkim=pass with your domain.
Repeat for every domain and subdomain that sends mail. Then do the same for each third-party sender: most marketing and invoicing platforms let you set up DKIM with your domain. Without that, their mail can pass SPF for their domain but fail DMARC alignment for yours.
Step 3: publish DMARC in monitoring mode and read the reports
The p=none policy tells receivers not to take action yet. They will, however, send aggregate reports to the address in rua. These reports show every source sending as your domain and whether it passed or failed.
Raw DMARC reports are XML files and not friendly to read. A DMARC reporting service turns them into a dashboard, which is worth it for anything beyond a very small domain. Note that Microsoft 365 does not send forensic (per-message) DMARC reports, so plan around aggregate reports.
Reading the reports and fixing failures
Give monitoring at least two to four weeks so monthly senders, like payroll and statements, show up. Then work through the failures:
What you see
What it usually means
Fix
A known service fails both SPF and DKIM
Service not in SPF and not signing with your domain
Add it to SPF and set up DKIM at the service
A known service passes DKIM but alignment fails
It signs with its own domain, not yours
Configure custom DKIM at the service
Unknown IP addresses, high volume, all failing
Someone is spoofing your domain
Nothing to fix. This is what DMARC will block
Failures from mailing lists or forwarders
Forwarding breaks SPF and sometimes DKIM
Normal. Expect a small amount
Step 4: tighten the policy gradually
Move to p=quarantine. Failing messages go to junk. You can use pct= to apply it to a portion of mail first, for example pct=25, then raise it.
Watch reports and help desk tickets for two to four weeks.
Move to p=reject. Failing messages are refused outright. This is the goal for every domain you own.
Do not forget parked domains that never send email. For those, publish v=spf1 -all and a DMARC record of v=DMARC1; p=reject; straight away, since there is no legitimate mail to break. The same applies to your *.onmicrosoft.com domain if you do not send from it. Its DMARC record is added in the Microsoft 365 admin center rather than at your registrar.
You can publish a p=none DMARC record early to start collecting reports, and Microsoft suggests this for complex organizations. But do not move to quarantine or reject until SPF and DKIM are configured for every legitimate sender.
How long does a full DMARC rollout take?
For a typical small or mid-sized business, six to twelve weeks from monitoring to p=reject. Most of that time is waiting for reports to capture infrequent senders.
Will DMARC stop all phishing that uses my company name?
No. DMARC stops exact-domain spoofing. It does not stop lookalike domains or display-name tricks. Those need anti-phishing policies, user impersonation protection, and staff awareness.
Not sure what your SPF, DKIM, and DMARC records look like today? Book a free Microsoft 365 security assessment and we will check your domains and give you a safe rollout plan.
SPF, DKIM, and DMARC are the three DNS records that tell the rest of the internet which email really comes from your domain. Get them right and spoofed messages pretending to be you get rejected. Get the order wrong and your own invoices start landing in clients’ junk folders. This guide gives you a DMARC Microsoft 365 setup order that protects your domain without breaking legitimate mail.
You do not need to understand every technical detail. You do need to follow the steps in sequence and give each one time before moving on.
What each record does, in plain English
DMARC depends on the other two. A message passes DMARC if SPF or DKIM passes and the domain it validated aligns with the domain in the visible From address. That is why the order matters.
Step 0: list everything that sends email as you
This is the step people skip, and it is the reason DMARC rollouts break things. Before touching DNS, write down every system that sends email using your domain in the From address:
For bulk email services you do not directly control, Microsoft recommends using a subdomain, such as
news.yourdomain.com, so problems with those services do not hurt the reputation of your main domain.Step 1: get SPF right
Your SPF record lives at your domain registrar or DNS host, not in Microsoft 365. There is no Microsoft 365 portal for it. Microsoft 365 setup will already have asked you to add
include:spf.protection.outlook.com.include:entry for each legitimate service from your Step 0 list, using the value each vendor publishes.include:counts, and so do the lookups inside it.-all(hard fail) once you are confident every sender is listed.~all(soft fail) is a reasonable interim choice while you confirm.A typical record looks like:
v=spf1 include:spf.protection.outlook.com include:servers.example-mailer.com -allStep 2: turn on DKIM signing for your custom domain
Microsoft 365 automatically signs mail for your
*.onmicrosoft.comdomain, but not for your custom domain. You need to enable it.Email & collaboration > Policies & rules > Threat policies > Email authentication settingsand open the DKIM tab.selector1._domainkeyandselector2._domainkey.dkim=passwith your domain.Repeat for every domain and subdomain that sends mail. Then do the same for each third-party sender: most marketing and invoicing platforms let you set up DKIM with your domain. Without that, their mail can pass SPF for their domain but fail DMARC alignment for yours.
Step 3: publish DMARC in monitoring mode and read the reports
Now add a TXT record at
_dmarc.yourdomain.com:v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@yourdomain.comThe
p=nonepolicy tells receivers not to take action yet. They will, however, send aggregate reports to the address inrua. These reports show every source sending as your domain and whether it passed or failed.Raw DMARC reports are XML files and not friendly to read. A DMARC reporting service turns them into a dashboard, which is worth it for anything beyond a very small domain. Note that Microsoft 365 does not send forensic (per-message) DMARC reports, so plan around aggregate reports.
Reading the reports and fixing failures
Give monitoring at least two to four weeks so monthly senders, like payroll and statements, show up. Then work through the failures:
Step 4: tighten the policy gradually
p=quarantine. Failing messages go to junk. You can usepct=to apply it to a portion of mail first, for examplepct=25, then raise it.p=reject. Failing messages are refused outright. This is the goal for every domain you own.Do not forget parked domains that never send email. For those, publish
v=spf1 -alland a DMARC record ofv=DMARC1; p=reject;straight away, since there is no legitimate mail to break. The same applies to your*.onmicrosoft.comdomain if you do not send from it. Its DMARC record is added in the Microsoft 365 admin center rather than at your registrar.You can check your current public records with our free tenant checker. For help with the full rollout, our Defender for Office 365 service covers email authentication alongside anti-phishing, and a Microsoft 365 security assessment reviews it as part of your wider posture. Microsoft’s step-by-step reference is set up DMARC to validate the From address domain.
Frequently asked questions
Can I set up DMARC before DKIM?
You can publish a
p=noneDMARC record early to start collecting reports, and Microsoft suggests this for complex organizations. But do not move to quarantine or reject until SPF and DKIM are configured for every legitimate sender.How long does a full DMARC rollout take?
For a typical small or mid-sized business, six to twelve weeks from monitoring to
p=reject. Most of that time is waiting for reports to capture infrequent senders.Will DMARC stop all phishing that uses my company name?
No. DMARC stops exact-domain spoofing. It does not stop lookalike domains or display-name tricks. Those need anti-phishing policies, user impersonation protection, and staff awareness.
Not sure what your SPF, DKIM, and DMARC records look like today? Book a free Microsoft 365 security assessment and we will check your domains and give you a safe rollout plan.