Gmail, Microsoft, and Yahoo each evaluate two distinct reputation signals when deciding where to deliver your email: the reputation of your sending IP address and the reputation of your sending domain. These signals behave differently, decay at different rates, and require different remediation strategies when damaged. Confusing the two — trying to fix a domain reputation problem by changing IPs, or trying to fix an IP problem by improving content — is the most common mistake senders make during deliverability recovery.
What Domain Reputation and IP Reputation Actually Measure
Understanding the mechanics of each signal is essential for choosing the right recovery strategy.
IP reputation is the sending history associated with a specific IP address. Every complaint, bounce, spam trap hit, and engagement signal from that IP accumulates into a reputation score at each ISP. IP reputation is local to the ISP — your IP may have a High reputation at Gmail and a Low reputation at Microsoft simultaneously. IP reputation is also time-limited: most ISPs use a rolling 30-day window, meaning old negative signals age out if you stop sending problematic mail from that IP.
Domain reputation tracks the From: header domain across all IPs it has ever sent from. Gmail's domain reputation system, for example, observes engagement patterns for yourcompany.com regardless of whether you sent from 10.0.0.1, 10.0.0.2, or a Mailchimp shared pool. Domain reputation is slower to build and slower to recover because it aggregates signals across your entire sending history.
Signal Independence — Same Sender, Different IP and Domain Reputations at Gmail
Reading Both Signals in Gmail Postmaster Tools
Gmail Postmaster Tools shows both domain reputation and IP reputation as separate panels. Domain Reputation shows the reputation of your From: header domain. IP Reputation shows the reputation of each sending IP you use, listed individually if you use multiple IPs. The panels update with a 24–48 hour lag and use a four-level scale: High, Medium, Low, Bad.
The critical distinction: if your domain reputation is High but your IP reputation is Low, your messages will still be delivered to the inbox at a reasonable rate — Gmail leans on domain reputation heavily once it is established. If your domain reputation is Low regardless of IP, changing to a new clean IP will not recover inbox placement. The domain signal follows you.
| Domain rep | IP rep | Expected outcome | Which to fix first |
|---|---|---|---|
| High | High | 95-98% inbox placement | Maintain — no action needed |
| High | Medium | 88-94% inbox — some filtering | IP warm-up / throttle adjustment |
| High | Low | 70-85% inbox — noticeable impact | Rest the IP; send from clean IP temporarily |
| Medium | High | 70-88% inbox — domain dragging down | List segmentation; engagement focus |
| Medium | Medium | 55-75% inbox — dual issue | List first, then IP warm-up protocol |
| Low | High | 20-40% inbox — domain is the bottleneck | Aggressive list cleanup; do not change IPs |
| Low | Low | <10% inbox — critical recovery mode | Full pause, list rebuild, systematic recovery |
Microsoft — How Domain and IP Reputation Interact
Microsoft's reputation system (EOP — Exchange Online Protection) also evaluates both domain and IP signals, but the tooling available to senders is less transparent than Gmail. SNDS (Smart Network Data Services) shows IP-level data: complaint rate, trap hits, and block status per IP. Domain-level reputation at Microsoft is less directly observable but is inferred through delivery patterns: messages from the same domain seeing consistent rejection across multiple clean IPs indicates a domain-level issue rather than an IP issue.
Microsoft's May 2025 enforcement changes raised the weight of domain-level authentication signals. After May 2025, a domain without proper DMARC alignment began receiving 550 5.7.515 regardless of IP reputation. This is a pure domain signal — clean IPs make no difference if the domain's authentication is not configured correctly.
# IP reputation problem — symptoms: # - 550 5.7.520 or 550 5.7.1 on specific IPs # - Clean IPs from same domain deliver normally # - SNDS shows red status on blocked IP(s) # Fix: SNDS delist request for blocked IP; clean list; register JMRP # Domain reputation problem — symptoms: # - 550 5.7.515 on DMARC alignment failure # - All IPs (including fresh ones) see similar rejection rates # - Authentication-Results shows dmarc=fail regardless of IP # Fix: SPF/DKIM/DMARC authentication fix — not an IP problem # Both problems simultaneously: # - Some IPs blocked (SNDS red) AND dmarc=fail # Fix: Authentication first, then IP delist request # Delisting before fixing auth → re-listed within days
Recovery Strategy by Scenario
▶ Scenario 1: IP reputation damaged, domain reputation intact
▶ Scenario 2: Domain reputation damaged, IP reputation intact
Situation: After migrating to a new ESP (and new sending IPs), Gmail inbox placement dropped from 93% to 31%. The team assumed the new IPs needed warming and started a standard IP warm-up protocol — which made no difference after 6 weeks.
Diagnosis: Postmaster Tools showed IP reputation: Medium (acceptable). Domain reputation: Low (the problem). The migration had nothing to do with the issue — domain reputation had been declining for 4 months due to growing unengaged list segments from a product sign-up integration that was adding unverified addresses.
Fix: Suppressed 62K contacts with zero opens in 90 days. Fixed the sign-up integration to require email verification. Sent re-engagement sequence to 45K borderline contacts — 18K re-engaged, 27K suppressed.
Outcome: Domain reputation recovered to Medium in 3 weeks, High in 7 weeks. Inbox placement: 91%. The IP warm-up effort was abandoned as unnecessary — domain was the issue all along.
