When an outreach campaign starts landing in spam, the instinct is almost always to change the message. You question the subject line. You rewrite the copy. You change the call to action. You add personalization. You rework the sequence. It feels productive because the email is the part you can see and control.

But there is a good chance the message was never the problem. A sending IP can carry reputation long before it is assigned to you, and a shared pool can carry reputation created by other senders. This idea comes from a recent post by Nithyanandan Ramakrishna, which makes the case for checking your sending infrastructure before your next campaign goes out: the original LinkedIn post.

This article expands on that point and turns it into a practical checklist for agencies running outbound email.

The goat and the strangers

The post retells an old story about a man carrying a prize goat to market. Four strangers along the road tell him it is a dog. By the fourth, he starts to question the goat himself.

Email senders do something surprisingly similar. We keep changing the campaign because that is the part we can see. The subject line is visible. The copy is visible. The sequence is visible. The reputation of the infrastructure carrying the message is not, so it gets overlooked.

That is the trap. If the sending IP already has a poor reputation, no amount of rewriting will repair it. A better pitch cannot fix a poor sending reputation.

Why the sending IP matters as much as the domain

Most deliverability advice focuses on the sending domain: SPF, DKIM and DMARC records, domain warmup, and consistent sending volume. All of that matters. But authentication and reputation are not the same thing.

Your domain can authenticate correctly while the infrastructure carrying the message still has reputation signals worth investigating. In other words, passing authentication tells receiving servers that the mail is legitimately yours. It does not tell them that the IP it arrived from has a clean history.

This distinction matters most for agencies, because agencies often send on shared infrastructure. When you send through a shared IP pool, the reputation of that pool is partly built by other senders. If another sender on the pool has a poor history, the pool can carry that reputation with it. You inherit conditions you did not create.

What to check before you rewrite anything

Before you touch the copy again, work through the infrastructure side. The post points to three things worth checking: the sending IP, its history, and its blocklist exposure, along with the sending domain itself.

1. Identify the actual sending IP

Find out which IP or IP pool your campaign is sending from. If you use an email platform, this may be a shared pool rather than a dedicated one. Ask your provider directly if you are not sure. You cannot investigate a reputation you have not located.

2. Check the IP history

An IP can have a sending history that predates your use of it. Look for signs that the address has been used heavily, or used poorly, before it reached you. If you are on a shared pool, ask what the provider does to monitor and remediate the pool's reputation.

3. Check blocklist exposure

Check whether the sending IP or domain appears on major blocklists. Blocklist listings are one of the more concrete signals you can act on, and they are worth checking on a routine schedule, not only when something breaks.

4. Check the sending domain

Confirm that your SPF, DKIM and DMARC setup is correct and aligned. This is the baseline. It will not rescue a poor IP reputation, but a broken setup will damage your results regardless of how good the infrastructure is.

Why rewriting first is so tempting

Rewriting the campaign is satisfying because it produces visible output. You can point to the new subject line. You can show the client the revised sequence. Checking IP reputation produces a less glamorous result: a finding, sometimes an uncomfortable one, that the infrastructure needs attention.

But the cost of skipping that step is real. Teams can spend days iterating on copy, testing subject lines and rebuilding sequences while the underlying reputation problem stays exactly where it was. Every send during that period adds more data to a reputation that may already be working against you.

A practical order of operations for agencies

When a campaign suddenly struggles, resist the urge to assume the message is the problem. Work in this order instead:

  1. Pause and check the infrastructure. Look at the sending IP, its history, blocklist exposure and the sending domain before changing anything in the campaign.
  2. Confirm authentication. Verify SPF, DKIM and DMARC are set up and aligned for the sending domain.
  3. Review the pool. If you are on shared infrastructure, find out who else sends from it and how the provider manages reputation.
  4. Only then look at the message. Sometimes the message needs fixing. Sometimes you need to look at the road it travelled.
  5. Fix the cause, not the symptom. If the infrastructure is the issue, changing the copy will not solve it. Escalate to your provider or move to cleaner infrastructure.

What this means for client work

For agencies, this is also a client communication issue. When a campaign underperforms, clients often ask what changed in the copy. Having an infrastructure check as part of your standard process gives you a factual answer, and it protects you from rewriting good emails to compensate for a problem that was never in the writing.

It also shapes how you choose a sending platform. Ask providers how they monitor IP reputation, how they handle blocklist exposure, and whether shared pools are segmented by sender quality. Those answers matter more than most feature comparisons.

The takeaway

A campaign landing in spam is a signal, not a diagnosis. The message might be the cause. The infrastructure might be the cause. Before you rewrite another email, check what is carrying it: the sending IP, its history, its blocklist exposure and the sending domain.

A better pitch cannot repair a poor sending reputation. So when a campaign suddenly struggles, do not automatically assume the message is the problem. Sometimes the message needs fixing. Sometimes you need to look at the road it travelled.