Missing SPF record

A forger sending as your domain passes the SPF stage by default, because there is no policy to fail against.

Your own mail arrives with one fewer authentication signal, which receivers weigh alongside everything else when deciding on the spam folder.

DMARC cannot be enforced meaningfully, because alignment requires either SPF or DKIM to pass — a domain with neither has nothing for DMARC to align.

Bulk senders and mailbox providers increasingly require authentication before accepting volume at all, so the absence eventually becomes a delivery failure rather than a reputation cost.

None of this is visible from inside: your mail keeps arriving for the people who already know you, and the losses are silent.

This is the whole difficulty, and it is not technical. Most organisations do not know every system sending as their domain.

The usual list is longer than expected: the mail platform, a marketing tool, a billing system, a ticketing system, a form handler on the website, a script on a server nobody owns.

Publishing a restrictive record before knowing the list is how legitimate mail starts failing, usually for whoever depended on the forgotten sender.

The safe order is to publish a permissive record first, publish a DMARC reporting address alongside, and read the aggregate reports for a few weeks.

Those reports name the sending addresses, which is the list you could not otherwise obtain.

One TXT record at the domain apex, beginning with the version tag and ending with an `all` qualifier.

Include mechanisms for each platform that sends on your behalf — every provider publishes theirs, and including their domain is how you avoid tracking their addresses yourself.

Literal address ranges for servers you operate directly, which cost no DNS lookup and are the cheapest mechanism there is.

A soft-fail ending while you are still establishing the list, which asks receivers to accept and mark rather than reject.

A hard-fail ending once the aggregate reports show every legitimate source passing, which is the position worth reaching.

The specification caps the evaluation at ten DNS lookups, counting your includes and everything inside them.

Above that, receivers return a permanent error and stop — which is the same outcome as publishing nothing, arrived at by a different route.

Three includes can exceed the budget on their own if one provider publishes a deep tree of its own.

So a record that works today can fail on a day you changed nothing, because a provider restructured its side.

Measure the expansion rather than counting your own includes, and leave headroom rather than sitting at nine.

`dig +short TXT example.com` prints the TXT records at the apex; the SPF record is the one beginning with the version tag.

Confirm there is exactly one. Several SPF records is a permanent error and produces the same result as none.

Read the ending qualifier rather than assuming it: a record ending neutrally parses correctly and protects nothing.

Send a message to a mailbox you control and read the raw headers, which report the authentication result the receiver computed.

Do not judge the outcome from one message. The aggregate reports over weeks are what show which sources pass.

`email.spf.present` reports whether a record exists at the apex, and `email.spf.single` whether exactly one is published.

`email.spf.syntax` reports whether it parses, since an unparseable record is discarded by receivers.

`email.spf.lookups` expands the include tree and counts it against the ten-lookup limit, and `email.spf.all` reads the ending qualifier.

`email.spoofing_exposure` combines the result with DKIM and DMARC, because SPF alone does not establish whether a domain can be impersonated.

`email.usage_context` establishes whether the domain appears to send mail at all, which decides whether the absence is a finding or simply not applicable.