← Blog/Deliverability

IP reputation attacks: how senders get framed, and what to do

October 15, 2026·6 min read·By MailPilot

When people say their sending IP was "attacked", the cause is almost always one of five things: a mailbox whose credentials leaked, a relay or web form that strangers can send through, a signup-bomb that funnelled abuse complaints at your address, harvested addresses that turned out to be spam traps, or a shared IP where somebody else did the damage. Only the last one is genuinely outside your control, and even then your response is the same: find the source of the mail that got you listed, stop it, then ask for review with evidence.

Work out whose mail got you listed

Before anything else, confirm the listing is real and read what it says. A blocklist entry usually names the exact object listed and sometimes the observation window.

  • IP listings come from Spamhaus SBL/CSS/XBL, Barracuda, UCEPROTECT, SpamCop and the big mailbox providers' own internal scores.
  • Domain listings come from Spamhaus DBL, SURBL, and — since 3 September 2026 — Validity's Heatwave list, which lists domains rather than IPs and launched with over a million of them. Its lookup lives at lookup.validity.tools and review requests go through the /delist path on the same host.
  • SORBS is gone. It was shut down in June 2024, so a tool still reporting a SORBS listing is reporting nothing.

Then pull your own logs for the same window. A real compromise shows up as mail you did not author: unfamiliar envelope senders, a burst at 03:00, recipients in domains you never sell to, or thousands of 250 OK deliveries from one mailbox in an hour.

The five patterns and their fingerprints

PatternWhat you see in logsFirst move
Credential compromiseOne mailbox, huge burst, SMTP AUTH from a country you do not operate inReset the password, revoke app passwords and OAuth tokens, force re-auth
Open relay or unauthenticated submissionAccepted mail where the envelope sender is not in your domainRequire AUTH on submission, close port 25 relaying
Vulnerable web formContact or "share this" form sending attacker-supplied bodiesRate-limit, add a challenge, never put user text in the envelope
Subscription bombingThousands of inbound confirmations, your own complaint rate spikingNothing to fix on your side; ride it out, keep sending clean mail
Shared-pool neighbourYour mail is fine, provider-wide block, other tenants affectedEscalate to the provider, ask to be moved, consider your own IP

A tell for the shared-IP case: your domain reputation signals look normal and your authentication passes, yet a single provider block appears on every message at once. That is a pool problem, not yours.

Shut off the source, in this order

  1. Rotate credentials for every mailbox that sent in the suspect window, and revoke app passwords and refresh tokens — a password change alone does not kill an existing OAuth grant.
  2. Require authenticated submission on 587 and refuse relaying on 25 for anything not in your own domains.
  3. Check your SPF record for the open-ended entries that make spoofing cheap: a bare +all, an include: of a provider you no longer use, or more than ten DNS lookups, which produces a permerror and silently stops SPF from protecting you.
  4. Publish DMARC with a reporting address even if you stay at p=none for now. Aggregate reports are the only cheap way to see who else sends as your domain.
  5. Only then request review. Listings re-apply instantly if the source is still live, and repeated failed requests make later ones slower.

What not to do

Do not buy a new IP or domain to escape the listing. Fresh objects start with no history, which providers treat as suspicious in its own right, and the pattern of hopping is itself a signal. Do not mass-mail your list to "prove" you are legitimate while a block is active — every bounce and complaint is added evidence against you. Do not pay a delisting service; the public lists all have free review paths. And do not treat a subscription bomb as something to fix with filtering alone: the inbound flood is noise, the damage is in the complaint rate it generates, and that recovers by sending wanted mail to engaged recipients, slowly.

Also resist the urge to verify recovery with a reputation grade. Google Postmaster Tools retired its domain and IP reputation charts, so there is no longer a "Bad / Low / Medium / High" label to watch. What remains useful is the Gmail spam rate — keep it under 0.3%, and well under 0.1% if you can — plus your own seed placement across providers and the authentication and delivery-error panels.

Reduce the blast radius before the next one

Separate your streams. Transactional mail, marketing mail and cold outreach should not share a domain, let alone a mailbox. Use subdomains so a problem in one stream cannot take your main domain down with it. Keep a current inventory of every system allowed to send as you, because the thing that gets you listed is usually a tool someone connected two years ago and forgot. Turn on feedback loops where your provider offers them, and have an owner for them — a complaint feed nobody reads is the same as no complaint feed.

MailPilot helps on the detection side: it checks SPF, DKIM and DMARC on every connected domain, measures real per-provider inbox placement through a seed network so you can see a block the day it starts rather than when a campaign underperforms, and tracks each mailbox's reputation daily so a single compromised account stands out against the rest of the fleet.

MailPilot

Ready to reach the inbox every time?

Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.

Start free trial
Reach the Inbox, Every Time
Connect unlimited inboxes for warmup. Free 7-day trial, no credit card.
Try for Free
WORKS WITH
OZOHO
inbox placement99.2%
free trial7-day
companies trust us340+

Start for free - no credit card required.

Get started freeBook a demo