Most teams respond to a falling reply rate by rewriting the email. New subject line, shorter opener, different call to action. Sometimes that helps. Often the copy was never the problem, because the message was not reaching an inbox in the first place.
We went looking for the actual sending path on a set of cold email domains last month. What we found was not what the DNS records suggested.
SPF tells you what could send, not what does
The SPF record on each domain authorised eighteen IP addresses. That number felt reassuring. A decent pool, spread across ranges, plenty of room to rotate.
Then we sent ten test messages through one domain and read the Received header on every delivered copy, which records the address the receiving server actually saw. Two addresses. One carried six messages, the other four. The remaining sixteen authorised addresses were never touched.
That gap matters because reputation attaches to the address that sends, not the address that is permitted to. A wide SPF record creates an impression of distribution that may not exist. Ours was concentrating everything onto two addresses, and when we checked those two against blocklists, both were listed on Spamhaus CSS.
So every message from that domain was leaving through a blocklisted address. Not some fraction. All of it.
The server you connect to is not the server that delivers
There is a second layer of misdirection here, and it is easy to misread.
When your tool submits a message, it connects to a submission host on port 587. We recorded which address it landed on each time. Across one batch it hit four different ones, and across another it stayed on a single address for all ten messages.
Neither pattern told us anything useful. The submission address is chosen by DNS round robin on your side, and it has no relationship to the address the message leaves from afterwards. Two messages that entered through the same door left through different ones. Think of it as the difference between the post office counter you queue at and the van that drives your parcel across the country.
Only the second one carries a reputation. Only the second one appears on a blocklist. And the only way to observe it is to send a message somewhere you control and read the headers.
Sometimes you are not sending as the domain you configured
The result that genuinely surprised us: we authenticated with the credentials for one domain, set the From address to that domain, and the message arrived from a completely different one. Different sender in the From header, different envelope sender, signed with the other domain's DKIM key, delivered from the other domain's address pool.
This turned out to be deliberate. Providers rotate the sending identity across domains as a deliverability measure, spreading volume so no single domain carries all of it. Reasonable in principle.
The practical consequence is worth sitting with. If you configure a campaign against one domain, prospects may see mail from another. Replies land in the other domain's mailbox. Reputation, good or bad, accrues to the other domain. If you are monitoring the first domain's inbox for responses, you can be looking in the wrong place and conclude the campaign failed.
We only found this because we read the From header on a delivered copy. Nothing in DNS shows it. No dashboard reported it.
What to check, in the order worth checking it
None of this requires special tooling. It requires sending mail to yourself and reading what arrives.
- Send yourself ten messages through each sending domain. Not one. Rotation only becomes visible across a batch, and ten is enough to see the shape of it.
- Read the Received header on each delivered copy. The address there is what receivers judge you on.
- Check the From header against the domain you configured. If they differ, your provider is rotating identities and you should know which ones.
- Look up every address you actually observed against Spamhaus, SpamCop and Barracuda. Use a resolver that is not a large public one, because the major lists refuse queries arriving from 1.1.1.1 and 8.8.8.8 and return codes that naive checkers misread as a listing.
- Confirm each sending address has reverse DNS that resolves back to itself. One of the addresses we checked had none at all, while announcing a perfectly good hostname in its SMTP banner. The operator knew what the machine was called and had simply never set the record.
Repeat it weekly. On shared infrastructure the answer changes without notice, because the addresses are shared with other customers whose behaviour you cannot see and do not control.
Where copy still decides things
Everything above governs whether your message is accepted and where it is filed. It has nothing to say about whether anyone replies.
If your mail reaches the inbox and nobody responds, the problem is your offer, your targeting, or your writing, and no amount of infrastructure work will fix it. Those are genuinely separate failures, and treating one as the other wastes weeks.
The distinction is testable. Send to a handful of addresses you control across the major providers and see where the message lands. Inbox with no replies is a message problem. Spam folder, or silence from providers that used to respond, is an infrastructure problem. Guessing between the two is how teams end up on their fifth subject line rewrite while the sending address sits on a blocklist.
Before you rewrite anything, spend twenty minutes sending yourself ten emails and reading the headers. You will either rule this out or find something that no amount of copywriting was ever going to fix.