How Do You Create an SPF Record for Your Domain? A Step-by-Step Guide
If your email lands in spam, or you worry that strangers could send mail pretending to be your business, an SPF record is one of the first fixes. It takes about ten minutes, costs nothing, and this guide walks through it in plain English. If you want the shortcut, our free SPF Record Generator writes the record for you; the steps below explain exactly what it is doing and why.
What is an SPF record and why does your domain need one?
An SPF record is a line of text in your domain’s DNS that lists every server allowed to send email using your domain name. Receiving mail servers check it on every incoming message: listed senders pass, unlisted senders fail. Without one, anyone can send email that claims to be from your domain, and your own genuine mail is more likely to be treated as suspicious.
SPF stands for Sender Policy Framework, and it has been a standard since the mid-2000s. It does not encrypt anything or check the message content; it simply answers one question, was this server authorised to send for this domain? That single check, combined with DKIM and DMARC, is what modern inbox providers such as Gmail and Microsoft now expect every legitimate sender to have in place.
Step one: how do you list everyone who sends for you?
Write down every service that sends email using your domain: your mailbox provider such as Google Workspace or Microsoft 365, your newsletter tool, your invoicing or CRM system, your website’s contact form, and any transactional service. Each one will be authorised in the record, and forgetting a sender is the most common cause of SPF problems later.
Be thorough here, because the day you publish a strict record is the day a forgotten sender’s mail starts failing. Check your billing and app settings if you are unsure; marketing tools and helpdesks are the usual stowaways. Subdomains that send, such as a dedicated mailing subdomain, each need their own record.
Step two: how do you build the record itself?
An SPF record starts with v=spf1, then lists one include for each sending service, such as include:_spf.google.com for Google Workspace, then any individual IP addresses, and ends with an all mechanism that says what to do with everyone else. Each part is separated by a single space, and the order of includes does not matter.
Rather than memorising each provider’s include value, use our SPF Record Generator: tick Google Workspace, Microsoft 365, SendGrid, Mailchimp or Amazon SES, add anything unusual, and it produces the finished record with a breakdown of what every part means. Copy it exactly; a single typo in an include value quietly authorises nothing.
Step three: what is the DNS lookup limit and why does it matter?
SPF checks are capped at 10 DNS lookups. Every include counts at least once, and big providers hide further lookups inside their own includes, so your real total is always higher than the number of services you ticked. Pass 10 and the check returns a permanent error, meaning SPF fails for every message you send, legitimate or not.
The practical defence is restraint. Remove tools you have stopped using, do not authorise a provider “just in case”, and if your list is genuinely long, split sending across subdomains so each one has a short record of its own. Our generator counts your visible includes live and warns you as you approach dangerous territory.
Step four: where do you publish the record?
In your domain’s DNS settings, as a TXT record on the root domain. Your DNS provider will show a host field, which for the root is usually @ or blank, a type field where you select TXT, and a value field where you paste the whole record starting with v=spf1. If a record already exists there, edit it rather than adding a second one.
One domain, one SPF record: publishing two is a permanent error. Propagation usually takes minutes, though it can take a few hours if old DNS values were cached with a long TTL. After publishing, send test emails from every service you listed to a Gmail inbox and inspect the authentication results in the message details.
Step five: should you end with ~all or -all?
End with ~all, called SoftFail, while you are testing: unlisted senders get flagged but their mail is usually still delivered, so a mistake costs you nothing. After a week or two of clean sending, with every service confirmed, change the ending to -all, Fail, which tells receivers to reject unlisted senders outright.
Never end with +all. That mechanism announces that every server on the internet is authorised to send as your domain, which deletes the protection you just built. If you inherit a domain whose record ends in +all, fixing that one detail is the single highest-value change you can make.
What should you do after SPF?
Publish a DMARC record, the policy layer that watches the From address your readers actually see and tells receivers what to do with failures. Start DMARC in monitoring mode, read its reports to catch any sender you missed, then strengthen the policy over a few weeks until failing mail is rejected.
Our DMARC Record Generator builds that record and explains every tag, and our DMARC guide covers the staged rollout in detail. Add DKIM signing in each sending service as well, and your domain has the full set of authentication that inbox providers now expect.
Frequently asked questions
How long does an SPF record take to start working?
Usually within minutes of publishing, and almost always within a few hours. If tests still show the old record after a day, you probably edited the wrong domain or created a second record instead of updating the existing one.
Does SPF stop phishing emails that look like mine?
It stops messages sent from unauthorised servers claiming your domain, at receivers that check it. It does not stop lookalike domains or display-name tricks, which is why SPF is one layer alongside DKIM, DMARC and plain user caution.
What happens if I exceed 10 lookups by accident?
Receivers return a permanent error called PermError and treat the message as failing SPF. The fix is always the same: shorten the record by removing stale includes or moving some sending to a subdomain with its own record.
Do I need a separate SPF record for each subdomain?
Yes, if the subdomain itself sends email, because SPF is checked per exact domain. Most subdomains that never send should publish a simple record ending in -all so nobody can send as them either.
DNS and email settings vary between providers, and a wrong record can disrupt real mail; test with ~all first and consider asking your email provider’s support team to review your finished record before switching to -all.
