What Is an SPF Record and How to Set One Up

Anyone can send an email that claims to come from your domain; the basic email protocol does nothing to stop it. An SPF record is the first line of defence. It is a short line of text in your DNS that lists which servers are allowed to send mail for your domain, so receiving mail servers can spot messages from anywhere else. Setting one up correctly is also now a basic requirement for getting your own mail delivered to the big mailbox providers.

What SPF checks, exactly

SPF (Sender Policy Framework, defined in RFC 7208) works with the envelope sender, the address given in the SMTP MAIL FROM command, which ends up in the Return-Path header. It is not necessarily the "From" address people see in their mail client. When a message arrives, the receiving server:

1. Takes the domain from the envelope sender.
2. Looks up that domain's SPF record, a TXT record beginning v=spf1.
3. Checks whether the IP address that connected to it is authorised by the record.
4. Records a result: pass, fail, softfail, neutral, none, or an error.

Because SPF alone does not protect the visible From address, it is used together with DKIM and DMARC. DMARC ties the SPF result to the From domain the reader actually sees.

Anatomy of an SPF record

v=spf1 ip4:203.0.113.25 include:_spf.google.com include:sendgrid.net -all

Read from left to right: this is SPF version 1; the server at 203.0.113.25 may send; anything Google Workspace authorises may send; anything SendGrid authorises may send; everything else fails.

Mechanisms

The ptr mechanism also exists but the standard discourages its use; avoid it.

Qualifiers

Each mechanism can be prefixed with a qualifier. + (pass, the default), - (fail), ~ (softfail: probably not authorised) or ? (neutral: no opinion). In practice you only ever put a qualifier on the final all:

• -all: hard fail. Mail from unlisted servers should be rejected.
• ~all: soft fail. Mail from unlisted servers is suspicious but should not be rejected on SPF alone.
• ?all: neutral, which provides almost no protection.
• +all: authorises the entire internet. Never use it.

How to set up an SPF record, step by step

1. List everything that sends mail as your domain

This is the step that matters most. Include your mailbox provider, marketing platform, CRM, helpdesk, invoicing or accounting software, website contact forms and any server or printer that sends notifications. If you already have DMARC reports, they show you every source using your domain.

2. Collect each sender's SPF instructions

Each provider documents what to add, usually an include. Common examples are include:_spf.google.com for Google Workspace and include:spf.protection.outlook.com for Microsoft 365. Always take the value from the provider's current documentation rather than copying it from another domain.

3. Combine them into a single record

A domain must have exactly one SPF record. Two TXT records both starting v=spf1 produce a permerror and SPF fails entirely. If a new service tells you to "add an SPF record", what it really means is add its include to your existing one.

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.25 ~all

4. Publish it

In your DNS control panel, create a TXT record on the root of your domain (host @) with the value above. Do not add it at www or another subdomain unless that subdomain sends mail.

5. Test it

dig example.com TXT +short | grep spf1

The DNS lookup tool shows the same TXT records from a browser. Or use our SPF, DKIM and DMARC checker, which also counts DNS lookups and flags syntax problems. Then send a message to an external mailbox, open the full headers, and look for spf=pass in the Authentication-Results header.

Softfail or hardfail?

Many administrators start with ~all while they confirm every sender is included, then consider moving to -all. Once you have DMARC in place, the difference matters less, because DMARC policy rather than the SPF qualifier decides what happens to failing mail, and most receivers treat SPF as one signal among many. A softfail is the safer choice if you are not completely sure your sender list is complete.

Limits and common mistakes

• The 10-lookup limit. Evaluating SPF may trigger at most 10 DNS lookups. Every include, a, mx, exists and redirect counts, including those nested inside other providers' records. ip4 and ip6 do not count. Exceeding it causes a permerror.
• Multiple SPF records, as described above.
• Forgetting a sender, so legitimate invoices or notifications fail.
• Leaving old services in the record long after you stopped using them, which wastes lookups and authorises servers you no longer control.
• Domains that never send mail are left without SPF. Publish v=spf1 -all on them so nobody can use them convincingly.

SPF and forwarding

When a message is forwarded, for example from an old address to a personal mailbox, the forwarding server sends it from its own IP, which is not in your SPF record. SPF then fails at the final destination. This is a known limitation and one of the reasons DKIM, whose signature survives forwarding, matters just as much.

Key takeaways

• An SPF record is a TXT record listing the servers allowed to send mail for your domain.
• Have exactly one SPF record, combine every sender into it, and end it with ~all or -all.
• Stay within the 10 DNS lookup limit and remove services you no longer use.
• Use SPF together with DKIM and DMARC; on its own it does not protect the visible From address.