How to create an SPF record: syntax, examples and common errors

The short version

1. What an SPF record does. SPF stands for Sender Policy Framework.
2. The syntax, piece by piece. Every SPF record starts with v=spf1.
3. Step 1: list every sender. Write down every system that sends email as your domain: your sending service, your mailbox provider, your website or shop, your CRM, your support desk and any invoicing or HR tool.
4. Step 2: build the record. Begin with v=spf1, add one include or ip4 for each sender, and finish with ~all.
5. Step 3: publish it in DNS. Add a TXT record at the root of your domain.
6. Step 4: test it. Use a lookup to confirm the record is published and parses correctly, then send a test message to a mailbox you control and read the authentication results in its headers.

What an SPF record does

SPF stands for Sender Policy Framework. It is a TXT record in your domain's DNS that lists which servers may send mail using your domain. When a message arrives, the receiving server looks up the sending domain's SPF record and checks whether the connecting IP address is on the list.

SPF checks the envelope sender, also called the Return-Path or MAIL FROM address, not the From address people see. That distinction matters later when we get to DMARC alignment.

The syntax, piece by piece

Every SPF record starts with v=spf1. After that come mechanisms, each naming a source of mail, and the record ends with an all mechanism that says what to do with everything else. ip4 and ip6 list addresses or ranges. include pulls in another domain's SPF record, which is how you authorise a sending service. a and mx authorise the addresses of your domain's own web or mail servers.

v=spf1 ip4:203.0.113.10 include:YOUR_SPF_HOST ~all

Each mechanism can have a qualifier in front. A plus means pass and is the default. A minus means fail, a tilde means softfail, and a question mark means neutral. So ~all says that anything not listed is suspicious but not forbidden, and -all says it must be rejected.

Step 1: list every sender

Write down every system that sends email as your domain: your sending service, your mailbox provider, your website or shop, your CRM, your support desk and any invoicing or HR tool. SPF has to cover all of them in one record, so an incomplete list breaks the ones you forgot.

Each provider documents the include value to use. For MigoSMTP, copy the SPF value shown in your dashboard rather than guessing it.

Step 2: build the record

Begin with v=spf1, add one include or ip4 for each sender, and finish with ~all. For example, a business that uses a mailbox provider and a sending service would have two includes and one ending.

Put the whole thing in a single TXT record. Do not create one record per sender. That is the most common cause of SPF failure, and we cover it below.

Step 3: publish it in DNS

Add a TXT record at the root of your domain. In many DNS panels the host is @ or left blank. Paste the value exactly as built, without extra quotes unless the panel asks for them. Indian registrar panels such as GoDaddy, BigRock and Hostinger, and DNS hosts like Cloudflare, all follow the same pattern.

If a record already exists at the root, edit it instead of adding a second. Changes can take from minutes to a few hours to spread, depending on the record's TTL.

Step 4: test it

Use a lookup to confirm the record is published and parses correctly, then send a test message to a mailbox you control and read the authentication results in its headers. Look for spf=pass. Our free checker shows your SPF, DKIM and DMARC records in one place and flags common errors.

Test from every system that sends, not just one. A pass from your sending service says nothing about the invoicing tool.

Mistake 1: more than one SPF record

A domain must publish exactly one SPF record. Two records make SPF return a permanent error, and receivers treat that as a failure. If different teams each added their own, merge them into one record containing all the includes.

This is easy to cause when you add a new tool and its instructions say to create a new TXT record. Read what is already there first.

Mistake 2: too many DNS lookups

SPF allows at most ten DNS lookups while evaluating a record. Each include, a, mx and similar mechanism counts, and nested includes count too. ip4 and ip6 do not. Go over ten and SPF returns a permanent error, so the check fails even though each part looked fine.

Remove senders you no longer use, replace a and mx mechanisms with explicit ip4 ranges where the addresses are stable, and avoid stacking many includes. Some services offer SPF flattening, which replaces includes with addresses. It works, but the addresses change over time, so it needs to be kept up to date.

Mistake 3: choosing -all too early

A hard fail with -all tells receivers to reject anything not listed. If your list is missing a sender, that sender's mail is rejected. Most teams start with ~all, watch their DMARC reports for a few weeks, and tighten only when they are sure every sender is listed.

Whichever you choose, SPF alone does not decide inbox placement. It is one signal that works alongside DKIM and DMARC.

Why SPF fails on forwarded mail

When someone forwards your message, it is sent from the forwarder's server, which is not in your record, so SPF fails at the final destination. That is normal and not a mistake on your side.

This is why DKIM matters. A DKIM signature usually survives forwarding, and DMARC passes if either SPF or DKIM passes and aligns. Set up both.

Further reading and sources

• RFC 7208: Sender Policy Framework (SPF)
• Google Workspace: Define your SPF record
• Microsoft: Set up SPF to help prevent spoofing

Related guides and tools

• Check SPF, DKIM and DMARC: Test your domain's records.
• DKIM, SPF and DMARC setup: Authenticate your domain end to end.
• How to set up DMARC: Start with p=none and move to reject safely.