SPF Record Checker

What Is an SPF Record?

SPF, short for Sender Policy Framework, is an email authentication standard defined in RFC 7208. It lets the owner of a domain publish a list of servers that are allowed to send email on that domain's behalf. The list lives in DNS as an ordinary TXT record that begins with v=spf1. When a receiving mail server accepts a connection and sees a message claiming to come from your domain, it looks up that record and checks whether the sending server's IP address is on the list. If it is, the message passes SPF; if not, your record tells the receiver how suspicious to be.

SPF matters for two practical reasons. First, it makes it harder for spammers to forge your domain in the envelope sender of their messages, which protects your reputation. Second, major mailbox providers now expect authenticated mail, and a correct SPF record is one of the basic requirements for reliable inbox placement. SPF is not a complete solution on its own — it works alongside DKIM and DMARC — but it is usually the first record to set up and the easiest to get wrong, which is exactly what the checker above is designed to catch.

How Receiving Servers Evaluate SPF

SPF is typically checked early in the SMTP conversation, often before the message body has been transferred. The receiver takes the domain from the envelope sender — the MAIL FROM address, also called the Return-Path — and queries its DNS for a TXT record starting with v=spf1. If the envelope sender is empty, as it is for bounce messages, the receiver uses the domain announced in the HELO greeting instead. Note that this is not the From address users see in their mail client; SPF deliberately operates on the hidden envelope, which is one reason DMARC exists to connect the two.

The record is evaluated left to right, and the first mechanism that matches the connecting IP determines the result. There are seven possible outcomes: pass (the IP is authorized), fail (explicitly not authorized), softfail (probably not authorized), neutral (the domain makes no assertion), none (no record found), temperror (a temporary DNS problem), and permerror (the record is broken). A fail rarely causes outright rejection by itself; most providers feed the SPF result into their DMARC evaluation and broader filtering, so a broken record hurts you gradually rather than dramatically.

Mechanisms and Qualifiers in Depth

Mechanisms are the building blocks of an SPF record, and each one describes a set of IP addresses. ip4 and ip6 name addresses or ranges directly and cost nothing to evaluate. a matches the IP addresses of a hostname, and mx matches the mail servers listed for a domain — both require DNS lookups. include pulls in another domain's SPF record, which is how you authorize a third-party provider: if the included record would return a pass for the connecting IP, the mechanism matches. Importantly, a fail produced inside an included record just means the include does not match and evaluation continues, so an include never inherits another domain's failure policy. exists matches if a constructed hostname resolves to any address, and ptr matches based on reverse DNS — the standard discourages ptr because it is slow and unreliable.

Every mechanism can be prefixed with a qualifier that decides what happens on a match. + means pass and is the default, so mx and +mx are identical. - means fail, ~ means softfail, and ? means neutral. In practice qualifiers matter most on the final all mechanism, which matches everything that nothing earlier matched: -all tells receivers to reject unlisted senders, ~all asks them to be suspicious, and +all authorizes the entire internet, which defeats the point. Two modifiers round out the syntax: redirect= hands evaluation to another domain's record entirely, and exp= points to an explanation string returned with failures.

Quick Reference: Mechanisms, Qualifiers, and Modifiers

The table below summarizes every element you will meet in a real-world SPF record, including whether it counts toward the ten permitted DNS lookups. Paste your domain into the checker above to see which of these your record actually uses.

A Worked Example, Piece by Piece

Here is a realistic record for a company that sends from its own servers, a hosted mailbox provider, and a marketing platform: v=spf1 ip4:203.0.113.0/24 a:mail.example.com include:_spf.mailbox-provider.com include:spf.campaigns.example ~all. Reading left to right: v=spf1 identifies the record version and must come first. ip4:203.0.113.0/24 authorizes every address in that range — typically an office or data-center block. a:mail.example.com authorizes whatever IPs that hostname currently resolves to, which is handy when a server's address changes occasionally. The two include mechanisms delegate to the published records of the mailbox provider and the campaign tool, so those vendors can update their own IP lists without you touching your DNS. Finally ~all says that anything not matched so far should softfail.

Now count the lookups, because this is where records quietly break. The ip4 mechanism is free. The a mechanism costs one lookup. Each include costs one lookup plus however many lookups the included record performs internally — a large provider's record can easily contain nested includes that consume three or four on its own. This example might already be at five or six of the ten allowed, with only two visible vendors. Order also matters: evaluation stops at the first match, so putting the mechanisms that cover your highest-volume mail first keeps things fast and easy to read.

The 10-Lookup Limit, Void Lookups, and Flattening

RFC 7208 caps the number of DNS-querying mechanisms at ten per evaluation. include, a, mx, ptr, exists, and the redirect modifier all count, and nested includes count too — the limit applies to the whole tree, not just your top-level record. Cross the limit and receivers return permerror, which most DMARC evaluations treat the same as an SPF failure. There are sub-limits as well: a single mx mechanism must not trigger more than ten address lookups for its mail hosts — exceeding that is a permerror — and ptr processing ignores anything beyond ten returned names. Finally, if more than two lookups return no answer at all (a void lookup, meaning a nonexistent domain or an empty result), the evaluation may also fail with permerror. Void lookups usually come from stale includes pointing at vendors you stopped using years ago.

When a record approaches the limit, the common cure is flattening: replacing include mechanisms with the literal ip4 and ip6 ranges they resolve to, which cost no lookups. The catch is that providers change their ranges without notice, so a record flattened by hand will silently rot and start blocking legitimate mail. If you flatten, automate it — re-resolve the includes on a schedule and update the record when ranges change. Before reaching for flattening, try cheaper fixes: delete includes for services you no longer use, move marketing or transactional vendors onto their own subdomains with separate SPF records, and ask vendors whether they offer a leaner include.

Common SPF Failure Modes

The single most frequent error is publishing more than one SPF record. A domain must have exactly one TXT record beginning with v=spf1; if receivers find two, the result is permerror and neither record counts. This usually happens when someone adds a new vendor's suggested record alongside the existing one instead of merging the mechanisms into it. The most dangerous error is +all, which tells the world that every server on the internet may send as your domain — receivers treat it as a red flag, and it hands spoofers a free pass. Almost as bad is ending the record without any all or redirect, which leaves unlisted senders at an implicit neutral.

Other failure modes are quieter. Mechanisms placed after all are silently ignored, so a vendor appended to the end of the record may never be evaluated. Stale includes for cancelled services burn lookups and create void-lookup risk. Records that grow past 255 characters must be split into multiple quoted strings within the same TXT record — splitting them into two separate TXT records breaks everything. And remember that ordinary forwarding rewrites nothing: the forwarder's IP is not in your record, so forwarded mail fails SPF no matter how perfect the record is, which is precisely why DKIM should accompany it.

Migrating Safely to -all

A strict -all is the destination, but flipping it on blindly is how legitimate mail gets bounced. Start by making the record accurate rather than strict: inventory every system that sends as your domain — application servers, the CRM, billing, the helpdesk, marketing — and get each one represented. While you do that, keep a permissive qualifier such as ~all and publish a DMARC record with a monitoring policy, so aggregate reports show you who is sending on your behalf and whether they pass. After a few reporting cycles with no legitimate source failing, tighten to -all. The change is a one-character edit, but the confidence behind it comes from the data.

Migration is not a one-time event. New tools get adopted, old servers get decommissioned, and each change is a chance for the record to drift out of date. Re-check the record whenever a sending service is added or removed — the checker above makes that a ten-second habit.

How SPF Interacts with DMARC Alignment

DMARC does not just ask whether SPF passed; it asks whether the pass is aligned, meaning the domain that passed SPF (the Return-Path domain) matches the domain in the visible From header. With relaxed alignment, the default, a match at the organizational-domain level is enough — bounces.example.com aligns with example.com. With strict alignment the two must be identical. This catches a subtle gotcha: many sending platforms use their own bounce domain for the Return-Path, so their mail passes SPF against the platform's record but is unaligned with yours. Configuring a custom return-path, often a CNAME on a subdomain you control, fixes it.

Because forwarding breaks SPF and alignment issues are common, DMARC only requires one of SPF or DKIM to pass with alignment. Treat them as a pair: SPF covers direct delivery, DKIM survives forwarding. A domain relying on SPF alone will see a steady trickle of DMARC failures it can do nothing about.

Frequently asked questions

Is SPF published as a TXT record or a special SPF record type?

Always as a TXT record. A dedicated SPF DNS record type once existed but was deprecated by RFC 7208, and modern receivers ignore it. If your DNS provider still offers the SPF type, leave it unused and publish TXT only.

How many SPF records can a domain have?

Exactly one TXT record starting with v=spf1. Two or more cause a permerror, which receivers treat as having no valid SPF at all. If you need to authorize a new service, merge its mechanisms into your existing record rather than adding a second one.

Does SPF check the From address my recipients see?

No. SPF validates the envelope sender (the Return-Path), which is invisible in most mail clients and often differs from the visible From header. DMARC closes that gap by requiring the two domains to align before an SPF pass counts.

What is the difference between ~all and -all?

~all (softfail) asks receivers to be suspicious of unlisted senders, while -all (fail) tells them such mail is not authorized at all. ~all is the sensible setting while you are still confirming your list of senders; -all is the stronger end state once you are confident the record is complete.

Do ip4 and ip6 mechanisms count toward the 10-lookup limit?

No. They contain literal addresses, so the receiver needs no extra DNS queries to evaluate them. Only include, a, mx, ptr, exists, and redirect count, which is why flattening includes into IP lists relieves pressure on the limit.

Why does my mail pass SPF but still fail DMARC?

The most likely cause is alignment: the message passed SPF for the Return-Path domain, but that domain does not match your From domain. This is common with sending platforms that use their own bounce domain. Set up a custom return-path with the platform, or rely on aligned DKIM signing instead.

How quickly do SPF changes take effect?

As soon as DNS caches expire, which is governed by your record's TTL — typically minutes to a few hours. Receivers look the record up fresh for each evaluation, subject only to that caching, so a corrected record starts working almost immediately.