The deliverability rules have not become stricter since February 2024. The consequences of ignoring them have. The volume threshold, the complaint rate ceilings and the unsubscribe deadline are all exactly where they were. What changed is that in November 2025 the largest mailbox provider began applying real rejections: “Gmail is ramping up its enforcement on non-compliant traffic. Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections.”
That distinction matters for a B2B newsletter, because it means the work is known and finite rather than a moving target. It also means a list that was quietly degrading for two years may now be visibly failing.
Three of the rules commonly quoted alongside the real ones turn out to have no primary source at all, and they are named at the end.
The thresholds, and the one that never expires
The published requirements split into two tiers, and the boundary between them is stickier than most people realise.
The tier boundary. “A bulk sender is any email sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period. Messages sent from the same primary domain count toward the 5,000 limit.”
And the part nobody plans for. “Senders who meet the above criteria at least once are permanently considered bulk senders … Bulk sender status doesn’t have an expiration date … Changes in email sending practices will not affect permanent bulk sender status once it’s assigned.”
Which has a practical consequence. One large announcement to a merged list, sent once, moves your domain into the stricter tier for good. Subdomains aggregate to the primary domain, so splitting sends does not undo it.
What every sender owes, at any volume. SPF or DKIM, valid forward and reverse DNS, TLS, a spam rate below the threshold, and message formatting per the internet message format standard.
What the bulk tier adds. SPF and DKIM, a published DMARC record, alignment between the visible sender domain and one of the authenticated domains, and one-click unsubscribe on marketing mail.
With a detail that saves an argument. The minimum acceptable policy is the weakest one: “Your DMARC enforcement policy can be set to none.” Publishing p=none satisfies the requirement. It is widely misreported as requiring enforcement.
This is the metric that decides whether your newsletter arrives, and the guidance contains two figures that get collapsed into one.
The sentence that carries both. “Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.”
What each level costs. “The user-reported spam rate’s impact on delivery is graduated, and rates of 0.3% or higher have an even greater negative impact on email inbox delivery. Even today, user-reported spam rates greater than 0.1% have a negative impact on email inbox delivery for bulk senders.”
And the recovery rule, which is the most operationally useful line published. “Beginning June 2024, bulk senders with a user-reported spam rate greater than 0.3% will be ineligible for mitigation … Bulk senders will be eligible for mitigation when their spam rates remain below 0.3% for 7 consecutive days.”
One measurement subtlety, from the other major provider. “Spam rate is calculated in our system based on mail delivered to the inbox.” The denominator is delivered mail, not messages sent, which means a poorly delivered send can post a worse complaint rate than a well delivered one with the same number of complaints.
Put in absolute terms for a B2B list. At 5,000 recipients, 0.30 percent is fifteen complaints. Fifteen people clicking the spam button on one send is enough to lose eligibility for support.
Which reframes the list-building question entirely. The cost of a badly acquired subscriber is not a wasted send. It is a shared reputation that every other recipient pays for.
One-click unsubscribe, and why most implementations are inert
This requirement is widely implemented and frequently implemented in a way that does not work.
What is required. Two headers, exactly: List-Unsubscribe-Post: List-Unsubscribe=One-Click and a List-Unsubscribe header containing an HTTPS URI.
What does not count. “Other types of one-click unsubscribe, such as mailto and URL unsubscribe links, don’t meet our one-click unsubscribe requirement.” And: “One-click unsubscribe links that link to a landing or other type of web page don’t comply with RFC 8058.”
The deadline. “Process and honor unsubscribe requests within 48 hours.” The other major provider phrases it as two days. Build to the shorter.
And the requirement almost nobody implements correctly. The standard is explicit: “senders MUST apply at least one valid DKIM signature to the message … The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature.” Without that, “the mail receiver SHOULD NOT offer a one-click unsubscribe for that message.”
Which means an unsigned header does nothing at all. The unsubscribe button simply does not appear. This is invisible from the sending side, and it is the most common reason a correctly configured header produces no effect.
Why the standard exists at all is worth knowing. “Anti-spam software often fetches all resources in mail header fields automatically, without any action by the user … To prevent accidental unsubscriptions, senders return landing pages with a confirmation step.” One-click exists to remove that confirmation step safely, using a POST that scanners will not issue.
With the recipient-side logic stated in the standard itself. “If an unsubscription process is too difficult, the recipient’s alternative is to report mail from the sender as junk.” A hard unsubscribe converts directly into the complaint rate that decides your delivery.
One scope limit. It applies to marketing and subscribed messages only: “Transactional messages are excluded from this requirement.”
The three providers do not agree
Building to one set of rules is not the same as building to all of them, and the differences are specific.
On volume, one publishes a number and one refuses. “A ‘bulk’ sender is classified as an email sender sending a significant volume of mail. We will not specify a volume threshold.” Any numeric threshold attributed to that provider did not come from it.
On mailto, they disagree outright. One states that mailto links do not meet the requirement. The other says “the mail-to: method is acceptable.”
On scope, the third is narrower than both. Microsoft’s requirements for high-volume senders cover authentication only: SPF must pass, DKIM must pass, and DMARC with “at least p=none and align with either SPF or DKIM.” It publishes no spam-rate threshold, no unsubscribe requirement and no TLS requirement, listing unsubscribe links and list hygiene as recommendations rather than requirements.
And its threshold wording differs from its own blog. The support page defines a high-volume sender as one who sends “5,000 or more email messages to Microsoft consumer email services” with no time window stated, while the announcement said “more than 5,000 emails per day”. Both texts are live.
What that produces in practice. Build to the strictest reading of each rule and you satisfy all three: both authentication methods, alignment, HTTPS one-click with a DKIM-covered header, a 48-hour unsubscribe, and complaint rates under 0.10 percent.
Alongside the documented requirements sit three widely repeated rules that do not come from anyone.
There is no published bounce rate ceiling. Searching the sender documentation of all three major providers returns guidance and no threshold. Gmail says to “automatically unsubscribe recipients who have multiple bounced messages” and to reduce volume if messages start bouncing. Yahoo says to “remove invalid recipients from your list promptly.” Microsoft lists bounce management as a recommendation. None states a number.
And the number people cite is not in the document they cite it from. A five percent hard bounce threshold is widely attributed to an industry working group’s best practices document. That figure does not appear in it.
What that document does contain is a usable rule. Remove an address “if it bounces consecutively at least two times over two weeks or more. This should account for any server issues on the receiving side that could have caused an erroneous bounce.” Worth noting the document is from 2015.
There is no plain-text-part requirement. Gmail’s formatting requirements cite the internet message format standard and say that HTML messages should follow HTML standards. No published requirement obliges a multipart alternative text version.
And there is no published Yahoo volume threshold, because Yahoo says explicitly that it will not publish one. Every number attributed to it is somebody’s inference.
None of this makes the underlying advice bad. Suppressing repeated bounces, sending a text part and keeping volumes modest are all sensible. They are just not requirements, and presenting them as such makes the real requirements harder to take seriously.
One thing did move, and it moved at the specification level rather than at the provider level.
The DMARC specification was replaced. The 2015 document was obsoleted in May 2026 by a successor that also replaces a 2021 update. Citing the old number as the current DMARC specification is now wrong.
And the status changed with it. The old document was Informational. The new one is Standards Track.
Three substantive changes are worth knowing. The policy tag went from required to recommended, a record without a policy tag now defaults to none, and the sampling tag was removed entirely and marked historic.
The semantics shifted too. The old text told receivers what to do. The new one describes what the domain owner considers: none means “the Domain Owner offers no expression of preference”, reject means the owner “considers all such failures to be a clear indication that the use of the domain name is not valid.”
With the receiver’s discretion made explicit. “The final handling of any message is always a matter of local policy and is left to the discretion of the Mail Receiver”, and receivers “SHOULD NOT reject messages solely because of a published policy of ‘reject’.”
Which is worth understanding before you tighten your own policy. Moving to reject does not compel anybody to reject. It expresses a position, and it can break forwarded mail and mailing lists while doing so.
The recurring cost is not the sending platform. It is four pieces of maintenance that nobody budgets.
Authentication upkeep. SPF, DKIM and DMARC records that stay correct as tools change. Every new sending tool added to the stack is a chance to break alignment, and a broken alignment is a silent failure.
Complaint monitoring. Somebody has to look at the postmaster data after each send and act on a rising rate before it crosses the line, given that recovery takes seven consecutive days.
Suppression handling within the window. Forty-eight hours is not a batch job that runs weekly. It is an automated path from the header to the list.
And list decay. Business addresses go stale faster than personal ones, because people change employers. A list you have not cleaned in two years is not the list you think you are sending to.
One thing that is not a cost. Open rate reporting, which has not measured opens reliably since privacy protections began pre-fetching images. Building a newsletter programme around it means optimising a number that is partly generated by machines.
Which leaves the metrics worth keeping. Clicks to a named destination, replies, unsubscribes, complaint rate, and whatever downstream event you actually care about. All four survive image blocking, and the last one is the only one that pays for the programme.
What to do with this
Check your alignment first, because it is the single point of failure that produces no visible error. Send yourself a message from each tool that mails on your behalf, look at the headers, and confirm the visible sender domain matches an authenticated one.
Then verify that your one-click header is covered by your DKIM signature. If it is not, the button does not appear, and no amount of correct header syntax fixes that.
Put the complaint rate somewhere a person sees it weekly, with 0.10 percent as the line rather than 0.30 percent. Recovery from the higher figure takes a week of clean sending, which is a week of a newsletter you cannot send.
What is the volume threshold for the stricter rules?
Around 5,000 messages a day to personal Gmail accounts, and the classification is permanent: 'Senders who meet the above criteria at least once are permanently considered bulk senders.'
What spam complaint rate is acceptable?
Two figures. The published guidance is to 'keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.'
Is there a maximum bounce rate?
No provider publishes one. Gmail, Yahoo and Microsoft all give guidance on removing invalid addresses without stating a threshold. The widely quoted 5 percent figure does not appear in the document it is attributed to.
Does a mailto unsubscribe link satisfy the requirement?
Not at Gmail. It states that mailto and URL unsubscribe links 'don't meet our one-click unsubscribe requirement'. Yahoo says mailto 'is acceptable'. Build to the stricter rule.