Free Tools

DMARC Record Generator and Checker

Check a domain

We'll find the DMARC record that actually applies to this name and check it against RFC 9989.

Check a record you have not published

This reads the record itself and looks nothing up, so it cannot tell you whether an external reporting address has authorised you. Check the domain above for that.

What this checks

DMARC was re-specified in May 2026, and receivers are split across the old rules and the new ones. Some records that look correct are handled two different ways depending on who receives them, and one kind is silently doing nothing at all. Enter a domain to see which policy actually applies to it and what it is costing you.

Read the DMARC documentation for what the 2026 revision changed and how to point reporting at us, or enter a domain above to see where yours stands today.

Build a record
Start by collecting reports. Add an address below and publish p=none first. Stepping up without report data means the mail you break will be your own, and nothing will tell you which.
What should happen to mail that fails?
  1. 1 Delivers everything and stops nothing. It exists to start your reports, so you can find every legitimate sender before any of their mail is at risk.
  2. 2 Failing mail lands in the junk folder. This is the safe way to test enforcement — a sender you had forgotten is annoyed rather than invisible, and you can undo it.
  3. 3 Failing mail is turned away at the door and never reaches a mailbox. Move here once a few weeks of reports show only senders you recognise.
Why can't I roll this out to a percentage of my mail?

You used to be able to. The pct tag applied your policy to a share of failing mail and the next-weaker policy to the rest, so p=reject; pct=10 meant reject a tenth and quarantine the remainder.

The 2026 revision removed it, because receivers never implemented it consistently — the percentage published and the percentage applied were rarely the same number. Receivers that have adopted the revision ignore pct entirely and apply your full policy, so a record carrying one today is already doing more than its author intended.

Its replacement, t=y, drops your policy one step for everyone rather than for a proportion. It is the better design, and we still do not offer it: a receiver predating the revision cannot see it and applies your policy in full, so p=reject; t=y means quarantine at some receivers and real rejection at the rest, while p=quarantine means quarantine at both. The three rungs above mean the same thing to every receiver, which is the one property a staged rollout needs.

Aggregate reports arrive as XML, several times a day, from every receiver that handles your mail. Point this at something that can read them, and separate several addresses with commas.

The rest of the record
np The same choice, for subdomains that do not exist - the ones a spoofer invents.

Closes a gap sp never did: a spoofer inventing billing.yourdomain.com. It costs nothing, because there is no real mail from a name that does not exist, and a receiver that does not support it falls back to your p.

adkim How closely the DKIM signing domain has to match. Strict breaks subdomain senders.

Strict alignment. Breaks any sender that signs with a subdomain — which most bulk senders do — so leave it off unless your reports show nothing relies on it.

aspf How closely the SPF domain has to match. Strict breaks subdomain senders.

The same, for the domain SPF authenticated.

The 7 tags you are not using
sp The same choice, for existing subdomains. Without it they follow p.

Leave this alone and subdomains inherit your p, which is usually what you want. Set it when a subdomain needs treating differently, or to pin today's behaviour so a later change to p does not move it too.

ruf Where per-message failure reports go. Most receivers refuse to send them.

Copies of individual messages that failed, which means real message content and real recipients. Do not point this at us — we process aggregate reports only, so anything sent to a Report URI address is received and discarded. Use a mailbox you control, and only while you are actively debugging.

fo Which failures earn a failure report. Ignored entirely without ruf.
psd Whether this name is a public suffix. Stops the search for a policy here.

Stops the policy lookup here rather than letting it walk up the tree, which makes the answer deterministic — useful when different teams manage DNS at different levels. Set n only on the domain that really is the top of your organisation: on a subdomain it declares that subdomain its own organisation, which changes how alignment is judged. y is for registry operators running a whole public suffix.

t Asks receivers to hold off applying your policy while you test it. RFC 9989 Section 4.7

Still in the specification, and we do not offer it. It asks receivers to apply one step less than your policy while you test, but a receiver predating the 2026 revision cannot see it and applies your policy in full — so it means different things at different receivers, which is the one thing a test must not do. The three rungs above do not.

pct Used to apply your policy to a percentage of mail. Removed - upgraded receivers ignore it. RFC 9989 Section A.6

Removed by the 2026 revision, and ignored by every receiver that has adopted it. If your record still carries one, it is holding nothing back — see the explanation under the policy ladder above.

rf Used to request a failure report format. Removed, and ignored. RFC 9989 Section 9.3

Removed by the 2026 revision. It asked for a particular failure-report format, and there has only ever been one in practice.

ri Used to request how often aggregate reports arrive. Removed, and ignored. RFC 9989 Section 9.3

Removed by the 2026 revision. It asked how often aggregate reports should arrive, which receivers treated as advisory at best — almost all send daily whatever you ask for.

Publish this as a TXT record, then come back in a week and check what your reports say: 

v=DMARC1; p=none; np=reject
This record is valid, and it will stop mail that fails authentication. It will not tell you anything, though — without a reporting address you never see which of your own senders it is about to break. Add one before you move past p=none.
Type
TXT
Name
_dmarc.example.com

Published a rua address? Find out who is sending as you.

Aggregate reports arrive as XML, from every receiver that handles your mail, several times a day. Report URI turns them into a list of who is sending as you — which is the thing you need before moving off p=none without breaking your own mail.

Start Free Trial