How to Check Your Domain's SPF Record

Why setting up SPF isn't enough

An SPF record tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain. But DNS records change, services get added or removed, and providers update their IP ranges. If you don't verify your SPF record after every change — and periodically even without one — you may find your emails landing in spam or getting rejected without warning.

This article covers three ways to check your domain's SPF record: online analyzers, command-line queries, and automated monitoring. For each method, you'll learn what to look for and how to interpret the results.

Checking with an online analyzer

The fastest and most comprehensive way to verify your SPF record. An analyzer parses the record, recursively expands all include mechanisms, counts DNS lookups, and flags syntactic and logical errors.

What an analyzer checks

Check your SPF record with SPF Monitor's analyzer — it displays the full include tree, counts DNS lookups, and highlights all detected issues.

Checking via command line

If you prefer the terminal, you can query DNS directly for your SPF record.

Linux and macOS: dig

dig example.com TXT +short

The output lists all TXT records for the domain. Look for the one starting with v=spf1:

"v=spf1 include:_spf.google.com ip4:198.51.100.10 -all"

To filter for SPF records only:

dig example.com TXT +short | grep spf

Windows: nslookup

nslookup -q=txt example.com

The SPF record appears under the "Non-authoritative answer" section. On domains with many TXT records, nslookup may omit some — use dig instead (available through WSL or tools like BIND).

Windows: PowerShell

Resolve-DnsName -Name example.com -Type TXT | Where-Object { $_.Strings -match "spf" }

PowerShell returns structured output where the Strings property contains the TXT record text.

What to look for

When checking via command line, verify three things:

1. Does an SPF record exist? If no line starting with v=spf1 is returned, the domain has no SPF record — and emails from it may be flagged as suspicious.
2. Is there only one? Per RFC 7208 (Section 4.5), a domain must have exactly one SPF record. Two or more cause a PermError.
3. Does it end with the right all qualifier? The recommended ending is -all (hard fail). ~all (soft fail) is acceptable during rollout. +all effectively disables protection.

Command-line queries show the current state of the record but don't validate syntax, count DNS lookups, or reveal nested issues. That's what analyzers are for.

Common problems found during verification

Exceeding the 10 DNS lookup limit

Every include, a, mx, ptr, exists mechanism and redirect modifier triggers a DNS lookup. Nested include records count too — each include may contain further nested records that consume additional lookups from the limit.

As you add more services (email, marketing, helpdesk, billing), you'll approach the limit quickly. Exceeding it causes a PermError — SPF verification fails for all emails from your domain, including legitimate ones.

Solutions:

• Remove include entries for services you no longer use
• Replace include with ip4/ip6 if a service uses stable IP addresses
• Consider SPF flattening — an automated technique that replaces nested includes with IP addresses

Multiple SPF records on a domain

A common mistake: when adding a new service, an administrator creates a new TXT record instead of editing the existing one. The result is two records starting with v=spf1 and a PermError.

# Wrong — two SPF records
v=spf1 include:_spf.google.com -all
v=spf1 include:sendgrid.net -all

# Correct — one merged record
v=spf1 include:_spf.google.com include:sendgrid.net -all

Missing sender

SPF only passes for servers listed in the record. If you add a new service (e.g., a billing system) without including it in your SPF record, its emails will be rejected under -all. Symptoms: customers don't receive invoices, notifications from the new system end up in spam.

Fix: update and verify your SPF record after introducing any new email-sending service.

Using the deprecated ptr mechanism

The ptr mechanism is explicitly discouraged in RFC 7208 (Section 5.5). It's slow, unreliable, and puts unnecessary load on DNS. Some receiving servers ignore it entirely. If your record contains ptr, replace it with include, ip4, or ip6.

When to verify your SPF record

A one-time check isn't enough. Verify your SPF record:

• After every DNS change — adding or removing TXT records
• After introducing a new email service — marketing, helpdesk, CRM, billing
• After domain or DNS migration — changing registrar, moving DNS hosting
• Regularly — at least monthly, ideally through automated monitoring

Third-party services can change their IP addresses or SPF records without notice. Your include:service.com may work today and exceed the DNS lookup limit tomorrow because the provider added another nested include.

Automated domain monitoring catches these changes and alerts you before they impact email deliverability.

SPF verification is just the beginning

Checking your SPF record is essential, but complete email authentication also requires DKIM (message integrity verification) and DMARC (linking SPF and DKIM to the From header address). Without DMARC, an attacker can pass SPF from their own server while spoofing your address in the From header — the recipient won't notice the difference.

If your SPF record checks out, continue with setting up DKIM and DMARC. If the analyzer found issues, go back to How to Create an SPF Record Step by Step and fix them.