SPF Record Helper

Build a new SPF TXT record from common email providers, or paste an existing record to see a breakdown of mechanisms, DNS lookup count, syntax issues, and common SPF mistakes. Includes presets, migration guidance, and shareable URL state.

Live Email Builder SPF Email DNS Authentication DMARC

Build SPF record

Tick the email services you use, add custom mechanisms if needed, choose a final policy. The record updates live.

Each provider adds one include: mechanism to your record.
Single IPs or CIDR blocks. Each becomes ip4:<value>.
Use only if your provider isn't listed above.

Generated record

Add this as a TXT record on the root of your domain (or as SPF on legacy DNS hosts). 

v=spf1 ~all
DNS lookups 0 / 10 max
Total length 11 chars
Mechanisms 1
Final policy ~all

How to publish

  1. Log in to your DNS provider (where the domain's nameservers live).
  2. Add a new TXT record on the root of your domain (host = @ or empty).
  3. Paste the generated value above. Wait for DNS propagation (a few minutes to 24 hours).
  4. Verify with nslookup -type=TXT yourdomain.com or dig +short TXT yourdomain.com.

Paste an SPF record

Paste a v=spf1 string (e.g. from dig TXT). It analyses live as you type.

Analysis

Paste an SPF record on the left to see a breakdown.

No record to analyse yet.
DNS lookups 0 / 10 max
Mechanisms 0
Length 0 chars
Final policy —

Mechanisms (in order of evaluation)

# Qualifier Mechanism Value What it does

Migrating from ~all to -all safely

Going from soft fail to hard fail without breaking legitimate email.

  1. Publish ~all first. Soft fail still gets your email delivered while you observe.
  2. Enable DMARC reporting. Add a DMARC record with p=none; rua=mailto:reports@yourdomain.com. Reports tell you which sources send as your domain.
  3. Wait 1–2 weeks. Read the DMARC reports. Identify legitimate senders that you may have forgotten (CRM, helpdesk, marketing tools, payroll, monitoring, accounting).
  4. Add the missing senders. Update SPF until DMARC reports show 100% SPF pass for legitimate sources.
  5. Switch to -all. Now hard fail. Unauthorised senders are explicitly rejected.
  6. Tighten DMARC progressively. Move from p=none → p=quarantine → p=reject over weeks, not days.

Common SPF mistakes

The five errors that cause most SPF failures in production.

1. Two SPF records on the same domain RFC 7208 forbids it. Receivers will PermError and reject. Always keep exactly one v=spf1 TXT record per domain.
2. Exceeding 10 DNS lookups Each include:, a, mx, exists, and redirect= counts. Worse, include is recursive — a single include can pull in many sub-lookups. Crossing 10 causes PermError and SPF fails entirely.
3. Using +all Allows the entire internet to send as your domain. Spammers love it. Never use it in production, even temporarily.
4. Forgetting third-party senders Marketing tools, helpdesk software, invoice systems, monitoring alerts, payroll vendors — they all send mail "from" your domain. Audit every system that sends email before switching to -all.
5. Trusting SPF alone SPF only checks the Return-Path header, which the user never sees. Spoofers forge the visible From: header, which SPF doesn't protect. Always pair SPF with DKIM and DMARC.