BuildNot yet confirmed elsewhere1 publisher2 min readPublished
SPF and DMARC records that pass every free checker and stop nothing
Presence and enforcement are different questions, and the free checkers only answer the first. The switches that matter are the qualifier on SPF's all term and DMARC's p=, sp= and pct= tags.
The Engineer · Build desk
What happened
- A Merlonix post republished on dev.to splits domain authentication into two questions: whether the records exist, and whether they stop anyone sending as you.
- SPF enforcement rests on the qualifier before the all term, and only -all tells receivers to reject servers that are not on the list.
- The author calls a published DMARC record left at p=none the most common state on the internet, and p=none delivers forged mail anyway.
- Two further tags soften a policy that reads as enforced: sp= sets subdomain policy separately, and pct= applies the policy to only a share of mail.
Why it matters
- constraint A green result from a presence checker cannot distinguish a rollout from a finished deployment, so it is not evidence anyone can offer to a customer or auditor asking whether the domain is spoofable.
- decision Onboarding another SaaS sender stops being a DNS append and becomes a spend against a fixed lookup budget, which means the helpdesk purchase belongs in the same conversation as the mail policy.
- exposure An apex domain that reads as locked can leave mail., news. and billing. as the reachable target, so the useful address for an attacker is the one nobody put on the checklist.
- cost The bill for a permissive setting is paid by whoever receives the forged mail, because on the sending side the DNS looks unchanged and the record still passes inspection.
Every permissive setting in this stack fails in the same direction, which is delivery. Softfail marks the message and hands it over [4], neutral states no opinion at all [5], `p=none` reports and delivers [12], and `p=reject; pct=20` enforces on one message in five while the other four go through [14]. That last one is 80 percent of exactly the mail the policy was written to stop [17]. Of the four qualifiers available on SPF's `all` term, three produce no rejection [18], and the one that does is the one you never reach by leaving the rollout setting where it is [3][4].
The ten-lookup cap is what turns a one-time setup into a decaying asset. RFC 7208 stops SPF evaluation at ten DNS lookups, and each vendor `include:` can cost one or more [10]. Take the friendly case where every vendor costs exactly one: ten includes puts you level with the cap, and the eleventh sender you onboard puts you over it [19]. Nested includes mean ten is a ceiling nobody actually reaches. Past the line, receivers return PermError and abandon SPF evaluation entirely, and nothing in your DNS changed to tell you [10][11].
There is a second-order effect the post does not follow through. DMARC acts on messages that fail both SPF and DKIM [15]. With SPF in PermError there is no SPF pass available to align, so every DMARC pass has to come from the DKIM signature [20]. A domain in that state can be publishing `p=reject` and running on one leg, and the record text still reads as strong.
Worth naming what this material is. It is a Merlonix blog post republished on dev.to [16], and the supplied text breaks off mid-sentence in the DKIM section [7], so DKIM here amounts to the description of how signing and key publication work [8] and nothing about how it gets left half-configured. The two switches it does document are enough to work with, because both live in text you publish yourself rather than in telemetry you have to buy. The reason so many domains sit unenforced is not obscurity: permissive modes exist so a rollout does not bounce your own legitimate mail, and "published it in monitor mode to watch first" is indistinguishable from "finished" to any tool that only looks up whether a record exists [9].
What to watch
- Whether the completed DKIM section documents an equivalent do-nothing default, which would extend the presence-versus-enforcement argument to all three records rather than two.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence60
- Adoption
- Insufficient
- Hype gap+12
- Incentives55
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The post separates two questions about domain email authentication: whether SPF, DKIM and DMARC records exist (a presence lookup) and whether those records actually stop someone sending mail that looks like it came from you (enforcement). A domain can pass the first and fail the second completely, with every free checker showing green, because each record is published in its permissive mode.
ReportedSupportedSource: Merlonix post republished on dev.to2 sources— create a free account to open themView cited source - [2]
An SPF record lists which servers may send as your domain and ends in an all mechanism; the qualifier on that final all term is the entire enforcement decision, and there are four qualifiers.
- [3]
-all (hardfail) means reject mail from any server not listed, and is the only qualifier that protects the domain.
- [4]
~all (softfail) means accept but mark suspicious; receivers still deliver. Softfail is the rollout setting and, per the author, where most records get stranded.
- [5]
?all (neutral) means no opinion, functionally the same as having no policy on the all term.
- [6]
+all means any server on the internet may send as the domain; the author calls it actively worse than no SPF at all and usually a copy-paste accident.
- [7]
The supplied text breaks off mid-sentence in the DKIM section, after describing DKIM as the third leg of the triad, and does not document DKIM's permissive or misconfigured states.
- [8]
DKIM signs each message with a private key and publishes the matching public key in DNS, so a receiver can verify the message was not altered and really came from an authorized sender.
- [9]
Permissive modes exist so these records can be rolled out without bouncing legitimate mail; the problem is that 'published it in monitor mode so I could watch first' and 'finished' look identical to a tool that only checks presence, and the author says an enormous number of domains never come back.
- [10]
RFC 7208 caps SPF evaluation at 10 DNS lookups, and every include: (each mail vendor added) can cost one or more; go over 10 and receivers return a PermError and stop evaluating SPF entirely.
- [11]
A record that read as fine yesterday silently stops working the day another vendor is added; nothing in DNS changed to warn you, the lookup count just crossed a line.
- [12]
DMARC's p= tag is the enforcement switch with three settings: p=none checks and reports but delivers anyway (monitor-only, forged mail still lands in the inbox), p=quarantine sends failing mail to spam, p=reject refuses failing mail outright.
- [13]
sp= sets the policy for subdomains; a record with p=reject but sp=none leaves every subdomain (mail., news., billing.) fully spoofable, and the author says attackers know to try them.
- [14]
pct= applies the policy to only a percentage of mail: p=reject; pct=20 enforces on one message in five and delivers the other four. It is a rollout dial people forget to turn back to 100.
- [15]
DMARC ties SPF and DKIM together and tells receivers what to do when a message fails both.
- [16]
The article was published on dev.to and was originally published on the Merlonix blog.
- [17]
Under p=reject with pct=20, 80 percent of mail that fails the policy is still delivered normally.
- [18]
Three of the four available SPF all-qualifiers (~all, ?all, +all) result in no rejection of unlisted senders.
- [19]
If each vendor include costs exactly one DNS lookup, ten includes sit level with the RFC 7208 cap and an eleventh crosses it into PermError; because includes can cost more than one lookup, ten vendors is an upper bound rather than a working allowance.
- [20]
When SPF returns PermError, evaluation stops and no SPF pass is available, so a DMARC pass can only come from an aligned DKIM signature.
- [21]
The author states the single most common email-auth state on the internet is a domain that publishes a DMARC record, shows as present in checkers, and has the policy set to p=none: published and unenforced.
ReportedInsufficientSource: Merlonix post republished on dev.to2 sources— create a free account to open themView cited source
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toSPF, DKIM, and DMARC: Why “Valid” Records Still Let Your Domain Be Spoofed
1 article · August 24, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.