What is DMARC? A plain-English guide

Anyone can send an email that claims to be from your domain. That is not a flaw in your email provider - it is how email was designed in the 1980s, when nobody imagined it would carry invoices, payroll instructions and client funds.

Domain-based Message Authentication, Reporting and Conformance (DMARC) is the standard that fixes this. It lets you publish a public instruction telling every mail server in the world what to do with email that claims to come from your domain but cannot prove it - and it sends you reports about everything they see.

This guide explains how it works, what the three policy levels mean, and why the reporting side of DMARC matters as much as the policy side.

The problem DMARC solves

When an email arrives at, say, a Gmail inbox, Google needs to decide whether the sender is genuine. Two older standards help with this:

• SPF (Sender Policy Framework) is a list, published in your domain's DNS, of the servers allowed to send email for your domain.
• DKIM (DomainKeys Identified Mail) is a cryptographic signature attached to each message, proving it came from your domain and was not altered in transit.

Both are useful, and both have gaps. SPF checks a hidden technical address, not the "From" address your recipient actually sees. DKIM only helps if the receiving server knows what to do when a signature is missing. Crucially, neither tells receiving servers what action to take when checks fail - and neither tells you anything at all.

DMARC closes both gaps. It ties SPF and DKIM to the visible From address (this matching is called alignment), tells receivers what to do with failures, and creates a feedback loop of reports back to the domain owner.

How DMARC works, step by step

1. You publish a DMARC record in your domain's DNS - a single line of text. It states your policy and where reports should be sent.
2. A mail server receives a message claiming to be from your domain.
3. It checks: did the message pass SPF or DKIM, and does the passing identity align with the From address the recipient sees?
4. If at least one aligned check passes, the message is treated as authenticated.
5. If neither passes, the server applies your published policy.
6. Either way, the server records what it saw. Once a day, major providers bundle these records into an aggregate report and send it to the address in your DMARC record.

No software is installed anywhere. The entire system runs on one DNS record and the cooperation of the world's mail providers - which, for DMARC, is now very broad. Google, Yahoo and Microsoft have all tied their bulk-sender rules to DMARC since 2024, which is why even businesses that have never heard of it are increasingly required to have it.

The three policy levels

Your DMARC record contains a policy tag - p= - with one of three values. This is the instruction every receiving server follows for mail that fails authentication.

p=none - monitor only. Failing mail is delivered as normal. Nothing is blocked. You still receive reports. This is the correct starting point: it lets you see all your legitimate email sources before you risk blocking any of them. It is not protection, and treating it as protection is one of the most common mistakes in email security - we cover this in detail in Why DMARC p=none is not protecting you.

p=quarantine - treat with suspicion. Failing mail is typically delivered to spam or junk folders. A sensible intermediate step.

p=reject - block. Failing mail is refused outright. This is the destination. The National Cyber Security Centre (NCSC) recommends UK organisations progress to p=reject on all domains, including parked ones, and it is the only policy that actually stops spoofed mail reaching inboxes.

The journey from none to reject should be driven by what your reports show - not by guesswork. Move too early and you can block your own newsletters, invoices or booking confirmations sent by legitimate third-party services you had forgotten about.

What aggregate reports are - and why they matter

Aggregate reports (often called RUA reports) are XML files sent daily by receiving mail providers. Each one lists, for your domain: which IP addresses sent mail claiming to be from you, how many messages, whether SPF and DKIM passed, whether alignment passed, and what action the receiver took.

Read properly, they answer the questions that matter:

• Who is legitimately sending as us? Your mail provider, yes - but also your accounting software, your CRM, your newsletter tool, your scanner-to-email device.
• Is anyone spoofing us? Unauthenticated mail from unexpected sources, often overseas, claiming to be your domain.
• Is our own setup broken? Legitimate sources failing SPF or DKIM - the silent cause of email landing in spam.

The catch is that raw aggregate reports are unreadable in practice: dozens of XML files a day, full of IP addresses and result codes. They were designed for machines. This is the gap SealedMail exists to fill - we receive your reports, interrogate them, and send you one weekly email in plain English explaining what happened and whether anything needs attention. We have written a full walkthrough of the raw format in What does a DMARC report actually show?.

Why monitoring is essential, not optional

DMARC without monitoring is a policy you cannot safely change and a smoke alarm with the battery removed. Monitoring is what tells you:

• when a new legitimate sender appears (a marketing team signs up to a new tool) before it starts failing;
• when an existing sender breaks (a DKIM key rotates, an SPF record hits its lookup limit);
• when someone starts actively spoofing your domain - which, for many organisations, is the first time they discover it has been happening for months.

It is also, increasingly, evidence. Cyber insurers, procurement questionnaires and frameworks such as the NHS Data Security and Protection Toolkit ask not just "do you have DMARC?" but "do you monitor it?". A weekly written report you can produce from your inbox answers that question directly.

Where to start

First, find out where you stand. A DMARC record might already exist on your domain - set up years ago by a web developer, possibly still pointing reports at a service that no longer exists (a common discovery since the NCSC retired Mail Check in March 2026).

SealedMail's Free Domain Health Check audits your DMARC record alongside SPF, DKIM, MTA-STS, TLS-RPT, BIMI and blacklist status, and emails you a clear, scored certificate. It is free, with no sign-up and no follow-up sales call. From there, you will know exactly what good looks like for your domain - and if you want the ongoing reporting handled and explained for you, that is what SealedMail does, for £49 per domain per month.