DMARC record checker

What DMARC adds that SPF and DKIM do not

SPF checks the sending server. DKIM checks that the message was not altered and was signed by the domain. Neither of them says what a receiver should do when the check fails, and neither of them tells you it happened.

DMARC supplies both. It sets a policy for failures, and it asks receivers to send you aggregate reports about every message claiming to be from your domain. The reports are the part people underrate, because they are the only view you will ever get of who is sending as you.

p=none, quarantine, reject

p=none means deliver everything and report. Nothing is blocked. A spoofed message that fails every check still lands in the inbox looking exactly like you.

p=quarantine sends failures to spam. p=reject refuses them at the door. Both count as enforcement, and BIMI, among other things, will not work below quarantine.

The path is to start at none, read the reports until you recognise every legitimate sender, then move up. Skipping straight to reject on a domain you do not fully understand will bounce your own invoices, and that is the specific fear that leaves so many domains parked at none forever.

The tags that matter, and the ones that do not

p is the policy and it is required. rua is where aggregate reports go, and without it you are enforcing blind. sp sets a separate policy for subdomains, which matters if you send outreach from a subdomain and want it held to a different standard.

pct applies the policy to a fraction of your mail. It reads like a safety valve and mostly is not: at pct=50 half your spoofed mail is delivered anyway, so it is a step on the way up rather than a resting place.

adkim and aspf control alignment strictness. The relaxed default is right for almost everyone. Tightening them is something you do after the reports are clean, not before.

What this means before a cold campaign

Google and Yahoo tightened bulk sender requirements in February 2024, and outbound is exactly the kind of sending that gets measured against them. A domain at p=none with a clean SPF and DKIM setup will still deliver, so this is not a blocker on day one.

It becomes one the first time somebody spoofs you, or the first time a receiver has to decide between your cold email and a slightly better authenticated one. Check SPF and DKIM at the same time; DMARC needs at least one of them to be aligned before it can pass anything.

Where does the DMARC record go?

In a TXT record at _dmarc.yourdomain.com, not on the domain itself. A record published at the apex alongside SPF is a common mistake and does nothing.

What is a safe first DMARC record?

v=DMARC1; p=none; rua=mailto:you@yourdomain.com. That blocks nothing and starts the reports flowing, which is the only way to learn what you send before you decide to enforce.

The aggregate reports are unreadable XML. Now what?

They are meant for machines. Point rua at a DMARC reporting service rather than your own inbox, several of which have a free tier at low volume. Reading raw XML from a dozen receivers by hand is how the project gets abandoned in week two.

How long before I can move to reject?

Long enough to see a full cycle of your own sending, which in practice means at least a month and often a quarter. The condition is not elapsed time, it is that you recognise every source in the reports. Invoicing systems, helpdesks, calendar tools and marketing platforms are the ones that get forgotten.

Does DMARC need both SPF and DKIM to pass?

No, either one is enough, provided it is aligned with the From domain. Alignment is the part that catches people: an SPF pass on your provider bounce domain does not align with your From address unless it is configured to.

Will DMARC at reject stop my cold email from being delivered?

Not if the mail is authenticated, which it will be when you send through your own Gmail or Outlook account. DMARC does not judge whether mail is wanted, only whether it is genuinely from you. Spam filtering is a separate question that content, volume and reputation decide.