Free SPF Record Checker

What is SPF?

Sender Policy Framework (SPF) is an email authentication standard that lets a domain owner publish a list of mail servers authorized to send email on that domain's behalf. The list lives in a DNS TXT record and is checked by every receiving mail server before deciding whether to deliver a message.

When a message arrives, the receiving server looks at the envelope sender domain—the address used in the SMTP MAIL FROM command—fetches the SPF record for that domain, and checks whether the sending IP is listed. If the IP matches, SPF passes. If it does not match and the record ends with -all, the message fails and is typically rejected.

SPF records use mechanisms to define authorized senders: ip4: and ip6: list specific IP addresses or ranges, include: pulls in another domain's SPF record, and a and mx authorize the domain's own A or MX records. Each mechanism that triggers a DNS lookup counts toward a hard limit of 10.

SPF alone is not enough. It only protects the envelope sender, not the visible From header. That gap is why SPF must be combined with DKIM and DMARC: DKIM signs the message content, and DMARC ties both results to the From header domain that recipients actually see.

Common SPF failures and how to fix them

Too many DNS lookups

The SPF specification limits evaluation to 10 DNS lookups. Every include:, a, mx, and ptr mechanism counts, as do any lookups triggered by nested include: records. Exceeding 10 causes a "permerror" result and SPF fails as if the IP were not authorized—even if it actually is.

To fix this, audit every include: in your record and remove services you no longer use. Where a provider publishes static IP ranges, replace include: with ip4: blocks—each ip4: entry costs zero lookups. For services that do not publish static IP ranges, use an SPF flattening tool to resolve the current IPs and keep the lookup count under 10.

Multiple SPF records

A domain must have exactly one SPF record. If your DNS zone contains two TXT records that both start with v=spf1, receiving servers will return a permerror and SPF will fail for all mail. This is a common mistake after migrating email providers—the old record is forgotten but never deleted. Check your DNS zone for duplicates and merge everything into a single record.

SPF alignment failure under DMARC

SPF can pass technically—the sending IP is listed—yet still fail DMARC. DMARC requires that the domain in the envelope sender (MAIL FROM) matches the From header domain. When a third-party sending service uses its own domain in the envelope sender, SPF passes for that service's domain but does not align with your From domain. The fix is to configure a custom MAIL FROM domain on your sending service so the envelope sender uses your domain, or to rely on DKIM alignment instead, which is what most providers recommend.

How to configure SPF for Amazon SES

By default, Amazon SES sends mail using amazonses.com as the envelope sender domain. SPF passes for amazonses.com, but that domain does not align with your From header, so DMARC will fail on the SPF check. To achieve SPF alignment you need a custom MAIL FROM domain.

Problem 1: SPF alignment — set a custom MAIL FROM domain

In the SES console, open your verified identity and find the "Custom MAIL FROM domain" section. Set the MAIL FROM domain to a subdomain of your sending domain, for example mail.yourdomain.com. SES will show you two DNS records to add:

1. An MX record on mail.yourdomain.com pointing to feedback-smtp.us-east-1.amazonses.com (replace us-east-1 with your SES region) with priority 10.
2. A TXT record on mail.yourdomain.com containing v=spf1 include:amazonses.com ~all.

Note that the SPF TXT record goes on the MAIL FROM subdomain, not on your root domain. Once these records propagate, SES will use mail.yourdomain.com as the envelope sender, SPF will pass, and it will align with your From domain.

Problem 2: Your root domain's SPF record

If you also send mail directly from your root domain through other services (Google Workspace, Postmark, your own servers), your root domain TXT record should list those senders. Do not add include:amazonses.com to your root domain record unless SES is also sending from the root domain—the MAIL FROM subdomain handles SPF for SES. Keeping the root record clean reduces lookup count and avoids confusion during audits.

How to read an SPF record

A typical SPF record looks like: v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all. Each space-separated token is a mechanism or modifier:

v=spf1

Version tag. Must be present and must be the first token. There is only one valid SPF version.

ip4: / ip6:

Authorizes a specific IPv4 address or CIDR range (ip4:203.0.113.0/24) or IPv6 address. Costs zero DNS lookups.

include:

Pulls in another domain's SPF record. Counts as one DNS lookup. Nested includes count toward the same 10-lookup limit.

a

Authorizes the IP addresses that the domain's A record resolves to. Costs one DNS lookup.

mx

Authorizes the IP addresses of the domain's MX servers. Costs one lookup plus one per MX host.

redirect=

Replaces the entire record with another domain's SPF policy. Used when you want a single canonical record shared across subdomains.

+all / ~all / -all / ?all

The catch-all qualifier. +all passes everything (never use this). ~all soft-fails unlisted senders. -all hard-fails and is the recommended production setting. ?all is neutral and provides no protection.