Skip to content
RRAECHLY

Deliverability glossary · Updated 2026-08-10

SPF record

Also called: Sender Policy Framework

An SPF record is a DNS TXT record listing which servers are allowed to send mail for your domain. Receiving servers check the envelope sender against it to detect forgery.

SPF answers one question: did this message come from a server the domain owner authorised? The record lives in DNS as a TXT entry starting `v=spf1` and ends with a policy — usually `~all` (softfail) or `-all` (hardfail) — telling receivers what to do with mail from anywhere else.

The detail that trips people up is that SPF checks the envelope sender (the Return-Path), not the From address a recipient sees. A message can pass SPF while displaying a completely different From domain, which is exactly why SPF alone was never sufficient and why DMARC exists to tie the two together.

SPF also has a hard limit of ten DNS lookups. Every `include:` in your record counts, and nested includes count too. Exceed ten and the check returns permerror, which most receivers treat as a failure. Organisations that have accumulated a decade of SaaS vendors in one SPF record routinely break it this way without noticing.

For cold email the practical rule is that SPF must pass and must align with the domain in your From address. That means sending from a domain whose SPF you control, rather than one where you are guest number eleven in a shared record.

How Raechly handles it

The SPF record for your MAIL FROM subdomain is generated as part of `create_domain` and returned alongside the DKIM CNAMEs, so alignment is set up before the domain can send rather than diagnosed afterwards.

Related terms

Back to the full deliverability glossary, or read how these pieces fit together in how Raechly protects deliverability.

Deliverability you can check, not take on trust.

Raechly reports what it can prove: verified DKIM, verified reply capture, and the verbatim error on every failed send.