The Email That Vanished

A 20-minute deliverability detective story.

Not yet a Member? Read for Free

Every tool said the setup was perfect. Gmail disagreed. Here’s how we found the lie in the middle.

Names, domain, IP addresses, and keys below are fictionalized. The technical mechanism is exactly as it happened.

A friend brought me a problem that sounds simple until you’ve lived it. He does IT for a living and helps a handful of local small businesses on the side, so he’d already poked at this one himself before he asked whether we had a way to crack it. The symptom: one of his clients had email that could receive mail just fine, but anything they sent to a Gmail address silently failed. Orders, replies, test messages — bounced hours later, or just never arrived.

The client runs a small online shop — call it Northwind Supply (northwindsupply.com) — on a hosted store platform. The bounce looked like this:

From: Mail Delivery System <MAILER-DAEMON@[relay-service].net>
Subject: Undeliverable: Testing my email
Delivery has failed to these recipients:
   buyer@gmail.com

He’d already done the responsible thing. He ran the domain through the popular checkers. SPF: present. DMARC: present. MX: resolves. All green. Every dashboard told him the configuration was healthy.

So why was Gmail eating his mail?

The four-layer trap

The first move wasn’t to add records. It was to figure out which of four separate systems actually controlled each piece. This is where almost everyone gets stuck, because they’re casually treated as one thing:

• Registrar — where the domain is registered.
• DNS host — whose nameservers are authoritative for the zone (this is the one that matters).
• Mailbox host — where the inbox physically lives.
• Outbound relay — the server that actually transmits his sent mail to the world.

He had a login to the registrar. He’d been editing DNS records there for an hour. But a live nameserver lookup showed the zone was delegated to the client’s store platform — a completely different company, which he had no login to. Every “fix” he’d made at the registrar was landing in a zone file nobody was reading. That alone explained weeks of frustration.

Mail passes through four systems. Most people treat them as one.

The tell hiding in the bounce

The bounce wasn’t from his mailbox host. It came from a third-party SMTP relay — the kind budget hosts quietly route all outbound mail through. That single detail was the whole case.

Gmail wasn’t seeing mail “from Northwind’s server.” It was seeing mail arriving from a relay’s shared IP address, claiming to be Northwind. And here’s what every green checkmark missed: his SPF record never listed that relay. It authorized his mailbox server and a couple of marketing tools — but not the one machine actually doing the sending.

v=spf1 a:mail.northwindsupply.com include:_spf.somemarketingtool.example ~all

No relay. And no DKIM signature anywhere (the default selector was empty). So from Gmail’s side: the mail was unauthenticated by both methods it accepts.

Since February 2024, Gmail requires every sender to pass SPF or DKIM. Fail both and you get this, which was waiting in the full bounce text:

550-5.7.26 This mail has been blocked because the sender is unauthenticated.

The checkers said “clean” because they only verify that an SPF record exists and is valid syntax. They have no idea your real send-path is a relay you forgot to list — and they won’t flag a missing DKIM key unless you hand them the exact selector. “Valid” and “authenticates in the real world” are not the same test.

The fix

Two records, published in the zone that’s actually authoritative — not the registrar:

1. SPF — add the relay. The host’s own include already chained to it, so one addition did the job:

v=spf1 a:mail.northwindsupply.com include:_spf.webhost.example include:_spf.somemarketingtool.example ~all

(That _spf.webhost.example include nested the relay's own SPF inside it — so listing the host covered the relay automatically. Worth verifying by reading the chain, rather than trusting the label.)

2. DKIM — and this is where he nearly tripped. The host handed him a key and called it a CNAME. But anything whose value starts with v=DKIM1; k=rsa; p=… is a TXT record — a CNAME can only point to a hostname, never hold a key. Published correctly:

Type:  TXT
Name:  default._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEF...AQAB;

One more landmine: the mailbox’s A record had to stay unproxied. Route SMTP through a CDN proxy and it breaks — and your a:mail SPF mechanism starts resolving to the proxy's IP instead of your server's.

We pushed the changes, sent a test to a Gmail inbox, and ran the headers through a deliverability scorer. SPF ✅, DKIM ✅, DMARC aligned. Delivered. Weeks of silent failures, closed in an afternoon.

What to steal from this

• Email lives across four systems, not one. Before touching a record, confirm which system is authoritative. The login you have is often not the one that matters.
• The bounce names the culprit. It came from the relay — that’s your proof of the real send-path, and the first thing your SPF must authorize.
• “All green” only means syntactically valid. Checkers can’t see that your actual outbound path isn’t listed.
• Gmail needs SPF or DKIM to pass. Have both. Relying on one is one outage away from invisible.
• A key is a TXT record, not a CNAME. If the value starts with v=DKIM1, it's text.

The part that’s actually ours

Everything above is yours. Every record, every gotcha, the exact order we changed things. We don’t gatekeep the what; if you’re fighting the same bounce, copy it wholesale.

What turned weeks of being stuck into a single afternoon wasn’t the records, though. It was the how. This solve was organized by Quiet AI, the quiet system we build with: it read all four layers of live evidence at once, spotted the one that was lying, looked there first, and sequenced the fix before a single guess got made. (It assembled this write-up while it was at it.)

That’s the part that doesn’t fit in a checklist. Anyone can learn what a DKIM record is. The edge is the system that knows which of four layers to interrogate, and in what order, so the right answer surfaces in minutes instead of weeks.

Which is the whole point of Quiet AI. It doesn’t do anything you couldn’t eventually do yourself; it makes the right move obvious and fast, then gets out of the way. The email goes through and nobody sees the machinery. The bounce had been naming the answer the entire time — all it took was something that knew which layer to read it from.

Information doesn’t scale. Systems do.

Finding the one lying record in an afternoon is the small version of what we do. The bigger version: taking the hard-won expertise that lives in one person’s head — the stuff a business quietly runs on — and turning it into systems it can run without them. We don’t sell websites. We build clarity.

**Work with Quiet AI →**