A DMARC policy is the instruction in your DMARC record that tells Gmail, Outlook and Yahoo what to do with mail from your domain that fails authentication: deliver it anyway, send it to spam, or refuse it outright. The policy lives in the p tag, and for a cold email domain the right choice depends on how new the domain is, not on which setting sounds the strongest.
This page covers the three policy values, the other tags alongside p, a rollout path for a cold email sending domain, and what Google and Yahoo require. It builds on our SPF, DKIM and DMARC overview, which covers how to set up all three records. This page goes deeper on the policy itself.
What is a DMARC policy for cold email?
A DMARC policy is the p tag in a domain's DMARC TXT record, and it tells receiving mail servers what to do with messages that claim to be from that domain but fail the DMARC check. It has three possible values: none, quarantine and reject.
The policy only ever applies to mail that fails. Your own cold emails, correctly signed and sent through the servers listed in your SPF record, pass DMARC regardless of the policy. The policy exists to decide what happens to everyone else's attempts to send as your domain.
| Policy | What receivers do with failing mail | Typical use on a cold email domain |
|---|---|---|
p=none | Deliver it as normal, and send you a report | Every new sending domain, from day one |
p=quarantine | Treat it as suspicious, usually routing it to spam | Once reports show only your own mail, all passing |
p=reject | Refuse the message outright | Rarely needed on a sending domain used only for cold outreach |
A full DMARC record combines the policy with a reporting address and, optionally, a handful of other tags covered below. A minimal record for a brand-new domain looks like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com.
What is a DMARC record on a cold email domain, and how does the policy fit in?
A DMARC record is one TXT record, published at _dmarc.yourdomain.com, that combines the policy with reporting instructions and alignment settings. The version tag v=DMARC1 must come first, followed by the policy and any other tags, separated by semicolons.
DMARC passes a message when SPF or DKIM passes and the authenticated domain matches the "From" address, a check called alignment. The policy is only consulted once that check has already failed. Our SPF, DKIM and DMARC page covers how SPF and DKIM get set up before DMARC is added, which is the order that matters for a new domain.
What do the other DMARC tags do for a cold email sending domain?
Beyond v and p, a handful of optional tags control where reports go and how strictly alignment is checked. Most cold email domains only need two or three of them.
| Tag | Meaning | Typical value for a cold email domain |
|---|---|---|
rua | Mailbox that receives the daily aggregate report | A mailbox or group you actually read |
ruf | Mailbox that receives per-message failure reports | Usually left out; most cold email domains run on rua alone |
sp | Policy applied to subdomains, when different from the main policy | Leave out unless the domain has subdomains sending separately |
adkim | How strictly the DKIM domain must match the From domain, relaxed or strict | Relaxed (the default), unless you have a specific reason to tighten it |
aspf | Same strictness setting, for SPF alignment | Relaxed (the default) |
pct | In the original 2015 specification, applied the policy to only a percentage of failing mail | No longer part of the current standard, covered next |
t | New in RFC 9989: tells receivers the stated policy is being tested, so they apply one level below it | Not needed on p=none; useful when testing quarantine or reject |
The pct tag deserves its own note because most articles about it are out of date. DMARC was rewritten in May 2026 as RFC 9989, which replaces the 2015 specification, RFC 7489, and splits DMARC into three documents: the core protocol, aggregate reporting, and failure reporting. RFC 9989 removes pct from the record format entirely.
Existing records are not broken by this. The version string is still v=DMARC1, there is no DMARC2, and RFC 9989 requires receivers to ignore tags they don't recognize. A record still carrying pct=100 simply has a tag that does nothing, since 100% was always the default behavior anyway.
If your record sets pct below 100 on a reject or quarantine policy to deliberately throttle enforcement, fix that on your next edit. Receivers following the new standard no longer honor the throttle, and apply the full policy instead. RFC 9989 adds a t tag for the job pct used to do: testing a stricter policy before committing to it. With t=y, receivers apply one level below the stated policy, so p=reject; t=y is treated as quarantine and p=quarantine; t=y as none. On a new domain starting at p=none it does nothing, so only reach for it when you move up. For a new cold email domain, the practical takeaway is simple: do not add pct to a new record. It is not part of the current standard.
Which DMARC policy should a cold email domain use?
A cold email domain should start on p=none and move to p=quarantine only once its reports show every message passing. There is rarely a reason for a sending domain used only for cold outreach to go further to p=reject.
- Launch on
p=none. Mail is delivered as normal, and you get a daily report. Run this for the entire warm-up period. - Read the reports. Our guide to reading DMARC reports covers the fields to check.
- Confirm several clean reports in a row. Move on once reports show only your own mail, all passing.
- Move to
p=quarantine. Failing mail now gets treated as spam instead of delivered untouched. Your own mail is unaffected. - Leave
p=rejectfor your main business domain, not a domain built only for cold outreach. It protects against impersonation, which matters more for a brand's primary domain.
Pipefire publishes a DMARC record on every sending domain it sets up with the policy set to none and a reports address configured, as part of getting the domain ready to send. The mailbox behind that reports address still needs setting up before reports arrive anywhere you can read them; our guide to reading DMARC reports covers that step. Moving a domain beyond p=none is not something the platform does automatically today. Our setup page covers what else gets configured and checked before a mailbox goes live.
What do Google and Yahoo require of bulk cold email senders?
Google and Yahoo both require a DMARC record from any domain sending meaningful volume, though a p=none policy satisfies that requirement for both. Neither one demands p=quarantine or p=reject to start.
Google's email sender guidelines set two tiers. Every sender to Gmail needs SPF or DKIM at minimum. Senders of more than 5,000 messages a day to Gmail accounts need the fuller list:
- SPF, DKIM and a DMARC record, where the policy is allowed to be
p=none. - An aligned From address, so the authenticated domain matches what the recipient sees.
- A spam rate under 0.3% in Postmaster Tools.
- One-click unsubscribe on bulk or marketing mail.
Yahoo's sender best practices are close to identical for bulk senders. Both SPF and DKIM must be implemented, and a DMARC policy of at least p=none must be published and passing. A working rua address is strongly recommended so results can be monitored early on.
Most cold email sending stays under the 5,000-a-day Gmail threshold per domain, especially when volume is spread across several domains during warm-up. Publish full authentication anyway. Reports show providers favor senders who authenticate completely over those who meet only the bare minimum, and a brand-new sending domain needs every trust signal available to it.
Example DMARC records for each stage of a cold email domain
Copy the record that matches your domain's stage, replacing the domain and mailbox with your own. Each one is a single TXT record at the host _dmarc.
For a new domain just starting warm-up:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
For a domain with several clean reports, ready to tighten:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
For a domain ready for full enforcement, rarely needed on a sending-only domain:
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com
Add adkim=s; aspf=s to any of these if you specifically need strict alignment, though relaxed alignment, the default, is enough for most cold email setups. None of these records include pct, since it no longer does anything useful under the current standard.
How is a DMARC policy different from SPF and DKIM for cold email?
A DMARC policy is a decision about failing mail, while SPF and DKIM are the checks that decide whether mail passes in the first place.
- SPF lists which servers may send for the domain.
- DKIM signs each message so it cannot be altered in transit.
- DMARC reads the result of those two checks and applies the policy you chose.
Setting a DMARC policy without working SPF or DKIM is counterproductive, because mail that should pass gets judged against your policy by mistake instead. Confirm SPF and DKIM pass cleanly first, which the parent SPF, DKIM and DMARC guide covers in order, and only then add or tighten the policy.
A broken SPF record under a strict policy is one of the faster ways cold emails end up in spam. Check both together whenever you change either one.
DMARC policy for cold email FAQ
What is a DMARC policy in cold email terms?
It is the p tag in a domain's DMARC record, telling receivers what to do with mail claiming to be from that domain that fails SPF and DKIM: deliver it, quarantine it, or reject it. Your own correctly signed cold email is unaffected by whatever the policy says.
How do I set up DMARC for a cold email sending domain?
Add one TXT record at _dmarc.yourdomain.com after SPF and DKIM have been working for 48 hours, starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. The full setup order for all three records is on our SPF, DKIM and DMARC page.
How do I add DMARC to a new cold email domain I just bought?
Publish the _dmarc TXT record through whichever DNS provider manages the domain, using the same panel where SPF and DKIM were added. Wait for SPF and DKIM to be confirmed working first, then add the DMARC record with p=none and a reports mailbox you will actually read.
What is a DMARC record for cold email, exactly?
It is the single TXT record at _dmarc.yourdomain.com that holds the policy and its supporting tags, written as semicolon-separated pairs starting with v=DMARC1. It is distinct from the policy itself, which is just the p tag inside that record.
Does a cold email domain need p=reject?
No, and most never will. p=reject protects a domain against impersonation, which matters most for a company's main business domain. A sending domain used only for cold outreach rarely needs to go past p=quarantine.