The four strangers and the dead snake

A man left his bag with four strangers while he swam. Each one told him the same thing: "Why are you carrying a dead snake?" Four voices, one claim. He left the bag behind without ever opening it.

That story comes from a recent post by Nithyanandan Ramakrishna about sender reputation and email infrastructure, and it maps almost perfectly onto how agencies troubleshoot outbound email. Somebody says your copy is the problem. Somebody else says your domain is burned. Then it is the IP. Then the provider. Then the warm-up. The same diagnosis gets repeated until you start changing things, and changing things costs money and time.

You can read the original LinkedIn post for the short version. This article expands on the practical point: repetition is not evidence, and the mistake is acting before checking.

Why repeated advice feels like proof

When three people in a Slack channel tell you your domain is burned, it is tempting to treat that as a finding. It is not. It is three people repeating a plausible story, often based on the same surface symptom: replies dropped, opens fell off, or a campaign suddenly stopped landing in the inbox.

The same thing happens inside agencies. One account manager hears a client say "our emails go to spam," and by the end of the week the whole team believes the domain is damaged. Nobody has looked at the actual sending infrastructure. Everyone is reacting to a story about a bag nobody opened.

Diagnosis by consensus is comfortable because it lets you act quickly. But acting quickly on the wrong diagnosis usually makes things worse. You buy a new domain and lose the reputation you had built. You rewrite copy that was working. You migrate providers and inherit a fresh IP with no history, then wonder why results got worse before they got better.

What to check before you change anything

The post lists a specific set of checks. None of them require guesswork, and most take minutes rather than days.

The sending IP and its history

Look at the IP address your email actually leaves from. Is it shared or dedicated? How long has it been sending? A dedicated IP that has been sending consistent, low-complaint volume for months tells a very different story than an IP that was assigned to you last week. If you are on a shared IP, you are partly at the mercy of other senders on that pool, which is worth knowing before you blame your own copy.

Blocklist exposure

Check whether your sending IP or domain appears on major blocklists. This is one of the few deliverability signals that is close to binary: either you are listed or you are not. If you are listed, you have a concrete thing to fix. If you are not, you have just eliminated a suspect and can stop worrying about it.

Authentication

Check that SPF, DKIM and DMARC are set up correctly and passing. Authentication is the foundation of how receiving providers decide whether to trust your mail. A misconfigured DKIM record or an SPF lookup that fails will undermine everything else, no matter how good your copy is. This is also where a lot of "our domain is burned" stories turn out to be a DNS problem instead.

Reputation signals around the infrastructure

Look at the reputation signals attached to your sending infrastructure. That includes how receivers are treating your mail, complaint patterns and the general health of the domain and IP you send from. You do not need a perfect score. You need to know whether the signals point to an infrastructure problem or not.

What the evidence usually tells you

Once you have run those checks, you are in a much better position to decide what deserves fixing and what probably does not. Sometimes the advice you were given is right. Sometimes it is not. The point is that you now know which.

If authentication is failing, fix authentication. If you are on a blocklist, work through delisting. If the IP history is thin, focus on consistent volume and engagement rather than dramatic changes. If all of those checks come back clean, then the conversation can legitimately move to copy, targeting and offer, because you have ruled out the infrastructure layer first.

That order matters. Infrastructure problems masquerade as copy problems all the time. A campaign that lands in spam looks identical, from the reporting dashboard, to a campaign with a weak offer. Checking infrastructure first stops you from rewriting messaging to solve a DNS issue.

A simple pre-flight routine for agency teams

Agencies running outbound for multiple clients need this to be repeatable, not improvised every time a client panics. A short pre-flight routine helps:

  • Confirm SPF, DKIM and DMARC are configured and passing for every sending domain you manage.
  • Record which IP each client sends from, and whether it is shared or dedicated.
  • Check blocklist status on a regular schedule, not only when something breaks.
  • Keep a note of when domains and IPs were set up, so you can tell a new sender from an established one.
  • When a client reports a deliverability problem, run the checks before anyone proposes a fix.

The last point is the cultural one. If your team's default response to a deliverability complaint is "let's rewrite the sequence," you will spend a lot of time fixing things that were never broken.

Before you buy another domain

The post ends with a simple instruction: before you buy another domain, rewrite the campaign or move providers, open the bag. Look at what is actually happening.

For agencies, that is also a commercial argument. New domains, new providers and rewritten campaigns all cost billable hours, and none of them are free to undo. A fifteen minute infrastructure check before a larger intervention is one of the highest leverage habits you can build into your outbound process.

So the next time four people tell you your domain is burned, do not take their word for it. Check the sending IP. Check its history. Check blocklist exposure. Check authentication. Check the reputation signals around the infrastructure. Then decide.

Sometimes the snake is real. Often it is not. Either way, open the bag first.