What Is DMARC? Email Security Protocol Explained

DMARC sits at the heart of any serious email security programme. SPF and DKIM tell a receiving server whether a message is authenticated; DMARC tells it what to do about the answer, and reports back so you can see who is sending mail in your name. For UK businesses worried about domain spoofing and impersonation fraud, it is the single most effective DNS-level control available.

Why does DMARC exist?

SPF and DKIM each handle one part of email authentication, but neither tells a receiving server what to do when a check fails. A message can fail SPF — sent from an unauthorised IP — and most servers still deliver it. DMARC closes that gap with an explicit policy and a reporting feedback loop.

DMARC was created by a coalition of major technology companies and email providers and published as an IETF standard (RFC 7489) in 2015. The NCSC recommends DMARC as a baseline email security control for all UK organisations, alongside SPF and DKIM. Without it, the two underlying checks generate signal that no one acts on.

This is also why DMARC matters more than people expect: spoofed email is the delivery mechanism for most business email compromise. DMARC works hand in hand with SPF and DKIM email authentication — stopping criminals from sending mail that appears to come from your exact domain removes one of their most convincing tools.

How does a DMARC record work?

DMARC is published as a TXT record in your domain's DNS at `_dmarc.yourdomain.co.uk`. The record names a policy, where to send reports, and what proportion of failing mail the policy applies to. A typical record looks like this:

``` v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.co.uk; ruf=mailto:dmarc-forensics@yourdomain.co.uk; pct=100 ```

The key tags break down as follows:

The `p=` tag is the one that matters most. `none` takes no action and only collects data; `quarantine` sends failing mail to spam; `reject` refuses delivery outright. Only `p=reject` gives full protection against spoofing of your exact domain.

What is DMARC alignment?

DMARC introduces alignment: for DMARC to pass, the domain checked by SPF or DKIM must match the From-header domain the recipient actually sees. This closes a gap where an attacker passes SPF for one domain but displays a spoofed From header for another.

There are two alignment modes, and the difference matters during setup:

For most organisations, relaxed alignment is correct and avoids breaking legitimate mail from subdomains and third-party platforms. Strict alignment is reserved for cases where subdomain impersonation is a specific, modelled threat.

What do DMARC aggregate reports show?

Aggregate reports (the `rua=` address) are sent daily by participating receiving servers. They summarise every source sending mail in your name: sending IP addresses, whether SPF and DKIM passed, which policy was applied, and message volumes. They are XML, so they need a reporting tool to read.

These reports are the whole point of a careful rollout. During the monitoring phase they reveal every service sending email on behalf of your domain — including the ones you forgot about, like an old CRM, a marketing platform, or an invoicing tool. Services such as DMARC Analyzer, Postmark DMARC, Valimail and DMARCian parse the XML into readable dashboards. Reading these reports before you enforce is how you avoid blocking your own legitimate mail.

How do you roll out DMARC safely?

Jumping straight to `p=reject` is the most common DMARC mistake. Without preparation it blocks legitimate mail from sources that are not yet authenticated, triggering pressure to revert. The safe path is staged: monitor, fix, tighten, then enforce — typically over 6 to 12 weeks.

The sequence AMVIA follows for UK businesses:

1. Configure SPF and DKIM for every legitimate sending source 2. Deploy DMARC with `p=none` and switch on `rua` reporting 3. Review aggregate reports over 2–4 weeks to map all senders and their pass rates 4. Fix SPF or DKIM failures on legitimate sources 5. Advance to `p=quarantine`, starting at a low `pct` and increasing to 100% 6. Monitor for false positives over 2–4 weeks 7. Advance to `p=reject`

Most businesses that have DMARC at all are stuck at step 2 — `p=none` monitoring mode they never progressed past. That state gives you visibility but no protection. The work is in steps 3 and 4: identifying every legitimate sender and getting it properly authenticated before you turn on enforcement.

How does DMARC fit with Microsoft 365?

If your mail runs on Microsoft 365, DMARC works alongside Exchange Online's built-in SPF and DKIM. Microsoft publishes the SPF include and DKIM signing settings; you add the DMARC record in your own DNS and point reporting at a service you can read. The platform handles authentication, but the policy decision is yours.

Microsoft's own DMARC guidance walks through enabling DKIM signing for custom domains and publishing the DMARC record. The common failure point for M365 tenants is third-party senders — marketing tools, ticketing systems, finance apps — that send "as" your domain without being included in SPF or signed by DKIM. Those are exactly what the aggregate reports surface before you enforce.

What DMARC does not stop

DMARC is precise: it stops spoofing of your exact domain in the From header. It does not stop everything that looks like email fraud, and treating it as a complete defence is a mistake.

It does not prevent:

• Typosquatting — a lookalike domain such as `amvia-uk.co.uk`
• Display-name spoofing — a friendly name that hides a different domain
• Compromised legitimate accounts — real mail from a hijacked mailbox

These need additional controls: domain monitoring, email gateway impersonation detection and phishing protection, and user-awareness training. DMARC is a foundational layer in a broader managed cybersecurity programme, not a standalone fix.