SPF: who's allowed to send mail on behalf of your domain?

Module 4: Records for email · Reading time: 10 minutes

Learning objective: After this lesson, you'll be able to read an SPF record, add a service correctly, and avoid the three best-known SPF mistakes: two records, +all, and more than ten lookups.

Key terms: SPF, v=spf1, mechanism (a, mx, ip4, ip6, include), qualifier (+ - ~ ?), all, one SPF record, limit of 10 DNS lookups, envelope sender (Return-Path)

The problem: anyone can use your name

Email was designed in the 1980s for a small, friendly internet. Any mail server can send an email with info@example.com as the sender, even if that server has nothing to do with example.com at all. Scammers happily take advantage of this.

SPF (Sender Policy Framework, RFC 7208) is a first step towards preventing this. In an SPF record, you specify which servers are allowed to send mail on behalf of your domain. A receiving mail server checks, for every incoming email: does this email come from a server that's on the list?

Think of it as a guest list at a door. The doorman (the receiving mail server) asks your domain for the list and checks whether the visitor (the sending server) is on it.

What does an SPF record look like?

An SPF record is a TXT record on your domain name that starts with v=spf1:

example.com.  3600  IN  TXT  "v=spf1 mx ip4:192.0.2.25 include:spf.mailer.example ~all"

You read it from left to right. The receiver goes through the parts one by one and stops at the first one that matches.

The ending: ~all, -all, ?all or +all

Each part can have a symbol in front of it that says what happens if it matches. For all (which always matches), that symbol makes all the difference:

If there's no symbol, + applies. So mx means +mx.

Which one should you choose? ~all is a safe default. -all is stricter and good if you're certain all your senders are listed in the record. If you use DMARC (lesson 4.5), the DMARC policy ultimately determines what happens; many administrators choose ~all in that case.

Mistake 1: two SPF records

There can only be one SPF record per domain. If the receiver finds two, the result is an error (permerror) and your SPF doesn't count at all. That's worse than having no SPF.

This often goes wrong in practice. A newsletter service or Microsoft 365 says "add this SPF record", and suddenly there's a second v=spf1 record alongside the old one. The solution: add the new service to the existing record.

Wrong:

"v=spf1 mx include:spf.oldhost.example ~all"
"v=spf1 include:spf.protection.outlook.com -all"

Right:

"v=spf1 mx include:spf.oldhost.example include:spf.protection.outlook.com ~all"

Note: when merging records, don't remove servers you still use. If your website sends mail via your hosting provider's server, that needs to stay in the record, even if your regular email goes to Microsoft 365. A hosting package often already has a default SPF with an include for the hosting provider (at WebOké, for example, that's include:webawere.nl); leave it in place as long as your website or forms send mail via that server.

Mistake 2: +all or a record that's too broad

+all at the end, or a huge range such as ip4:0.0.0.0/0, means anyone is allowed. At that point your SPF no longer offers any protection, and spam filters see it as a bad sign.

Mistake 3: more than ten lookups

To check an SPF record, the receiver sometimes has to make extra DNS queries. Every include, a, mx, exists, ptr and redirect costs a lookup, and an include also counts all the lookups in the record it points to. According to RFC 7208, the total may not exceed ten. If it does, the result is permerror and SPF fails.

ip4 and ip6 don't cost a lookup. Neither does all.

In addition, a maximum of two lookups are allowed to come back "empty" (a name that doesn't exist or has no answer). So an include pointing to a service you stopped using ages ago, and which has removed its record, can also cause problems.

If you use lots of services, count them using an SPF checking tool (lesson 8.3) and remove services you no longer use.

What SPF doesn't do

SPF checks the envelope sender: the technical sender address (Return-Path) that mail servers use between themselves. That's not always the same address as the "From:" address you see in your email program. A newsletter service often sends with its own Return-Path. So SPF alone doesn't stop every forged sender. That's what DKIM (lesson 4.4) and DMARC (lesson 4.5) are for.

SPF also breaks with forwarding: if you forward email automatically to another address, it arrives at the final recipient from a server that isn't in your SPF.

Why it matters

Major mail providers have become stricter. Since February 2024, Gmail and Yahoo require that everyone sending email has at least SPF or DKIM, and that anyone sending large volumes of mail (more than about 5,000 per day) has SPF, DKIM, and DMARC. Microsoft has imposed the same requirement for Outlook.com, Hotmail, and Live.com since May 2025. Even if you send little mail, a good SPF record helps keep you out of the spam folder.

In practice: what it looks like in a panel

In this example, we use DirectAdmin. In DNS Administration, click the pencil icon next to the TXT record that starts with v=spf1. DirectAdmin opens an SPF helper: under Include Domain, enter the domain of the service (without include:); under Mode, choose SoftFail (~all) or Fail (-all). At the bottom, you'll see the full record. My WebOké has a similar SPF helper on the DNS tab.

Other panels don't always have such a helper. In that case, you edit the TXT record as plain text; the content is exactly the same.

Summary

• SPF is a TXT record with v=spf1 that states which servers are allowed to send mail on behalf of your domain.
• Exactly one SPF record per domain. New service? Add it to the existing record.
• End with ~all or -all, never with +all.
• Maximum of ten DNS lookups (include, a, mx, exists, ptr, redirect); ip4/ip6 don't count.
• SPF looks at the envelope sender; for real protection you also need DKIM and DMARC.

Quiz

Exercise

Exercise Z4.3: Looking up SPF. Look up the SPF record for google.com (or your own domain). Paste the full record, and fill in what it ends with (~all, -all, ?all, or +all). For your own domain, the exercise also checks whether you have exactly one SPF record.

Exercise O4.3: Set it up yourself in your practice zone. In the practice zone, you use a fake service; for your real domain, you use the real include provided by your mail provider (for example include:_spf.google.com). In your practice zone <code>.dnspractice.eu, create an SPF record that allows: the zone's MX servers (mx), the address 192.0.2.25, and the practice service _spf.mailsuite-demo.dnspractice.eu. Other servers are suspicious or not allowed, so the record ends with ~all or -all.

Further reading

The steps in these articles apply to WebOké's panels; other panels work in a similar way.

• DirectAdmin guide 5.7: Setting up and adding to SPF
• How does the SPF record work in DNS?
• Adding or changing an SPF record in DirectAdmin
• WebOké manual 5.5: DNS helpers: MX, SPF, DMARC, CAA and SRV
• RFC 7208 (SPF), particularly section 4.6.4 (limit of ten lookups and two empty lookups)