How to Set Up DMARC for Cold Email

What DMARC Does

DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) sits on top of SPF and DKIM and does three things: it requires that at least one of them passes and aligns with your From header domain, it tells receivers what to do when both fail, and it generates reports showing authentication results across all mail claiming to come from your domain.

The alignment requirement is what makes DMARC meaningful for anti-spoofing. SPF can pass for amazonses.com while your From header says yourdomain.com. Without DMARC, that mismatch is irrelevant — the SPF pass is enough. With DMARC, the domain that passed SPF or DKIM must match your From domain. A phisher who spoofs your From address cannot satisfy DMARC alignment because they cannot control your DNS records.

DMARC supports two alignment modes for each mechanism: relaxed and strict. Relaxed (the default, aspf=r; adkim=r) allows subdomains — SPF passing for bounce.yourdomain.com aligns with a From of yourdomain.com under relaxed mode. Strict requires an exact domain match. For cold email, relaxed alignment is appropriate.

Before adding a DMARC record, confirm that SPF and DKIM are both passing and aligned. DMARC evaluates whether at least one passes with alignment. If both are misconfigured, DMARC has nothing to work with and every message fails regardless of policy.

The p=none to p=reject Progression

Start with p=none. At p=none, DMARC collects reports but does not affect delivery. Mail that fails alignment goes through anyway. Publish this as your first record and monitor for at least two weeks before enforcing anything. Look for unexpected sources: a CRM you forgot, an automated notification system, a partner platform sending on your behalf. Every source with DMARC failures needs to be authenticated or confirmed before you move to a stricter policy.

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

Move to p=quarantine. Once reports show all your legitimate sending sources are passing, update the policy to p=quarantine. This routes failing mail to spam rather than the inbox. For most cold email senders, quarantine is the right long-term policy — it protects against spoofing without the risk of silently dropping legitimate mail.

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

Consider p=reject only after thorough monitoring. At p=reject, receivers refuse failing mail entirely — no bounce, no recovery. Move here only after several weeks on quarantine with clean reports. Check whether any of your sending sources use email forwarding, which can break SPF alignment in ways that cause unexpected failures under reject.

An optional tag worth knowing: pct= applies the policy to only a percentage of failing messages. pct=25 under quarantine would quarantine 25% of failing mail and let the rest through. This is useful for gradual rollout when you have many sending sources and want to catch edge cases before full enforcement. Publish the record at _dmarc.yourdomain.com as a TXT record.

SES-Specific DMARC Setup

For SES senders, DMARC alignment requires attention to two separate mechanisms.

SPF alignment. By default, SES uses amazonses.com as the MAIL FROM domain. SPF passes for that domain, but it does not align with your From header domain under DMARC. The fix is a custom MAIL FROM subdomain — configure bounce.yourdomain.com in the SES console as the MAIL FROM domain. That subdomain aligns with yourdomain.com under relaxed mode, so SPF alignment passes. The setup requires an MX record and SPF record on the subdomain — see the SPF setup guide for the exact records.

DKIM alignment. Easy DKIM on SES signs messages with d=yourdomain.com, which aligns directly with your From header domain. No additional configuration is needed. As long as Easy DKIM is enabled and the three CNAME records are published, DKIM alignment passes automatically. For cold email senders on SES, having both mechanisms aligned — custom MAIL FROM for SPF, Easy DKIM for DKIM — gives you the strongest possible DMARC result and does not depend on either mechanism alone. If one mechanism fails intermittently (a DKIM key rotation edge case, or a forwarding hop that strips SPF), the other provides a fallback that keeps DMARC passing.

Reading Aggregate Reports

DMARC aggregate reports are XML files sent daily by major providers — Gmail, Outlook, Yahoo, and others — to the address in your rua tag. Each report covers a 24-hour period and contains: the sending organization, the IP addresses that sent mail claiming your From domain, SPF pass/fail status, DKIM pass/fail status, the DMARC alignment result, and the policy applied. The count field shows how many messages that IP sent during the reporting period.

Reading raw XML is impractical. Several free tools parse reports into readable dashboards — Postmark's DMARC Digests, EasyDMARC's free tier, and Dmarcian all accept report forwarding and display results per source IP. Set one up before publishing your DMARC record so reports go directly to the tool rather than accumulating in a mailbox.

What to look for: sources with 100% pass rates are your authenticated services working correctly. Sources with partial failures typically indicate a configuration problem — an SPF alignment issue with a specific service, or a DKIM key that was recently rotated. Unknown IPs with any volume are either forwarding intermediaries (the IP will be a major mail provider like Google or Microsoft) or spoofing attempts (the IP will be unrelated infrastructure).

If reports show a consistent volume of failures from IPs you do not recognize, that is evidence your domain is being spoofed. Moving from p=none to p=quarantine will route that spoofed mail to spam rather than inboxes.

Reports also show you what percentage of your own sends are passing DMARC. A healthy sending setup shows 100% pass rate for your own IP addresses. If you see 80% pass from your SES sending IPs, that typically means some messages are failing DKIM (a key rotation issue or a relay modifying content) or SPF alignment (the custom MAIL FROM is not configured). Tracking this percentage over time is more informative than a one-off check, because problems like intermittent DKIM rotation failures only appear as patterns across multiple days of reports.

Common DMARC Failures

Jumping to p=reject without monitoring. Mail from services you forgot to authenticate is silently dropped with no error message to the sender. Always spend at least two weeks at p=none reviewing reports before enforcing any policy.

SPF alignment failure on SES without custom MAIL FROM. SPF passes for amazonses.com but fails DMARC alignment because it does not match your From domain. Your reports will show SPF pass alongside DMARC fail until the custom MAIL FROM subdomain is configured.

No rua tag. Without a reporting address, you have no visibility into what is passing or failing. DMARC without reports means you cannot diagnose alignment problems or know whether your domain is being spoofed.

DMARC on apex does not cover subdomains by default. If you send cold email from go.yourdomain.com, the apex DMARC policy applies only if the subdomain has no separate record. To explicitly control subdomain policy, add an sp= tag to your apex record (sp=quarantine) or publish a dedicated record at _dmarc.go.yourdomain.com.

pct= accidentally set to zero. pct=0 effectively disables enforcement — 0% of failing mail receives the policy treatment. If you are on quarantine but seeing no effect in reports, check whether a pct= tag is limiting policy application.