The problem
Email was built on trust. Nothing in its original design stops a server putting your domain in the From line of a message. A criminal who wants your customers to pay a fake invoice does not need to break into anything. They type your address and press send.
Whether the receiving server believes them depends on three DNS records that most organisations have never looked at.
Three records
SPF
Who may send
The list of services allowed to send email for you.
DKIM
What was sent
A tamper-proof signature on every message you send.
DMARC
What to do with fakes
Your instruction to inboxes about mail that fails: watch it, junk it or refuse it.
SPF and DKIM do the checking. DMARC ties them to the address people actually see, and says what happens next.
Alignment
SPF and DKIM can both pass for a domain the reader never sees, such as the newsletter service that carried the message. DMARC asks one more question: does the domain that passed match the one in the From line? That match is called alignment.
This is why "we have SPF, so we are covered" is not true. SPF on its own does not protect the address your customers read.
Three settings
Watch
Fakes are delivered. You get a report. Most domains are here.
Junk
Fakes go to the spam folder.
Refuse
Fakes are turned away before they arrive. This is the goal.
Only the last two protect anyone. Together they are called enforcement.
The reports
Your DMARC record names an address for reports. Every day, receivers such as Google, Microsoft and Yahoo send it a summary of the mail they saw that claimed to come from you: which servers sent it, how much, and whether it passed. The summaries arrive as XML files, which is why most people use a service to read them.
Why domains stall at none
Move to reject too early and you bounce your own invoices, newsletters and CRM email, because some service nobody remembered is sending as you without the right records. So organisations publish p=none, mean to come back to it, and never do.
The safe route is to find every real sender first, fix each one, then tighten a step at a time. This is the route OuterMark's Managed DMARC takes:
- Day 0Observep=none. Reports start arriving.
- About day 30Quarantine 25%A quarter of failing mail is junked.
- About day 60Quarantine 50%Half of failing mail is junked.
- About day 90Quarantine 100%All failing mail is junked.
- About day 120RejectFakes are refused.
Each step waits for at least 30 days of evidence since the last one, and for a person to approve it. Starting from none, reject takes about four months. The patience is the point: it is what keeps the invoices arriving.
What inbox providers require
| Provider | Since | What it requires |
|---|---|---|
| Gmail | 1 February 2024 | SPF or DKIM from every sender. SPF, DKIM and a DMARC record from anyone sending 5,000 or more messages a day. |
| Yahoo | February 2024 | SPF and DKIM from bulk senders, and a DMARC policy of at least none that passes. |
| Microsoft | 5 May 2025 | SPF, DKIM and DMARC from senders of 5,000 or more messages a day to Outlook.com, Hotmail and Live. Mail that fails is rejected with error 550 5.7.515. |
Source: Microsoft, Outlook's new requirements for high-volume senders.
None of the three requires enforcement. They require a DMARC record from bulk senders, and p=none meets that. The rules are why your mail needs the records. Enforcement is what protects you.
The 2026 standard
DMARC was rewritten in May 2026 as RFC 9989, with RFC 9990 and RFC 9991 for its reports. Four changes matter to a domain owner.
- The percentage tag is gone. Receivers applied
pctinconsistently, so the new standard drops it. A test-mode tag,t=y, takes its place. - Subdomains that do not exist get their own policy. A new tag,
np, covers made-up subdomains, a favourite of spammers. - Receivers find your organisation differently. They now walk up the DNS tree, where they used to rely on a published list of domain endings.
- Reject needs DKIM. Forwarding breaks SPF. A sender that passes on SPF alone has its forwarded mail refused at reject, so every real sender should sign with DKIM first.
Source: RFC Editor, RFC 9989.
The large inbox providers are still adopting it, so OuterMark reads every record both ways and says where the two disagree.
Reading a record
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourcompany.co.uk
| Tag | What it says |
|---|---|
| v | The version. Always DMARC1, always first. |
| p | The policy for your domain: none, quarantine or reject. |
| sp | The policy for your subdomains, when it differs. |
| np | The policy for subdomains that do not exist. New in 2026. |
| rua | Where the daily reports go. |
| t | Test mode. With t=y, receivers apply the policy one level down. New in 2026. |
| pct | The share of failing mail the policy applies to. Removed in 2026; some receivers still apply it. |
Questions
Will DMARC break our email?
Only if it is rushed. Real email breaks when a policy tightens before every real sender has been found and fixed. Done in steps, with evidence at each one, real email keeps arriving.
Does DMARC stop phishing?
It stops other people faking your domain. It does not stop phishing sent from other people's domains reaching you. That is a job for your email filter.
This domain never sends email. Does it need DMARC?
Yes. A domain that never sends is the easiest one to fake, because nobody is watching it. It can go straight to reject, since there is no real email to break.