"Our reputation tanked" is the most common explanation for a cold campaign that stopped working, and one of the least useful. Mailbox providers do not keep a single score for you. They judge the IP address your mail leaves from, the domain it claims to come from, and the individual sending account, and they weigh all three together.
Those layers fail for different reasons, show different symptoms and recover on different timelines. Fix the wrong one and you burn weeks while the real problem keeps compounding. This guide breaks down each layer and gives you a way to tell which one is actually hurting you.
Three Layers, Three Different Scorecards
Think of it as a parcel arriving at a building. The IP is the delivery van, the domain is the company name on the label, and the mailbox is the person who signed it. Security looks at all three. A trusted company sending from a van that has dropped off junk all week still gets inspected closely.
- IP reputation belongs to the server address that connects to the receiving mail server.
- Domain reputation belongs to the domain in your From address and the domains used to sign the message, mainly through DKIM.
- Mailbox reputation belongs to the specific sending account and its own history of volume, engagement and complaints.
IP Reputation: The Address Your Mail Leaves From
IP reputation is built from the volume and quality of everything sent from that address: bounce rates, spam complaints, spam trap hits and how consistent the sending pattern looks. It is damaged fastest by sudden volume spikes, bad lists that produce lots of hard bounces, and hitting spam traps. IP problems also show up publicly, because the main blocklists, such as Spamhaus, list IP addresses.
IP reputation is the layer you control least if you do not control who else uses the address.
Shared Pools and the Neighbour Problem
On most cold email platforms and many email service providers, your mail goes out through a shared pool of IPs used by many customers. When one of those customers sends to a scraped list, the pool's reputation drops for everyone on it. You did nothing wrong, and your placement still falls.
A dedicated IP removes the neighbours. Its reputation reflects only your own sending, for better or worse. That cuts both ways: there is nobody else's good behaviour to lean on, so a dedicated IP needs consistent volume and its own warmup. But when something goes wrong, you can see it, trace it and fix it. This is the main reason Sendbox puts customers on dedicated IPs with isolated infrastructure rather than shared pools.
Domain Reputation: The Name That Follows You
Domain reputation travels with the domain no matter which IP or platform you send through. Providers have leaned on it more over time precisely because IPs are easy to change and domains are not. It is built from authenticated mail (SPF, DKIM and DMARC that align with the From domain), low complaint rates and recipients who open, reply and do not mark you as spam.
It is damaged by complaints, by sending poor content at volume, and by a domain appearing in spam that other people send, which is what puts domains on lists like the Spamhaus DBL. Because it follows you, switching platforms does not fix a burned domain. That is also why cold outreach should never run on your primary company domain.
Mailbox Reputation: The Individual Sender
Providers also judge behaviour tied to individual sending accounts. If you send from Google Workspace or Microsoft 365, the hosting provider is watching the account too, and it can throttle or suspend one that looks abusive. A mailbox gets into trouble by being pushed well past its usual daily volume, by sending to a batch of bad addresses, or by drawing complaints from one specific campaign.
Mailbox problems are the most contained and usually the quickest to recover, provided you notice them before the damage spreads to the domain.
A Diagnostic: Match the Symptom to the Layer
The trick is to compare what is failing against what is not. Group your results by IP, by domain and by mailbox, then look for the boundary where good turns to bad.
| What you see | Most likely layer | How to confirm |
|---|---|---|
| Every domain sending from one IP drops at the same time | IP | Check the IP on blocklists and in Microsoft SNDS |
| One domain drops across all its mailboxes while other domains on the same IP are fine | Domain | Check the domain on domain blocklists and in Google Postmaster Tools |
| One mailbox lands in spam while its siblings on the same domain land in the inbox | Mailbox | Run a placement test from that mailbox alone and review its recent volume and bounces |
| Bounces quote an IP blocklist in the error text | IP | Read the bounce message and confirm the listing |
| Only one provider, such as Outlook, drops while others hold | Usually IP or domain at that provider | Compare SNDS data with Postmaster Tools |
| Everything drops at once across IPs, domains and mailboxes | Probably not reputation | Check the list source and the copy you changed most recently |
The last row matters. When every layer fails together, the common factor is usually something you sent, not where you sent it from. A new lead source or a new template is the first suspect. Read the actual headers of a spam-foldered message with the email header analyzer to see authentication results and the path it took.
Where to Get Real Data
Guessing from reply rates is slow. Use the data providers publish:
- Google Postmaster Tools shows how Gmail sees a domain you verify: user-reported spam rate, authentication results and compliance with Gmail's sender requirements. Data only appears once you send a meaningful daily volume to Gmail users, so smaller cold domains often show nothing.
- Microsoft SNDS (Smart Network Data Services) shows how Outlook.com sees specific IPs: a traffic-light status, complaint rates and spam trap hits. You can only register IPs you control, so it is of little use on a shared pool.
- Inbox placement tests show where a real message lands across providers right now. Run one from each suspect layer with the inbox placement test, and see how to run a placement test properly so the results mean something.
- Blocklist checks cover both IPs and domains. The blacklist checker runs both.
Recovering Each Layer
Mailbox: pause cold sends from that account, let warmup keep running, and find what changed: a volume jump, a bad batch of addresses or one campaign drawing complaints. Most mailboxes recover within one to a few weeks once the cause is gone. If one keeps relapsing, retire it.
Domain: cut volume on every mailbox on the domain, clean the list, confirm SPF, DKIM and DMARC alignment, and get off any domain blocklist once the cause is fixed. Recovery is slower, often several weeks, and a domain that has been badly burned is sometimes cheaper to retire than to rehabilitate.
IP: on a shared pool, your options are to wait or to move. On a dedicated IP, stop the source of the problem, request delisting where relevant (see the delisting guide), then rebuild with steady, modest volume. IPs respond to consistent good behaviour over time, not to a single fix.
Whatever the layer, recover before you scale. Pushing volume through a damaged layer only deepens the hole.
