Free account

Keep your requests in reach

Create an account in under 30 seconds to keep 6 months of history, share saved requests, and trigger email or webhook alerts on every diff.

  • 6-month searchable history
  • Diff alerts via email & webhook
  • Latency spike monitoring
Create account

SPF syntax checker

Understand the structure of an SPF record

Sender Policy Framework (SPF) describes which servers are allowed to send mail for a domain. The policy lives in a TXT record beginning with v=spf1 followed by mechanisms and modifiers. This page explains what the validator inspects and how to interpret the API response.

Anatomy of an SPF policy

An SPF rule is a list of space separated terms. Each term may start with a qualifier (+, -, ~, ?), followed by a mechanism name (such as ip4, mx, include) or a modifier (redirect=, exp=).

v=spf1 ip4:203.0.113.0/24 include:_spf.example.net -all

Mandatory elements

  • v=spf1 — the version tag must be present and placed at the beginning of the record.
  • Mechanisms — at least one mechanism (for example ip4, ip6, mx, include) defines the authorised senders.
  • Terminal directive — a final mechanism (-all, ~all, ?all or +all) completes the policy and tells recipients how to handle unmatched mail.

Optional modifiers

  • include: chains another SPF record and triggers extra DNS lookups.
  • redirect= delegates the evaluation to a different domain. It must be the last term and cannot appear with all.
  • exp= points to a TXT record containing an explanation message. It is deprecated and only informational.

Frequent pitfalls detected by the tool

  1. Record too long. SPF strings longer than 450 characters are rejected by the validator.
  2. Unknown or duplicated terms. Misspelled mechanisms and repeated modifiers are flagged as errors.
  3. Invalid IP prefixes or domains. The validator checks the syntax of CIDR ranges and hostnames.
  4. Lookup limits exceeded. SPF processing stops after 10 DNS lookups, including include, mx, a, ptr and exists.
  5. Neutral or permissive policies. Qualifier ? and +all reduce the protection level and appear as warnings.

What the validator checks

  • Record envelope — empty values, missing v=spf1, trailing quotes or extra characters trigger syntax errors.
  • Mechanisms and modifiers — unknown or duplicated terms (unknown_mechanism, unknown_modifier, duplicate_modifier) are rejected; redirect must appear once, last, and never with all.
  • Values and operands — missing or malformed arguments for include, a, mx, exists, ip4, ip6 or redirect raise mechanism_missing_value / mechanism_invalid_value.
  • Policy endings and weak qualifiers — multiple all, neutral qualifiers ? and permissive endings are surfaced as warnings so you can tighten the policy.
  • DNS pressure — lookup cycles, more than 10 lookups or too many void responses (lookup_limit_exceeded, lookup_cycle, void_lookup_limit_exceeded) are surfaced alongside a counter to avoid SPF permerror in production.

Best practices before publishing

  • Keep the policy concise and remove unused mechanisms to stay below lookup limits.
  • Prefer ip4 and ip6 ranges managed by your organisation or service provider.
  • Document who maintains each include chain and review the delegated domains regularly.
  • Test the final record with this validator, then query DNS once deployed to confirm propagation.

By validating the syntax ahead of publication you reduce the risk of a broken SPF policy and avoid lengthy troubleshooting when messages start to bounce.