Six weeks. Eleven variables tested. One flat, stubborn number.
Nina came to me in January. Clean sending infrastructure, verified lists, done right from day one. By the end of her third week, she'd run her first cold outbound campaign — 2,400 contacts, tight ICP, a sequence she'd written herself and felt good about. Bounce rate came in under 1.4%.
The open rate came back at 3.7%.
She went through the standard checklist methodically. Tested three subject line variants over two weeks. Moved send timing from morning to midday to Thursday afternoons. Shortened the copy twice. Rewrote the opening line four separate times. At the end of week five, nothing had moved the number by more than half a percentage point in either direction.
By Friday of week five, she had a spreadsheet with eleven variables tested and one flat, stubborn number sitting at the bottom of every column. She was starting to write it off as a list problem.
I asked her one question before we went anywhere near her copy: "Did you check the domain authentication?"
We fixed all three. Two weeks later, the same sequence — same copy, same list, same timing — ran at 24%.
Why the same domain can be broken in three completely different ways
Nina assumed one broken thing was causing the problem. I had to explain why that assumption was wrong: SPF, DKIM, and DMARC aren't three checks on the same problem. They're answers to three completely different questions, and a domain can fail all three independently.
Nina's SPF said she was not authorized to send from her own domain. Her DKIM signature couldn't be verified. Her missing DMARC record meant she had no way to know either of those things was happening. She hadn't been failing at three things. She'd been blind to three things, in three different ways, at the same time.
What we found in Nina's record
The SPF record was the first thing we pulled up. What came back was this:
The -all at the end made it worse
The corrected record
The 10-lookup ceiling — Nina will hit it again if she's not careful
The SPF specification caps DNS lookups at 10 per evaluation. Every include: statement counts as one lookup — and every include you reference may trigger its own nested lookups inside that provider's SPF record.
Nina's stack today is small — Google Workspace and Mailgun. But she's planning to add a transactional email provider and a marketing automation platform. With four or five services all sending from the same domain, she could exceed 10 lookups without the record looking complicated. When the limit is exceeded, SPF returns a permanent error — the exact problem she just spent five weeks diagnosing, recreated by growth instead of neglect. Also: never publish two separate SPF TXT records on the same domain. The specification treats multiple SPF records as an error. Edit the existing one in place.
The problem that wasn't neglect — it was a job half-finished
The SPF problem had been born from nobody paying attention. The DKIM problem, once we traced it, was the opposite — someone had actively tried to do the right thing, and stopped halfway through.
A contractor had configured DKIM before Nina arrived. At some point during setup, they rotated the private key — a reasonable security practice. They updated the private key on the sending server. They did not update the matching public key in DNS.
From that day forward, every email the company sent was signed with private key version 2, while every receiving server retrieved public key version 1 from DNS. The two keys never corresponded. Every DKIM verification failed. Every one of her emails still delivered — which is exactly why nobody had caught it.
DKIM failure doesn't bounce the email. The message goes through. The failure is recorded silently in the message headers — a dkim=fail entry in the Authentication-Results field. Six weeks of sending where every outgoing message carried a cryptographic signature that said, to any server that checked, "this message cannot be verified" — and no alert, no bounce, nothing in her inbox to tell her.
What DKIM is actually doing when it works
DKIM-Signature headerThe selector — the one piece that would have saved Nina five weeks
Every DKIM record lives at an address that includes a selector — a label telling the receiving server which key to use. Format: selector._domainkey.yourdomain.com
The selector exists to support rotation without breaking email in transit. The correct process: generate the new key pair → publish the new public key under a new selector (not the existing one) → switch the server to sign with the new private key → leave the old selector live in DNS for 48 hours → then remove it.
The contractor had skipped this entirely — overwriting the existing selector's public key with the new one. The fix took five minutes: publish the current public key under the selector the sending server was actually referencing. Five minutes to undo two months of silent failure.
Two things Nina now checks on a recurring basis
Use 2048-bit keys — the 1024-bit standard is deprecated. Rotate keys every 6 to 12 months — nothing reminds you to do this, so put a recurring calendar event on it. To verify DKIM is working: send a test email to a Gmail address you control, open the raw headers (three-dot menu → Show original), and find the Authentication-Results header. dkim=pass means it's working. dkim=fail or dkim=none means the key in DNS doesn't match the key the server is signing with.
The missing policy, and the missing signal
When Nina found out her SPF was broken and her DKIM was failing, she asked me a reasonable question: why hadn't anything told her this was happening?
Email authentication failures are silent by default. An SPF fail doesn't trigger a bounce. A DKIM fail doesn't trigger a bounce. Both are noted in message headers, factored into spam filtering decisions, and passed to the placement algorithm — but the sender never hears back. If Nina had published a DMARC monitoring record on day one, she would have had reports in her inbox within 24 hours. She would have found both real problems on day two instead of week five.
Publishing your first DMARC record
A DMARC record is a TXT record published at _dmarc.yourdomain.com. Nina's first record, published that same afternoon:
The p=none starting point isn't a compromise. Moving straight to p=reject without reading monitoring reports first is how teams accidentally stop their own legitimate mail from delivering. If Nina had inherited a domain with p=reject already configured on day one, her emails wouldn't have gone to spam — they wouldn't have delivered at all. Not 3.7%. Zero.
The policy progression
The subdomain question
Root domain DMARC policy applies to subdomains by default. When Nina started reading DMARC reports, she discovered a transactional notification subdomain she'd forgotten existed. The sp= tag lets her enforce different policies on root vs subdomains:
What it actually cost, and what the fix actually took
An SPF record update. A DKIM public key republished under the correct selector. A DMARC monitoring record published for the first time. Three DNS changes, a 48-hour propagation window, and the same sequence ran at 24%.
If you're staring at an open rate that doesn't move no matter what you change about the message, that's the question to ask on day one, not week five: did you check the domain authentication?
Everything you need, in the order it needs to happen
dig TXT yourdomain.com and check every include: points to a provider you're actively usingv=DMARC1; p=none; rua=mailto:your-address at _dmarc.yourdomain.com — today, before anything elseClean lists need authenticated sends
Verification ensures your recipients are real. Authentication ensures your sends are trusted. Both are required — and neither replaces the other.