How to Validate SPF Record Syntax Step by Step

To validate an SPF record, query the domain's TXT records and confirm that exactly one starts with v=spf1. Then check each mechanism's syntax, keep the number of DNS lookups at 10 or fewer, and make sure the record ends with an all mechanism that matches your policy. You can do this by hand with dig, or run the same checks in seconds with the free SPF checker.

The rest of this guide walks through each check, explains why it matters, and shows the errors that most often break SPF.

What does it mean to validate an SPF record?

Validating an SPF record means confirming that the record is published correctly, parses without errors, stays within the protocol's limits, and authorises every service that sends mail for your domain. A record can look fine and still fail at evaluation time, so syntax alone is not enough.

SPF is defined in RFC 7208. A receiving server takes the domain from the envelope sender (the MAIL FROM address, or the HELO name if MAIL FROM is empty), fetches that domain's SPF record and compares the connecting IP address against it. The result is one of pass, fail, softfail, neutral, none, temperror or permerror. Validation is about making sure your legitimate mail gets pass and that your record never produces permerror.

How do I check an SPF record manually?

To check an SPF record manually, run a DNS TXT query for your domain and look for the single value that begins with v=spf1. Read it left to right, confirm every mechanism is spelled correctly, and check that it ends with an all mechanism.

On Linux or macOS:

dig +short TXT example.com

On Windows:

nslookup -type=TXT example.com

A typical result looks like this:

"v=spf1 ip4:192.0.2.10 include:_spf.mailprovider.example ~all"

If you see no v=spf1 value, the result for your domain is "none". If you see more than one, you have a problem covered below. For a faster route, paste the domain into the SPF checker, which fetches the record and reports problems for you.

What is the correct SPF record syntax?

A valid SPF record is a single TXT record that begins with v=spf1, followed by space-separated mechanisms and optional modifiers, usually ending with all. Each mechanism can carry a qualifier: + pass (the default), - fail, ~ softfail or ? neutral.

The common building blocks are:

• ip4: and ip6: authorise an address or CIDR range directly.
• a and mx authorise the addresses of the domain's A/AAAA or MX records.
• include: evaluates another domain's SPF record and passes if it matches.
• redirect= is a modifier that hands evaluation to another domain's record.
• exists: passes if a DNS lookup of the given name returns an address.
• all matches everything and belongs at the end.

A clean example:

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.mailprovider.example -all"

Syntax mistakes that cause trouble include:

• A missing or misspelled version tag, such as spf1 or v=spf2.
• A typo in a mechanism name, which produces a permerror.
• Spaces inside an IP range or stray quotation marks pasted into the DNS editor.
• Mechanisms placed after all, which are never evaluated because all always matches.
• Using the ptr mechanism, which RFC 7208 says should not be used.

How many DNS lookups can an SPF record have?

An SPF record can trigger at most 10 DNS-querying terms during evaluation. The mechanisms include, a, mx, ptr and exists, plus the redirect modifier, each count. Going over 10 produces a permerror, and receivers may treat the message as failing SPF.

The ip4, ip6 and all mechanisms do not require DNS lookups, so they are free. The limit applies to the whole evaluation, including lookups nested inside included records. That is why a short-looking record can still exceed the limit: each include: for a mail provider may itself contain several more includes.

RFC 7208 also says evaluation should stop with a permerror if more than two lookups return no data or a nonexistent domain, known as void lookups. Stale include: entries pointing to domains that no longer exist are a common cause.

To validate this limit, count the lookups in your record and in every record it includes, or let the SPF checker do the recursive count. If you are over, remove services you no longer use, replace includes with ip4: ranges where the provider guarantees they are stable, or split mail streams across subdomains.

Why does my domain have an SPF permerror?

A domain gets an SPF permerror when its record cannot be evaluated: most often because there are multiple SPF records, a syntax error, or more than 10 DNS lookups. It is a permanent error, so retrying does not help until you fix the record in DNS.

The usual causes are:

1. Two SPF records. RFC 7208 requires exactly one v=spf1 record per domain. This often happens when someone adds a new TXT record for a new provider instead of editing the existing one. Merge them into one record.
2. Too many lookups. See the section above.
3. Broken includes. An include: that points to a domain with no SPF record returns a permerror for the whole evaluation.
4. Long records. A single DNS TXT character-string is limited to 255 characters. Longer values must be split into several quoted strings in one TXT record, which receivers join together. Most DNS providers do this automatically, but check how yours handles it.
5. Wrong record type. The dedicated SPF record type (99) is obsolete. Publish SPF as a TXT record.

How do I confirm every sender is covered?

A syntactically perfect record still fails if it omits a real sending source. List every system that sends mail using your domain in the envelope sender, such as your mail platform, marketing tools, billing systems and support desks, and confirm each one is covered by an include: or ip4: entry.

SPF checks the envelope sender, not the visible From address, so a third-party service may use its own bounce domain. In that case SPF can pass for the provider's domain without helping your own domain's DMARC alignment. Seeing which sources actually send as your domain is easiest with aggregate reports, which DMARC monitoring collects and visualises. You can also run a domain scan to see your SPF, DKIM, DMARC and related records together.

Which "all" qualifier should I use?

Use -all once you are confident your record covers every legitimate sender, and ~all while you are still discovering sources. Avoid +all, which authorises any server to send as your domain, and be cautious with ?all, which asserts nothing.

Because DMARC acts on SPF and DKIM results, a softfail and a fail are both treated as an SPF failure when DMARC is evaluated. Check your published policy with the DMARC lookup to see how SPF results feed into it. Sender requirements from large mailbox providers also expect authentication to be in place; the compliance page summarises them.

A quick validation checklist

1. Query TXT records and confirm exactly one begins with v=spf1.
2. Check the spelling of every mechanism and modifier.
3. Confirm the record ends with a single all, with nothing after it.
4. Count DNS lookups, including nested includes, and stay at 10 or fewer.
5. Remove includes for services that no longer send for you.
6. Confirm each active sender is authorised.
7. Re-test after every DNS change, since TTLs can delay propagation.

If you would rather not maintain this yourself, yourDMARC offers a managed service where its team runs the rollout to p=reject for you.

Key takeaways

• To validate an SPF record, fetch the TXT record, check syntax, count lookups and confirm all senders are covered.
• A domain must publish exactly one v=spf1 record; two records cause a permerror.
• SPF allows a maximum of 10 DNS-querying terms, counting nested includes, and void lookups should stay at two or fewer.
• ip4, ip6 and all do not count toward the lookup limit.
• Put all last, and move from ~all to -all when you are sure of your sender list.
• Re-validate after every change with the SPF checker, and check the DMARC side with the DMARC lookup.