The Missing SPF Record That's Supposed to Be Missing

The Trigger#

Mail from sales@stonefyr.com was landing in Hotmail and Outlook junk folders. The domain had DKIM, so I assumed it was authenticated and went hunting for content-filter problems. Wrong direction. dig told the real story: no SPF record, no DMARC record. Outlook weights both heavily, and DKIM alone wasn't enough to clear the junk threshold.

That kicked off an audit of every domain I run, which finished on 2026-06-06 with all of them at SPF + DKIM + DMARC parity. Adding records turned out to be the easy part. The work was realizing that the right records differ per domain, and that copying a working config from one zone to another would have actively broken things.

Three Sender Profiles#

Every domain falls into one of three buckets, and the records have to match the actual sender:

Google Workspace mailboxes (stonefyr.com, airassaultfireworks.com, valkyrienexus.com): root SPF of v=spf1 include:_spf.google.com ~all, DKIM at google._domainkey. The standard setup.

Resend transactional domains (mattsdeliciousmeat.com, arnoldsappliancerepair.com -- contact-form mail only): root SPF is intentionally absent. This is the one that looks like a bug in every audit tool. SPF is evaluated against the envelope return-path, and Resend's return-path lives on the send. subdomain, so the records sit there instead: send.<domain> gets a TXT of v=spf1 include:amazonses.com ~all and an MX pointing at feedback-smtp.<region>.amazonses.com. Receivers check SPF against send.<domain>, never against the root. Adding a root SPF would authenticate nothing and imply the root sends mail, which it doesn't. So when a scanner flags "missing SPF" on these domains, the correct response is to leave it alone.

Brand-only domains that never send (valkyrienexus.dev): root SPF of v=spf1 -all, a hard deny, no DKIM, and DMARC at p=reject. Anyone spoofing the domain fails everything immediately.

The lesson under the lesson: DNS email records describe a sender, and you cannot copy a sender description between domains that send differently.

The DMARC Ladder#

DMARC policy starts at p=none (monitor only), moves to p=quarantine, and ends at p=reject once the aggregate reports confirm nothing legitimate is failing. Most of my domains are still at p=none, valkyrienexus.com is at p=quarantine, and valkyrienexus.dev went straight to p=reject because nothing legitimate can ever send from it.

All rua reports funnel to one inbox, dmarc@valkyrienexus.com, which has to stay a real, monitored mailbox or the reports bounce. Centralizing reports across domains has a catch I didn't know about: when DMARC reports go to a mailbox on a different domain, RFC 7489 requires an authorization record on the receiving zone -- <reporting-domain>._report._dmarc on valkyrienexus.com, content v=DMARC1. Without it, providers silently drop the reports. No bounce, no error; the reports just never arrive, and you conclude your mail is fine because you see no failures. stonefyr.com is the one exception, since it reports to its own dmarc@stonefyr.com.

Gotchas From the Rollout#

• A domain may carry only one SPF record and one DMARC record. Edit the existing one; adding a second invalidates both.
• DMARC lives only at the exact name _dmarc. I fat-fingered _dmard on valkyrienexus.dev and the policy was silently disabled until a dig pass caught it. Receivers don't guess at typos.
• TXT records cannot be Cloudflare-proxied. Always DNS only.

Verification#

DOMAIN=stonefyr.com
dig +short TXT "$DOMAIN" | grep -i 'v=spf1'
dig +short TXT "_dmarc.$DOMAIN"
dig +short TXT google._domainkey."$DOMAIN" | head -c40

For a Google Workspace domain I expect one v=spf1 line, a v=DMARC1 line with a rua=, and a DKIM key. For a Resend domain the root SPF query coming back empty is the correct result. After any change, I send a fresh test message to an Outlook or Hotmail address and read the message source for spf=pass / dkim=pass / dmarc=pass -- the headers receivers actually compute are the only verdict that matters.

The records themselves took minutes to write. Knowing which records each domain was supposed to have, and which "missing" ones to leave missing, took the audit.