SPF Record Checker and Generator

How to check an SPF record

1. Type a domain into the box above. A full email address works too. The tool keeps only the domain.
2. Click Check SPF record. The SPF record check reads the live record from public DNS, the same record a receiving server reads.
3. Read the summary first. It tells you whether the record is valid, has warnings, or is broken.
4. Then read the list of problems, if there are any. Each one says what to change.
5. Below that, each part of the record is explained, with the DNS lookups it costs. Open an include to see what the service behind it allows.

The link in your address bar runs the same SPF check again, so you can send it to a colleague or your DNS host. One limit: a receiver checks SPF against the IP address of the server that sent a message. This SPF analyzer has no message to look at, so it checks the record itself. It can’t evaluate parts built from SPF macros, which change for every sending server.

What is an SPF record?

An SPF record is a TXT record in a domain’s DNS. It lists the servers that may send email for that domain. SPF stands for Sender Policy Framework, and the rules are in RFC 7208. A domain that uses Google Workspace often has a record like this one:

v=spf1 include:_spf.google.com ~all

v=spf1 marks it as an SPF record. include:_spf.google.com allows every server in Google’s own list. ~all tells receivers to treat mail from any other server with suspicion.

When a message arrives, the receiving server takes the domain from the bounce address, called the Return-Path. It reads that domain’s SPF record and checks whether the sending server’s IP address is on the list. SPF does not look at the From address you see in your inbox. That is why it works together with DKIM and DMARC. For how the three fit, see SPF, DKIM and DMARC explained.

Since February 2024, Gmail requires SPF or DKIM from every sender, and both from bulk senders. Yahoo has the same rules.

What each part of an SPF record means

An SPF record is a list of terms separated by spaces. Receivers read them from left to right and stop at the first one that matches the sending server.

Any part can start with a qualifier that sets the result when it matches. + means pass and is the default, so nobody writes it. - means fail, ~ means soft fail, and ? means neutral. That is why the same word, all, can end a record as -all, ~all or ?all.

Names are not case-sensitive, so Include: works as well as include:. RFC 7208 recommends ending every record with all or a redirect. Without either, servers you didn’t list get a neutral result.

The 10 DNS lookup limit

Every include, a, mx, ptr, exists and redirect makes the receiver run a DNS lookup. RFC 7208 allows 10 in total. Lookups inside an include count too, so one include can cost several. ip4, ip6 and all cost nothing. When a record needs more than 10, receivers stop and return a permerror, and SPF fails.

The limit is easy to reach. We measured what common includes cost against live DNS: Google Workspace 1, Microsoft 365 1, Salesforce 2, Mailgun 5 and Freshdesk 7. A company on Google Workspace that adds Mailgun and Freshdesk already needs 13 lookups. A 2024 study of SPF records in .com, .net, .org and .se found that 6.5% needed more than 10 lookups. Includes of just two hosting providers’ records caused 83.7% of those cases.

Costs also change. Google’s include cost 4 lookups until December 2025, when Google replaced its nested includes with a flat list. Some SPF guides and generators still say 4. The checker above counts the real number every time you run it.

Going over the limit doesn’t always break every message. Microsoft points out that receivers stop at the first match. Mail from a server listed early can still pass, while mail from a server listed late fails. That makes the problem look random, so count the full record.

There is a second limit. A lookup that finds nothing is a void lookup, for example an include of a domain that no longer exists. RFC 7208 says receivers should stop after 2 of these.

How to get under 10 lookups

1. Remove includes for services you no longer use.
2. Remove includes a service no longer asks for. Mailchimp, Postmark, Brevo and Klaviyo don’t need one on your main domain, and SendGrid and Amazon SES put theirs on a subdomain. The list is further down.
3. List your own servers with ip4 and ip6 instead of a or mx. RFC 7208 recommends this order, and IP addresses cost no lookups.
4. Send some mail from a subdomain, such as news.example.com. Each subdomain has its own record and its own 10 lookups.

Some services offer SPF flattening, which replaces includes with the IP addresses behind them. It saves lookups, but providers change their addresses, and a flattened record doesn’t follow. Microsoft advises flattening only services with stable, documented IP ranges, never Microsoft 365 itself, and checking the result at least every quarter.

SPF includes for Google Workspace, Microsoft 365 and other services

These are the include values from each service’s setup guide, with the DNS lookups each one costs. We measured the costs against live DNS on 12 October 2026. When you set up a service, copy the value from its own guide, because some depend on your region or account.

HubSpot gives every account its own include, ending in hubspotemail.net. Copy it from your HubSpot email settings. It costs 1 lookup.

Services that usually don’t need an include

SPF is checked against the bounce address, not the From address. Many sending services now use a bounce address of their own, or a subdomain of yours. An include for them on your main domain does nothing except use up lookups.

• Mailchimp. Mailchimp’s domain setup now asks only for DKIM and DMARC records, not SPF.
• Postmark. Postmark says SPF is no longer required. It sends with its own bounce address, or a Return-Path record you point to it.
• Brevo. Brevo says SPF is not required unless you send from a dedicated IP address.
• Klaviyo. Klaviyo says you usually don’t need to add an SPF record.
• SendGrid. SendGrid’s domain authentication puts SPF on a subdomain it creates for you, such as em1234.yourdomain.com.
• Amazon SES. SES needs it only on a custom MAIL FROM subdomain, such as bounce.yourdomain.com. By default it uses its own bounce address.

The checker flags these includes when it finds them in your record.

How to create an SPF record

Use the Create tab above to generate an SPF record. Tick the services that send your mail, and the SPF record maker writes the record and counts its lookups. If your domain already has a record, load it first, so you add to it instead of replacing it. These are the steps behind it:

1. List every service that sends email as your domain. Think beyond your mailbox provider: newsletters, your CRM, the help desk, billing, website forms. DMARC reports show senders you forgot.
2. Find the include for each one in its setup guide, or tick it in the tool. For your own mail servers, use their IP addresses.
3. Choose the ending: ~all or -all. The next section explains the difference.
4. Publish it as one TXT record on the domain itself. Most DNS hosts call that name @. If a record starting with v=spf1 already exists, edit it instead of adding a second one.
5. Wait a few minutes and check the domain again with the SPF checker.

Each name that sends mail needs its own record, because subdomains don’t use the parent’s record. A domain or subdomain that never sends mail should still get one: v=spf1 -all. RFC 7208 calls this a well-established best practice. It stops others from sending mail that passes as that name. The UK NCSC suggests adding a DMARC record with p=reject and a null MX record to such domains too.

A record longer than 255 characters has to be split into several strings within the same TXT record. Receivers join the strings without spaces, so put the space inside a string, not between them. Check how your DNS host handles long values.

~all or -all: which ending to use

The big providers don’t agree, and each has a reason.

• Google recommends ~all.
• M3AAWG, an industry group whose members include large mailbox providers and senders, says records should end in ~all. It also asks receivers not to reject on an SPF fail until DMARC has run.
• Microsoft recommends -all, as long as DKIM and DMARC are set up too.

The risk with -all is that some receivers reject the message during delivery, before DMARC is checked. RFC 9989, the 2026 DMARC standard, notes that such mail never appears in your DMARC reports. That makes problems harder to find.

In practice, ~all is the safer choice for a domain that sends mail, especially while you are still finding all your senders. If you have DMARC at quarantine or reject, DMARC decides what happens to failing mail anyway. Use -all on domains that send no mail at all. Never use +all, which lets every server pass, and avoid ?all, which counts the same as having no record.

What your SPF check result means

Receiving servers use their own words for the outcome of an SPF check. You see them in message headers, as in spf=pass or spf=softfail, and in DMARC reports:

Common SPF record errors and how to fix them

A 2023 scan of 12 million popular domains found SPF on 56.5% of them, and errors in 2.9% of the SPF records. The most common error was an include or redirect pointing to a name with no SPF record. Too many lookups came second.

Two SPF records on one domain

This often happens when a new service’s setup guide says “add this TXT record” and someone adds it next to the old one. Two records cause a permerror. Merge them into one. Start with one v=spf1, list every include and IP address, and end with one all.

An include that points nowhere

If an include points to a domain with no SPF record, the whole record fails with a permerror. It can be a typo, or a service that shut down or changed its include. Remove it or replace it with the current value from the service.

+all, ?all or no all at the end

+all allows every server on the internet, so the record protects nothing. ?all, or no all at all, gives a neutral result, which receivers treat like no record. End the record with ~all or -all.

ptr in the record

RFC 7208 says ptr should not be used. It is slow, it costs a lookup, and it is less reliable than other mechanisms when DNS has problems. Replace it with ip4 and ip6 entries for the servers it was meant to cover.

Typing mistakes

A space after a colon, an IPv4 address with a missing part, or a word SPF doesn’t know all cause a permerror. One mistake is quieter: include=example.com with an equals sign is read as an unknown setting and skipped, so that service is never allowed. The checker flags all of these.

Three details SPF guides often get wrong

• “An SPF record can’t contain capital letters.” RFC 7208 says names are not case-sensitive.
• “An SPF record can be at most 255 characters.” The 255 limit applies to each string. A longer record is split into strings. RFC 7208 only asks that the whole DNS answer stay small, under about 450 bytes.
• “You can have up to 10 includes.” The limit counts DNS lookups, and lookups inside includes count too.

SPF is one part of email authentication

An SPF pass has limits. In the same 2023 scan, 34.7% of the domains allowed mail from more than 100,000 IP addresses. SPF also breaks when someone forwards your message, because the forwarding server isn’t in your record.

DKIM signs the message itself, so it usually survives forwarding. DMARC checks that SPF or DKIM passed for the same domain as the From address, and tells receivers what to do when neither did. Many sending services pass SPF with their own bounce domain, which doesn’t match your From address. A custom Return-Path at the service fixes that. Set up the other two records with the DKIM generator and the DMARC generator, and use the MX lookup to check where your domain receives mail.

Authentication also doesn’t help with addresses that don’t exist. Mail to them bounces, and a high bounce rate hurts delivery. Check single addresses with the email checker, or a whole list with the bulk email verifier. For a short definition to share with your team, see the SPF record glossary entry.