Getting an email into the inbox in 2026 depends less and less on writing the perfect subject line and more on DNS, authentication, reputation, spam rates, and sender behavior. Gmail and Yahoo maintain specific requirements for anyone sending high volumes, while DMARC just took another step forward with the publication of RFC 9989. A misconfigured domain or an IP with a bad reputation can mean throttling, rejections, or messages routed straight to spam.
Email deliverability in 20 seconds
- Gmail treats anyone sending around 5,000 messages a day to personal accounts from the same primary domain as a bulk sender.
- SPF, DKIM, and DMARC are now part of the baseline technical requirements for large senders.
- Google recommends keeping the spam rate below 0.1% and never reaching 0.3%.
- Yahoo also requires simple unsubscribes, processed within two days at most.
- IP address, DNS, reputation, and traffic separation matter just as much as content.
This shift didn’t happen overnight. Gmail tightened its requirements for bulk senders in 2024, and since November 2025 it has stepped up enforcement against traffic that doesn’t comply. Google warns that affected messages can face temporary rejections, permanent rejections, or end up in spam.
In practice, running a bulk email platform increasingly resembles operating a network service. You need to know which domains are sending, from which IP addresses, how their DNS records are configured, which applications are generating the traffic, and what percentage of recipients are marking it as spam.
Gmail turns 5,000 daily deliveries into an important threshold
Google defines a bulk sender as anyone sending roughly 5,000 messages or more within 24 hours to personal Gmail accounts.
The count isn’t done in isolation per subdomain.
If an organization sends 2,500 emails from company.com and another 2,500 from marketing.company.com, Google adds them together because they belong to the same primary domain. Once a domain crosses the bulk-sender threshold, Gmail says the classification is permanent.
That carries technical consequences.
For large senders, Gmail requires SPF and DKIM, plus a published DMARC policy. That policy can start out as simply p=none, but it has to exist.
It also requires valid forward and reverse DNS records for the servers or IP addresses used to send mail, TLS transmission, and messages that comply with RFC 5322.
There’s a requirement that tends to cause confusion: DMARC isn’t just about creating a TXT record in DNS.
For a message to pass DMARC, the domain visible in the From: header has to align with an identifier authenticated through SPF or DKIM. It’s precisely that link between the visible identity and authentication that makes domain spoofing harder.
The new RFC 9989, published in May 2026, formalizes the current DMARC specification and replaces the earlier RFC 7489 and RFC 9091. The document is part of the Internet Engineering Task Force’s (IETF) Standards Track.
RFC 9990 for DMARC aggregate reports and RFC 9991 for failure reports also arrived alongside it, splitting off into their own documents some functions that used to live inside the same specification.
A 0.3% spam rate is already too much
Reputation also isn’t measured just by whether a message was technically authenticated.
Gmail pays close attention to user complaints.
Google recommends keeping the spam rate shown in Postmaster Tools below 0.1% and avoiding reaching 0.3% or higher. Even going above 0.1% can already hurt inbox delivery.
The figure puts the problem in perspective.
With 100,000 messages delivered, 0.1% would mean 100 spam complaints. Reaching 0.3% would mean 300.
That explains why a technically sound mailing list can still see its reputation deteriorate if it contains too many recipients who no longer want those messages.
Google calculates this metric daily and notes that bulk senders with rates above 0.3% can be dropped from its mitigation mechanisms. To become eligible again, they need to stay below that threshold for seven consecutive days.
The takeaway for any email infrastructure is simple: authentication and reputation are different problems.
SPF, DKIM, and DMARC can be perfectly configured, and messages can still land in spam if recipients keep reporting them.
Yahoo requires a very similar setup
Yahoo applies a policy close to Google’s.
For bulk senders it requires SPF and DKIM, a valid DMARC policy with at least p=none, alignment between the visible domain and SPF or DKIM, forward and reverse DNS, and compliance with RFC 5321 and RFC 5322.
It also sets a spam rate below 0.3%.
Another especially important point involves unsubscribes.
Marketing and subscription emails must offer a simple opt-out mechanism, including List-Unsubscribe, and Yahoo requires requests to be processed within two days at most.
Gmail likewise requires one-click unsubscribe on promotional and marketing messages sent by bulk senders.
This requirement doesn’t generally apply to purely transactional emails like password resets, booking confirmations, or certain notifications triggered directly by a user action.
The technical mechanism is defined in RFC 8058.
The message carries the List-Unsubscribe and List-Unsubscribe-Post headers, along with an HTTPS URL the mail provider can send a POST request to in order to complete the unsubscribe without forcing the user to click through several pages.
An IP’s reputation still matters
The rise of SPF, DKIM, and DMARC hasn’t erased one of the classic elements of deliverability: the sending IP address.
Mail providers watch both domains and sending infrastructure.
A brand-new IP that suddenly starts pushing hundreds of thousands of messages doesn’t have the same history as one that has kept a steady volume for months with few complaints and properly processed unsubscribes.
That’s why IP warm-up is still used.
There’s no universal schedule that automatically guarantees a good reputation. The principle is to start with controlled volumes and recipients more likely to engage positively, then gradually increase traffic without jumps that are hard to justify.
Stability matters.
Google recommends increasing volume gradually whenever the sending pattern changes and warns that a sudden spike can cause delivery problems. Its own sender documentation also stresses sending volumes that recipients actually expect to receive.
That turns email capacity planning into something quite similar to running any other piece of infrastructure.
Switching providers, spinning up a new IP, or moving hundreds of thousands of emails to another pool shouldn’t be treated as a purely commercial decision.
Marketing and transactional email shouldn’t share every risk
One of the more useful architectural decisions is separating different types of traffic.
A password-reset email serves a completely different purpose from a promotional campaign.
The first is usually explicitly requested by the user and can be necessary to access a service. The second depends on a subscription list and carries more risk of unsubscribes, low engagement, or spam complaints.
If both share exactly the same infrastructure, a decline in commercial campaigns can potentially affect much more sensitive messages.
Separation can be done through sending domains or subdomains, distinct DKIM identifiers, and, at a certain scale, separate IP pools.
That doesn’t mean splitting traffic automatically eliminates reputation problems. Google applies certain criteria at the primary-domain level to classify bulk senders, and providers can connect different signals back to the same organization.
But operational separation makes something basic possible: knowing which application is generating which behavior.
If bounce or complaint volume rises, it should be possible to quickly identify whether it’s coming from newsletters, commercial campaigns, notifications, or transactional mail.
A blocklist isn’t the only signal worth watching
Blocklists remain a tool used across the email ecosystem, but reducing deliverability to checking whether an IP shows up on one gives an incomplete picture.
Each provider runs its own reputation and filtering systems.
An IP might not appear on a given public list and still have a poor reputation inside Gmail or Yahoo. It can also appear on a list whose real influence on major providers is minimal.
That’s why monitoring should pull together several sources.
For Gmail, Postmaster Tools provides insight into reputation, authentication, spam, and requirement compliance. Google has also added a dedicated Compliance status panel to check whether a domain meets its guidelines.
DMARC aggregate reports offer another angle: they show which IP addresses are sending mail on a domain’s behalf and let senders check SPF and DKIM results.
Teams can add their own metrics on bounces, unsubscribes, and complaints on top of that.
The goal shouldn’t be a dashboard packed with indicators, but catching early when a signal that’s normally stable starts to shift.
DMARC doesn’t replace SPF or DKIM
A common confusion is treating SPF, DKIM, and DMARC as three equivalent mechanisms.
They aren’t.
SPF lets a domain owner publish which servers are authorized to send mail on its behalf.
DKIM adds a cryptographic signature to the message so the recipient can verify that certain parts haven’t been altered and that the signature matches the stated domain.
DMARC uses the results of those authentication checks and verifies their alignment with the domain shown as the message’s visible author.
RFC 9989 defines a valid DMARC result as one where a policy exists for the author domain and at least one authenticated identifier is properly aligned.
This matters especially when marketing platforms, CRMs, support tools, billing systems, or third-party providers are involved.
A company can have ten different applications sending mail from its domain. Each one has to be properly folded into the authentication policy.
DMARC reports are useful precisely because they surface servers that are legitimately sending mail but were never documented, as well as possible spoofing attempts.
2026 turns deliverability into an operations discipline
The biggest shift isn’t in any single Gmail or Yahoo rule.
It’s that commercial email is turning into infrastructure that demands continuous technical governance.
You have to manage domains, DNS, IPs, TLS, DKIM keys, DMARC policies, reports, subscriber lists, unsubscribes, bounces, and reputation. And any provider change can shift several of those pieces at once.
A campaign can have flawless design and a compelling offer and still fall flat if the infrastructure carrying it has already lost the recipient’s trust.
The reverse is also true: perfect configuration doesn’t turn unwanted email into wanted email.
Google makes exactly this point. Its technical requirements don’t replace the need to send messages recipients actually want.
Deliverability in 2026 can be summed up like this: prove who’s sending, do it from consistent infrastructure, and make sure users don’t want to report that mail as spam.
Everything else starts from there.
Frequently Asked Questions
When does Gmail consider a domain a bulk sender?
When it sends roughly 5,000 messages or more within 24 hours to personal Gmail accounts. Google adds up sends from the same primary domain and keeps the classification permanently once it’s reached.
What spam rate does Gmail recommend?
Google recommends staying below 0.1% and avoiding 0.3%. Rates above 0.1% can already hurt inbox delivery.
Is DMARC mandatory for sending bulk email?
Gmail and Yahoo require DMARC for their bulk-sender categories. Both platforms allow starting with a p=none policy, though SPF, DKIM, and domain alignment also need to be correctly configured.
What changed with DMARC in 2026?
In May 2026, RFC 9989 was published as the new DMARC specification on the IETF’s Standards Track. It replaces RFC 7489 and RFC 9091, and is complemented by RFC 9990 and RFC 9991 for reporting.
Source: brandergroup