New here? I’m building Vesprit in public for Shipaton, a study app that predicts what you’re about to forget and brings it back before it’s gone. I wrote a full intro to it here. This post is one bug from that build: the week my waitlist quietly broke, and why “my domain is authenticated” turned out to mean nothing.
The Setup
Vesprit has a waitlist. Someone enters their email, the form posts to my email provider, they get a confirmation email, they click it, they’re on the list.
Every part of that worked. The form returned success. The subscriber showed up stored. The confirmation email sent.
And landed in spam. Every time. Under double opt-in that isn’t cosmetic: an unconfirmed subscriber never gets anything again, so a signup in spam is a signup I don’t have, and nothing anywhere reports it as a failure.
So I did what the tutorials say. Four records from my provider, CNAMEs and TXT, into the zone at my registrar, alongside the SPF already there. A DMARC record. Green checkmark in the dashboard: domain authenticated.
Still spam. That checkmark is the whole story. It was true. It just wasn’t answering the question I thought it was.
Five Days of Chasing the Wrong Thing
First spam filing August 11. Cause found August 15. Fixed August 16.
I blamed the email content first, too many links and spammy words, the usual deliverability folklore. Then I blamed propagation. Neither.
Then it got worse in a way that was my own fault. My provider paused my account for new-account verification, which stopped it sending anything at all. I’d added a new sending address by then, and it sat pending, because the confirmation email for that address couldn’t send while the account was paused. Nothing in my repo, my DNS, or my site could move it.
And what contributed to the pause was me clicking “resend confirmation” over and over. I made the block longer by fighting it. The correct action was to wait, which is the least satisfying instruction there is.
None of that was the bug. All of it was me not yet understanding the bug.
The Note That Said “Fixed”
Here’s the part I’d rather leave out.
While I was locked out, my own project notes recorded domain authentication as the fix. Shipped, awaiting a re-test. I’d written down a conclusion, and the only thing between me and believing it permanently was a test I couldn’t run yet.
That re-test would have failed. And since I’d be re-testing what I already believed was the answer, it would have failed while leaving the cause unexplained. I’d have gone looking for a fifth reason.
What actually happened is that the wait left me nothing to do but re-read what I’d written, and the sentence stopped making sense. One line said the domain is authenticated. Another said the mail fails DMARC. I’d been reading those as sequential when they were simultaneous, and both being true at once is only possible if the authenticated domain and the checked domain are different domains.
So I corrected the note before the test rather than after it. Commit 5a63f7e, August 16: “This repo recorded domain authentication as the fix. It was necessary and not sufficient.” I kept the wrong version in the file rather than editing it away. I trust that record more now that it has a reversal in it than I did when it was clean.
What was actually wrong
Here’s the Show original from one of those spam emails.
- SPF: PASS
- DKIM: PASS, on a domain belonging to my provider, not mine
- DMARC: FAIL,
header.from=gmail.com
SPF passed, DKIM passed, DMARC failed. That looks impossible until you know what DMARC checks.
SPF and DKIM each authenticate a domain, and neither has to be the domain a human sees. SPF checks the envelope sender, which the recipient never looks at. DKIM checks whatever domain signed the message. Both of mine passed cleanly, on my provider’s domains. DMARC is the check that ties one of those back to the visible From header, and it passes only if an authenticated domain aligns with the From domain. Not “is valid.” Aligns.
My provider was sending from a gmail.com From address, its own account signup address, which I had never looked at. The mail authenticated on my provider’s domain, the From header said gmail.com, and those are not the same domain. Alignment failed.
My domain being authenticated was irrelevant. It was never the domain being checked. I’d spent five days perfecting the authentication of a domain that didn’t appear where it mattered.
The Policy I Assumed Was Strict
I told myself a tidy story about the junking: gmail.com publishes a strict DMARC policy, my mail failed it, into the bin. I checked that before publishing this, because this whole article is about not trusting the version of events you find satisfying.
$ dig +short TXT _dmarc.gmail.com
"v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
$ dig +short TXT _dmarc.vesprit.app
"v=DMARC1; p=none;"
p=none is monitoring. It asks receivers to take no action on a failure and just send a report. Both domains involved published p=none, and the mail was junked on every single send.
So no policy ever told Gmail to bin my mail. Gmail did it anyway. I can’t see inside their filter and won’t pretend to, but the shape isn’t mysterious: mail claiming to come from gmail.com that didn’t come from Google is a strong spam signal on its own merits. DMARC alignment isn’t only an instruction to receivers. It’s a fact they get to use however they like.
Which kills the comforting version. If you’ve been telling yourself misalignment is cosmetic while you’re on p=none, here’s your counterexample.
The Fix
Not more DNS. Changing the From address to one on my own domain, so the domain that authenticates and the domain in the From header are finally the same.
One trap inside it: adding a sending address doesn’t make it the default. The old one stays default until you explicitly move it. So for a while I had the right address configured and the wrong one still sending. Configured is not active.
- SPF: PASS
- DKIM: PASS, now on my domain
- DMARC: PASS,
header.fromset to my domain
Same three checks. Two were already passing before. The only line that changed is the one that was ever in question.
Read the Result, Not the Proxy
I didn’t confirm the fix by checking which folder it landed in. That’s what I’d done for five days, and the folder is downstream of heuristics I can’t see. The p=none lookup proves it: the folder and the policy disagreed completely.
I confirmed it by opening Show original and reading dmarc=pass and header.from myself. The folder is an opinion. The Authentication-Results block is the fact.
Which is what I should have done on day one. My whole debugging failure was trusting a green checkmark and a folder location, two proxies, instead of the one line that states the outcome. Authenticated is not delivered. The checkmark confirms a mechanism ran, not that mail arrives.
The part I’d generalize past email: a passing check on the wrong subject is worse than no check at all. SPF passed. DKIM passed. Both true, both irrelevant, and both made me more confident while the one alignment that mattered failed quietly underneath them.
Honest Scale
Nobody was affected. Vesprit is pre-launch, it isn’t on any store, there are no users on the product. The only confirmation emails going to spam were mine, in my own test inboxes.
It was my bug, not just the tool’s. A provider defaulting to a gmail.com From address is a bad default. But I’m the one who authenticated a domain without checking it was the one in the From header, then read the folder instead of the headers for five days, then wrote “fixed” in my own notes about something I hadn’t tested.
And it isn’t fully fixed. It reaches the Gmail inbox now. On August 18 I sent the same mail to Outlook and it went to Junk. Nothing is misconfigured. Same message, same passing DMARC, same aligned From. Outlook junks it anyway.
That isn’t a bug and there’s no setting for it. It’s a cold domain with almost no sending history, and placement at that point is reputation, which you earn by sending mail people want over time. So the accurate status isn’t “fixed.” It’s “reaches Gmail, still proving itself to Outlook.” There’s no green checkmark for that one.
If your confirmation emails are hitting spam: open one, Show original, and check whether the From domain is actually yours. Then check what your provider has set as its default sending address, which is somewhere else in the product entirely.
Mine was a gmail.com address the whole time, and no amount of DNS was ever going to fix the domain I wasn’t looking at.