Skip to content

DMARC for Cold Email: Policies Explained

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that tells receiving servers what to do when an email claiming to come from your domain fails authentication, and where to send reports about it. For cold email it does two useful things: it satisfies bulk-sender authentication requirements, and its reports show you who is sending mail as your domain. No single DMARC policy is required to send.

What DMARC actually does

DMARC sits on top of two older standards: SPF and DKIM. On its own, neither SPF nor DKIM tells a receiving server what to do with a message that fails. DMARC adds two things: a policy (what action to take on failures) and reporting (where to send feedback).

A DMARC record is a single TXT entry published at _dmarc.yourdomain.com. A minimal one looks like this:

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

The p= value is the policy. The rua= value is the address that receives aggregate reports. That is the core of it.

Alignment: the part that matters most

DMARC does not just check that SPF or DKIM passed. It checks alignment — whether the domain that passed authentication matches the domain in the visible From: address.

  • SPF alignment: the domain SPF validated (the envelope sender) matches the From: domain.
  • DKIM alignment: the domain in the DKIM signature matches the From: domain.

A message passes DMARC if it is aligned on either SPF or DKIM. It only fails DMARC — and triggers your policy — when both are unaligned. This is why a domain can have a valid SPF record yet still fail DMARC: the SPF check passed for a different domain than the one in the From: line. For cold email, getting DKIM alignment right is usually the more reliable path, because DKIM survives forwarding where SPF often does not.

The three DMARC policies

The policy tells receiving servers what you want them to do with mail that fails alignment. There are three values.

PolicyWhat you ask receivers to doTypical use
p=noneTake no action; just send reportsMonitoring, early rollout, gathering data
p=quarantineRoute failing mail to the spam folderEnforcing after alignment is confirmed
p=rejectBlock failing mail outrightStrict enforcement, mature setups

A few points worth being precise about:

p=none still counts as having DMARC. The bulk-sender requirements ask for a published DMARC record — they do not mandate enforcement. A record at p=none with aligned SPF and DKIM passes the authentication check.

Enforcement protects your domain, not your deliverability. quarantine and reject reduce the chance that someone spoofs your domain. They do nothing to push your own legitimate cold email into the inbox. That is governed by reputation, targeting, and complaint rate — see the cold email deliverability guide.

pct= lets you ramp. A tag like pct=25 applies the policy to a percentage of failing mail, which some senders use to test enforcement gradually before committing to 100%.

Where DMARC fits in the bulk-sender requirements

Since February 2024, Google and Yahoo have required bulk senders to authenticate with SPF, DKIM, and DMARC, offer one-click unsubscribe, and keep spam complaint rates low — commonly cited as under roughly 0.3%. The DMARC piece of that is a published record. It does not specify which policy you must run.

This is the practical reason cold-email senders publish DMARC: it is a checkbox the major receivers now expect to be ticked. Whether you run none, quarantine, or reject behind it is a separate decision about how strictly you want to defend the domain against spoofing.

DMARC reporting: the underused part

The rua= tag turns on aggregate reports — daily XML summaries that participating receivers send back. They show, per source IP and per domain, how much mail passed and failed SPF, DKIM, and alignment.

For cold email run across many sending domains, these reports are the cleanest way to confirm that your authentication is actually aligning in the wild, not just in a validator. They surface two things quickly:

  • Legitimate sources that are failing alignment because of a misconfiguration.
  • Unauthorised sources sending mail that claims to be your domain.

A second tag, ruf=, requests forensic (per-message) reports, but most receivers no longer send these for privacy reasons, so rua= is where the signal lives.

A note on what DMARC does not do

DMARC is an authentication and policy layer. It is not a deliverability lever, and it is certainly not a compliance one.

A perfectly aligned p=reject record does not make your mail wanted, and it does not change the legal position of an unsolicited message. Consent and local law sit entirely with you as the sender. Germany’s UWG §7(2) generally requires prior opt-in for advertising email, including B2B. Authentication and consent are two different problems — see is cold email legal for the consent side. This is not legal advice.

How Mailionaire approaches this

Every sending domain we provision is set up with SPF, DKIM, and DMARC configured automatically across its own isolated Microsoft 365 tenant, so alignment is correct from the first send rather than something you debug later. The shipped DMARC policy is p=none — a published record that meets the bulk-sender check while you keep the option to tighten enforcement yourself. Pricing stays flat at $50 per active domain. You can see the full setup on the how it works page.

FAQ

What DMARC policy should I use for cold email?

There is no single required policy. A published DMARC record satisfies bulk-sender authentication checks regardless of whether the policy is none, quarantine, or reject. Many senders start at p=none to gather reports, then tighten only after confirming SPF and DKIM align cleanly. The right setting depends on your domain, not a universal rule.

Does DMARC improve cold email deliverability?

DMARC's direct job is authentication and policy signalling, not placement. Having a valid DMARC record alongside aligned SPF and DKIM meets the Google and Yahoo bulk-sender requirements. It does not guarantee the inbox — content, targeting, complaint rate, and reputation still decide where mail lands.

What is the difference between p=none, quarantine, and reject?

p=none asks receivers to take no action on failing mail and only send reports. p=quarantine asks them to route failing mail to spam. p=reject asks them to block it outright. All three publish a policy; they differ only in what a receiver does when a message fails both SPF and DKIM alignment.

Does setting up DMARC make my cold email legal?

No. DMARC is a technical authentication control, not a consent mechanism. Legality depends on the recipient's jurisdiction and whether you have a lawful basis to email them. Germany's UWG §7(2) generally requires prior opt-in even for B2B. The sender stays responsible. This is not legal advice.


Mailionaire provisions real, isolated Microsoft 365 mailboxes for cold email — built in Switzerland, with optional EU/Swiss data residency — then monitors and replaces them as they wear out. One flat price per domain. See how it works →