What is IP reputation? The practical difference from Domain reputation

What is IP reputation? The sending-server history behind mailbox filtering

It is not a universal score. Gmail, Outlook.com, Yahoo, and other receivers can form different views of the same IP because they see different recipients, complaints, volumes, and abuse patterns.

What the IP represents

At SMTP time, the receiving server can see the IP address of the server connecting to it. That makes the IP a useful infrastructure identity even before the receiver evaluates the domains inside the message. An IP can be:

• dedicated to one sender or one organization
• shared across many customers of an email service provider
• part of a rotating pool
• new, with little receiving history
• mature, with a long record of stable traffic

The IP therefore answers a different question from domain reputation. A domain is a portable brand or authentication identity. An IP is a network-origin identity for a particular delivery hop.

Dedicated versus shared IPs

A dedicated IP gives one sender much more direct control over the traffic that builds that IP's history. It also gives that sender the responsibility to establish and maintain the history.

A shared IP spreads infrastructure and volume across multiple customers. That can be efficient for smaller senders, but the pool operator must police abuse because one customer's behavior can contribute to the IP-level signals seen by receivers. Google's sender guidance explicitly warns that activity from senders on a shared IP affects the reputation of everyone using that IP.

This does not make dedicated IPs automatically better. A low-volume sender can struggle to create stable history on a dedicated IP, while a well-managed shared pool can have predictable traffic and active abuse controls. The right choice depends on volume, consistency, operational maturity, and how much isolation you need.

What tends to hurt IP reputation

Providers do not publish complete scoring formulas, but common operational causes include:

• high user complaint rates
• mail to invalid or poor-quality destinations
• sudden or erratic volume changes
• spam or malware traffic
• repeated policy failures
• lack of valid forward and reverse DNS where providers require it
• compromised systems or unexpected senders using the IP
• a shared pool with weak customer controls

Some signals are highly provider-specific. Microsoft SNDS is an example: it gives senders data about individual IPs and Outlook.com reputation. Its portal is not a score for Gmail or Yahoo.

A current 2026 example: Microsoft SNDS changed

Microsoft's Smart Network Data Services is a useful reminder that provider tooling itself changes. The current SNDS portal says it gives detailed data about individual IPs for Outlook.com and includes the Junk Email Reporting Program. Microsoft also announced in July 2026 that this new portal replaced the prior sender-support site and deprecated the old automated-access URLs.

So a guide that tells operators to bookmark a legacy SNDS URL can be technically accurate in concept and operationally stale. The durable lesson is to use provider-native IP evidence while treating the exact interface and exported fields as freshness-sensitive.

Google is in a similar transition. Its Postmaster Tools documentation still describes historical IP Reputation ratings, while its v2 deprecation notice says the legacy IP and Domain Reputation dashboards will be retired. That is another reason to teach the diagnostic model rather than a screenshot-dependent workflow.

IP reputation is not a blocklist check

Public blocklists can be useful evidence, but "not listed" does not mean a mailbox provider considers an IP healthy. Large receivers can maintain private reputation systems based on their own data.

Likewise, appearing on one external list does not tell you the impact at every provider. You need to correlate the listing with the actual SMTP errors, provider dashboards, and affected recipients. A blocklist is a signal. IP reputation is the broader receiving history and policy context.

IP reputation is not domain reputation

A sender can have:

• a strong domain on a damaged IP pool
• a clean IP carrying a new or poor-quality domain
• one provider that reacts primarily to the IP problem while another appears normal
• a shared IP problem that affects several unrelated domains

Receivers can combine both identities with complaints, content, authentication, URLs, and user behavior. When troubleshooting, ask which dimension changed instead of debating which reputation type is "the real one."

Warming: building predictable history, not performing a ritual

A new dedicated IP has little or no receiver history. "IP warming" is the practice of introducing traffic gradually so mailbox providers can observe stable, wanted mail instead of a sudden high-volume burst.

The important variable is not a magic calendar. It is the relationship between volume, recipient quality, provider response, and consistency. A practical warm-up process should:

1. start with recipients most likely to expect and value the mail
2. keep authentication and reverse DNS stable
3. increase volume in controlled steps
4. watch provider-specific temporary failures and complaints
5. pause or reduce expansion when signals worsen
6. avoid switching between IPs in a way that prevents any one identity from building a stable history

Gmail's sender guidance explicitly recommends increasing sending volume slowly and avoiding sudden spikes.

1. Name the provider

"IP reputation is bad" is too vague. Determine whether Gmail, Outlook.com, Yahoo, or another receiver is rejecting or filtering the traffic.

2. Capture the exact sending IP

Do not assume the IP shown in your application configuration is the one that delivered the affected message. ESPs can use pools, failover hosts, or separate transactional infrastructure.

3. Separate shared and dedicated ownership

If the IP is dedicated, inspect your own traffic changes and account security. If shared, ask the provider for pool-level evidence and whether other customers created an incident.

4. Read the SMTP responses

Temporary failures can signal throttling. Permanent failures can include policy or reputation rejection. Keep the provider's enhanced status text, not just your ESP's simplified label.

5. Correlate with volume and complaints

Plot volume, complaints, invalid recipients, authentication changes, and rejection rates on the same timeline. Reputation incidents often become obvious once the triggering traffic change is visible.

6. Use provider-native tools where available

For Outlook.com IPs, Microsoft SNDS is directly relevant. For Gmail, use current Postmaster compliance, spam, delivery-error, and authentication data while the reputation-dashboard product is transitioning. For Yahoo, use Sender Hub resources and complaint feedback.

Shared-IP and dedicated-IP decision table

The table describes trade-offs, not a universal recommendation.

Worked example

A merchant's DKIM and DMARC are correct, complaint rate is stable, and nothing changed in its campaigns. Suddenly, Outlook.com begins deferring a large share of messages.

• The merchant checks the actual delivery IP and discovers it is part of an ESP shared pool. Microsoft SNDS shows the affected IP's Outlook.com health deteriorated during the same period. Other IPs in the ESP account are not showing the same problem

That evidence points toward an IP-pool incident, not a reason to rewrite the merchant's DMARC policy or replace every subject line. The merchant should still review its own sending quality, but the remediation owner now includes the ESP because the merchant does not control the shared IP's entire traffic history.

Common mistakes

1. Treating an IP reputation score from one provider as universal
2. Assuming a dedicated IP is automatically healthier than a shared IP
3. Moving to a fresh IP every time filtering worsens, which resets history without fixing behavior
4. Ignoring shared-pool effects
5. Treating a public blocklist result as a complete deliverability diagnosis
6. Warming with the full database instead of the most wanted traffic
7. Looking only at bounces without plotting volume and complaints by provider

Questions we get asked