DMARC Policy for Cold Email Domains: Which One to Use First

Start a new cold email domain on p=none. Publish a DMARC record with p=none and a rua address (the email address that receives the reports) so the reports come back to you, and leave it there through warm-up and the first weeks of live campaigns. Tighten to quarantine, and later to reject, only after the reports show every tool you send from passing and aligned.

On none, a broken setup costs you a row in a report. On reject, the same broken setup costs you a campaign, and nobody sends you a warning.

The mistake I see founders make is copying p=reject advice written for a company's main domain onto an outreach domain that went live three days ago. The two domains carry different risks, so they get different policies.

Is p=none enough for Gmail's sender rules?

Yes. Gmail asks bulk senders to authenticate with SPF and DKIM and to publish a DMARC record, and the policy on that record may stay at none (Gmail sender guidelines). So a p=none record already meets the requirement.

Google's own setup guide for Workspace admins gives the same starting advice: begin with none and move to quarantine or reject over time (Google Workspace Admin Help).

Microsoft says the same for Outlook. Microsoft's Defender for Office 365 blog advises moving gradually from none to quarantine to reject to avoid unintended mail loss.

Other mailbox providers publish their own sender pages and revise them, so check the current version of each before you plan around it.

Keep the policy question apart from sender hygiene. Hygiene is everything else that decides where a cold email lands: separate domains, warm-up, verified lists and a sane daily volume per mailbox. A perfect DMARC record will not save a domain that mails unverified lists. If a domain already got listed, that is a different repair job, namely recovering a blacklisted domain.

The order of work does not change either. SPF, DKIM and DMARC go live before the domain sends anything at volume.

What does p=none actually do on an outreach domain?

Google's guide lists the instructions DMARC can give a receiving server about mail that fails: reject it, quarantine it or deliver it. A p=none policy is the deliver instruction. Receivers handle failing mail the way they normally would and send aggregate reports to the address in your rua tag.

The record is one TXT entry, published at _dmarc.youroutreachdomain.com:

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

What you get for it is visibility while the setup is still moving. A cold sending stack has more parts than founders expect (a typical cold email tool stack shows how many): the mailbox provider, the sequencing tool, sometimes a warm-up service, sometimes a CRM that sends follow-ups in your name. Any one of them can send as your domain without signing correctly.

A misconfigured tool shows up as a failing row in next week's report. Without that row, the quiet campaign gets blamed on the copy first, and copy cannot fix a weak sender.

There is a price. A p=none policy does nothing against spoofing. Anyone can put your outreach domain in a From line, and receivers are not asked to act on it. You see it in a report and that is all. That risk is fine for a few weeks on a cold domain. Left there for a year, it means nobody is looking.

p=none vs p=quarantine vs p=reject: when should a cold domain tighten?

Move one step at a time, and only when two conditions hold together: every source sending as the domain is one you recognize, and each of those sources passes with alignment in report after report.

The rollout dmarc.org describes is the same sequence: publish with none, then move to quarantine, then to reject (dmarc.org overview). None of these guides starts a domain on reject.

These are the rules I would hand a founder who runs secondary sending domains:

1. New or warming domain: p=none. No exceptions: the weeks of domain warm-up are the weeks of p=none.
2. Anything in the stack changed: stay on none, or drop back to it. A new sequencing tool, a new mailbox provider, new IPs or a CRM that starts sending as you all count. Wait until the reports show the new source passing and aligned.
3. Quarantine after several weeks of clean live sending. Clean means only your known sources appear and every one passes with alignment. Warm-up traffic alone is too thin to judge.
4. Reject only once the domain has stopped growing. The mailbox count is fixed, the tools are fixed, and a full quarantine period never caught your own mail.
5. Never tighten the week before a launch or a scale-up. When volume is about to rise, the policy waits until the new volume shows up clean in the reports.
6. Treat your main company domain as its own decision. It carries invoices, contracts and support replies, so spoofing hurts it most and it has the strongest case for reaching reject.

p=reject is the right end state for a cold domain, once the domain earns it. A domain that has run for months on the same mailboxes and the same tools, with a clean quarantine stretch behind it, can hold reject safely.

Why does alignment matter more than the policy?

Alignment decides whether DMARC passes at all, so it comes before any policy choice. DMARC passes only when the domain in the visible From line matches a domain that SPF or DKIM authenticated. Gmail's guidelines put it plainly for direct mail: the From domain has to align with the domain SPF or DKIM authenticated (Gmail sender guidelines).

When alignment fails, the policy only chooses where you see the failure.

The typical cold email version is a sending tool that signs DKIM with its own shared domain instead of yours. The bounce address can also sit on the tool's domain. SPF and DKIM then both pass, neither matches your From domain, and DMARC fails anyway.

You can test this in five minutes. Send one message from each tool to a personal Gmail inbox and open "Show original". Read the SPF, DKIM and DMARC lines, then find the domain after d= in the DKIM signature. It should be your outreach domain. If it is the tool's domain, fix the signing before you touch the policy.

My team sends cold email from domains bought for that purpose. A subdomain of your main domain puts your real brand domain into every cold From line, which is the exposure separate domains are meant to remove. If you do send from a subdomain anyway, give it aligned DKIM and a policy you picked on purpose.

How do you read DMARC aggregate reports from cold email?

Aggregate reports are what your rua address collects: summaries from receiving providers of how mail carrying your domain was authenticated. They arrive by email at the address in the rua tag of your DMARC record (DMARC.org). Outlook sends them there too, per Microsoft's Defender for Office 365 blog.

If that address sits on another domain, such as a report parser's, DMARC.org explains that the other domain must publish a DNS record with the contents "v=DMARC1" before reports can go there. The raw files are XML and hard to read by eye, so run them through a report parser and work from the table it gives you.

Check six things for each sending source:

1. Source. Every IP should be one you can name, such as your mailbox provider or your own sending IPs.
2. Volume. It should roughly match what you sent that week. A known source with far more volume than your campaigns means something else is sending through it.
3. SPF result and domain. A pass, on a domain that matches your From domain.
4. DKIM result and signing domain. A pass, signed with your domain and never a tool's.
5. DMARC result. A pass for every legitimate source. When SPF and DKIM pass but DMARC fails, look at alignment first: the right tool is signing with the wrong domain.
6. Unknown sources. Small, scattered volume from IPs you do not know can be recipients forwarding your email, which breaks SPF alignment. Steady, failing volume from unknown IPs is a tool someone forgot to mention, or someone sending as you.

A healthy report shows known sources only, all aligned, with volumes that match your sending. Several weeks of that is the clean signal rule 3 asks for. Anything else keeps the domain on none until the source is fixed.

What changes when you run many outreach domains?

For cold email that usually means between 10 and 20 domains carrying 20 to 40 mailboxes, and bigger sales teams need more. That is a lot of DMARC records to keep in step. A fresh mailbox warms up for 10 to 14 days at the very least before it writes to a single prospect, and a sensible rule is to keep the bounce rate under 0.5%.

Two habits carry over to any sender. Dedicated sending IPs keep reports short: the list of legitimate sources is known, so anything else stands out on the first screen. And the warm-up weeks are exactly when p=none pays for itself, because mailboxes and tools are still being added.

I treat the domain like any funnel. A funnel that does not convert at small numbers will not start converting at big ones, and without foundations it makes no difference whether you push 100,000 emails out this week or next month. The DMARC reports are that small-numbers test for the domain. Prove it clean on p=none with a few mailboxes first, then scale, then tighten the policy.

The part founders skip is ownership. Whoever runs your sending, name one person who reads the reports every week. A p=none domain that nobody reads protects nothing. A reject policy that nobody watches fails just as quietly, and the mail it drops is your own.

The newer DMARC standard (covered in the last question below) changes nothing about the rule for a new outreach domain: start on p=none and read the reports weekly. Fix the sources first. Then tighten.

If you are setting up outreach domains and want a second look at your DMARC record or first report, send the record beforehand. Book a call.