What is DMARC?
DMARC — short for Domain-based Message Authentication, Reporting and Conformance — is an open standard that lets you tell the world's mail systems two things: which servers are genuinely allowed to send email as your domain, and what to do with messages that pretend to be you but fail that test. Just as importantly, the world's major mail systems will send you regular reports about mail they see claiming to come from your domain — giving you the visibility to act.
If you own a domain and send email from it — invoices, newsletters, password resets, ordinary human replies — DMARC is how you stop other people from sending email as you, and how you find out who is trying.
DMARC is an email authentication standard, published as a DNS record, that tells receiving mail servers how to verify that a message really comes from your domain and what to do when it does not.
DMARC defined: the acronym, word by word
That one-line DMARC definition is compressed on purpose. The clearest way to define DMARC in full is to unpack its own name, because each word names a working part of the mechanism rather than a marketing idea.
| Word | What it means in practice |
|---|---|
| Domain-based | The unit of protection is a domain, not an individual mailbox or a single campaign. Publish one record for example.com and it covers every message that carries that domain in the From address. |
| Message Authentication | Every message is judged on the results of the two existing standards, SPF and DKIM — and on whether the domain those checks passed for matches the domain your reader sees. |
| Reporting | Participating mail systems send the domain owner regular summaries of the mail they saw claiming to be from that domain, including how it authenticated and which servers sent it. |
| Conformance | You publish the rule for messages that do not conform — deliver anyway, quarantine, or reject — and receivers that honour DMARC apply it on your behalf. |
Those four words describe the whole system: a domain-level rule, applied message by message, with a feedback loop that tells you whether the rule is safe to tighten.
The problem: anyone can claim to be your domain
SMTP, the protocol that moves email around the internet, was designed in an era when the network was small and everyone on it was trusted. It performs no check at all on the address a message claims to be from. Anyone, anywhere, can connect to a mail server and hand it a message that says From: [email protected] — and without extra protection, many receiving systems will deliver it exactly as written.
Criminals exploit this gap at enormous scale. Spoofed email is the engine behind phishing campaigns, fake invoices, payroll-diversion fraud and business email compromise. And the damage is not limited to the people who receive the fakes: every convincing forgery erodes trust in your domain, and mailbox providers respond by treating all of your mail — including the legitimate messages — with more suspicion. Domains without authentication increasingly see their real email land in spam, or not land at all.
DMARC exists to close this gap. It gives receiving mail systems a reliable, domain-owner-approved way to answer one question: "Is this message really from the domain in the From address?"
Spoofing is not one attack — which kind DMARC stops
"Spoofing" gets used for several different attacks that share a family resemblance and very little else. They forge different things, happen at different points in the chain, and have different defences. The pair that causes the most confusion is email spoofing vs DNS spoofing: one forges the message, the other forges the DNS answer a receiver relies on when judging that message. DMARC was designed for the first and makes no claim about the rest.
These are the types of spoofing you are most likely to meet, and where DMARC sits in each.
| Attack | What the attacker forges | Where it happens | Does DMARC stop it? |
|---|---|---|---|
| Email spoofing | The header From address — the one your reader actually sees | In the message itself | Yes, once you publish p=quarantine or p=reject. At p=none it is only reported, never blocked. |
| Display-name spoofing | The friendly name only, in front of an address the attacker genuinely controls | In the message itself | No. The From domain belongs to the attacker, so DMARC passes for it. |
| Lookalike or cousin domain | A domain you do not own but which reads like yours, such as examp1e.com | At the registrar, before a single message is sent | No. You cannot publish a policy for a domain that is not yours. |
| DNS spoofing or cache poisoning | The resolver's answer, including your _dmarc, SPF and DKIM TXT records | Between the receiving server and DNS | No. DNSSEC is the control for this one. |
| ARP spoofing | The MAC-to-IP mapping on a local network segment | Layer 2 of a local network, nowhere near email | No. Different layer entirely. |
The honest summary is that DMARC removes exactly one option from an attacker's list — using your real domain — and that this happens to be the option that does the most damage to your recipients and your reputation.
Why DNS integrity matters to DMARC
DMARC is published in DNS and evaluated from DNS, so every verdict depends on DNS answers being truthful. Judging a single message takes at least two of them — the _dmarc TXT record carrying your policy and the v=spf1 record listing your permitted servers — plus one <selector>._domainkey TXT lookup for each DKIM signature on the message, and more again for every include: in your SPF chain.
If any of those answers is forged before it reaches the receiver, the receiver acts on a policy you never published. A poisoned _dmarc answer can present p=none where you published p=reject, and the receiving server has no way to tell the difference. That is a DNS problem with a DNS fix: DNSSEC signs authoritative answers so a resolver can detect tampering with them.
What DMARC contributes is visibility. Aggregate reports arrive from mailbox providers all over the world, so a record that has been tampered with, replaced or quietly deleted shows up in your data — as authentication results you did not expect, or as reports that stop arriving. Checking the live record yourself is the fastest sanity test — the free DMARC checker queries public DNS resolvers and shows you what they return for your domain right now.
How DMARC builds on SPF and DKIM
DMARC does not replace the two older email authentication standards — it stands on top of them and fixes their shared blind spot.
SPF (Sender Policy Framework) is a DNS record in which you list the servers permitted to send mail for your domain. When a message arrives, the receiver looks up that list and checks whether the connecting server's IP address is on it.
DKIM (DomainKeys Identified Mail) takes a different approach: your sending server adds a cryptographic signature to each message, and the receiver verifies it using a public key you publish in DNS. A valid signature proves the message really was authorised by the signing domain and was not altered in transit.
Both checks are useful, but each verifies a technical domain that the person reading the email never sees. A message can pass SPF and DKIM for one domain while displaying a completely different domain in the From header — which is exactly what phishers do. DMARC closes the loop with three additions:
- Alignment. For a message to pass DMARC, at least one of SPF or DKIM must pass, and the domain it passed for must match the domain in the visible From address. This is the piece that finally ties authentication to what the reader actually sees.
- Policy. Your DMARC record tells receivers what to do when a message fails: deliver it anyway, send it to spam, or reject it outright. You are in control, and you can tighten the policy at your own pace.
- Reporting. Receivers that evaluate your mail send you regular feedback about it — the visibility layer that makes a safe rollout possible.
DMARC vs SPF vs DKIM at a glance
The three standards are often presented as alternatives to choose between. They are not. SPF and DKIM each answer one narrow technical question and produce evidence; DMARC is the layer that ties that evidence to the address your reader sees and decides what happens next.
| Standard | What it checks | Where it lives | What it cannot do on its own |
|---|---|---|---|
| SPF | Whether the connecting server is on the list of servers permitted to send for the envelope-from domain | A TXT record on your domain, beginning v=spf1 | Say anything about the From address your reader sees; it also breaks when mail is forwarded |
| DKIM | Whether the message carries a valid cryptographic signature from the domain named in its d= tag | A TXT record at <selector>._domainkey on the signing domain | Stop a phisher who signs their own message with their own domain, perfectly validly |
| DMARC | Whether SPF or DKIM passed for a domain that matches the visible From address, and what receivers should do when neither did | A TXT record at _dmarc on your domain | Do anything useful until at least one of SPF or DKIM is working and aligned |
Read the last column downwards and you have the argument for deploying all three: each one covers a gap the others leave open.
What a DMARC record looks like
DMARC is just a TXT record in your DNS, published at the hostname _dmarc. followed by your domain. A minimal, real-world starting record looks like this:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"| Tag | What it means |
|---|---|
v=DMARC1 | The version tag. It is always exactly this value and must appear first. |
p=none | Your policy — what receivers should do with mail that fails DMARC. none means deliver it normally but include it in reports. |
rua=mailto:... | The address where receivers should send aggregate reports about mail claiming to be from your domain. |
The standard defines further tags for fine-tuning — subdomain policy, alignment strictness, sampling percentage — but the three above are all most domains need to get started, and we cover them in a dedicated tag reference.
Check your domain in seconds: our free DMARC checker fetches your live record and explains its policy, reporting and alignment tags — no sign-up needed.
Aggregate reports: your eyes on the world's inboxes
The moment your record includes a rua address, something remarkable happens: Google, Microsoft, Yahoo and thousands of other mail operators start sending you aggregate reports, typically once per day per operator. Each report is an XML file summarising the mail they received with your domain on it: which IP addresses sent it, how many messages, whether SPF and DKIM passed, and whether alignment held.
Aggregate reports contain no message content and no recipient addresses — only authentication statistics — so they are safe to collect and analyse.
This feedback is the heart of DMARC, because it answers questions you cannot answer any other way. Which services actually send email as your domain — not just the ones you remember, but the CRM someone connected two years ago and the billing tool nobody documented? Are they all authenticating correctly? And who, from what corner of the internet, is forging your name right now?
There is one catch: raw reports are compressed XML files that arrive by the dozen and are unreadable at any real scale. That is why most teams feed them into a monitoring service that parses, aggregates and visualises them — it turns a folder full of XML into a dashboard you can act on. How to read a DMARC report walks through the structure of these files and what each field tells you.
The three policy levels
The p= tag supports three values, and together they form a deliberate on-ramp:
| Policy | What receivers do with failing mail | When to use it |
|---|---|---|
p=none | Deliver normally; just report it. | You are starting out and mapping your legitimate senders. |
p=quarantine | Treat it as suspicious — usually the spam folder. | Reports confirm your real senders all pass. |
p=reject | Refuse delivery entirely. | You are confident nothing legitimate fails. Full protection. |
The golden rule of DMARC deployment is to climb this ladder in order, guided by your reports. Start at p=none and watch the data. Fix each legitimate source that fails — usually by finishing its SPF or DKIM setup. Only when the reports run clean do you move to p=quarantine, then p=reject. Jumping straight to a strict policy without monitoring is the classic mistake: it silently discards real mail from the senders you forgot about.
Reaching p=reject is the goal. At that point, spoofed mail claiming to be your domain is refused by every major mailbox provider before a human ever sees it.
Common questions about DMARC
Is DMARC mandatory?
No law requires it, but the largest mailbox providers effectively do. Since February 2024, Google and Yahoo have required bulk senders — on Google's side, anyone sending 5,000 or more messages a day to Gmail addresses — to publish a DMARC record on their From domain, and p=none is the accepted minimum, so meeting the rule costs nothing in delivery risk. Below that threshold a lighter set of rules still applies: SPF or DKIM must pass, and unauthenticated mail is filtered aggressively whatever your volume. Google and Yahoo DMARC requirements sets out both tiers in full.
Does DMARC stop all phishing?
No, and any tool that says otherwise is overselling. DMARC stops one technique: forging your exact domain in the From address. It does nothing about lookalike domains, display-name tricks or messages sent from a free webmail account, because in each of those the From domain genuinely belongs to the sender — the table earlier on this page shows where the line falls. Think of DMARC as the control that takes your own domain off the attacker's list, not as a phishing filter.
Do I need SPF and DKIM before DMARC?
You need at least one of them working and aligned with your From domain, because DMARC has nothing of its own to test — it judges the results SPF and DKIM produce. In practice, set up both: DKIM survives forwarding where SPF does not, and Google and Yahoo require both from bulk senders. Alignment is what catches most domains out, so DMARC alignment explained is worth reading before you publish a policy. You can still publish p=none first — it changes nothing about delivery and switches the reporting on while you finish the setup.
How long does DMARC take to set up?
Publishing the record itself takes a few minutes. How quickly every resolver sees it depends on your DNS provider and the record's TTL, but minutes to an hour is typical, and the first aggregate reports usually arrive within a day or two. What takes real time is the rollout: most domains spend a few weeks at p=none finding and fixing legitimate senders that fail, then move through p=quarantine before reaching p=reject. DMARC policy: none, quarantine, reject sets out the pace and the checks to run at each stage.
Where to go from here
Getting started with DMARC takes minutes, and the safe first step carries zero risk to your mail flow:
- Check what you have — run your domain through the free DMARC checker to see your current record, or confirm you don't have one yet.
- Publish a
p=nonerecord with aruareporting address, like the example above. This changes nothing about how your mail is delivered — it only switches the reporting on. - Monitor the reports and act on them. Create a free DMARCmetric account to collect your aggregate reports automatically and see every sender, pass rate and threat on one dashboard — then tighten your policy with confidence.
Want to see what that looks like in practice? Read What is DMARCmetric? or explore the live demo with realistic sample data.