DMARC Explained: How to Stop Email Spoofing and Reach Enforcement
DMARC is the standard that stops attackers sending email that appears to come from your own domain. Almost everyone has published a record. Far fewer have it enforced, which is the only state that actually protects anyone. Here is how SPF, DKIM and DMARC fit together, what the policies mean, and how to get to enforcement without blocking your own mail.
There is a gap in email that most people never think about. By default, anyone on the internet can send a message that says it is from your domain, and the recipient's mail server has no built in way to know it is a fake. That is how a scammer sends an invoice that appears to come from your finance team, or a phishing email that wears your brand to fool your own customers. DMARC exists to close that gap. It lets you tell the world's mail servers which senders are genuinely yours, and what to do with anything that fails the check.
SPF and DKIM prove a message genuinely came from your domain. DMARC ties them together, tells receiving servers what to do when a message fails, and sends you reports on who is using your domain. Publishing a record is easy. The value only arrives when the policy is set to enforcement, p=quarantine or p=reject, so fraudulent mail is actually stopped. Most organisations stall at p=none and get no protection at all.
SPF, DKIM and DMARC: how the three fit together
These three standards are often lumped together, but each does a distinct job, and DMARC only works when it sits on top of the other two.
- SPF, Sender Policy Framework. A published list of the mail servers allowed to send on behalf of your domain. The receiving server checks whether the message came from an approved source. It answers the question, is this sender permitted.
- DKIM, DomainKeys Identified Mail. A cryptographic signature added to each message, which the receiver verifies against a public key in your DNS. It proves the message genuinely came from your domain and was not altered in transit. It answers the question, is this message authentic and untampered.
- DMARC, Domain based Message Authentication, Reporting and Conformance. The policy layer. It requires that SPF or DKIM not only pass but align with the domain the user actually sees in the From line, then tells the receiver what to do if the checks fail, and asks the receiver to send you reports. It answers the question, and what should happen now.
The alignment part is what makes DMARC strong. Spammers can pass a technical SPF or DKIM check for some unrelated domain of their own. DMARC insists the passing domain matches the visible From address, which is the one a human reads and trusts.
The three policies, and why only two protect you
A DMARC record carries a policy, the instruction to receiving servers. There are three settings, and the difference between them is the whole game.
- p=none. Monitor only. Failing mail is still delivered as normal, but you receive reports on it. This is the starting point, the observation phase. It protects nobody. It simply shows you what is being sent in your name.
- p=quarantine. Failing mail is treated as suspicious, usually delivered to the spam or junk folder. The first real level of enforcement.
- p=reject. Failing mail is refused outright and never delivered. This is full enforcement, and the only state that truly stops an attacker spoofing your exact domain.
Here is the uncomfortable truth. A published record sitting at p=none, which is where a great many organisations quietly remain, gives you no protection whatsoever. Attackers can still spoof your domain freely. If DMARC is on your list of controls but the policy is none, treat it as not done.
Why so many get stuck at p=none
Reaching enforcement is not technically hard, but it carries a real risk that stops people moving. If you jump straight to p=reject and you have not accounted for every legitimate system that sends mail as you, your marketing platform, your invoicing tool, your helpdesk, your payroll provider, then that genuine mail starts bouncing. Nobody wants to be the person who blocked the company's own invoices, so the safe looking choice is to leave it at none and forget about it.
The modern estate makes this harder. A typical organisation has a long tail of third party services authorised to send on its behalf, and that list changes over time as tools come and go. Working out which senders are legitimate, from the raw XML reports that receiving servers send back, is genuinely tedious by hand. That difficulty, not the DNS change itself, is what keeps most records stranded at none.
DMARC enforcement is not a single switch, it is a staged migration. The goal of the none phase is not to sit there, it is to learn exactly who sends mail as you, authorise every legitimate source, and then tighten the policy with confidence. A record parked at none forever has skipped the only part that mattered.
How to reach enforcement safely
The route to p=reject is a controlled sequence, not a leap. Done in order, it gets you to full protection without blocking a single genuine message.
- Publish SPF and DKIM properly first. DMARC has nothing to align against if these are missing or incomplete, so get them right for every sending source before you begin.
- Start at p=none with reporting on. Publish the record in monitor mode and turn on aggregate reports. Deliver nothing differently yet, just watch.
- Read the reports and build the inventory. Over a few weeks, identify every server and service legitimately sending as you, and make sure each one is covered by SPF and DKIM. This is the real work, and where a DMARC management platform earns its keep.
- Move to p=quarantine, often on a percentage first. Once the legitimate senders are all authenticating cleanly, tighten to quarantine, optionally applied to a fraction of mail to start, and confirm nothing genuine is being caught.
- Move to p=reject. When quarantine has run clean, step up to full enforcement. Now anything spoofing your exact domain is refused at the door.
- Keep watching. Enforcement is not the end. New tools get added, records drift, so the reporting stays on and the inventory stays maintained.
What DMARC does not do
DMARC is essential, but it is precise about what it protects, and it is important to be honest about the edges. It stops an attacker spoofing your exact domain. It does nothing about the two tricks that most targeted fraud actually uses.
- Lookalike domains. An attacker registers a domain that reads almost like yours, swapping one letter or adding a word. That is a different domain, so it passes its own authentication, and DMARC on your domain never sees it.
- Display name spoofing. The email comes from an unrelated address, but the sender's display name is set to your chief executive's name. The From domain is not yours, so again DMARC is not involved.
These are exactly the methods behind most business email compromise, which is why DMARC and impersonation protection are complementary, not alternatives. DMARC shuts the door on exact domain spoofing. Impersonation protection and a payment verification process handle the lookalikes and the display name tricks. You need both.
Where a DMARC management tool fits
You can reach enforcement with nothing but DNS changes and patience reading raw reports, and some organisations do. The reason tools such as Mimecast DMARC Analyzer exist is that the reporting is where people get stuck. A management platform turns the raw XML into a readable picture of who is sending as you, flags the sources that are not authenticating, and makes the staged tightening to quarantine and reject a managed process rather than a nervous guess. Where you have a complex estate with many third party senders, that visibility is usually what gets a stalled record over the line. We are a strategic Mimecast partner, and we recommend it where the estate justifies it rather than as a default, because a small, simple domain can often get there without it.
Not sure whether your domain is genuinely protected or just carrying a record at p=none? Our free, interactive Email Security Assessment covers authentication alongside the other five dimensions of email and collaboration security, and returns an instant, personalised view of where the gaps are. It is the quickest way to find out if your DMARC is doing anything at all.
Stuck at p=none, or not sure your domain is protected?
C4C helps organisations reach DMARC enforcement safely, mapping every legitimate sender, getting SPF and DKIM right, and tightening the policy to reject without blocking genuine mail. Vendor neutral, with no quota to fill.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.
Frequently asked questions
What is DMARC?
DMARC, Domain based Message Authentication, Reporting and Conformance, is an email authentication standard that stops attackers sending mail that appears to come from your domain. It builds on SPF and DKIM, tells receiving servers what to do with mail that fails the checks, and sends you reports on who is using your domain. Properly enforced, it prevents fraudulent email appearing to come from your own organisation.
What is the difference between SPF, DKIM and DMARC?
SPF lists the servers allowed to send for your domain, so it answers whether a sender is permitted. DKIM adds a cryptographic signature that proves a message is authentic and untampered. DMARC sits on top, requires that SPF or DKIM pass and align with the visible From address, then decides what happens when they fail and reports back to you. You need all three, and DMARC only works when SPF and DKIM are in place.
What do p=none, p=quarantine and p=reject mean?
They are the three DMARC policies. p=none is monitor only, failing mail is still delivered and you just receive reports, so it protects nobody. p=quarantine sends failing mail to spam or junk, the first level of real enforcement. p=reject refuses failing mail outright, which is full enforcement and the only state that truly stops an attacker spoofing your exact domain.
Why is my DMARC stuck at p=none?
Usually because moving to enforcement risks blocking your own legitimate mail if you have not first accounted for every system that sends as you, such as marketing, invoicing, helpdesk and payroll tools. Working out that list from the raw XML reports is tedious by hand, so records get left at none and forgotten. That difficulty, not the DNS change, is what keeps most domains unprotected.
How long does it take to reach DMARC enforcement?
For a simple domain, a few weeks. For a complex estate with many third party senders, a few months is realistic. The DNS changes are quick. The time goes into the monitoring phase, where you identify every legitimate sender, get them authenticating cleanly with SPF and DKIM, then tighten the policy through quarantine to reject with confidence that nothing genuine breaks.
Does DMARC stop phishing and BEC?
Only partly. DMARC stops attackers spoofing your exact domain, which is important. It does not stop lookalike domains that read almost like yours, or display name spoofing where the attacker uses an unrelated address with your executive's name. Those are the methods behind most business email compromise, so DMARC needs to be paired with impersonation protection and a payment verification process, not treated as the whole answer.