- DMARC, defined
- DMARC is a published policy telling receiving servers what to do with mail that claims to be from your domain but passes neither an aligned SPF check nor an aligned DKIM signature.
The record lives at _dmarc.yourdomain.com and carries a policy tag plus a reporting address: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. The reporting address is the reason to publish it at all.
Alignment is the part that closes the hole. SPF validates the envelope sender and DKIM validates a signing domain, but your recipient reads neither. DMARC requires one of them to match the From domain they actually see.
Those aggregate reports arrive daily as XML from every major receiver, listing which IPs sent mail as you and how each one fared. Reading two weeks of them is how you find the invoicing tool nobody told you about.
Since February 2024, Google and Yahoo require a DMARC record from anyone sending bulk mail to their users. A p=none record satisfies the requirement, which is why publishing one is now a starting move rather than an advanced one.
How ZapBounce reports it
Your DMARC policy governs mail leaving your domain, so it never appears in a verification result. Our free DMARC checker parses the record, flags a missing rua address, and shows whether subdomains inherit the policy.
Two weeks of reports from a company that thought it had one sender
Imagine you publish p=none on a Monday and collect aggregate reports for a fortnight. Totaled up, receivers saw 41,200 messages claiming to be from your domain. Google Workspace sent 38,900 of them, and they pass SPF and DKIM with both aligned, as you'd hoped.
Another 2,100 came from your invoicing tool. SPF passes, but for the tool's own bounce domain, and the DKIM signature carries the tool's domain as well. Neither lines up with your From address, so under an enforcing policy every invoice would have been quarantined. You fix this by setting up a custom return path and custom signing in that tool.
The last 200 came from an address range you don't recognize, failing everything. That's somebody forging your domain, and it's the mail a reject policy exists to stop. Without the reports you couldn't have told these 200 apart from the 2,100.
Moving from none to reject without losing invoices
Once every legitimate source shows aligned passes, tighten in steps. Go to p=quarantine with pct=25, which asks receivers to apply the policy to a quarter of failing mail. Watch a week of reports, raise the percentage, and only then move to p=reject.
Two tags are easy to forget. The sp tag sets the policy for subdomains, and without it they inherit the main policy, which may surprise a team sending from a subdomain you've never heard of. Alignment is set by the adkim and aspf tags, which choose relaxed or strict. Relaxed is the default and lets mail.yourdomain.com align with yourdomain.com, which is what most senders want.
Stay at none if you can't read the reports yet. Enforcement without visibility is how companies block their own payroll notices. The raw XML is unpleasant to read, so point the rua address at a mailbox feeding a report parser.
DMARC: common questions
Do I need SPF and DKIM before DMARC?
Yes. DMARC evaluates their results. Publishing a policy with neither in place means every message fails, which is why p=none comes first.
What does p=none actually do?
Nothing to your mail. It asks receivers to send you reports about it. That is the point: you gather the picture before you enforce anything.
Is a DMARC record required now?
For bulk senders to Gmail and Yahoo, yes, since February 2024. A record with p=none meets the requirement.