Is SPF enough to stop email spoofing?

No. SPF checks the envelope sender, which the recipient never sees, so a message can pass SPF for a domain the sender controls while displaying your domain in the From: header. Only DMARC ties the visible From: address to an authenticated result, which is why SPF, DKIM and DMARC are used together rather than SPF alone.

Where does the SPF record go?

In a TXT record at the apex of your domain: the record name is the bare domain, usually entered as @ in a DNS panel. It does not go at spf. or _spf. There must be exactly one SPF record per domain; a second one is a permanent error.

Do subdomains need their own SPF record?

Yes. SPF is evaluated against the exact domain in the envelope sender and does not inherit, so a subdomain that sends mail needs its own record. This differs from DMARC, which does apply to subdomains by default.

ConceptSPF

What is an SPF record?

SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are allowed to send email using your domain. When a message arrives, the receiving server reads the domain in the envelope sender, looks up its SPF record, and checks whether the server that actually sent the message is on the list. If it is, SPF passes; if not, the record's policy tells the receiver how suspicious to be. SPF is one of the three checks (with DKIM and DMARC) that decide whether your mail is trusted.

See it on your own domainSPF checker

How SPF actually works

An SPF record lives as a single TXT record at your domain and starts with v=spf1. After that comes a list of mechanisms (include:, ip4:, a, mx) that name the servers and services allowed to send as you, and it ends with an all mechanism that sets the policy for everyone else. A receiver evaluates the mechanisms left to right and stops at the first match. Crucially, SPF is checked against the envelope sender (the address in the SMTP conversation), not the From: address a person reads, which is why SPF alone cannot stop display-name spoofing, and why DMARC exists.

The one limit that catches everyone

SPF permits a maximum of ten DNS lookups when a receiver evaluates the record. Every include pulls in that provider's own record, whose mechanisms count too, so a record with a handful of includes can quietly exceed ten, at which point SPF returns permerror and stops passing for all of your mail, not just the senders past the tenth lookup. This is the single most common way a correct-looking SPF record fails, and it is worth checking your live lookup count rather than counting the includes you can see.

How to end the record

Start the record with ~all (softfail), which asks receivers to treat unlisted senders with suspicion without rejecting them, giving you room to find any sender you missed. Once you are confident every legitimate source is listed, tighten to -all (hardfail). Never use +all, which authorises the entire internet to send as your domain and is worse than having no record at all.

Common questions

Is SPF enough to stop email spoofing?: No. SPF checks the envelope sender, which the recipient never sees, so a message can pass SPF for a domain the sender controls while displaying your domain in the From: header. Only DMARC ties the visible From: address to an authenticated result, which is why SPF, DKIM and DMARC are used together rather than SPF alone.
Where does the SPF record go?: In a TXT record at the apex of your domain: the record name is the bare domain, usually entered as @ in a DNS panel. It does not go at spf. or _spf. There must be exactly one SPF record per domain; a second one is a permanent error.
Do subdomains need their own SPF record?: Yes. SPF is evaluated against the exact domain in the envelope sender and does not inherit, so a subdomain that sends mail needs its own record. This differs from DMARC, which does apply to subdomains by default.