To set up DMARC for Microsoft 365, add a TXT record named _dmarc.yourbusiness.com.au at your DNS host, starting with v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.com.au. Read the reports it brings for a few weeks, fix any genuine email that fails, then move to p=quarantine and finally p=reject, which is where Microsoft says every domain should end up.
DMARC tells receivers what to do with email that claims to be from your domain but fails its checks, and asks them to send you reports. An email passes DMARC when SPF or DKIM passes for the same domain as your From address. That match is called alignment.
Before you start
- Set up SPF and DKIM first. Microsoft says to do both for every domain you send from before adding DMARC. Microsoft 365 uses your own domain for the hidden bounce address, so SPF lines up with your From address. DKIM is the safety net when SPF breaks, for example when your email is forwarded.
- You add the record at your DNS host. There's no DMARC setting in Microsoft 365 for your own domain. The one exception is your onmicrosoft.com domain (see below).
- Pick a mailbox for reports. Microsoft suggests a mailbox or Microsoft 365 Group set aside for them, not someone's own inbox. A DMARC reporting service will give you an address instead.
Step 1: Publish a monitoring record
Add this record. It's the same one our report gives you when it finds no DMARC record:
| Type | Name | Value |
|---|---|---|
| TXT | _dmarc.yourbusiness.com.au | v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.com.au |
Change the rua address to a mailbox you read. Many DNS hosts add your domain automatically, so you type only _dmarc as the name. If you type the full name into one of those, you end up with the domain twice and receivers won't find the record. A domain can have only one DMARC record.
p=none is monitoring mode. Receivers deliver your email as they normally would and send you reports, so nothing changes for your email yet.
Microsoft's examples also include pct=100 and a ruf= address. You can leave both out: 100 is the default, and Microsoft 365 doesn't send the failure reports that ruf asks for. The updated DMARC standard, RFC 9989, published in May 2026, drops pct and adds a simple test flag, t=y or t=n.
Step 2: Read the reports
Microsoft, Google, Yahoo and other receivers send a daily summary of every email they saw from your domain. Reports are compressed XML files, so most small businesses send them to a DMARC reporting service that turns them into charts.
For each server or service that sent email as you, the report shows whether SPF and DKIM passed, and whether they aligned with your domain. Look for:
- Genuine email that fails. A newsletter tool, website form or booking system you'd forgotten about. Set up DKIM for your domain in that service.
- SPF passing but not aligned. The service passes SPF with its own domain, not yours. That doesn't count for DMARC, so DKIM signed with your domain is the fix.
- Unknown servers failing everything. This is often someone sending email pretending to be you. It's exactly what quarantine and reject stop.
Give it at least a few weeks, including a month-end, when invoices and statements go out.
Step 3: Move to quarantine
Once your genuine email passes, change p=none to p=quarantine:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourbusiness.com.au
Receivers now treat failing email as suspicious. For Microsoft 365 recipients, the Honor DMARC record policy setting is on by default, and failing email goes to the Junk Email folder. Outlook.com, Hotmail and Live addresses go further: Microsoft said in 2023 that its consumer service rejects failing email when the policy is quarantine or reject.
Microsoft also suggests easing in by stepping pct from 10 up to 100. RFC 9989 drops that tag, though many receivers still read it, so treat it as a rough brake, not an exact dial.
Step 4: Move to reject
When quarantine has run cleanly, change it to p=reject:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourbusiness.com.au
Failing email is now refused outright. Microsoft 365 and Outlook.com bounce it with the error 550 5.7.509. Keep the rua address, so you notice when a new tool starts sending as you.
If you have several domains, Microsoft suggests starting with the quietest and doing your main domain last.
Your onmicrosoft.com domain
Every Microsoft 365 organisation has an original address such as yourbusiness.onmicrosoft.com. Microsoft sets up SPF and DKIM for it, but not DMARC. If you don't send email from it, Microsoft says to treat it like an unused domain and give it a p=reject record. You add this one in the Microsoft 365 admin center, not at your DNS host:
- Go to Settings → Domains (under Show all).
- Select the onmicrosoft.com domain by clicking its name, not the checkbox.
- Open the DNS records tab and select Add record.
- Check the Type is TXT (Text). Enter
_dmarcas the TXT name andv=DMARC1; p=rejectas the TXT value, leave the TTL at 1 hour, and select Save.
Before you do, check nobody still sends from an @yourbusiness.onmicrosoft.com address, such as an old shared mailbox. If you're not sure, use p=none with a rua address first.
Any other domain you own but never send from should get v=DMARC1; p=reject; and an SPF record of v=spf1 -all.
Check it worked
DNS changes can take up to 48 hours. Send an email from your Microsoft 365 mailbox to your free test address. The report shows your DMARC record and policy, whether your email passed DMARC and through which check, and whether SPF and DKIM aligned with your From address. You also get a verdict for Gmail, Google Workspace, Outlook.com, Microsoft 365 and Yahoo. Test each other service that sends as you before you move past p=none.
Checked against: Microsoft Learn, Set up DMARC to validate email in Microsoft 365 · Microsoft Learn, Anti-phishing policies in Microsoft 365 (Spoof protection and sender DMARC policies) · Microsoft Exchange Team Blog, Announcing New DMARC Policy Handling Defaults for Enhanced Email Security · RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance (DMARC).