SPF Record Checker

What is an SPF record checker?

An SPF record checker reads a domain’s Sender Policy Framework record and tells you whether it works. SPF is a single DNS TXT record, starting with v=spf1, that lists every server and service allowed to send email for your domain. When a message arrives, the receiving server checks the sending IP address against that list. Pass, and the message has one strong signal in its favour. Fail, or return an error, and it is more likely to land in spam or be rejected.

This free SPF checker finds your record, confirms there is exactly one, counts every DNS lookup it triggers (including those hidden inside other providers’ includes) against the hard limit of 10, explains how the record ends, flags deprecated mechanisms, and shows the full include tree so you can see which service is responsible for what.

How to use the SPF checker

1. Enter your sending domain, for example yourcompany.com. Pasting an email address works too.
2. Press “Check SPF”. The tool fetches your record and follows every include: and redirect= recursively.
3. Read the score and checks. Red means SPF is broken for every message right now. Amber means it works but is fragile. Green means it is healthy.
4. Use the include tree to see which services are in the record and whether any of them has no SPF of its own, which also breaks the result.

How SPF works, in plain English

When your mail server hands a message to Gmail, Gmail sees two things relevant to SPF: the IP address that connected, and the domain in the envelope sender (the technical “return path”, which is usually your domain or a subdomain of your sending tool). Gmail looks up that domain’s SPF record and walks through it from left to right until something matches the IP address. Each piece of the record is called a mechanism:

Each mechanism can have a qualifier in front: + pass (the default), - fail, ~ soft fail and ? neutral. In practice the qualifier only matters on the final all.

The checks, explained

Exactly one SPF record

The SPF standard (RFC 7208) allows one v=spf1 record per domain. Two records produce a “permanent error” and receivers treat SPF as failed. This usually happens when a new tool’s setup guide says “add this SPF record” and someone creates a second one instead of adding the tool’s include: to the existing record. The fix is always to merge them into one.

The 10 DNS lookup limit

To stop SPF being used to overload DNS servers, receivers stop evaluating a record after 10 DNS lookups and return a permanent error. The count includes every include, a, mx, ptr, exists and redirect, including those inside the records you include. That is the trap: Google’s include costs several lookups on its own, and a typical stack of mailbox provider, CRM, marketing platform, help desk and outreach tool can pass 10 without anyone noticing. The checker counts them all and warns you from 8 upwards.

How the record ends

• ~all (soft fail): mail from unlisted servers is marked suspicious. The most common choice, and the safe one while DMARC handles enforcement.
• -all (hard fail): mail from unlisted servers should be rejected. Strict and correct once you are sure every legitimate sender is listed.
• ?all (neutral): says nothing about unlisted servers. Gives receivers almost no protection; replace it.
• +all: allows every server on the internet to send as you. Never use it.
• No all at all: behaves like neutral. Add ~all.

Includes that have no SPF record

If you include a domain that has no SPF record, perhaps a service you have stopped using that has since changed its setup, the evaluation returns a permanent error. The include tree marks these in red. Remove them.

Deprecated ptr

The ptr mechanism is slow, unreliable and discouraged by the standard. Some receivers ignore it. Replace it with the actual ip4: ranges.

SPF record examples

Always copy the include value from each provider’s own documentation; the examples show the shape, and providers do change their values occasionally.

How to fix “too many DNS lookups”

1. Remove services you no longer use. Old tools are the most common source of wasted lookups.
2. Check which includes are actually needed. A tool that sends through your Google or Microsoft mailbox (connected by OAuth or SMTP) does not need its own include; your mailbox provider’s include already covers it.
3. Replace a and mx with ip4: when the addresses are stable. IP mechanisms cost no lookups.
4. Move bulk senders to a subdomain. Send newsletters from news.yourcompany.com with its own SPF record, keeping the main domain lean.
5. Be careful with “SPF flattening”. Replacing includes with the IP addresses they currently resolve to fixes the count, but breaks silently when the provider changes its IPs. If you flatten, use a service that keeps the list updated.

SPF and cold email

For cold outreach, SPF is one of three records that must pass, alongside DKIM and DMARC. A few points specific to outbound:

• Every sending domain needs its own SPF record. If you use secondary domains for outreach, each one needs SPF, DKIM and DMARC. Check each with the Domain Health Checker.
• Sending through your mailbox keeps SPF simple. Outreach tools that send through your own Google or Microsoft account inherit your provider’s SPF. Tools that send through their own servers need their include added.
• SPF alone does not satisfy DMARC for forwarded mail. SPF breaks when a message is forwarded, which is why DKIM matters just as much. Check your keys with the DKIM Checker.
• Alignment matters for DMARC. For SPF to count towards DMARC, the envelope sender domain must match (or be a subdomain of) your visible From domain. Tools that use their own bounce domain pass SPF but not SPF alignment; they rely on DKIM alignment instead.

How to create or edit an SPF record, step by step

1. List every service that sends email as your domain. Your mailbox provider, CRM, marketing platform, help desk, billing system, website contact form and any outreach tool that sends through its own servers. Ask colleagues; this list is always longer than expected.
2. Find each service’s SPF include in its documentation, usually on a page called “authenticate your domain” or “SPF setup”.
3. Check whether a record already exists by running this checker. If it does, you will edit it; never add a second one.
4. Write the record: v=spf1, then each include separated by spaces, then ~all. For example v=spf1 include:_spf.google.com include:mail.zendesk.com ~all.
5. Publish it at your DNS host as a TXT record on the root of the domain (host @ or empty).
6. Run this checker again and confirm one record, under 10 lookups, ending in ~all or -all.
7. Send a test email through each service and confirm SPF passes in the message headers.

Reading SPF results in email headers

Every receiving mailbox records its SPF verdict in the message headers. In Gmail choose “Show original”; in Outlook open the message, then File, Properties, Internet headers. Look for two lines:

• Received-SPF: pass (google.com: domain of [email protected] designates 203.0.113.5 as permitted sender)
• Authentication-Results: … spf=pass smtp.mailfrom=yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass

The possible SPF results are pass, fail (hard fail), softfail, neutral, none (no record), temperror (a temporary DNS problem) and permerror (a broken record, such as two SPF records or more than 10 lookups). A permerror is the one to fix immediately, because it fails every message.

Less common SPF rules worth knowing

The void lookup limit

Besides the 10-lookup limit, the standard recommends receivers fail SPF after more than two “void” lookups: lookups that return no answer, such as an include pointing at a domain that no longer has SPF. Removing dead includes fixes this too.

Subdomains need their own record

SPF is not inherited. If you send from mail.yourcompany.com, that subdomain needs its own v=spf1 record. Many email platforms use a subdomain as the envelope sender for exactly this reason: they publish SPF on their own subdomain so you do not have to change your root record.

Forwarding breaks SPF

When a recipient forwards your message, the forwarding server’s IP is not in your record, so SPF fails at the final destination. Some forwarders rewrite the envelope sender (SRS) to avoid this; many do not. This is why DKIM, which survives forwarding, matters just as much for DMARC.

Record length

A single DNS text string is limited to 255 characters; longer SPF records are split into several quoted strings that receivers join. Most DNS hosts handle this automatically. Very long records are a sign it is time to simplify.

SPF, DKIM and DMARC compared

Where to find the SPF include for common services

Providers change their values occasionally, so always confirm in the provider’s own documentation. These are the usual places to look and the shape of the value:

A useful rule of thumb: if a service sends through your own Google or Microsoft mailbox, it needs no include. If it sends through its own servers with your From address, it needs either an include in your SPF or its own return-path subdomain plus DKIM.

Glossary

• Envelope sender (return path): the technical sender address SPF checks, separate from the visible From.
• Mechanism: one term in an SPF record, such as include: or ip4:.
• Qualifier: the prefix that sets the result for a match: +, -, ~ or ?.
• Permerror: a permanent SPF error caused by a broken record; fails every message.
• Flattening: replacing includes with the IP ranges they resolve to, to save lookups.

A quick SPF audit checklist

• One v=spf1 record on the root of the domain.
• Every active sending service included, and no services you have stopped using.
• Eight lookups or fewer, leaving headroom for the next tool.
• Ends in ~all or -all.
• No ptr, no +all, no includes that return nothing.
• Every sending subdomain has its own record.
• Non-sending domains you own publish v=spf1 -all so nobody can use them for spoofing.

Testing SPF after a change

After editing your record, run the checker again. Most DNS hosts publish changes within minutes, but receivers may cache the old record until its TTL expires. For a real-world test, send an email to a Gmail address you control, open it, choose “Show original” and look for SPF: PASS with your domain.

How Prosyo helps

Prosyo sends LinkedIn and email outreach from your own connected mailboxes, so your existing SPF and DKIM setup covers it with no extra records to add. It keeps each account inside safe daily limits, verifies contacts before sending and stops every sequence the moment someone replies. Start a 7-day free trial.

Related free tools

These tools are often used together with the SPF Checker. All of them are free, and the checkers and calculators run instantly in your browser.

• Domain Health Checker: Score your sending domain on MX, SPF, DKIM, DMARC, BIMI, MTA-STS and blocklists in one click, with a fix for everything that fails.
• DKIM Checker: Find your DKIM keys by selector or scan 40+ common selectors, with key length and revocation checks.
• DMARC Checker: Read your DMARC policy in plain English, get a grade from A to F and a safe path to full enforcement.
• DNS Lookup: Query A, AAAA, CNAME, MX, TXT, NS, SOA and CAA records for any name from a public resolver.