How to Check an SPF Record

SPF is published as a DNS TXT record on the sending domain. The first step is to query the domain's TXT records and confirm whether one of them starts with v=spf1.

If no SPF TXT record is present, the domain has no SPF policy at all. If several separate SPF records exist, that is also a problem because receivers expect one valid SPF policy per domain.

• SPF Checker
• TXT Lookup

A common mistake is checking the visible From domain when the real sending domain is a subdomain or third-party bounce domain. For SPF, what matters is the domain the receiver evaluates during the SMTP transaction.

If you are troubleshooting a live message, compare the domain you are checking with the Return-Path or envelope sender shown in the headers.

• Email Header Analysis
• Return-Path vs From address

• v=spf1 identifies the TXT record as an SPF policy
• ip4 and ip6 authorise specific IP addresses or ranges
• include brings in another domain's SPF policy
• redirect points evaluation to another SPF policy entirely
• all defines the fallback result for anything not matched earlier

SPF is evaluated from left to right, so the order of mechanisms matters. A short record can still expand into a complex effective policy once includes and redirects are followed.

To check an SPF record properly, you need to follow any include and redirect mechanisms and see what policy they create in practice. That is especially important when the domain sends mail through Microsoft 365, Google Workspace, help desk tools, or marketing platforms.

A record that looks simple at first glance may still cause trouble if the imported policies add too many recursive DNS lookups or authorise senders you no longer use.

• SPF Checker
• How to read SPF records correctly

• -all means mail that does not match should fail
• ~all means soft fail and is less strict
• ?all means neutral and gives little protection
• +all effectively allows everything and is usually unsafe

The final qualifier is often the quickest way to judge whether the domain has a strong SPF posture or only a loose monitoring policy.

• No SPF record exists at all
• More than one SPF TXT record is published
• The record appears to exceed or approach the ten-DNS-lookup limit
• The policy includes old providers that are no longer meant to send mail
• The fallback qualifier is overly permissive

These are the issues most likely to cause SPF failures, permerrors, or a policy that technically exists but does not offer meaningful protection.

• Query the domain's TXT records and find the record that starts with v=spf1
• Confirm you are checking the correct sending domain
• Read the mechanisms and note all includes and redirects
• Resolve the effective policy and count recursive DNS lookups
• Review the final qualifier and any warnings
• Compare the result with the real mail providers that should be allowed to send

If you want to validate this topic in practice, these DNS Pro tools are the fastest next step.

• SPF Checker
• Email Security Check
• SPF Flattener