Why Winnr Uses DMARC p=reject: The Technical Case for Strict Enforcement on Cold Email Domains

The short answer

A Winnr-managed domain is a single-purpose sending domain. It exists for one reason: to send cold email through Winnr's infrastructure. Winnr controls the SPF record, signs every outbound message with a DKIM key published on that exact domain, and owns the entire mail path from MUA to MTA. There is no shadow IT, no second SMTP relay, no marketing platform piggybacking on the apex. Every legitimate message passes SPF aligned and DKIM aligned, every time. That is the precondition where DMARC p=reject stops being a risk and starts being a pure win.

So we ship it by default. v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-domain.com goes on every domain the moment it is provisioned, alongside SPF and DKIM. There is nothing to tune, nothing to phase in, nothing to monitor first. The math is already correct.

The rest of this article is the long version -- the technical case, the math, and the myth-busting -- so you can see exactly why we made this call and why softening it would be a mistake.

DMARC 101: the three policies

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS TXT record at _dmarc.your-domain.com that tells receiving mailbox providers what to do when an inbound message claims to be from your domain but cannot prove it. The "prove it" check requires two things:

1. SPF alignment: the message arrived from an IP listed in your domain's v=spf1 record, and the envelope-from domain (the MAIL FROM at the SMTP layer) matches the From: header domain.
2. DKIM alignment: the message carries a valid DKIM signature, and the d= tag in that signature matches the From: header domain.

DMARC passes if either SPF or DKIM is aligned. If neither aligns, the message fails DMARC, and the receiver looks at the policy you published. There are exactly three valid policy values:

That table is the entire DMARC enforcement model. There is nothing else to it. The three policies are not "beginner, intermediate, expert." They are "off, halfway, on." Anything less than p=reject leaves a hole that someone can drive a forged invoice or a phishing pretext through.

The alignment math: why Winnr domains pass DMARC 100% of the time

The fear of p=reject is rational only if your own outbound mail might fail alignment. On a Winnr domain, that probability is zero. Here is the configuration, step by step:

SPF

Winnr publishes a domain-specific SPF record that includes every outbound IP your mail can possibly leave from -- the KumoMTA pool serving your account, plus any overflow pools we route through. The record is rebuilt automatically if your pool assignment changes (during a migration, dedicated IP carve-out, or relay rebalance). The envelope-from is always set to a subdomain of your domain at the MTA layer, so the SPF check happens against your own domain, not a third-party bounce domain. SPF alignment is mechanical, not probabilistic.

DKIM

Every Winnr domain gets a 2048-bit RSA DKIM key published at winnr._domainkey.your-domain.com (the selector is rotated on a regular cadence). The signing private key lives on the mail server, and every outbound message is signed with d=your-domain.com -- the same domain that appears in the From: header. Alignment is structural: the signing software literally cannot produce a message where the DKIM d= tag and the From: domain disagree, because both are derived from the same database field.

The result

For DMARC to fail, both SPF and DKIM would have to fail simultaneously. SPF can soft-fail in unusual cases (forwarded mail, mailing list expansion) but DKIM survives those, because the signature travels with the message body. The only way a Winnr-sent message fails DMARC is if it is not actually a Winnr-sent message -- which is exactly the case p=reject is designed to catch.

This is the asymmetry that makes p=reject so attractive on a single-purpose domain. Real mail passes (because we built the path that way). Fake mail fails (because the attacker cannot forge a DKIM signature without the private key). The policy throws out one category and not the other.

The "p=reject hurts deliverability" myth

The most common objection we hear is: "Doesn't strict DMARC enforcement increase the chance of legitimate mail bouncing?" Let us unpack what this confusion actually is, because it comes from a real concern applied in the wrong place.

On a corporate domain (the main company domain that your CEO emails from, the one that has 47 different SaaS tools sending notifications under it), p=reject is genuinely risky. HR sends payroll from one vendor, sales sends sequences from a CRM, finance sends invoices from a billing tool, marketing sends newsletters from yet another platform. Half of those are not in the SPF record. A third are not signing with the right DKIM domain. The day you flip the corporate domain to p=reject without first inventorying every sender, real mail starts bouncing.

On a Winnr cold email domain, none of that applies. There is exactly one sender. We provisioned it. We control SPF. We control DKIM. There is no second platform, no shadow integration, no IT team adding includes behind our back. The configuration that holds at provisioning time holds forever, because there is no one else who can change it.

The deliverability impact of p=reject on a Winnr domain is therefore exactly the same as the deliverability impact of p=none -- on your own legitimate mail. Both policies have zero effect on messages that pass DMARC. The difference shows up only on messages that fail DMARC, which on a Winnr domain are by definition not your messages.

Saying "p=reject might hurt my deliverability" on a Winnr domain is like saying "I am worried this lock might keep me out of my own house." It cannot. You have the key. The lock is for everyone who does not.

Why mailbox providers reward p=reject

Beyond the safety argument, p=reject delivers a positive reputation signal at every major mailbox provider. Gmail, Yahoo, and Microsoft all factor DMARC policy into their internal sender scoring -- they have said so publicly, and Postmaster Tools at Google explicitly tracks DMARC compliance as a first-class metric.

The logic from a mailbox provider's perspective is straightforward. A domain at p=reject is making a strong public commitment: "If a message claims to be from us and cannot prove it, throw the message away." That commitment is a credible signal of operational maturity. Anyone running a phishing campaign or a spoofing attack avoids domains at p=reject, because their forged mail will be bounced at the SMTP edge. Receivers see fewer abuse complaints tied to your domain, fewer "this looks suspicious" reports, fewer authentication failures across the board.

Compare that to a domain at p=none. From a receiver's perspective, a p=none domain is saying "I don't actually care if someone forges my mail." It is the deliverability equivalent of leaving your front door unlocked. The receiver has to do all the spoofing detection work itself, and the signal you are sending is that you are not invested in your own brand integrity. That goes into the reputation score, and it goes in the wrong direction.

This effect is small per-message and large in aggregate. Over thousands of sends per domain per month, the cumulative reputation lift from p=reject is one of the cheapest deliverability wins available. We have never seen a A/B comparison where softening DMARC improved placement -- the lift always runs the other way.

What p=reject actually protects you from

The threat model is concrete. Without p=reject, anyone on the internet can spin up a mail server, set the From: header to founder@your-cold-email-domain.com, and send a phishing message to your prospects or your own colleagues. The message will not pass SPF (the attacker's IP is not in your record) and will not pass DKIM (they do not have your signing key), so DMARC will fail. But:

• At p=none, the message delivers anyway. Your prospect sees a phishing email "from you" in their inbox.
• At p=quarantine, the message hits spam. Your prospect may still see it, and your domain accumulates spam-folder reputation damage.
• At p=reject, the receiving mail server bounces the connection. The forged message is never delivered. Your domain stays clean.

This is not a hypothetical. Cold email domains are frequent targets for opportunistic spoofing, particularly when a domain shows up in any leaked sending list or scraped database. Attackers harvest sending domains that look legitimate, then use them as throwaway disguises for invoice fraud and credential phishing aimed at third parties who have no relationship with you. When that third party reports the abuse, the report lands on your domain. p=reject is the cheapest way to make your domain a worthless target.

The counterfactual: what goes wrong at p=none or p=quarantine

Let us look at the failure modes when a cold email domain runs at a softer policy:

p=none

• Spoofers can impersonate your From: address without consequence.
• Forged messages count as "your domain" in receiver abuse statistics, accumulating spam-folder reputation that suppresses your real sends.
• Gmail's reputation model assigns a lower trust tier to p=none domains, particularly any domain sending bulk mail at scale.
• If anyone leaks credentials or a list, attackers can use your apex for free for as long as the policy holds.

p=quarantine

• All the same problems as p=none, except forged mail goes to spam instead of inbox -- which still damages your reputation, because receivers count "this domain frequently appears in spam" against you.
• You get no upside compared to p=reject: legitimate Winnr mail still passes (alignment is 100%), so there is nothing to be "safer" about by softening.
• Quarantine is often picked as a "halfway" step in a phased rollout -- but a phased rollout is meaningful only when you have unknown senders to discover. On a single-purpose domain, there are no unknown senders. The phased rollout is a phased rollout to nowhere.

p=reject

• Forged mail is bounced at the SMTP edge before it ever lands in front of a recipient.
• Mailbox provider reputation models register a positive enforcement signal.
• Your real mail is unaffected, because it passes alignment.
• Zero ongoing operational cost.

It is a one-sided trade. The only argument for picking p=none or p=quarantine is "I am scared of p=reject," and that fear comes from generalizing rules that apply to corporate domains onto cold email domains where they do not.

Why p=reject is risky on a corporate domain but trivial on a cold email domain

It is worth saying this directly, because it is the source of almost every objection: the DMARC advice you read on enterprise security blogs is not written for your cold email domain. It is written for the IT team at a 500-person company who needs to figure out which of their 47 SaaS vendors are sending unaligned mail, get every one of them properly configured, and only then flip the policy. That process is slow, political, and error-prone, which is why "phased rollout: p=none, monitor, p=quarantine, monitor, p=reject" is the standard playbook.

Your Winnr cold email domain is not a 500-person company. It is a single-purpose sending domain with one sender (us), one SPF record (us), one DKIM key (us), and zero shadow IT. The phased-rollout playbook does not apply. The phased rollout exists to discover unknown senders. You have no unknown senders. There is nothing to discover.

The right policy for a domain with one well-aligned sender is the strictest one available. That is p=reject. Every time.

Overriding the default if you really want to

We believe in the default, but we also believe you should be in control of your own domain. Winnr ships a Custom DNS Records feature with a dedicated DMARC override path: set your own value -- p=quarantine, p=none, a custom rua reporting address, sp= for subdomain policy, pct= for partial enforcement, fo= for forensic reporting -- and Winnr stores it on your domain. Subsequent DNS re-syncs respect your override automatically. Reset to our default at any time.

If you have a DMARC aggregator like dmarcian, EasyDMARC, Postmark, or Valimail and want to route reports there, override the rua field and keep p=reject. That is the configuration we see most often from sophisticated customers, and it is a great setup.

If you are genuinely uncertain, the safest action is to leave the default in place. We have provisioned tens of thousands of cold email domains at p=reject with zero deliverability incidents traceable to the policy. The data is in.

Related guides: Run a full audit with our cold email deliverability audit checklist, see how BIMI requires p=quarantine or p=reject to display your brand logo in Gmail, and check our DNS setup checklist for the complete record-by-record breakdown of what a properly-configured cold email domain looks like.