Why DMARC can destroy your cold email reputation

1. What DMARC actually does to your mail

DMARC sits on top of SPF and DKIM. It tells receiving servers what to do when one or both of those checks fail.

The three possible outcomes per email:

• SPF or DKIM passes with alignment: DMARC passes. Mail delivered normally.
• Both fail: DMARC fails. Your policy decides what happens next.
• No DMARC record at all: the provider makes its own call. For cold email, that usually means spam.

The part most operators miss: DMARC requires alignment, not just SPF or DKIM passing. A pass without alignment does nothing for DMARC.

2. The three policy levels and what each one costs you

• p=none: monitoring only. Receiving servers log failures and send you reports but take no action on bad mail. Safe starting point. Doesn't protect your domain at all.
• p=quarantine: failing mail goes to spam. Legitimate mail that fails alignment (see section 4) ends up in the spam folder silently.
• p=reject: failing mail is rejected outright. Not spammed. Rejected. The sender gets a bounce, the recipient never sees it. If your setup has any alignment issues, mail disappears with no warning.

For cold senders: start at p=none on every new domain. Move to p=quarantine only after you've read reports and confirmed alignment is clean. Never go straight to p=reject on a cold-sending domain.

3. The p=reject disaster scenario

This happens regularly to operators who copy a DMARC record from a guide without reading what it does.

The record looks like this:

v=DMARC1; p=reject; rua=mailto:you@yourco.com

If your SPF or DKIM alignment isn't perfect, every email you send gets rejected. Not spammed. Rejected hard. The bounce message says something generic about policy failure. Your cold tool shows "bounced." Your reply rate goes to zero.

The worst part: it looks exactly like a bad list. Operators spend days A/B testing subject lines while the real problem is one line of DNS.

Secondary domains are especially vulnerable. You set up 10 domains in a batch, paste in a template DMARC record with p=reject, and half of them have an alignment issue you never caught. Those domains are dead from day one.

4. Alignment failures: SPF passes, DMARC still fails

Alignment is the most misunderstood part of DMARC. You can have SPF and DKIM both passing and still fail DMARC.

DMARC requires that the domain used in either SPF or DKIM matches the domain in the visible From address. Not just "passes" — matches.

SPF alignment: the domain in the Return-Path header must match the From domain. When a tool sends on your behalf using its own bounce domain, SPF passes on the tool's domain, not yours. Alignment fails.

DKIM alignment: the d= tag in the DKIM signature must match the From domain. If a tool signs with its own domain key, same problem.

How to check: send a test email to a Gmail address you control. Open the message, click the three-dot menu, select "Show original." Look for Authentication-Results. You want:

spf=pass (yourco.com)
dkim=pass (yourco.com)
dmarc=pass

If dmarc=fail while SPF or DKIM pass, alignment is the issue. The domain in parentheses tells you which domain authenticated. It should match your From domain exactly.

5. Subdomain policy: the setting that wipes secondary domains

DMARC has a separate policy tag for subdomains: sp=. If you don't set it, subdomains inherit the root domain policy.

The trap: you set p=reject on your primary domain to protect it. Your secondary domains don't have their own DMARC records. If those secondaries are subdomains of the primary (like mail.yourco.com), they inherit p=reject. All mail from those subdomains is rejected.

For secondaries that are separate root domains (get-yourco.com, try-yourco.com), this doesn't apply. Each needs its own DMARC record. If they don't have one, no policy applies and providers decide on their own.

Safe setup for cold domains with subdomains:

v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@yourco.com

Root domain quarantines, subdomains stay in monitoring mode until you verify alignment there too.

6. RUA reports: what they tell you and how to read them

DMARC aggregate reports (rua=) are sent by receiving providers to the email address in your record. Gmail, Yahoo, and Outlook all send them. They arrive daily, in XML.

What they contain:

• Which IP addresses sent mail claiming to be your domain.
• How many messages each IP sent.
• Whether SPF and DKIM passed or failed, and whether they were aligned.
• What DMARC disposition was applied (none, quarantine, reject).

Raw XML is unreadable. Use a DMARC report parser. EasyDMARC, DMARCLY, and Postmark's free DMARC tool all process reports into readable tables. The key things to look for:

• Any IP you don't recognize sending on your behalf. That's either a misconfigured tool or someone spoofing you.
• High volume from a sending IP with SPF pass but DMARC fail. Classic alignment problem.
• Volume from legitimate sending IPs showing DMARC fail. Your policy is blocking real mail.

Set up the rua= tag on every domain, even at p=none. You can't fix what you can't see.

7. Correct DMARC setup for cold senders

New domain, not yet sending:

v=DMARC1; p=none; rua=mailto:dmarc@yourco.com

After confirming alignment is clean (2 to 4 weeks of reports):

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourco.com

pct=10 applies the policy to only 10% of failing mail. Lets you test quarantine without nuking your entire sending volume if alignment has an edge case you missed.

Once you've run at pct=10 for a week with no unexpected drops:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourco.com

Most cold-sending setups stop here. p=reject is for primary brand domains, not secondary cold domains.

8. Common mistakes that kill deliverability

• Copying p=reject from a template. The most common. Works fine if alignment is perfect. Destroys deliverability the moment it isn't.
• No DMARC record at all. Providers fill the gap with their own judgment. For cold email, that's usually spam.
• Setting rua= to an address on the same domain. If your sending is broken, the DMARC reports will also fail to deliver. Use a different domain for the report address.
• Skipping DMARC on secondary domains. You set it up on the primary and assume secondaries inherit it. They don't unless they're actual subdomains.
• Never reading the reports. p=none does nothing without someone checking the data. Set up the rua address and actually look at it.
• Jumping from p=none straight to p=reject. There's no grace period at reject. Any alignment gap is an instant, silent delivery failure.

9. Operator FAQ