May 24, 2026 · 13 min read

How to Use nslookup to Find SPF Records: A Complete Guide

Learn how to perform an nslookup spf record check on Windows, Mac, and Linux. Master reverse spf lookups, historical searches, and fix nested include errors.

May 24, 2026 · 13 min read

Email Security DNS Troubleshooting Network Administration

Under the Sender Policy Framework (SPF), domain owners publish a list of authorized mail servers that are permitted to send emails on behalf of their domain. When email servers receive a message, they check this framework to ensure the sender is legitimate, preventing domain spoofing and phishing. To verify, test, or troubleshoot these configurations, performing an nslookup spf record check is the most direct, built-in method available on modern operating systems.

In this comprehensive guide, you will learn how to get spf record nslookup outputs on Windows, macOS, and Linux, dive deep into decoding the records, execute a reverse spf lookup, and understand how an spf history lookup can help resolve long-term deliverability issues.

1. How to Get SPF Records with Nslookup (Step-by-Step)

nslookup (Name Server Lookup) is a command-line tool used to query the Domain Name System (DNS) to obtain domain name or IP address mapping, or other DNS records. Because SPF records are stored as DNS TXT (Text) records, we use nslookup to request the TXT records of a specific domain and then filter for the one that begins with v=spf1.

There are two primary ways to run nslookup: non-interactive mode (running a single command and returning to the command prompt) and interactive mode (entering an ongoing nslookup session).

Using Non-Interactive Mode (Recommended for Quick Checks)

To perform a quick lookup spf record nslookup check, open your terminal (macOS/Linux) or Command Prompt/PowerShell (Windows) and enter the following command:

nslookup -type=txt google.com

Depending on your operating system, the exact flag might slightly vary, though -type=txt is universally supported. On some legacy systems, -query=txt or -q=txt is also common.

Example Output on Windows:

C:> nslookup -type=txt google.com
Server:  unresolved.localdomain
Address:  192.168.1.1

Non-authoritative answer:
google.com      text =

        "v=spf1 include:_spf.google.com ~all"
        "facebook-domain-verification=2295bb4fdf27"
        "docusign=0597110e-c1a7-4701-83d1-e5fc81d0dfbf"

In the output above, nslookup returned multiple TXT records. The SPF record is explicitly the one beginning with "v=spf1 ... ".

Using Interactive Mode

If you need to query multiple domains or switch settings frequently, interactive mode is highly efficient.

Open your terminal or command prompt and type:
```
nslookup
```
Once the prompt changes to > (indicating you are inside the interactive shell), type:
```
set type=txt
```
Type the domain name you wish to check and press Enter:
```
google.com
```
The terminal will display the TXT records. You can then type another domain, or type exit to close the shell.

C:> nslookup
Default Server:  one.one.one.one
Address:  1.1.1.1

> set type=txt
> google.com
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
google.com      text =
        "v=spf1 include:_spf.google.com ~all"
> exit

2. Advanced Nslookup Techniques for SPF Troubleshooting

While a simple query is sufficient for most daily tasks, advanced troubleshooting of mail delivery issues requires a deeper understanding of DNS propagation, caching, and authoritative responses.

Bypassing Cache: Querying Specific Nameservers Directly

When you query DNS using the standard nslookup -type=txt domain.com command, your computer queries your local DNS resolver (usually managed by your ISP or router). This resolver caches results to speed up future requests.

If you have just updated your SPF record, the changes might not appear on your local resolver due to Time to Live (TTL) caching. To bypass this, you can force nslookup to query a public, highly updated DNS server or the domain's authoritative nameserver directly.

To query a public DNS resolver like Cloudflare (1.1.1.1) or Google (8.8.8.8), append the IP address of the server to your command:

nslookup -type=txt google.com 8.8.8.8

To query the domain’s authoritative nameserver directly:

First, find the authoritative nameservers for the domain:
```
nslookup -type=ns google.com
```
This will return nameservers like ns1.google.com.

Query that authoritative nameserver directly:

nslookup -type=txt google.com ns1.google.com

Using this authoritative nameserver query gives you the absolute real-time state of the record, eliminating any local DNS cache delays.

Dealing with UDP Truncation and Large SPF Records

Older DNS queries utilize the User Datagram Protocol (UDP) which historically limits packets to 512 bytes. If a domain has a massive number of TXT records (for site verifications, security keys, and complex SPF configurations), the response might exceed 512 bytes.

In such cases, nslookup might fail to show all records or show a truncated warning. To bypass this, you can instruct nslookup to use Transmission Control Protocol (TCP), which allows for much larger payloads:

nslookup -vc -type=txt cisco.com

The -vc (virtual circuit) flag forces nslookup to establish a TCP connection for the query, ensuring that no records are dropped or truncated due to packet size limits.

3. Decoding the SPF Record Structure

Getting the SPF record using nslookup is only the first step; you must also know how to interpret the output. An SPF record is composed of a version prefix, mechanisms, and modifiers.

Let's look at a typical SPF record: v=spf1 ip4:192.168.1.0/24 include:_spf.google.com -all

The Version Prefix

v=spf1: This defines the record as Sender Policy Framework version 1. Every valid SPF record must begin with this exact string.

Mechanisms

Mechanisms specify which hosts are authorized to send mail.

ip4 and ip6: Specifies a range of IPv4 or IPv6 addresses (e.g., ip4:192.0.2.1 or ip4:192.0.2.0/24). This is the most efficient mechanism because it does not require additional DNS lookups.
a: Authorizes the IP address defined in the domain’s A record.
mx: Authorizes the mail exchange (MX) servers configured for the domain.
include: Tells the receiving server to look up and apply the SPF record of another domain (e.g., include:_spf.google.com means "also trust whatever IP addresses Google authorizes in its own SPF record").
exists: A complex mechanism used for dynamic SPF lookups, performing a DNS A query on a constructed domain.
ptr: Historically used to authorize senders based on reverse DNS lookups. Warning: The ptr mechanism is deprecated. It is slow, highly resource-intensive, and many major receiving servers completely ignore it. Never use it in modern SPF records.

Qualifiers

Every mechanism is paired with a qualifier that tells the receiving server what to do if a sender matches that mechanism. If no qualifier is explicitly stated, it defaults to + (Pass).

+ (Pass): The message is authorized (e.g., +ip4:192.168.1.1 or simply ip4:192.168.1.1).
- (Fail / Hard Fail): The message is not authorized. The receiving server is advised to reject the email outright (e.g., -all).
~ (Soft Fail): The message is not authorized, but the server is advised to accept it while flagging it as suspicious (e.g., placing it in the spam folder or adding a security header). This is heavily used during DMARC implementations (e.g., ~all).
? (Neutral): No statement is made about whether the message is authorized. This is treated as if no SPF record existed (e.g., ?all).

4. The 10 DNS Lookup Limit and Manual Recursion

One of the most common pitfalls of SPF records is the strictly enforced 10 DNS lookup limit. To prevent Distributed Denial of Service (DDoS) attacks against DNS infrastructure, the SPF specification dictates that a single SPF validation check cannot trigger more than 10 nested DNS lookups.

If a domain's SPF record exceeds this limit, receiving servers return a PermError (Permanent Error) and fail SPF validation immediately, severely damaging email deliverability.

Which Mechanisms Count Toward the 10-Lookup Limit?

Do count: include, a, mx, exists, and redirect.
Do not count: ip4, ip6, and all (since they do not require additional DNS queries to resolve).

How to Manually Trace and Resolve Nesting with Nslookup

Standard nslookup only returns the top-level TXT record. It does not recursively resolve the inner nested records for you. To calculate your total lookup count, you must perform a manual recursive trace.

Let's run a trace on a sample domain:

Run the initial query:
```
nslookup -type=txt example.com
```
Output: "v=spf1 include:_spf.google.com include:sendgrid.net -all" (This uses 2 lookups out of your 10-lookup budget: one for _spf.google.com, one for sendgrid.net).
Query the first nested record:
```
nslookup -type=txt _spf.google.com
```
Output: "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all" (This adds 3 more lookups to your count: _netblocks.google.com, _netblocks2.google.com, and _netblocks3.google.com. Total so far: 5).
Query those sub-records to check for further nesting:
```
nslookup -type=txt _netblocks.google.com
```
Output: "v=spf1 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ~all" (Since this nested record only contains ip4 mechanisms, it adds 0 further lookups to the count. It resolves to direct IP addresses).

If your manual tracing reveals that your domain exceeds 10 lookups, you must optimize the record. This process is called SPF flattening, where you manually replace high-lookup include mechanisms with their resolved, static ip4 or ip6 address blocks. However, you must carefully monitor these IP blocks, as third-party providers can change their outbound IP addresses without warning.

5. Reverse SPF Lookup & SPF History Lookup: Explaining the Alternatives

Standard nslookup is a forward lookup tool—it asks, "What is the SPF record for this domain?" However, modern domain administrators, security researchers, and IT auditors frequently require more advanced investigation methods: Reverse SPF Lookup and SPF History Lookup.

Understanding Reverse SPF Lookup

A reverse spf lookup reverses the standard query. Instead of querying a domain to find its authorized IPs, it queries an IP address, netblock, or specific ESP include statement to find all domain names associated with it.

Why Use a Reverse SPF Lookup?

Vendor Auditing: Find every domain in your corporate portfolio that is currently configured to send emails through a specific third-party provider (e.g., Salesforce, SendGrid, or HubSpot) by searching for domains that contain include:sendgrid.net.
Threat Intelligence: If a malicious IP address is sending spoofed emails, security researchers use reverse lookups to find which domains have inadvertently authorized that compromised IP block in their SPF configuration.
De-provisioning: When transitioning off an old marketing platform, admins can run a reverse search to ensure no legacy domains still include the deprecated platform in their SPF records.

Standard DNS tools like nslookup cannot execute reverse SPF lookups natively because DNS is not indexed in reverse. To do this, you must query structured historical DNS databases (such as SecurityTrails or WhoisFreaks) that actively index TXT records and allow search queries like txt: "include:spf.protection.outlook.com".

Understanding SPF History Lookup

An spf history lookup tracks how a domain’s SPF record has changed over time. Since standard DNS queries only return the present state of a record, history lookups are vital when diagnosing sudden delivery failures or security incidents.

Why Use an SPF History Lookup?

Root-Cause Analysis: If email deliverability suddenly plummeted last Tuesday, an SPF history search can show whether someone modified the TXT record on Monday, introducing a syntax error or removing an authorized server.
Forensic Auditing: In the event of a domain spoofing incident, historical lookups can verify if an unauthorized IP address was temporarily added to the SPF record by an attacker who had gained unauthorized access to the DNS manager.
Change Management: Verify that automated provisioning scripts or DNS migrations executed cleanly and did not temporarily leave the domain without a valid SPF record.

To perform an SPF history lookup, you must leverage specialized web archives or DNS history platforms. These tools constantly capture timestamped snapshots of global DNS records, allowing you to view a timeline of every modification made to a domain's TXT records.

6. Troubleshooting Common SPF Failures and Nslookup Limitations

While nslookup is a highly powerful and lightweight tool, it is critical to recognize its limitations and know how to fix the most common SPF configuration failures.

Failure 1: Multiple SPF Records (The Fatal Error)

A domain is strictly permitted to have only one SPF record. If you publish more than one TXT record starting with v=spf1, receiving mail servers will immediately throw a PermError and reject all your emails.

How to spot this with nslookup:

If you run nslookup -type=txt yourdomain.com and see two lines beginning with v=spf1, you have a fatal configuration error:

"v=spf1 include:_spf.google.com ~all"
"v=spf1 include:spf.protection.outlook.com -all"

The Fix:

You must merge them into a single record:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

Failure 2: Character and Packet Size Limits

A single character string in a DNS TXT record is limited to 255 characters. If your SPF record exceeds 255 characters, it must be split into multiple quoted strings within a single TXT record. Furthermore, if the entire DNS response exceeds 512 bytes, older UDP-based resolvers will drop the packet.

Always use nslookup -vc (TCP mode) or dig +tcp to see if your DNS provider is properly serving long records over TCP.

Limitation of Nslookup: No Built-In Syntax Validation

nslookup is completely passive. It is simply a messenger. It will retrieve whatever string is published in your DNS—even if it is full of spelling mistakes, invalid mechanisms, or syntax errors.

For example, if you accidentally publish: v=spf1 inlcude:_spf.google.com -all (with "include" misspelled)

nslookup will successfully return that record without any warning. It is up to you to carefully audit the retrieved string or pass it through an online SPF validator to catch typos.

7. Frequently Asked Questions

Can I have multiple SPF records?

No. A domain must have exactly one SPF record. If you need to authorize multiple third-party services, you must combine them into a single record using include: mechanisms or direct IP ranges.

Why does nslookup return "No TXT record found"?

This usually indicates one of three things:

No TXT records are published on the domain.
The domain name was misspelled in the command.
DNS propagation is still occurring. If you recently added the record, it can take up to 24-48 hours to propagate worldwide, though direct authoritative queries to your nameserver (nslookup -type=txt yourdomain.com ns1.yourdns.com) will show the changes instantly.

What is the difference between nslookup and dig for SPF checks?

nslookup is built into almost all operating systems, including Windows, making it highly accessible. dig (Domain Information Groper) is a more advanced tool standard on macOS and Linux. dig provides cleaner formatting, explicit details about DNS flags, handles TCP fallback automatically, and is generally preferred by system administrators on Unix-based environments.

How do I check DKIM and DMARC using nslookup?

To check your DMARC record, query the _dmarc subdomain:

nslookup -type=txt _dmarc.example.com

To check a DKIM record, you must know the specific selector used by your email provider. Query the selector subdomain combined with _domainkey:

nslookup -type=txt selector1._domainkey.example.com

What is the difference between -all and ~all?

-all is a "Hard Fail," telling receiving servers to reject any emails that do not originate from your authorized list. ~all is a "Soft Fail," instructing servers to accept the emails but mark them as suspicious (often routing them to the spam folder). Modern organizations typically use ~all in combination with a strong DMARC policy (p=reject) to maintain control over delivery while ensuring maximum security.

Conclusion

Conducting a manual nslookup spf record check is a foundational skill for any IT administrator, security professional, or webmaster. By understanding how to query specific nameservers, trace nested includes, and troubleshoot common pitfalls like the 10 DNS lookup limit, you can safeguard your domain’s email reputation. While standard nslookup is invaluable for real-time validation, pairing it with historical SPF and reverse lookups ensures you maintain a robust, comprehensive defense against domain spoofing.