Every domain where Winnr hosts DNS ships with a p=reject DMARC policy. It is the strictest DMARC policy and the only one that stops forged mail from being delivered at all. The usual worry, that p=reject bounces legitimate mail, applies when a domain has senders outside its SPF and DKIM setup. A single-purpose cold email domain sending only through Winnr has one sender whose mail is aligned by design, so p=reject costs your real mail nothing and blocks impersonators. If you also send from the domain through another service, set that service up first or override the policy.
The short answer
A cold email domain on Winnr is usually a single-purpose sending domain. It exists to send outreach through Winnr's mailboxes. Winnr publishes the SPF record, signs outbound mail with a DKIM key published on that domain, and runs the sending path from SMTP submission to delivery. When nothing else sends as the domain, every legitimate message passes DMARC, and that is the condition where p=reject stops being a risk.
So it is the default. A p=reject DMARC record goes on every domain where Winnr hosts DNS when it is set up, alongside SPF and DKIM, with a reporting address. There is nothing to phase in.
The rest of this article explains the reasoning, and when you should change it.
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 a message claims to be from your domain but cannot prove it. Proving it takes one of two things:
- SPF alignment: the message arrived from an IP authorized by the SPF record of the envelope-from domain (the
MAIL FROMat the SMTP layer), and that domain matches theFrom:header domain (exactly, or as a subdomain under relaxed alignment, the default). - DKIM alignment: the message carries a valid DKIM signature, and the
d=domain in that signature matches theFrom:header domain.
DMARC passes if either SPF or DKIM is aligned. If neither is, the message fails DMARC and the receiver looks at your published policy. There are three policy values:
| Policy | What it tells receivers | Effect on a forged message |
|---|---|---|
p=none |
"Report failures, but handle them as you normally would." | Can still reach the inbox. No protection. |
p=quarantine |
"Treat DMARC failures as suspicious (usually the spam folder)." | Usually lands in spam. The recipient still sees it if they check the folder. |
p=reject |
"Reject DMARC failures." | Refused during the SMTP conversation, so it never reaches the recipient. |
Receivers can still apply their own judgment (some treat a reject policy as quarantine in edge cases), but this is the model. The three policies are best read as "off, halfway, on."
Why Winnr-sent mail aligns
Fear of p=reject is reasonable only if your own outbound mail might fail alignment. Here is how Winnr sets up a domain:
SPF
Winnr publishes the domain's SPF record (starting v=spf1 and ending -all) covering the servers its mail leaves from, and keeps it current when sending infrastructure changes. The envelope sender uses your domain or a subdomain of it, so SPF is evaluated against your own domain rather than a third-party bounce domain.
DKIM
Every domain gets an RSA DKIM key published at dkim._domainkey.your-domain.com. Outbound messages are signed with d=your-domain.com, the same domain that appears in the From: header, so DKIM aligns by construction.
The result
For your mail to fail DMARC, both SPF and DKIM alignment would have to fail. SPF breaks in some cases (forwarded mail, mailing lists), but DKIM usually survives those because the signature travels with the message. A message claiming to be from your domain that fails both is very likely not yours, which is exactly what p=reject is designed to catch.
That is the asymmetry: real mail passes because the path was built that way, and forged mail fails because an attacker cannot produce a valid DKIM signature without the private key.
The "p=reject hurts deliverability" myth
The most common objection is: "Doesn't strict DMARC increase the chance of legitimate mail bouncing?" It comes from a real concern applied in the wrong place.
On a corporate domain (the main company domain your CEO emails from, with dozens of SaaS tools sending notifications under it), p=reject is genuinely risky. HR sends payroll from one vendor, sales sends from a CRM, finance sends invoices from a billing tool, marketing sends newsletters from another platform. Some of those are not in the SPF record and some don't sign with an aligned DKIM domain. Flip that domain to p=reject without inventorying every sender and real mail starts bouncing.
On a dedicated cold email domain, none of that applies as long as Winnr is the only thing sending as it. The policy has no effect on messages that pass DMARC, so for your own aligned mail p=reject and p=none behave the same. The difference shows up only on messages that fail DMARC, which on such a domain are not your messages.
The one real exception: if you connect a domain you also use with another sending service (Google Workspace, a CRM, a newsletter tool), that service must be authenticated for the domain too, or you should use a softer policy until it is. That is why the default can be overridden.
What mailbox providers actually require
Since February 2024, Google's sender guidelines require senders of more than 5,000 messages a day to Gmail accounts to publish DMARC, and p=none satisfies that requirement. Yahoo has the same rule for bulk senders. Neither requires p=reject.
We are not aware of any mailbox provider publishing that a stricter DMARC policy improves inbox placement for legitimate mail, so we don't claim it does. The case for p=reject on a cold email domain is protection, not a placement boost:
- It stops forged mail using your domain from being delivered at receivers that honor the policy.
- Forged mail that never lands can't generate spam complaints against your domain.
- It is required, together with
p=quarantine, if you ever want BIMI logos.
What p=reject actually protects you from
Without an enforced policy, anyone can run a mail server, set the From: header to founder@your-cold-email-domain.com, and send phishing to your prospects or to strangers. The message fails SPF (their IP is not in your record) and DKIM (they don't have your key), so DMARC fails. Then:
- At
p=none, the receiver handles it as normal mail, so it can still be delivered. - At
p=quarantine, it usually goes to spam. The recipient may still see it, and complaints about it are tied to your domain. - At
p=reject, receivers that honor the policy refuse it. The forged message is not delivered.
Sending domains that look legitimate are attractive disguises for invoice fraud and credential phishing. When someone reports that abuse, the report names your domain. An enforced policy makes your domain a poor target.
The counterfactual: what goes wrong at p=none or p=quarantine
p=none
- Spoofers can impersonate your
From:address and the policy does nothing to stop delivery. - Complaints about forged messages are attributed to your domain.
- You get reports, but only useful ones if someone reads them.
p=quarantine
- Forged mail usually goes to spam instead of the inbox, which is better, but it can still be seen and reported.
- No benefit over p=reject for your own mail, because aligned mail passes either way.
- Quarantine is often a "halfway" step in a phased rollout. A phased rollout matters when you have unknown senders to discover. A single-purpose domain has none.
p=reject
- Forged mail is refused at receivers that honor the policy.
- Your real mail is unaffected, because it passes alignment.
- No ongoing work.
Why p=reject is risky on a corporate domain but simple on a cold email domain
Most DMARC advice is written for the IT team at a large company that has to find which of its many SaaS vendors send unaligned mail, fix each one, and only then tighten the policy. That process is slow and error-prone, which is why "p=none, monitor, p=quarantine, monitor, p=reject" is the standard playbook.
A dedicated cold email domain is not that company. It has one sender, one SPF record and one DKIM key. The phased rollout exists to discover unknown senders, and there are none to discover. For a domain with one well-aligned sender, the strictest policy is the right one.
This is also why outreach belongs on separate sending domains rather than your main company domain. If you need new ones, cold email domains bought through Winnr come with SPF, DKIM and p=reject DMARC already published.
Overriding the default if you really want to
The default is a recommendation, not a lock. On domains where Winnr hosts DNS, the domain's DNS Records tab has an Override DMARC button (see Custom DNS Records). Set your own value, for example p=quarantine, p=none, a custom rua reporting address, sp= for subdomain policy or pct= for partial enforcement, and Winnr keeps it when it re-applies DNS. Reset to the default any time. You can also override DMARC on many domains at once from the DNS button in the Domains action bar.
If you use a DMARC report tool such as dmarcian, EasyDMARC or Valimail, a good setup is to point the rua address at it and keep p=reject.
If you are unsure, leave the default in place.
Related guides: Run a full audit with our cold email deliverability audit checklist, see how BIMI builds on an enforced DMARC policy, and check our DNS setup checklist for the record-by-record breakdown of a properly configured cold email domain.
Frequently Asked Questions
Does DMARC p=reject hurt cold email deliverability?
Not for mail that passes DMARC. The policy only affects messages that fail both SPF and DKIM alignment. On a domain that sends only through Winnr, legitimate mail is signed with an aligned DKIM key and sent from servers in the domain's SPF record, so it passes. p=reject blocks impersonators; it does not affect your real outbound. If you also send from the domain through another service, authenticate that service first.
What is the difference between DMARC p=none, p=quarantine, and p=reject?
p=none is monitoring only: failures are reported but receivers handle the mail as usual. p=quarantine asks receivers to treat DMARC failures as suspicious, usually the spam folder. p=reject asks receivers to refuse DMARC failures. p=reject is the strictest policy and the only one that stops forged mail from being delivered.
Why is p=reject safe for a cold email domain but risky for a corporate domain?
A corporate domain often has many senders (HR sending from a payroll vendor, sales from a CRM, finance from a billing platform), and some of them are not in the SPF or DKIM setup. Flipping to p=reject without finding every sender risks bouncing legitimate mail. A dedicated cold email domain sending only through Winnr has one sender, with SPF and DKIM set up by Winnr, so p=reject does not affect its real mail.
Does Gmail or Yahoo require DMARC p=reject in 2026?
No. Gmail and Yahoo require bulk senders (more than 5,000 messages a day to their users) to publish a DMARC record, and p=none satisfies that. Neither requires p=reject, and neither has published that a stricter policy improves placement. The reason to use p=reject on a cold email domain is protection against spoofing.
Can I override Winnr's default DMARC policy?
Yes, on domains where Winnr hosts DNS. Open the domain's DNS Records tab and click Override DMARC, or use the API. You can set your own value, including p=quarantine or p=none, a custom rua reporting address, or sp= and pct= tags. Reset to default puts Winnr's policy back. We recommend keeping p=reject, but the choice is yours.
How do I check that my domain is actually at p=reject?
Run dig +short TXT _dmarc.your-domain.com from any terminal, or paste your domain into a free DMARC checker (MXToolbox, dmarcian, EasyDMARC). You should see a record starting with v=DMARC1; p=reject;. If you see p=none or p=quarantine on a Winnr domain, check whether someone on your team set a DMARC override.
Will p=reject affect mail forwarding?
Rarely. When a recipient automatically forwards your message, the forwarding server resends it from its own IP, so SPF fails. DKIM usually still passes because the signature travels with the message, and DMARC passes if either SPF or DKIM aligns. Forwarding only breaks under p=reject when the forwarder also modifies the message in a way that invalidates the DKIM signature, which is uncommon.