What DMARC is
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is published as a DNS TXT record on the subdomain _dmarc under the domain it protects, and it is read by receiving mail servers when they evaluate an incoming message.
A minimal record looks like this, as a single line of text:
v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s
- v=DMARC1 declares the version. It must come first and it is the only mandatory tag besides the policy.
- p=none is the policy: what a receiver should do with a message that fails. The values are none, quarantine and reject.
- rua=mailto:... is where aggregate reports are sent. Without it you are enforcing blind.
- adkim=s and aspf=s set strict alignment for DKIM and SPF respectively. The default for both is r, meaning relaxed.
- pct=, sp= and ruf= are the other tags you will meet: a percentage rollout, a separate policy for subdomains, and an address for forensic reports.
DMARC does not authenticate anything by itself. It consumes the results of SPF and DKIM, checks alignment, and then applies a policy. That layering is why a DMARC record on a domain with no working SPF or DKIM accomplishes nothing at all.
How a receiver evaluates it
When a message arrives, the receiving server performs a short sequence. Understanding it tells you exactly where a legitimate mail stream can break during a rollout.
- Evaluate SPF against the envelope sender domain, and evaluate any DKIM signatures on the message.
- Extract the domain from the visible From header - the one the recipient reads.
- Check alignment: does the SPF-authenticated domain, or the DKIM signing domain, match that From domain?
- If at least one of SPF or DKIM both passes and aligns, DMARC passes. Only one needs to succeed.
- If neither does, DMARC fails and the receiver applies the published policy: deliver, quarantine, or reject.
- Either way, the receiver records the outcome and includes it in the next aggregate report sent to the rua address.
Alignment is the part that actually matters
Alignment is the concept people skip, and skipping it is why they misunderstand what DMARC buys them. SPF validates the envelope sender - the address used in the SMTP conversation, which the recipient never sees. Nothing in SPF requires that address to have any relationship to the From header displayed in the mail client.
So an attacker can register a domain they control, publish a perfectly valid SPF record for it, send mail that passes SPF cleanly, and set the visible From header to your domain. SPF passes. The recipient sees your name. Nothing is technically wrong from SPF's point of view, because SPF was never looking at the header the human reads.
DMARC closes exactly that gap by requiring the authenticated domain and the visible From domain to align. Relaxed alignment (the default, r) accepts a match on the organisational domain, so mail.example.com aligns with example.com. Strict alignment (s) requires an exact match. Relaxed is right for most organisations; strict is worth it when you have full control of every sender and want to stop a compromised subdomain from being usable against you.
The three policy levels
| Policy | What the receiver does | What it is for |
|---|---|---|
| p=none | Delivers the message normally and reports the outcome. | Monitoring only. Protects nobody; it exists so you can discover your own senders before enforcing. |
| p=quarantine | Delivers to the spam or junk folder. | The transition step. Failures become visible to users without being lost outright. |
| p=reject | Refuses the message at the SMTP conversation, so it is never delivered. | The destination. This is the only setting that actually stops your domain being spoofed. |
Aggregate reports
The rua address receives XML aggregate reports, typically daily, from every receiver that processed mail claiming to be from your domain. Each report lists source IP addresses, message volumes, and the SPF and DKIM results for each.
This is the whole reason the monitoring stage exists. Almost every organisation is sending legitimate mail from more sources than anyone remembers: the CRM, the invoicing system, the recruitment platform, the marketing tool someone in another department signed up for, the monitoring alerts from a server nobody has logged into in a year. Move straight to p=reject and you will discover those systems by way of the people who stop receiving their mail.
Raw DMARC XML is not readable by a human at volume. Use a report analyser - there are free tiers that are perfectly adequate for a single domain - and read the reports for a few weeks before changing anything. Forensic reports (ruf) are much less useful in practice: many receivers do not send them at all, and those that do may include message content, which brings its own handling obligations.
A rollout that does not break your mail
- Inventory every system that sends mail as your domain. Ask finance, HR and marketing directly rather than assuming IT knows - the systems IT does not know about are exactly the ones that will break.
- Set up SPF and DKIM correctly for each of those senders. DKIM matters more than SPF here, because it survives forwarding.
- Publish p=none with a rua address and wait. Two to four weeks is realistic for a domain with any volume.
- Read the reports and fix what you find. Repeat until the only failures left are ones you recognise as spoofing rather than as your own systems.
- Move to p=quarantine, optionally with pct=10 and increasing, so a mistake affects a fraction of mail rather than all of it.
- Move to p=reject once quarantine has run clean. Then consider tightening adkim and aspf to strict.
- Set sp=reject too, so subdomains you are not using cannot be spoofed - an unused subdomain with no policy is an open door.
Keep reading the reports after you reach enforcement. A new SaaS tool added six months later will fail silently, and the first sign will be a colleague saying their mail is not arriving.
What DMARC does not stop
DMARC at p=reject ends direct spoofing of your exact domain. That is a genuinely large win and it is worth the work. It is also the entire scope of what it does, and being clear about the boundary matters because attackers simply move to the routes it does not cover.
- Lookalike domains. A message from exarnple.com passes its own DMARC perfectly. Your policy has no bearing on a domain you do not own.
- Display-name spoofing. Setting the display name to your CEO while sending from a free webmail address is not a DMARC failure, because the From domain is genuinely that webmail provider.
- Compromised legitimate accounts. Mail sent from a real, hijacked mailbox is authenticated and aligned, because it genuinely is your domain sending it.
- Anything outside email entirely - SMS, voice calls, chat platforms, QR codes.
- Inbound protection generally. DMARC on your domain protects recipients from mail forged as you. Whether you are protected from other people's forged mail depends on how strictly your own gateway enforces their policies.
That last point is worth an explicit note about sextortion mail, since it drives a lot of alarmed questions: messages claiming to be sent from the victim's own account as proof of compromise are almost always plain spoofing, which is precisely what a domain without DMARC enforcement permits. The sextortion email with my password entry covers what to do about one. And because none of this addresses a user handing credentials to a proxy, DMARC is no help against adversary-in-the-middle phishing once a message is delivered - see phishing tests for employees for the controls that pick up where authentication stops.
Frequently asked questions
Do I need both SPF and DKIM for DMARC to work?
Strictly, no - DMARC passes if either one passes and aligns. In practice you want both. SPF breaks when mail is forwarded, because the forwarding server is not in your record, while a DKIM signature survives forwarding intact. Having only SPF means forwarded legitimate mail will fail once you enforce.
Is p=none good enough?
No. p=none tells receivers to deliver failing mail anyway, so it provides no protection at all. It is the correct first stage, because it produces the reports you need to find your own senders, but it is a stage to pass through rather than settle on.
Will DMARC stop phishing aimed at my company?
It stops attackers forging your exact domain, which mostly protects your customers and partners rather than your own staff. Phishing sent from lookalike domains, from free webmail with a spoofed display name, or from a compromised third party is unaffected, because none of those fail your DMARC policy.
What happens to mail from a domain that has no DMARC record at all?
It is delivered under the receiver's own rules, and there is no policy telling anyone to reject forgeries of it. Publishing no record is why plain sender spoofing still works so widely, and it is also why an unused subdomain should carry an explicit sp=reject.
How long does a rollout to p=reject take?
For a small organisation with a handful of sending systems, a few weeks. For a larger one with departmental SaaS tools nobody has catalogued, a few months is realistic. The time is spent discovering senders in the aggregate reports, not on the DNS changes themselves, which take minutes.