How to check your sending IP reputation in 2026

A practical audit for finding your real sending IPs, reading receiver-specific signals, and fixing the behavior behind a reputation problem.

When delivery falls, “check the IP reputation” sounds like a simple first step. It is not. There is no universal score that every mailbox provider reads, and the IP shown by your office network is rarely the address that delivered the message. A green result from a public checker can coexist with Gmail spam placement, while a scary-looking listing can be irrelevant to the traffic you actually send.

A useful reputation check starts with the real outbound IP, then compares signals from the receivers accepting that traffic. The goal is not to collect a score. It is to find evidence that explains where mail is being deferred, rejected, or routed away from the inbox—and to connect that evidence to a behavior you can change.

Diagram showing one sending IP evaluated independently by Gmail, Microsoft, and Yahoo using authentication, complaints, failures, and traffic consistency — FIG.One sending IP produces several reputation views. Diagnose the receiver that changed, then use authentication, complaint, delivery, and volume signals to explain why.

Step 1: find the IP that actually sent the message

Before checking reputation, identify the server that connected to the recipient's mail system. Send a representative message to a mailbox you control and inspect the original message or full headers. Delivery logs from your email provider are even better because they can tie the outbound IP to a message ID, stream, recipient domain, and SMTP response.

Message-ID: <[email protected]>
Received: from mta.news.example.com [192.0.2.42]
Authentication-Results: spf=pass; dkim=pass; dmarc=pass

Outbound IP       192.0.2.42
DKIM domain       news.example.com
Return-Path       bounce.example.com
Recipient domain  gmail.com
SMTP result       accepted / deferred / rejected

Read Received headers from the receiving side with care: a message can pass through several systems, including your application, provider, relays, and the recipient's own infrastructure. Confirm the result against the provider's event log rather than assuming the first visible address is the sending IP.

Do not test the public IP of your laptop, office, or website unless it also runs the outbound mail server.
Record every production IP or pool; transactional and marketing streams may leave through different infrastructure.
Capture the DKIM d= domain, Return-Path domain, visible From domain, and tracking domain alongside the IP.
Save the exact SMTP status and enhanced status code for deferrals or rejections.
Repeat the check at each receiver where performance changed.

Step 2: determine whether the IP is shared or dedicated

On a shared pool, your email provider owns the IP and combines traffic from multiple customers. The provider usually controls reverse DNS, pool assignment, Microsoft SNDS access, blocklist remediation, and traffic removal. You still control consent, audience quality, complaint rate, authentication alignment, and the content sent from your domain.

A dedicated IP gives you more control over the traffic history, but it is not automatically more reputable. It needs enough wanted, consistent volume for receivers to learn from it. A low-volume sender can get more stable results from a well-managed shared pool than from a mostly idle dedicated address that suddenly sends a large campaign.

01 / Shared poolEscalate IP-level evidence to your provider

Send message IDs, receiver errors, dates, affected domains, and the exact outbound IP.

02 / Dedicated IPOwn the traffic pattern and infrastructure

Monitor PTR, authentication, volume, complaints, bounces, security, and receiver portals.

03 / Not sureCheck your sending plan and event logs

Do not assume an address is dedicated just because it appears repeatedly in your headers.

Step 3: use the receiver's own evidence

A reputation problem usually appears unevenly. Gmail can deteriorate while Outlook remains stable; Yahoo can defer a burst that other providers accept. Split delivery data by receiving domain before drawing conclusions. Acceptance, temporary deferrals, permanent rejections, complaint reports, and inbox testing are more useful when they are attached to the receiver making the decision.

Google Postmaster Tools: read the trend, not one label

Google Postmaster Tools reports on mail sent to personal Gmail accounts. Its data is not real-time, normally appears within about 24 hours, can take longer, and may be omitted when volume is too low to preserve privacy. That means a missing chart is not proof that the IP is healthy or unhealthy.

Google's legacy dashboard can classify an IP as Bad, Low, Medium, or High, but Google has announced that the legacy IP and Domain Reputation dashboards will be retired and replaced. Google says those scores can be difficult to act on, can change slowly after improvements, and can be misleading because reputation is only one factor in delivery. The retirement of the legacy interface has been postponed, but the direction is clear: use the broader evidence.

Spam rate: complaints reported by active users, interpreted with actual delivery and placement.
Feedback loop: unusual complaint concentrations tied to identifiers you configure.
Authentication: SPF, DKIM, and DMARC success for traffic associated with the domain.
Encryption: whether inbound and outbound transport used TLS.
Delivery errors: rate limits, low IP reputation, public RBL records, PTR issues, and other receiver responses.
Compliance status: actionable checks that help explain whether current sender requirements are met.

Microsoft SNDS and complaint feedback

Microsoft's Smart Network Data Services, or SNDS, provides data about traffic from IPs sending to Outlook.com. Access requires a Microsoft account and authorization for the IP ranges you control, which is why a shared-pool customer normally needs the email provider to investigate on their behalf.

Use SNDS to watch IP-level volume and reputation indicators, then compare any change with your own campaigns, bounces, and acquisition sources. Microsoft's Junk Email Reporting Program, now linked more closely with SNDS, provides complaint feedback in the Abuse Reporting Format. Microsoft has also strengthened network authorization and automated-download protections, so old scripts or inherited access assumptions deserve a review.

Yahoo Sender Hub and the Complaint Feedback Loop

Yahoo's sender guidance emphasizes wanted mail rather than a universal IP score. It recommends valid forward and reverse DNS, SPF, DKIM, DMARC, easy unsubscribe, removal of invalid recipients, controlled sending flow, and a spam complaint rate below 0.3 percent. Its Complaint Feedback Loop can help participating senders identify messages that recipients mark as spam.

Do not treat 0.3 percent as a target. It is an upper boundary in Yahoo's guidance, not a healthy operating goal. Keep complaints as low as possible and look for changes by list source, form, automation, campaign, and subscriber age.

Step 4: check public blocklists—without overreacting

Run the confirmed outbound IP through the official Spamhaus checker and any list named in an SMTP rejection. Spamhaus ZEN combines several IP datasets, including SBL, CSS, XBL, and PBL, so follow the result to the component record. A compromised-host listing demands a security response; a policy listing can simply mean that an address should not send mail directly to receiving servers.

A listing matters most when the exact production IP is involved, the timing matches a delivery change, and an affected receiver returns a related error. Scanning hundreds of obscure lists creates noise. Public lists also cannot tell you that a private receiver model has lost trust in your traffic.

Step 5: build a reputation scorecard from evidence

Instead of reducing the audit to one number, keep a small scorecard for every outbound IP and receiver. The same fields make weekly reviews comparable and reveal whether a change is isolated, systemic, or simply a reporting gap.

Identity: IP owner, pool name, shared or dedicated status, mail stream, and sending domains.
DNS: forward DNS, PTR or reverse DNS, and a sensible EHLO hostname.
Authentication: SPF authorization, DKIM pass, DMARC alignment, and TLS.
Volume: daily accepted mail, sudden bursts, idle periods, and traffic by receiver.
Delivery: accepted, temporarily deferred, permanently rejected, and the leading SMTP codes.
Audience: hard bounces, unknown users, complaints, unsubscribes, and engagement by source.
External evidence: Google Postmaster Tools, Microsoft SNDS and JMRP, Yahoo CFL, and relevant blocklists.
Security: unexpected traffic, stolen credentials, open relays, compromised forms, and unauthorized API keys.

IP / pool          192.0.2.42 — transactional — dedicated
Gmail              accepted stable; deferrals +0.1%; auth pass
Microsoft          volume normal; no new complaint pattern
Yahoo              accepted stable; CFL complaints below baseline
Infrastructure     PTR ✓  SPF ✓  DKIM ✓  DMARC aligned ✓  TLS ✓
Public lists       no relevant production-IP record
Change this week   password-reset retry volume increased 18%
Action              cap retries; watch Gmail errors for 72 hours

How to interpret the pattern

01 / One receiver worsensInvestigate that receiver's policy and audience

Compare its SMTP errors, complaints, engagement, and volume with unaffected receivers.

02 / Every receiver worsensLook for a shared root cause

Audit acquisition, authentication, compromise, list age, cadence, and a recent volume change.

03 / Shared IP is listedGive your provider reproducible evidence

Include the IP, message IDs, timestamps, recipient domains, and complete SMTP responses.

04 / New IP has no dataTreat it as insufficient history

Keep wanted volume consistent; missing portal data is not a positive reputation signal.

If reputation is damaged, fix behavior before volume

Start by stopping the riskiest source: a compromised credential, imported list, stale segment, broken form, aggressive retry loop, or unexpected customer. Verify SPF, DKIM, DMARC alignment, PTR, TLS, and unsubscribe handling. Then send only to recipients who recently asked for and engaged with the mail, at a stable rate the infrastructure can support.

Do not rotate through fresh IPs to outrun a reputation problem. Receivers also evaluate domains, authentication, content, links, behavior, and connections between infrastructure. Moving unchanged traffic can spread the damage while discarding the history you need to measure recovery.

Pause the campaign, tenant, form, or credential producing harmful traffic.
Suppress hard bounces, complaints, unsubscribes, and long-term unengaged addresses.
Correct PTR, forward DNS, HELO, SPF, DKIM, DMARC, TLS, and unsubscribe defects.
Resume with the most recent, clearly consented, engaged recipients.
Keep daily volume and cadence predictable; avoid catch-up blasts after a pause.
Track receiver-specific errors and complaint signals every day during recovery.
Request delisting only after the cause is fixed and only from the operator involved.

A monitoring cadence that stays maintainable

During normal sending, alert daily on unusual volume, authentication failures, complaint spikes, and receiver-specific deferrals. Review provider dashboards and the IP scorecard weekly. Audit DNS ownership, portal access, traffic separation, suppression rules, and every production sending IP monthly or after an infrastructure change.

The strongest reputation check is repeatable: identify the real sender, isolate the receiver, collect primary evidence, explain the behavior, and record the response. That process stays useful even as mailbox providers change dashboards and retire individual scores.