Key takeaways
- Accepted is not delivered to the inbox. A 99.5% delivery rate is compatible with a large share of your mail sitting in spam.
- Google and Yahoo enforce authentication for bulk senders from February 2024; Microsoft applied equivalent rules to consumer domains from 5 May 2025, rejecting non-compliant mail with
550 5.7.515. - Keep the Postmaster Tools spam rate under 0.10% and never let it reach 0.30%. Reputation degrades far faster than it recovers.
- Gmail and Yahoo now weight domain reputation more heavily than IP; Microsoft still weights IP significantly. You need both to be clean.
- You cannot observe inbox placement directly. Postmaster Tools, SNDS, and DMARC aggregate reports are the only feedback the receiving side gives you.
Deliverability is the probability that a message you send reaches the place the recipient will actually look. It is distinct from delivery, which only means a receiving mail server accepted the message and did not reject it at the SMTP layer. The gap between those two things is where every difficult email problem lives, because acceptance is observable and placement is not.
For most of email’s history, the requirements for good placement were conventions — strongly advised, inconsistently enforced, and survivable to ignore. That changed in February 2024, when Google and Yahoo began enforcing a shared set of sender requirements, and again in May 2025, when Microsoft applied equivalent authentication rules to its consumer domains. Failing them no longer means landing in spam. It means an SMTP rejection.
This playbook covers what is enforced, what is scored, how to work out which of the two is hurting you, and what to do when the answer is reputation.
What is enforced, provider by provider
The three largest consumer providers have converged on nearly identical baselines. The thresholds are counted per provider — 5,000 messages a day to Gmail addresses, not 5,000 messages a day overall — and Google treats bulk classification as permanent once triggered, so dropping back below the threshold does not remove the obligations.
| Requirement | Google / Gmail | Yahoo | Microsoft consumer |
|---|---|---|---|
| Bulk threshold | 5,000/day | 5,000/day | 5,000/day |
| SPF passing | Required | Required | Required |
| DKIM passing | Required for bulk | Required, minimum 1024-bit | Required for bulk |
| DMARC published | Required for bulk, minimum p=none | Required for bulk, minimum p=none | Required for bulk, minimum p=none |
Alignment with From: | Required for bulk | Required for bulk | Required — SPF or DKIM, preferably both |
| Valid PTR / reverse DNS | Required | Required, non-generic | Required |
| TLS on delivery | Required | Required | Required |
| One-click unsubscribe (RFC 8058) | Required on marketing mail | Required on marketing mail | Expected on marketing mail |
| Spam complaint ceiling | Under 0.10%, never reach 0.30% | Under 0.30% | Monitored via SNDS |
| Rejection code on failure | 550 5.7.26 | Provider-specific | 550 5.7.515 |
The one-click unsubscribe requirement applies to marketing and subscribed messages, not to genuine transactional mail. A password reset does not need List-Unsubscribe, and adding it invites users to opt out of mail they need in order to use your product. Send it where it belongs.
The signals mailbox providers score
Meeting the enforced requirements gets your mail accepted. What happens next — inbox, tab, or spam — is decided by a scoring process no provider documents fully. The inputs are well understood in outline, and they are not equally weighted.
| Signal | Weight | What moves it |
|---|---|---|
| Spam complaint rate | Very high | Recipients clicking "report spam" — the most direct negative signal available |
| Domain reputation | Very high | Accumulated history of the sending and DKIM-signing domain |
| Recipient engagement | High | Opens, replies, moving mail out of spam, adding you to contacts |
| Authentication results | High — and a hard gate | SPF, DKIM, DMARC pass and alignment |
| Invalid recipient rate | High | Repeated delivery attempts to non-existent mailboxes |
| IP reputation | Moderate at Gmail and Yahoo, high at Microsoft | Sending history of the connecting IP, including other tenants on a shared pool |
| Volume consistency | Moderate | Sudden spikes from an identity with no history of them |
| Content and link hygiene | Lower than commonly assumed | Shorteners, redirect chains, links to domains with poor reputation |
Content sits lower on that list than most teams expect. Spam-word checkers and "spam score" tools are largely a distraction: modern filtering is dominated by sender behaviour and recipient response, not by whether the word "free" appears in the subject. If your mail is going to spam, the cause is almost never the copy.
Engagement deserves a note for transactional senders, because it is where you have a structural advantage. Password resets and receipts are opened at rates marketing campaigns cannot approach, and that engagement is a strong positive signal — provided the stream is separated so the signal is attributed to the right identity rather than averaged with your marketing mail.
Domain reputation versus IP reputation
These are two separate scores, and the balance between them has shifted. Gmail and Yahoo now weight domain reputation more heavily than IP reputation, which is why a well-run sender on a shared pool can still perform well there. Microsoft continues to weight the connecting IP significantly, which is why the same sender can see materially different results between Gmail and Outlook.com.
| Domain reputation | IP reputation | |
|---|---|---|
| Attached to | Your sending domain and DKIM d= domain | The connecting IP address |
| Portable across providers | Yes — it follows you | No — it stays with the IP |
| Who else affects it | Only you | Every tenant on a shared pool |
| Survives a provider switch | Yes | No — you start over on new IPs |
| Time to build | Weeks to months | Weeks — the warmup ramp |
| How to protect it | Stream separation, list hygiene, low complaints | Choose your neighbours, or have none |
Diagnosing a deliverability problem
Work from the outside in. The first question is always whether messages are being rejected or accepted, because those have entirely different causes and entirely different fixes.
- 1
Are messages being rejected at SMTP?
Check your bounce and failure events for
5xxcodes. A rejection is explicit and usually names its reason — authentication failure, policy block, invalid recipient. If you are seeing rejections, stop here and fix the stated cause; nothing downstream matters yet. - 2
Is the failure specific to one provider?
Break delivery and bounce rates down by recipient domain. Problems isolated to Gmail point at domain reputation or authentication alignment. Problems isolated to Outlook and Hotmail point at IP reputation. Problems everywhere at once point at authentication or a listing.
- 3
What does Postmaster Tools say?
Check the domain reputation and spam rate panels in Google Postmaster Tools. A spam rate above 0.10% explains most Gmail placement problems on its own, and a reputation of Low or Bad is a direct answer.
- 4
Did anything change in the last two weeks?
New sending subdomain, a volume increase, a new message type, a list imported from elsewhere, a template that added a tracked redirect. Reputation problems are almost always preceded by a change, and the change is usually recent.
- 5
Is the complaint rate concentrated in one stream?
If transactional and marketing mail share an identity, a marketing campaign can be the cause of a transactional symptom. Segment complaint rate by message type before concluding anything.
- 6
Are you sending to addresses that do not exist?
A rising hard bounce rate means list quality has degraded — often from a signup form without validation. Repeated attempts at invalid mailboxes are a strong negative signal in their own right.
Reading the rejection codes
| Code | Meaning | Action |
|---|---|---|
550 5.7.26 | Gmail: message not authenticated | Fix SPF/DKIM and DMARC alignment before anything else |
550 5.7.515 | Microsoft: sending domain does not meet the required authentication level | Publish SPF, DKIM, and DMARC for the sending domain and align them |
550 5.1.1 | Recipient mailbox does not exist | Hard bounce — suppress the address immediately |
550 5.7.1 | Policy rejection — often a reputation or content block | Read the accompanying text; frequently links to the provider’s postmaster page |
421 / 4.7.x | Temporary rate limiting or greylisting | Back off and retry; persistent 421 means you are sending too fast for your reputation |
452 4.5.3 | Too many recipients on one message | Split the recipient list across messages |
4xx codes are transient and should be retried with backoff. 5xx codes are permanent and must not be retried — retrying a permanent failure is itself a negative signal.The monitoring stack
You cannot see inbox placement. What you can see is a set of partial signals, and a sender who has wired all of them up will notice a problem days before one who has not.
- Google Postmaster Tools — domain reputation, IP reputation, spam rate, authentication pass rates, and delivery errors for Gmail. Register every sending subdomain separately. This is the single most valuable feedback source available.
- Microsoft SNDS — per-IP data for Microsoft consumer domains, including complaint rates and trap hits. Relevant when you have dedicated IPs, or via your provider when you do not.
- DMARC aggregate reports — XML reports from receivers listing which sources sent mail as your domain and whether they aligned. The fastest way to find an unauthenticated legitimate sender you had forgotten about.
- Feedback loops — complaint notifications from providers that offer them, routed into your suppression list automatically.
- Your own event stream — delivery, bounce, and complaint webhooks, persisted and alertable, segmented by sending domain and message type.
- Seed-list testing — sending to a panel of real mailboxes across providers to observe folder placement. Directionally useful, but a small sample and not a substitute for the above.
- Every sending subdomain registered in Google Postmaster Tools
- DMARC
rua=address publishing to a report parser - Bounce and complaint webhooks writing to suppression automatically
- Alert when complaint rate exceeds 0.1% over a rolling day
- Alert when hard bounce rate exceeds 2% over a rolling hour
- Delivery metrics broken down by recipient provider, not just in aggregate
Recovering from a reputation hit
Reputation is asymmetric: it degrades in days and recovers in weeks. There is no appeal process at the consumer providers and no button to press. Recovery is behavioural, and it works by giving the receiver a sustained run of good evidence.
- 1
Stop the source
Identify the stream, list, or message type generating complaints or invalid recipients and pause it. Continuing to send while trying to recover does not work.
- 2
Purge and suppress aggressively
Remove every address that has hard bounced, complained, or shown no engagement over a long window. Sending less to better addresses is the entire mechanism.
- 3
Reduce volume substantially
Cut to your highest-engagement recipients only — often the transactional stream alone. This raises the average quality of everything the receiver sees from you.
- 4
Verify authentication end to end
Confirm SPF, DKIM, and DMARC pass and align on every sending subdomain. A reputation problem compounded by an alignment problem will not recover.
- 5
Rebuild volume slowly
Ramp back over two to four weeks, the same way you would warm a new identity, holding at each level until metrics are stable. The warmup guide applies directly.
- 6
Separate the streams before you return to full volume
If the incident originated in marketing mail sharing an identity with transactional mail, fix that architecture during the recovery rather than after the next incident.
The part you cannot fix with configuration
Every practice above is within your control: authenticate correctly, separate your streams, keep lists clean, watch the feedback, ramp deliberately. A sender who does all of it well will outperform one who does not, on any infrastructure.
What none of it addresses is who else sends from the IP addresses your mail leaves from. On a shared pool, the IP component of your reputation is a shared asset, and when a neighbouring tenant runs a campaign that generates complaints, the degradation arrives without warning and without a lever on your side.
The structural answers are to choose a pool whose other tenants have the same incentives you do, and — above a certain volume — to stop sharing the IP layer entirely. SuperSend TX runs production mail on a network that carries transactional traffic from paying customers only: no free-tier accounts, no marketing campaigns, no cold outbound. For teams that need genuine isolation, Dedicated provisions your own mail servers and IP addresses, which we build, warm through the full ramp, and operate — with the same API contract, so nothing in your application changes when you move.
Deliverability starts with who you share IPs with
Run production mail on a transactional-only network carrying paying customers exclusively, or move to dedicated servers and IPs that we build, warm, and manage for you.
Related reading