If your domain is still on DMARC p=none, you are now on a penalty track. Google and Microsoft's 2026 sender rules removed the volume threshold that used to let small senders slide. Send more than roughly 100 emails a day from a p=none domain and you're treated as a bulk sender with no enforcement policy. That means throttling, filtering, and in bad cases, domain-level blocks.
The old advice was simple: stay under 5,000 a day and nobody looks at your DMARC record. That advice is dead.
The volume loophole is gone
For most of 2024 and 2025, the bulk sender rules applied to domains sending 5,000+ messages a day to Gmail. Founders running outbound from a single domain at 200 to 800 emails a day sat comfortably under the line. No DMARC enforcement required. No visible penalty for p=none.
That changed. The 2026 rules drop the threshold to roughly 100 emails per day for enforcement purposes. Above that, your domain is assessed as a bulk sender. And a bulk sender with p=none is a bulk sender with no published policy on what to do when authentication fails.
The mechanics matter here. Under the old threshold, a domain sending 800 emails a day was evaluated as a low-volume sender, which meant receivers leaned on reputation signals and heuristic filtering rather than policy enforcement. The new threshold moves that same domain into the bulk sender category, where receivers apply the full authentication framework: alignment checks on SPF and DKIM, policy lookup on the DMARC record, and enforcement based on what that record specifies. A p=none record returns no enforcement instruction, so the receiver falls back to its own judgment. In practice, that judgment now trends toward throttling, spam placement, or outright rejection when authentication failures appear alongside other risk signals.
We saw this coming in our earlier breakdown of the Google and Microsoft DMARC volume loophole. The prediction was that p=none would become functionally equivalent to no DMARC at all. That's now the case.
What p=none actually tells the receiving server: "I have a DMARC record, but I'm not telling you what to do with mail that fails SPF and DKIM." For a domain sending 50 emails a week, that's fine. For a domain sending 500 a day, it's a signal that you either don't know your authentication is broken or don't care. Neither reads well to a spam filter.
The practical consequence is that the monitoring phase most teams treat as a permanent resting state is now a liability. p=none was designed as a transitional setting: collect aggregate reports, identify which sending sources fail alignment, fix them, then move to p=quarantine and eventually p=reject. Teams that parked at p=none because nothing broke are now exposed, because the threshold change means the enforcement they were avoiding is being applied by the receiver instead of by their own policy.
- Under 100/day:
p=noneremains tolerable; reputation signals dominate. - Over 100/day: you are a bulk sender, and
p=nonehands enforcement discretion to the receiver. - The fix: read your DMARC aggregate reports, remediate misaligned sources, and progress to
p=quarantinebefore the receiver decides forThe 0.3% spam complaint cap is now enforced
Google has published a 0.3% spam complaint rate threshold since February 2024. What changed in 2026 is enforcement. Postmaster Tools now flags domains that sustain rates above 0.3%, and sustained rates above 0.5% risk domain-level blocks.
Domain-level means exactly that. Not the sending IP. Not the individual campaign. The domain. If you're running outbound from your primary company domain and you trip the 0.5% line, you can lose the ability to send transactional email from that domain too. Password resets. Invoice delivery. Everything.
The distinction matters because it collapses a separation that most senders have relied on for years. Historically, reputation was assessed at the IP level, which meant a subdomain or a dedicated sending IP could absorb the damage from a bad campaign while your primary domain stayed clean. That buffer is gone. Google and Microsoft now evaluate reputation against the organizational domain — the root you registered — so mail.yourcompany.com and yourcompany.com share a single fate. You cannot quarantine a risky list segment behind a subdomain anymore.
Here's the math that matters. At 1,000 emails a day, 0.3% is three complaints. Three people hitting "Report spam" out of a thousand. That's not a lot of angry recipients. It's a normal Tuesday if your list quality is mediocre.
We've watched customers running outbound to UK accountancy firms hit 0.4% complaint rates from a single bad list segment. The segment was scraped from a directory that hadn't been updated in 18 months. Half the contacts had changed roles. The ones who hadn't were annoyed to receive a pitch about a service they'd already bought from someone else.
Two operational consequences follow. First, complaint rate is a lagging indicator — by the time Postmaster Tools surfaces a sustained breach, the damage is already aggregated against your domain, and recovery requires weeks of clean sending to dilute it. Second, the threshold is a ratio, not a count, which means volume growth works against you: scaling from 1,000 to 10,000 sends a day doesn't buy you more tolerance, it just raises the absolute number of complaints that trip the same 0.3% line. The only durable control is list quality at the point of entry, not suppression after the fact.
What actually moves the needle
Three things, in order of impact.
Move to p=quarantine or p=reject. If your SPF and DKIM are aligned and passing, this is a one-line DNS change. If they're not, fix them first. Run a DMARC report for two weeks, look at what's failing, and fix the sources. Most founders find it's a forgotten marketing tool or a CRM integration sending from a subdomain that was never configured.
Cut your list to people who might actually reply. The 0.3% cap is a list quality metric disguised as a deliverability metric. If you're sending to 2,000 people and getting three complaints, your targeting is too broad. Narrow the ICP. Drop the contacts you can't write a specific first line for. A 400-person list with a 0.1% complaint rate beats a 2,000-person list at 0.4% every time.
Watch Postmaster Tools weekly, not monthly. Complaint rates lag. By the time you notice a spike, you've already sent another 5,000 emails into the same bad segment. Set a calendar reminder. Check the domain reputation tab. If it drops to "Medium" or "Low," pause outbound and diagnose before you send again.
What doesn't work: switching to a new domain every time you get flagged. Google's 2026 rules track sending patterns across domains registered to the same organisation. Domain hopping buys you a few weeks and then you're back where you started, with worse reputation and no history to rebuild from.
The compliance angle nobody mentions
Deliverability and compliance are now the same conversation. The EU's GDPR enforcement has accelerated, and the ICO's AI code is law. If your outbound setup can't demonstrate lawful basis for the contacts you're emailing, a deliverability penalty is the least of your problems. We covered the GDPR fines and AI enrichment risk separately, but the short version: the same list quality problems that trigger spam complaints also trigger regulatory exposure.
The mechanism is worth spelling out, because the two regimes are converging on the same evidence. Google and Microsoft now treat authentication posture as a proxy for sender intent: a domain parked at p=none signals that you are monitoring DMARC but not enforcing it, which in practice means you cannot prove which sources are sending on your behalf. Regulators ask a structurally identical question. Under GDPR you must identify your lawful basis — consent, legitimate interest, or contract — and under the ICO's AI guidance you must be able to explain how automated enrichment selected those contacts and why they were appropriate to approach. Neither question can be answered from a spreadsheet alone.
That is why the operational fix is the same on both sides:
- Provenance: record where each address came from, when, and under what basis — not just that it exists.
- Enforcement: move DMARC from p=none to p=quarantine or p=reject so only authorised infrastructure can send as you.
- Suppression: honour opt-outs and complaints across every sending tool, not just the one that received them.
- Traceability: keep enrichment and consent records retrievable, because both an ISP and a supervisory authority may ask for them.
Clean list, clear basis, authenticated domain. That's the whole game now.
What we'd do next
Check your DMARC record today. If it says p=none and you're sending more than 100 emails a day, you have a project. The policy value is the first thing to audit, but it shouldn't be the last: p=none is a monitoring posture, not a protection one, and the 2026 rules treat it as an admission that you haven't finished the work. Moving to p=quarantine or p=reject is the destination, but the sequence matters more than the deadline. Start by confirming SPF and DKIM actually align with the From domain your recipients see — not a cousin domain, not a subdomain you forgot was in the header path. Misalignment is the most common reason teams stall at p=none for years without understanding why.
From there, the operational work breaks down into three tracks:
- Authentication: Publish a policy that matches your real sending infrastructure, then ratchet it. Use p=none only as a short diagnostic window with a defined end date, not a permanent state.
- List hygiene: Suppress hard bounces, sunset unengaged contacts, and stop treating a purchased or scraped list as a growth channel. Complaint rate is the metric that gets you filtered, and it moves faster than most teams expect.
- Volume discipline: Ramp new domains and new IPs gradually. Sudden spikes from a freshly authenticated domain read as abuse regardless of your intent.
Watch the complaint rate like it's a leading indicator, because it is — it tells you how recipients feel about your mail before the filters do. If you want a tool that scores inboxes before you send and never fires a message without you pressing the button, give MiraReach a try. We built it for exactly this moment.
— Mira