Valid SPF, DKIM and DMARC records can still leave your domain spoofable

A post on dev.to (originally published on the Merlonix blog) argues that the standard way of auditing email authentication asks the wrong question. Most free checkers confirm only whether a domain has SPF, DKIM and DMARC records published at all. But each of those records has a permissive mode that reads as "configured" to a presence check while doing nothing to stop spoofing, so a domain can show green across the board and still be forged at will.

Presence is not enforcement

According to the dev.to post, the permissive modes exist for a legitimate reason: they let operators roll out authentication gradually without bouncing their own legitimate mail. The failure mode is that "watching first" and "finished" look identical to a presence-only tool, and a large number of domains never return to tighten their configuration after the initial rollout.

SPF: only one qualifier rejects mail

An SPF record ends in an all mechanism whose qualifier decides what receivers do with mail from servers that are not on the list. The post breaks the four options down:

• -all (hardfail) rejects mail from unauthorized servers — the only setting that actually protects the domain.
• ~all (softfail) marks mail as suspicious but still lets it deliver; this rollout setting is where the post says most records get stranded.
• ?all (neutral) expresses no opinion, making it functionally equivalent to having no policy on the term.
• +all permits any server on the internet to send as the domain — the post calls this worse than no SPF at all, and usually a copy-paste accident.

The post also flags a second, less-known trap: RFC 7208 caps SPF evaluation at 10 DNS lookups, and each include: entry for a mail vendor — ESP, CRM, helpdesk, invoicing tool — consumes one or more. Cross the limit and receivers return a PermError and stop evaluating SPF entirely, so a record that worked yesterday can silently stop working the day one more vendor is added, with nothing in DNS changing to warn the operator.

DMARC: p=none reports but does not block

DMARC's p= tag is the enforcement switch. p=none tells receivers to check, report and deliver anyway, so forged mail still reaches the inbox — the post likens it to a smoke detector that detects the fire without putting it out. p=quarantine sends failing mail to spam, and p=reject refuses it outright, which the post describes as the goal.

Two further tags can quietly undercut a policy that looks enforced:

• sp= sets the policy for subdomains. A record with p=reject but sp=none leaves subdomains such as mail., news. or billing. fully spoofable, and attackers know to probe them.
• 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 — a rollout dial the post says people forget to return to 100.

DKIM: the outside check has limits

DKIM signs each message with a private key and publishes the matching public key in DNS at an address built from a selector chosen by the sender. Because selectors cannot be enumerated via DNS, an external checker can only probe a curated list of the well-known ones used by major providers — Google Workspace uses google, Microsoft 365 uses selector1 and selector2. A hit is definitive, but a miss only means none of the common selectors resolved; a domain signing with a custom selector will show up blank. The post's advice is to read a "DKIM: not found" result as "verify by hand," never as proof the domain lacks DKIM.

MTA-STS follows the same pattern

The split between published and enforced appears one layer down, in transit encryption for inbound mail. MTA-STS (RFC 8461) lets a domain tell other servers to always use TLS when delivering to it, but only mode: enforce forces it — a policy in mode: testing reports what the receiver would have done and delivers over plaintext anyway. TLS-RPT, its companion record, collects failure reports but enforces nothing on its own.

Why it matters

Email spoofing remains a primary vector for phishing and business email compromise, and the domains most at risk are the ones that believe they are already protected. The post's closing checklist: confirm SPF ends in -all and stays under the 10-lookup limit; confirm DMARC's p= is at least quarantine, that sp= is equally strong, and that pct= is at 100; verify DKIM by identifying the selector your sender actually uses rather than trusting an external probe; and check that MTA-STS is in enforce mode, not testing. Every one of these distinctions is visible with dig or nslookup and a careful read of each record's qualifiers — precisely the enforcement details most presence-only checkers skip.