SPF

SPF (Sender Policy Framework) is a DNS TXT record that tells receiving mail servers which hosts may send email for your domain. Without SPF, or with a broken SPF, domain mail is more likely to land in spam or be rejected.

SPF does not encrypt message content. It is only a policy for “who is allowed to send.” For a fuller email authentication chain, pair SPF with DKIM and DMARC.

A Simple Analogy

Think of your domain as a company. SPF is the official courier list posted on the notice board. Recipients check that list: if the courier is not listed, the package looks suspicious.

What the Record Looks Like

SPF lives in a TXT record, usually on the root domain (example.com), roughly like:

v=spf1 include:_spf.google.com include:mail.provider.com ~all

That means: allow the servers referenced by those include mechanisms, and apply the ending policy to everyone else (-all hard fail, ~all soft fail, ?all neutral).

When SPF Matters

• Business mail such as [email protected]
• CMS contact forms or notifications sending as your domain
• Newsletters or transactional mail from third-party tools
• Hosting or mail migrations — old SPF is easy to forget

The link to SMTP is practical: SMTP delivers the message; SPF helps the receiver decide whether the sender is authorized.

Common Mistakes

• More than one SPF record on the root (they must be merged into one)
• Too many DNS lookups from nested include chains
• Forgetting to add a new CRM, payment, or marketing sender
• Using +all, which is far too permissive

What to Watch For

• Edit SPF in the active DNS zone matching your nameservers
• Respect TTL when testing changes
• After updates, send test mail to Gmail/Outlook and read authentication headers
• SPF alone is rarely enough — continue with DKIM and DMARC

FAQ