Browserside Network Tools
☰

Network Tools

More tools →

Guide

SPF Checker and Record Guide

Read an SPF policy, find its direct includes, and troubleshoot common email authorization failures.

Open the tool

What it does

Sender Policy Framework (SPF) is a DNS policy that lists which systems may send mail for a domain. Receiving servers evaluate it against the SMTP envelope sender, also called the Return-Path or MAIL FROM domain. SPF does not directly validate the address users see in the From header.

An SPF policy is a TXT record beginning with v=spf1. A typical record is:

v=spf1 include:_spf.example.net ip4:192.0.2.10 -all

This authorizes the included provider and one IPv4 address. -all says other senders should fail. Common mechanisms include ip4, ip6, a, mx, include, exists, and all. The qualifiers +, ~, -, and ? mean pass, softfail, fail, and neutral; + is the default when no qualifier is written.

What this tool tells you

The checker finds TXT records at the domain, selects records beginning with v=spf1, and lists their direct include: domains. Use it to answer:

  • Is an SPF policy publicly visible at the exact domain being checked?
  • Is there one policy or more than one?
  • Does the text contain the provider include you expected?
  • Did a DNS edit publish malformed spacing, a wrong hostname, or an old sender?

A result with no SPF record means a successful TXT lookup found no v=spf1 policy at that domain. DNS response and transport failures are shown as errors instead of being treated as an empty policy. Multiple SPF records are invalid; combine authorized sources into one policy rather than publishing one record per vendor.

The include list is a map of dependencies. Each included domain publishes another SPF policy that can authorize addresses or include still more services. When mail fails after adding a vendor, first confirm that vendor appears in the direct list, then inspect the vendor’s own policy and the complete evaluation path.

How it fits with other technologies

SPF sits beside MX, DKIM, and DMARC, but each handles a different part of mail delivery:

  • MX records tell other systems where to deliver inbound mail. SPF describes permitted outbound senders. The two lists do not have to match.
  • DNS TXT records carry the SPF policy. A general DNS lookup can confirm other TXT records and zone data.
  • DKIM adds a cryptographic signature tied to a signing domain and selector.
  • DMARC requires the visible From domain to align with a passing SPF domain or a passing DKIM domain. SPF can pass while DMARC fails if the envelope sender belongs to a vendor and is not aligned with the visible From address.
  • PTR, A, and HELO/EHLO identity checks are separate reputation and server-identity signals used by many receivers.

Forwarding often breaks SPF because the forwarder’s IP is not authorized by the original sender. DKIM may survive forwarding if the message is not modified, which is one reason DMARC accepts aligned DKIM as an alternative. ARC can preserve authentication evidence through some forwarding systems, but it does not replace SPF, DKIM, or DMARC.

Troubleshooting unexpected results

  1. Check the right identity. Use the domain from the Return-Path in the received message headers, not automatically the visible From domain. Subdomains need their own policy unless the sending design explicitly uses another envelope domain.
  2. Publish one SPF record. Merge mechanisms from separate v=spf1 records. Do not create a second policy for a new vendor.
  3. Confirm the provider’s exact include. Similar-looking hostnames are not interchangeable. Copy the current value from the provider’s documentation.
  4. Count DNS-querying mechanisms. SPF evaluation permits at most 10 DNS-causing terms, including nested include, a, mx, ptr, exists, and redirect. Exceeding the limit produces a permanent error even if every listed provider is legitimate. SPF also limits void lookups, which are DNS queries that return no usable answer, to two during one evaluation.
  5. Inspect nested includes. This tool lists direct includes, not the complete recursive tree. An included provider may add more lookups, contain an error, or change over time.
  6. Check record length and quoting. DNS providers may split long TXT data into quoted chunks. That is valid when the chunks form one TXT record, but separate TXT records are not. Avoid flattening includes into IP addresses unless you also have a maintenance plan for provider changes.
  7. Review the ending policy. -all is a hard fail; ~all is a softfail. Changing the qualifier does not fix a missing sender earlier in the record.
  8. Allow for DNS caching. Compare the authoritative TXT answer with public resolvers and wait for the previous TTL when a change is recent.
  9. Read message authentication results. The Authentication-Results header usually states the evaluated domain, client IP, SPF result, DKIM result, and DMARC result. It is more diagnostic than a generic delivery dashboard warning.

What this tool cannot prove

The checker does not perform a complete SPF evaluation for a sending IP. It does not recursively resolve every include, expand a or mx mechanisms, count all DNS lookups, apply macros, test the 10-lookup limit, or validate DMARC alignment. Finding an SPF record therefore does not mean a particular message will pass.

For a real failure, collect the sending IP, HELO name, envelope sender, visible From domain, and Authentication-Results header. Evaluate that exact message path, then check DKIM and DMARC rather than weakening SPF until mail happens to pass.