What is DMARC? A plain-English guide for agencies

This guide is for agencies, freelancers and IT providers who look after other people's domains and need to explain DMARC to a client, or set it up for one, without a background in email. It covers what DMARC does, what the record looks like, what the three policies mean and how to reach reject without losing any genuine mail.

What DMARC does

Anyone can send an email with your client's domain in the From address. Without DMARC, the receiving server has to guess whether it's genuine. DMARC (Domain-based Message Authentication, Reporting and Conformance) lets the domain owner publish a policy that answers the question, and ask for daily reports on who is sending as them.

For a small business that means fewer convincing phishing emails in its customers' inboxes, and better delivery for its own mail. Gmail, Yahoo and Microsoft now expect it from anyone sending in bulk: see the sender requirements explained.

DMARC is defined in RFC 9989, published in May 2026 to replace the original RFC 7489. Records written for the old standard still work; the differences that matter are noted below.

How it works with SPF and DKIM

DMARC doesn't check anything itself. It builds on two older checks and adds one rule: at least one of them must pass, and match the domain in the From address. That match is called alignment.

• SPF asks: was this sent from a server the domain lists as allowed? (See SPF explained.)
• DKIM asks: is it signed with a key the domain publishes? (See DKIM explained.)
• Alignment asks: is the domain that passed the same as the one the reader sees in From?

If SPF or DKIM passes and aligns, the message passes DMARC. If neither does, the domain's policy decides what happens to it.

What a DMARC record looks like

It's a single TXT record at _dmarc in front of the domain:

v=DMARC1; p=quarantine; rua=mailto:reports@example.com

v=DMARC1

Required, and must come first.

p=

The policy: none, quarantine or reject. Always include it.

sp=

Optional policy for subdomains. Uses p= if left out.

np=

Optional policy for subdomains that don't exist in DNS, added in RFC 9989. Uses sp=, then p=, if left out.

t=

Optional test mode: y asks receivers to apply one level below p= while you test. It replaces pct=, which RFC 9989 removed in 2026.

rua=

Where to send daily aggregate reports. Strongly recommended.

adkim=

DKIM alignment: r for relaxed (the default) or s for strict.

aspf=

SPF alignment: r for relaxed (the default) or s for strict.

Our DMARC record generator writes a correct record from a few questions. If you host the record with Domain Health Hub and the domain's DNS is at Cloudflare, one click in Cloudflare's own dashboard adds it for you; see how hosted records work.

none, quarantine and reject

p=none

Report only. Nothing changes for failing mail; use it to find every sender.

p=quarantine

Failing mail goes to the junk folder. A safe middle step.

p=reject

Receivers are asked to refuse failing mail. Most large providers do, though RFC 9989 section 7.4 leaves room for a receiver's own local policy. Full protection for the domain.

A domain at quarantine or reject can also publish BIMI, the logo some mail apps show beside a message. The BIMI checker shows whether a domain qualifies.

Moving a client to reject safely

1. Publish p=none with a rua address. Nothing changes for delivery, but reports start arriving.
2. List every sender. Use the reports to find each service sending as the domain: the mailbox provider, newsletters, invoicing, the website's contact form.
3. Fix each one. Add it to SPF or, better, set up DKIM signing with the domain's own key, until each passes and aligns.
4. Move to quarantine once real mail passes consistently for a couple of weeks. Add t=y for a first, cautious step if you want to be extra careful.
5. Move to reject when the reports show only unknown senders failing. Keep watching them for new services.

For exit criteria at each stage and what to tell the client, see the staged plan from p=none to p=reject.

DMARC reports

The rua address receives an aggregate report from each large mailbox provider, usually once a day. Each lists the servers that sent mail as the domain, how many messages, and whether they passed. They arrive as zipped XML, which is why most people use a tool to read them. Domain Health Hub gives every domain its own reporting address and turns the reports into a list of senders. To read one yourself, see how to read a DMARC report.

There's also a ruf tag for forensic reports: copies of individual failing messages. Few providers still send them and they can contain personal data, so we recommend leaving it out; see forensic reports and why to turn them off.

Common mistakes

• Publishing two DMARC records. Receivers then ignore both.
• Jumping straight to reject before a newsletter or invoicing tool passes.
• Leaving a domain at none for years, which reports but protects nothing.
• Forgetting domains that never send email. Give them p=reject straight away (see protecting parked domains).

Doing this for clients? Domain Health Hub checks every client domain each day and puts the results in a monthly report card with your logo. Start a free trial; no card needed.