Sender Reputation

Sender reputation is the receiver-side score that drives every routing decision. Inbox. Spam. Quarantine. Reject. It is not a single number; it is a multi-dimensional profile each receiver computes from their own observations. Gmail's model differs from Microsoft's. Microsoft's differs from Yahoo's. The input categories are similar across all of them, though.

Reputation exists at two levels:

• IP reputation. The sending IP's history. Tracked per individual IP, not per /24 or AS. Your dedicated IP's reputation is yours alone.
• Domain reputation. The sending domain's history. Tracked per organisational domain (example.com) and sometimes per subdomain. Domain reputation persists across IP migrations, which is why senders moving infrastructure don't start completely fresh.

Receivers combine both. A sender with great domain reputation moving to a new IP gets more grace during warmup than a brand-new sender on the same IP. A sender with bad domain reputation can't escape it by switching IPs. The domain follows you.

Roughly ranked by impact:

• Complaint rate. Recipients hitting "report spam." Above 0.3% triggers warnings at most receivers. Above 0.5% triggers active reputation damage.
• Authentication consistency. SPF / DKIM / DMARC passing aligned, on every send. One unauthenticated send doesn't hurt. Sustained inconsistency does.
• Engagement signals. Opens, replies, "not spam" classifications, dwell time. Receivers track these directly when they own the mailbox, or via DKIM-signed engagement webhooks.
• Bounce rate. Hard bounces above 2% indicate list quality issues. (See the bounce-rate entry for thresholds.)
• Spam-trap hits. One of the worst signals. Strongly suggests scraped or purchased lists.
• Sending consistency. Stable daily volume builds trust faster than spiky patterns. Sudden 10× volume increases look like spam-pattern behaviour.
• Content patterns. Spammy keywords, suspicious URLs, image-only messages, missing unsubscribe links. All of it factors in.
• Subscriber-side actions. Recipients moving messages from spam to inbox is positive. Recipients deleting without opening is mildly negative.

Non-linear. Specifically:

• Building is slow. A new IP/domain takes 30-60 days of clean, consistent sending to reach stable "good" reputation at major receivers. No shortcuts.
• Losing is fast. A single bad campaign with high complaint rate, high bounce rate, or mass spam-trap hit can drop reputation by 20-40 points in 24 hours. Receivers respond quickly to negative signals.
• Recovery is asymmetric. After a drop, returning to baseline typically takes 30-90 days of clean sending. Days to lose, months to recover. Annoying but how it works.
• Reputation decays without traffic. An IP with no sending for 3+ months loses its profile. Restarting requires a partial re-warmup. Domains decay more slowly than IPs.

Two systems operating independently with different operational implications.

IP reputation moves with the IP. Migrate to a new IP and the new IP starts fresh. Your old IP's reputation stays with whoever inherits it next (usually a different sender entirely after some quiet period).

Domain reputation moves with the domain. Migrate IPs and your domain's reputation comes with you. This is why senders with established domains can warm new IPs faster than complete newcomers, because receivers see the trusted domain on the unfamiliar IP and apply less scepticism.

Practical implication: protect your domain reputation more carefully than your IP reputation. IPs can be replaced. Domains accumulate value over years and are much harder to recover if damaged.

This drives subdomain-rotation strategies. Keep marketing volume on a marketing.example.com subdomain so any reputation hits stay isolated from the root example.com domain that handles transactional and authentication-critical mail.

If your reputation is damaged, the recovery sequence:

1. Identify the cause. Postmaster Tools, SNDS, FBL volume, bounce-rate trends. All of them point to specific issues. Without knowing the cause you're guessing.
2. Stop the bleeding. Pause sending on the affected IP/domain for 24-48 hours.
3. Address the cause. List cleaning, content audit, segmentation review, whatever the underlying issue requires.
4. Restart at low volume. 25-50% of pre-incident volume. Treat it like a partial re-warmup.
5. Monitor recovery weekly. Track Postmaster Tools and SNDS gauges. They lag actual recovery by 7-14 days.
6. Don't panic at slow recovery. Returning to "high" reputation after a "low" rating typically takes 6-8 weeks. Patience and consistency produce recovery. Aggressive volume increases just slow it down.

Reputation operates at two layers and the interaction matters operationally. IP reputation is per-sending-IP; domain reputation is per-sending-domain. Receivers track both and weight them differently across decisions.

Gmail emphasizes domain reputation. Migrating sending IPs while keeping the same domain transfers most reputation; reputation rebuild on fresh IPs is faster when the domain is established. This is why Gmail-heavy senders prioritize domain reputation discipline (consistent From: domain, aligned DKIM signing, stable subdomain patterns) over IP-level decisions.

Microsoft emphasizes IP reputation. Migrating IPs starts the reputation clock over at Microsoft regardless of domain history. This is why Microsoft-heavy senders prioritize IP-level discipline (warmup of fresh IPs, careful per-IP volume management, IP retention even when domain changes).

Yahoo and Apple sit between, weighing both with somewhat different patterns each. Smaller receivers (ProtonMail, Fastmail, regional providers) often emphasize domain reputation given their smaller IP-monitoring infrastructure.

Implication for migration strategy. Operations migrating from one ESP to self-hosted infrastructure benefit from preserving the From: domain across migration; Gmail recovery is materially faster than re-warmup of fresh domain. Operations changing brand identity (the From: domain itself changes) should expect 60-90 day reputation rebuild even on existing IPs because the domain-level reputation is starting fresh. The interaction matters more than either dimension alone.

When operations migrate infrastructure, customers often ask which reputation signals transfer to the new setup. The answer depends on the type of change and which receiver you're asking about.

Same IP, same domain, infrastructure change underneath: full reputation continuity. Receivers see the same IP and domain; their reputation tracking continues uninterrupted. Internal infrastructure changes (server hardware, MTA software, ESP relationships) are largely invisible to receivers as long as IP and domain remain stable.

Same domain, new IPs: domain reputation transfers; IP reputation rebuilds. Gmail and other domain-heavy receivers see minimal disruption; Microsoft and IP-heavy receivers see fresh-IP treatment for 30-60 days. Re-warmup the IPs at conservative volume during this window.

New domain, same IPs: IP reputation transfers; domain reputation rebuilds. Microsoft sees minimal disruption; Gmail sees fresh-domain treatment. Domain warmup proceeds with engagement-quality discipline; the IP's established reputation provides some baseline.

New domain, new IPs: full rebuild. 30-day warmup minimum, similar to launching a new sending operation. Plan accordingly; don't expect the new operation to inherit anything from the old.

Subdomain reputation under established apex: partially transfers. Receivers track per-subdomain reputation but inherit some signal from apex domain reputation. Fresh subdomain under established apex warms faster than fresh apex domain; budget 14-21 days vs 30-60 days for apex.

Google launched Postmaster Tools v2 in October 2025 and made a structural change that every sender operating against Gmail needs to internalise. The previous dashboard reported domain reputation on a four-level scale (High, Medium, Low, Bad) plus IP reputation on a similar scale. The new dashboard reports binary compliance status: Pass or Fail. There is no intermediate state.

The operational consequence is that the warning band that used to give senders weeks of degrading reputation before enforcement is gone. Under the old dashboard a sender could watch reputation drop from High to Medium, recognise the trend, and act before it reached Low. Under v2 the same situation moves from Pass to Fail with no warning, often inside a single sending cycle.

Programmes that previously relied on the High/Medium/Low gradient as their primary monitoring need to switch to leading-indicator signals. Complaint rate trend (not just absolute value) is the strongest available leading indicator. A programme running at 0.12% complaint rate is healthy; the same programme at 0.12% with a slope climbing 10% month-over-month is heading for Fail. Build monitoring that alerts on slope, not just threshold.

Microsoft's SNDS (Smart Network Data Services) still reports on a multi-state scale (red/yellow/green) and tends to lag Gmail's signals by 12-18 days in most cases. SNDS remains a useful slower-cycle signal even when Postmaster Tools v2 has moved past the warning band Gmail used to provide.

Industry guidance through 2024 typically described reputation rebuild as a 30-60 day process. The 2026 reality is closer to 60-120 days for senders coming off significant damage. Two structural changes explain the shift.

First, ISP-side classification systems rely on longer historical data windows than they did two years ago. The current crop of AI-driven filtering systems weights 60-90 days of trailing signal rather than the 30-day windows that were standard in earlier generations. A reputation rebuild that produces clean signal for 30 days no longer triggers full recovery; the receiver waits for the longer trailing window to confirm the trend before lifting restrictions.

Second, the move from soft enforcement to hard rejection (Gmail November 2025, Microsoft April 2026) means damaged reputation now produces hard SMTP rejections rather than spam-folder routing. Rejected mail does not generate the engagement signal that reputation rebuild depends on. The result is a structural feedback loop: damaged reputation produces rejection, rejection prevents engagement signal accumulation, lack of engagement signal extends the rebuild window. Senders working from genuine damage need to deliberately route the early rebuild traffic to the most-engaged subscribers who will actually open and click, in order to generate the positive signal that breaks the rejection-damage loop.

The practical implication is that the cost of letting reputation deteriorate has gone up. A 2024 incident that cost 30 days of recovery would now cost 60-90 days. Preventive monitoring and consistent list hygiene have become more important defensive strategies, not less.

Through 2023-2024 most reputation discussions focused on infrastructure inputs: authentication results, bounce rates, complaint rates, blocklist status. Those still matter. But the 2026 receiver weighting has shifted further toward engagement-based signals as the dominant input, and senders who optimise infrastructure without thinking about engagement are missing where the actual reputation lives.

Engagement signals receivers track include positive ones (opens, clicks, replies, message moves from spam to inbox, contact-list additions, forwarding) and negative ones (deletes without open, spam-folder moves, complaint reports, unsubscribes). Each individual signal carries weight; the trend across signals over time carries more weight than any individual data point.

For receivers like Gmail and Yahoo, recipient interaction has become the primary driver of placement decisions. Senders with strong engagement get inbox placement even when their absolute complaint rate is slightly elevated. Senders with weak engagement get spam-folder placement even when their authentication and infrastructure are flawless. The asymmetry is sharp enough that any reputation programme should treat engagement quality as a primary metric, not a downstream consequence of other things going right.

The operational implication is segmentation discipline. Mailing your full list every campaign maximises absolute reach but minimises engagement quality. Mailing only your most-engaged segments preserves engagement quality but reduces absolute reach. The 2026 receiver behaviour rewards the second strategy more than it used to: a segment of 100K engaged subscribers produces better delivery and ultimately better total revenue than a list of 500K subscribers where 100K are active and 400K are dormant.

The distinction matters operationally because the two reputations behave differently under infrastructure changes. IP reputation is local to the specific sending IP and does not transfer when you migrate to a new IP. Domain reputation is local to the sending domain and follows you through IP migrations.

The practical consequence is that a sender with damaged IP reputation can recover by migrating to a clean IP and warming it up, because the new IP starts fresh. A sender with damaged domain reputation cannot escape it by switching IPs; the domain follows them. The only way to reset domain reputation is to migrate to a new sending domain, which means losing all the brand equity and recipient familiarity associated with the original domain.

Most operators in this position should not migrate the domain. Rebuilding domain reputation through disciplined sending typically works within 60-120 days. Migrating the domain restarts at zero on a new identity, costs the existing recipient relationships, and creates a fresh warmup obligation that itself takes 30-60 days. Domain migration as a reputation strategy almost never pays back; it is usually the wrong answer to the right question.

The exception is when the domain has been listed on Spamhaus DBL or has reputation damage so severe that the rebuild timeline exceeds the operational tolerance of the business. In those cases new-domain launch with proper subdomain delegation from the parent brand domain can produce something useful: the new sending subdomain inherits implicit trust from the established parent without carrying the reputation damage of the original sending subdomain. This is a structural play that requires careful DNS and authentication setup.