The message came on a Tuesday afternoon, as low-key as a message can be about a broken pipeline. "Hey Felix, our reply rate has tanked. We've sent over four hundred emails since Monday and got two replies, both opt-outs. Something is off."
I pulled up the Instantly.ai dashboard. The campaign metrics looked, at first pass, almost fine. Send rate exactly where it should be. Bounce rate under two percent. Sequences running on schedule. The sending domain was warmed properly before we launched.
But the open rate was 6 percent. Two months ago it had been 21.
I asked the usual questions. Any copy changes? The client had actually improved it, tighter subject lines and more personal openers. Same audience segment? Yes. Any major account changes?
And then, almost as an afterthought, the client mentioned it: "We migrated to a new domain registrar in July. DNS was a bit of a pain to move. We used an export tool but some records had to be recreated manually."
That sentence changed everything I was looking for.
When the Infrastructure Breaks Silently
A hard bounce is loud. You see it immediately: the delivery failure report, the address removal, the spike in your error log. The campaign tool tells you something went wrong and you investigate. Silent failures are a different problem entirely.
When an email lands in a spam folder, the sender gets no notification. The campaign tool reports a successful send. The email was accepted at the receiving server. The recipient's provider quietly filed it to spam. The send was counted. No alert on either side. It just disappears.
DMARC is what makes this possible at scale. When a domain has a DMARC policy set to p=quarantine, receiving mail servers that detect an authentication failure do not bounce the email with an error. They route it to spam and move on. The sender's delivery stats look clean. Open rates drop, but open rates are unreliable at the best of times. You can watch your reply rate collapse for weeks before you think to check the authentication chain.
I sent myself a test email through the client's campaign account, to a clean Gmail address I keep specifically for diagnostics. Then I pulled the full email headers.
The authentication results line read: spf=fail.
The DNS Export That Lost One Line
The client's main domain SPF record was correct. Google Workspace included. Every major sending service they used: properly authorized. But their cold outreach was configured through a dedicated subdomain set up for that purpose, separate from the main company domain. Call it campaigns.theirdomain.com. That subdomain had its own DNS records, independent of the root domain's zone file.
When the migration tool exported the DNS records from the old registrar, it had pulled the root domain's zone file. The subdomain records needed to be manually recreated at the new registrar. The person handling the migration had done it carefully, working from a side-by-side comparison of the old interface. They had gotten almost every record right.
Almost.
The SPF record for campaigns.theirdomain.com now read:
v=spf1 include:_spf.google.com -all
What it needed was an additional include statement authorizing Instantly.ai's sending servers: the line that tells receiving mail servers that these IP addresses are permitted to send email on behalf of this domain. Without that include, any email sent through Instantly.ai for this subdomain would fail SPF validation at delivery.
The DMARC policy on the root domain was p=quarantine, and the subdomain inherited it. Every outreach email sent in the twelve days since the migration had passed through Instantly.ai's servers, failed SPF alignment at the receiving end, and been silently filed into spam folders across hundreds of inboxes.
The sequences were running on schedule. The copy was the best the client had ever written. The list was clean and well-targeted. None of it mattered, because the authentication record that said "trust this sender" had quietly dropped out of existence during a routine DNS migration, and nobody had connected that to the collapse in replies.
The Call I Did Not Want to Make
Explaining this to a client is genuinely uncomfortable. They had spent two weeks refining subject lines, adjusting send timing, second-guessing their value proposition, writing and rewriting follow-up sequences. None of it had been seen by a human set of eyes. All of it had been landing in spam before any recipient could decide whether to reply.
I walked the client through what had happened and, more importantly, what had not happened. No malicious action. No account compromise. No black mark against the domain that would take months to repair. A DNS migration export had quietly dropped one include statement from one subdomain's SPF record. That was the entire explanation. The whole deliverability failure traced to a single missing line in a text record that most people never look at directly.
What kept the conversation from being worse was that we had caught it relatively early. Twelve days of bad sends on an already-warmed domain is recoverable. Three months would have been a different conversation entirely, potentially requiring a new sending domain and a full re-warmup from scratch.
The client asked one question I did not have a satisfying answer for: "How do we make sure we see this faster next time?" That question stayed with me.
After the Fix
The SPF update took about five minutes. Add the missing include statement to the subdomain's TXT record, save, wait for DNS propagation. Propagation typically takes anywhere from a few minutes to a few hours depending on the registrar and the TTL setting on the record. We paused the campaign, updated the record, ran another test email to the diagnostic inbox, confirmed the authentication results showed spf=pass and dmarc=pass, then gradually resumed sending.
Reply rates climbed back to normal over the following week. Not overnight: inbox providers recalibrate sender reputation slowly, based on engagement signals that accumulate over time. But it came back, and without needing to replace the domain or restart the warmup. Twelve days of bad sends on an already-warmed domain is recoverable. Longer would have been a different story.
What I Verify Before Any Domain Goes Live Now
That question from the client, about how to see this faster next time, pushed me to build a pre-launch check I now run on every sending domain before any campaign begins. It takes about fifteen minutes and has caught two more near-misses in the months since this incident.
The first thing I verify is the full authentication chain, and I verify it for the exact subdomain being used for outreach, not just the root domain. SPF record present and containing the correct include for every outbound tool in the stack. DKIM signature configured and verifiable. DMARC policy explicitly set, with the subdomain policy reviewed separately. I then send a test email to a diagnostic inbox and read the full headers, not just check whether the email arrived. The authentication results block in the headers tells you the truth about what receiving servers actually saw, and it takes 30 seconds to read.
The second thing I do before any DNS migration is a line-by-line diff. Export the zone file from the current provider, export the zone file after migration is complete, and compare them directly. Automated export tools are good but they routinely miss subdomain records, records with non-standard TTL values, and records that use syntax the export tool's parser does not handle cleanly. A five-minute diff before you flip traffic is far cheaper than diagnosing a silent failure two weeks later.
The third thing is a baseline benchmark. Before the first production send on any new domain, I record what a clean test batch looks like across a small sample: open rates, click rates, and critically, a spot-check of the delivery headers. That baseline is the reference point if something shifts. The twelve-day collapse in this case was only invisible because there was no reference point to compare against.
None of this is complicated. It is the kind of check you build after something goes wrong and you are looking at the gap between what you assumed was verified and what actually was. The outreach platform will tell you the sends are going out fine. The DNS records will tell you whether the receiving world agrees.
If you are running cold outreach from a custom sending domain and you have not looked at the delivery headers recently, that is the check worth doing today. Start with a test send and pull the full headers. The authentication results section does not lie. If you want a second pair of eyes on a deliverability issue you're trying to diagnose, get in touch.
Comments