Why one IP can stop a sound campaign
An IP address is the technical origin of an email. The receiving provider assesses not only the copy and domain, but also that address’s history: complaints, delivery failures, unusual sending patterns and the behaviour of other senders on shared infrastructure. DNSBLs are public or private lists of addresses associated with unwanted email activity. A listing on one list will not necessarily block delivery everywhere, but it can explain why some messages are rejected before anyone reads them.
| Signal | What you see | What to do |
|---|---|---|
| Hard bounce | The server response mentions a blacklist or reputation issue | Pause the flow and check the IP against the named list |
| Email accepted, but replies disappear | Few bounces, but a sharp decline in conversations | Check inbox placement using test addresses |
| Only some mailboxes are affected | The same email produces different outcomes | Compare the IPs, domains and histories of each mailbox |
Reputation is not permanently attached to a message. It changes when the IP, list quality or sending pattern changes. That is why technical checks belong alongside <a href="/en/services/list-verification/">email list verification</a>: a non-existent address creates a bounce, while a trap address or irritated recipient can leave a longer-term signal.
How to separate an IP problem from a weak offer
A weak offer usually produces negative or indifferent responses: “not relevant”, “send more information”, or silence after normal delivery. An IP problem appears earlier: the server returns a technical rejection, messages vanish from test inboxes, or identical copy performs differently when sent from different mailboxes.
A short diagnostic sequence
How a shared IP becomes someone else’s problem
On a shared IP, several senders use the same technical address. Your company may run a careful queue, while another sender uses an outdated list and their complaints affect everyone. In practice, two mailboxes with the same offer can produce different results because one is accepted by receiving servers less often. At that point, investigate the sending route rather than rewriting the subject line.
The wrong move is to immediately rewrite the email and continue sending. The right move is to pause the queue, separate mailboxes by IP, check <a href="/en/glossary/spf/">SPF</a>, <a href="/en/glossary/dkim/">DKIM</a> and <a href="/en/glossary/dmarc/">DMARC</a>, then restore volume gradually. If the issue is infrastructure, better copy will not fix it.
- For every sending mailbox, you know the domain, SMTP provider and sending IP.
- Bounce texts are retained together with the recipient domain.
- Addresses with persistent bounces do not return to a campaign without rechecking.
- Changes to IPs and volume are recorded separately from copy changes.
When a DNSBL check will not give you the answer
A DNSBL check does not replace full deliverability diagnosis. An IP can be absent from known DNSBLs while a receiving provider still lowers trust using internal signals. Conversely, a listing on a rarely used list may have no effect on your audience.
This diagnosis is not useful if you cannot access sending logs and full bounce messages: you cannot then separate a technical failure from recipient response. If you are starting from scratch, first establish <a href="/en/glossary/deliverability/">email deliverability</a> and <a href="/en/glossary/domain-mailbox-warm-up/">domain and mailbox warm-up</a> rather than treating DNSBL as a universal explanation.