DMARC for Cold Email: What It Does and Why It Matters
DMARC is the most misunderstood of the three authentication records. Here's what it actually does, what the settings mean, and how to configure it correctly for cold email.
SPF and DKIM are the authentication mechanisms. DMARC is the policy layer on top — it ties SPF and DKIM together, adds an alignment check, and gives you reporting on what's happening with your domain's email authentication. Without DMARC, you're flying blind on authentication failures and spoofing attempts.
What DMARC actually does
Policy enforcement
DMARC tells receiving servers what to do when email fails SPF or DKIM: nothing (p=none), quarantine it (p=quarantine), or reject it (p=reject). The policy only matters if SPF or DKIM fail — if both pass, DMARC doesn't interfere.
Alignment checking
DMARC adds a check that SPF and DKIM alone don't do: it verifies that the domain in your From address is aligned with the domains that SPF and DKIM authenticated. This closes a spoofing loophole where someone could use your domain in the From address while authenticating through a completely different domain.
Reporting
DMARC's most underused feature: it enables aggregate reports (rua) and forensic reports (ruf) that tell you about authentication failures, delivery stats, and spoofing attempts across all email claiming to come from your domain. This is the only way to know if your domain is being spoofed.
The DMARC record structure
A basic DMARC record: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
v=DMARC1: version, always this valuep=none: policy (none / quarantine / reject)rua=mailto:...: where aggregate reports are sentruf=mailto:...: where forensic reports are sent (optional)pct=100: percentage of failing mail the policy applies to (optional, default 100)adkim=r: DKIM alignment mode (r=relaxed, s=strict)aspf=r: SPF alignment mode (r=relaxed, s=strict)
Choosing the right policy for cold email
p=none (start here)
Monitoring mode. No email is filtered based on DMARC — authentication failures are reported but not acted on. Correct starting point for any new domain. Gives you visibility before you enforce anything.
When to use: always, for new sending domains. Stay here until you've confirmed all legitimate sending sources are passing authentication.
p=quarantine
Authentication failures are sent to spam/quarantine. Use this after you've verified all your legitimate sending sources pass authentication. Not typically necessary for cold email sending domains unless you want to signal higher security posture.
p=reject
Authentication failures are rejected outright. Strongest protection against spoofing. Only use this when you're 100% confident all legitimate sending passes auth — otherwise you'll block your own email. For cold email sending domains specifically, this is usually too aggressive.
Common DMARC mistakes in cold email
No DMARC record
Without DMARC, you have no authentication reporting and no policy layer. Some providers treat missing DMARC as a mild negative signal. Add at minimum: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
rua pointing to an unmonitored email
If your rua tag points to an email nobody checks, you're not getting any value from the reporting. Use a real, monitored email for DMARC reports. Tools like DMARC Analyzer or MXToolbox can parse the XML reports into readable summaries.
Starting with p=reject
Starting with reject before you've confirmed all sending sources pass authentication will block legitimate email from your own ESP. Always start with p=none and upgrade policy only after validating auth across all sending paths.
Checking your DMARC record
Use the DMARC lookup tool to check your current record, parse all the tags, and identify any configuration issues. The tool shows what policy is in effect and whether the rua tag is correctly formatted.
Run the checks first
Before replacing anything, run a free inbox placement test. You might find the issue is DNS, not the domain — and save yourself a week of unnecessary work.