Build1 distinct publisher2 min readPublished
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

Compiled by The EngineerSomething wrong?How this is made
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 [9], and `p=reject; pct=20` enforces on one message in five while the other four go through [12]. That last one is 80 percent of exactly the mail the policy was written to stop [16]. Of the four qualifiers available on SPF's `all` term, three produce no rejection [17], 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 [7]. 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 [18]. 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 [7][8].
There is a second-order effect the post does not follow through. DMARC acts on messages that fail both SPF and DKIM [13]. With SPF in PermError there is no SPF pass available to align, so every DMARC pass has to come from the DKIM signature [19]. 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 [20], and the supplied text breaks off mid-sentence in the DKIM section [21], so DKIM here amounts to the description of how signing and key publication work [14] 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 [15].
Ranked by verification strength, evidence, and original report placement.
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.
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.
-all (hardfail) means reject mail from any server not listed, and is the only qualifier that protects the domain.
~all (softfail) means accept but mark suspicious; receivers still deliver. Softfail is the rollout setting and, per the author, where most records get stranded.
?all (neutral) means no opinion, functionally the same as having no policy on the all term.
+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.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Protocol mechanics checkable, prevalence bare
The mechanism claims are specific, internally consistent and verifiable against the standards they name: four SPF all-qualifiers, the RFC 7208 ten-lookup cap and PermError behaviour, DMARC p=/sp=/pct= semantics, and the DKIM selector non-enumerability that makes external 'not found' results inconclusive. That is a solid basis. It is docked because the cluster contains one self-published source with no independent corroboration, no example records or query output are shown, the prevalence assertions carry no data, and the supplied text is truncated before its MTA-STS argument completes.
No deployment or usage data supplied
The cluster contains no release, deployment, benchmark, incident or usage disclosure. The only statements touching real-world uptake — that p=none is the most common email-auth state and that 'an enormous number' of domains never leave monitor mode — are unquantified author assertions with no sample, scan or dataset, and inferring an adoption figure from them would be guessing.
Sober mechanics, unmeasured scale claims
Most of the piece stays at or below what it can support: the qualifier and tag semantics are definitional, the derived arithmetic (three of four qualifiers reject nothing; pct=20 delivers four in five) follows directly, and the DKIM section explicitly narrows its own claims by conceding a selector miss proves nothing. The small positive gap comes from the internet-scale prevalence framing — 'the single most common email-auth state on the internet' and 'an enormous number of domains' — asserted without measurement, in a post whose commercial origin benefits from the problem being large.
Vendor-blog origin with checker-shaped framing
The item states it was originally published on the Merlonix blog and is hosted under that account, and its thesis — that free presence checkers answer the wrong question while real assessment requires reading qualifiers and DMARC tags, with an aside that any tool reporting a flat 'no DKIM' overstates itself — aligns with promoting a more capable checking service. That is a moderate, visible content-marketing incentive rather than a hidden one: no pricing, product name or call to action appears in the supplied text, and the technical content is standards-grounded rather than proprietary.
One self-published, truncated source
Confidence is moderate. The claim set is well specified and the reasoning is transparent, so the assessment of what is being asserted is firm; but there is a single publisher, a single item, vendor provenance, no independent verification of any statement, no adoption data at all, and a text that cuts off mid-word, leaving one section unassessable.
build
Buy transactional email on recovery controls, not send price1 distinct publisher
build
Judge transactional email on retries and DKIM alignment, not open rates1 distinct publisher
build
Email and Slack disagree on what a conversation is, and the join key is the envelope1 distinct publisher
build
1,400 npm maintainer domains, 18 flags, and one word doing too much work1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 24, 2026