Your SPF record is a single DNS entry that tells receiving mail servers which IP addresses are authorized to send on behalf of your domain. A missing or misconfigured record is one of the most common reasons legitimate emails end up in spam.

What an SPF check actually does

SPF (Sender Policy Framework) is defined in RFC 7208. When a receiving mail server accepts an incoming message, it extracts the domain from the envelope sender address (the MAIL FROM value used during the SMTP exchange) and looks up the corresponding SPF TXT record in DNS. It then checks whether the IP address of the sending server appears in that record.

An online SPF testing tool automates exactly that query. You enter your sending domain, and the tool performs the DNS lookup, parses the record, and returns a verdict. That verdict falls into one of three categories.

The three results you will see

The SPF specification defines several possible outcomes, but in practice you will encounter three situations that cover the vast majority of cases.

Result 1: Pass

A "Pass" means the tool found a valid SPF record and the IP you are testing is explicitly authorized by it. From the receiving server's perspective, the sender is legitimate.

A Pass is good news, but there are still a few things worth verifying:

Coverage of all your sending services. Every service that sends email on your behalf needs to be listed: your SMTP relay (OVH, Infomaniak, or whichever provider you use), your transactional email platform, your CRM. If a sending IP is missing from the record, messages from that service will fail even though the record itself is valid.
The ten-lookup limit. The SPF specification caps the number of mechanisms that trigger a DNS lookup (include:, a, mx, redirect, exists) at ten per evaluation. If your record chains together many include: directives, you may be near or over that limit. Exceeding it turns a Pass into a PermError for the extra lookups.
A clear default policy. Your record should end with -all (hard fail: reject any IP not listed) or ~all (soft fail: flag it but accept). A bare +all authorizes every IP on the internet to send as your domain and should never be used.

Result 2: Fail or SoftFail

A "Fail" (produced by -all) or "SoftFail" (produced by ~all) means the IP you tested is not listed in the record. Receiving servers will treat messages from that IP as suspicious: some reject them outright on a hard fail, others accept and flag them on a soft fail. Either way, deliverability suffers.

The most frequent cause is a missing include:. Adding a new SMTP relay, switching cold-email providers, or onboarding a new tool that sends on your behalf all require an update to your SPF record. If the update does not happen, those messages will fail.

How to fix it:

Find the exact include: mechanism your sending service requires. Your SMTP provider's documentation will specify it.
Add it to your existing TXT record. Do not create a second v=spf1 TXT record for the same domain -- SPF requires exactly one record per domain. Two records produce a PermError and invalidate both.
Keep the total number of DNS-lookup-triggering mechanisms under ten.
Publish the updated record, wait for DNS propagation, and run the test again.

If you send through multiple services and the record is getting long, consider whether any include: mechanisms can be replaced with explicit IP ranges (ip4: or ip6:). This reduces the DNS lookup count but requires manual updates whenever a provider changes their IP space.

Result 3: None or PermError

"None" means the tool found no SPF TXT record for your domain at all. "PermError" (permanent error) means a record exists but is syntactically broken, most often because there are two v=spf1 records published for the same domain, or because a mechanism contains a typo.

None is straightforward: you need to publish your first SPF record. A minimal valid record for a domain that sends only through a single SMTP relay looks like this:

v=spf1 include:spf.yourprovider.com -all

Replace include:spf.yourprovider.com with the include mechanism your actual provider documents.

PermError requires locating the broken record, correcting the syntax or removing the duplicate, and republishing. The most reliable way to find duplicates is to run a raw DNS query (dig TXT yourdomain.com on Linux or macOS, Resolve-DnsName yourdomain.com -Type TXT on Windows) and inspect every TXT record returned for lines that begin with v=spf1.

How to run the test

The diagnostic tool performs an SPF check for your domain and returns the raw TXT record, the list of parsed mechanisms, and a verdict. It also surfaces your DKIM and DMARC status so you can review your full authentication setup in one place.

If you prefer the command line, dig TXT yourdomain.com returns the raw DNS response. Look for the line starting with v=spf1 and read the mechanisms in order from left to right. The first matching mechanism determines the result.

SPF in context: DKIM and DMARC

Passing SPF is necessary but not sufficient. A message can pass SPF and still fail DMARC alignment if the domain in the envelope sender differs from the domain in the From: header visible to the recipient. For reliable inbox delivery, SPF needs to work alongside DKIM and a DMARC policy.

If you have not configured all three yet, the guide SPF, DKIM, and DMARC configuration covers each record step by step, including the specifics for SMTP relay setups.

Common mistakes that break SPF

Two TXT records for the same domain. Only one v=spf1 record is valid per domain. If you create a second one instead of editing the first, both are discarded and the result is a PermError.

Forgetting subdomains. An SPF record on yourdomain.com does not automatically cover outreach.yourdomain.com or any other subdomain. Each subdomain from which you send needs its own SPF record.

Using +all. This is a policy that says any server in the world is authorized to send as your domain. It defeats the purpose of SPF entirely.

Not verifying after adding a new sender. Each time you connect a new sending service, run the SPF test again. The assumption that the existing record already covers the new service is a common source of deliverability problems.

What to do after fixing the record

Once you have updated your DNS:

Run the SPF check again to confirm the result is now "Pass."
Send a test message to a mailbox you control and inspect the full email headers. The Received-SPF and Authentication-Results headers will confirm whether the receiving server evaluated SPF as "pass."
If you are sending cold emails through Fluenzr with a connected SMTP account, verify that the account's authentication status appears healthy in the account settings.

A clean SPF record is one part of a complete deliverability foundation. The diagnostic tool gives you a quick view of SPF, DKIM, and DMARC together so nothing is missed.

If you want to test your setup on a live domain and start sending with accounts that are properly authenticated, you can create a free Fluenzr account. The first 50 paying subscribers can use the code FOUNDING50 for 50% off any plan, for life.

Key Takeaways

An online SPF test performs a DNS lookup on your sending domain and checks whether a specific IP is authorized by the published record.
The three outcomes you will encounter are: Pass (the IP is authorized), Fail or SoftFail (the IP is not listed), and None or PermError (no record found, or the record is syntactically broken).
Fail and SoftFail most often mean a sending service is missing from your include: list; add it, keep the total DNS-lookup mechanisms under ten, and republish.
None requires publishing a first SPF record; PermError usually means two v=spf1 records exist for the same domain and need to be merged into one.
SPF must work alongside DKIM and DMARC for full deliverability coverage.
Use the diagnostic tool to check SPF, DKIM, and DMARC status in one place after any change.

How to Test Your SPF Record and Read the Result