What does an SPF record actually look like in DNS?

An SPF record in DNS looks like a single TXT record published on your domain that starts with v=spf1, followed by a series of mechanisms that define which mail servers are authorized to send email on your behalf, and ends with an all qualifier. For example: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. The sections below break down exactly what each part means, how the mechanisms work, and what to watch out for when setting one up.

What does a typical SPF record look like?

A typical SPF record is a DNS TXT record published on your domain that begins with the version tag v=spf1, lists one or more sending sources (IP addresses, domains, or includes), and closes with an all policy. A real-world example might look like this: v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.10 -all. Every legitimate SPF record follows this same basic pattern.

The record lives in your domain’s DNS zone as a TXT record, not an SPF record type (which was deprecated years ago). Anyone can look it up using a DNS query tool or command line, and receiving mail servers check it automatically whenever they receive an email from your domain. The entire record must fit within DNS constraints, which is why simplicity and efficiency matter.

What do the different parts of an SPF record mean?

Each part of an SPF record serves a specific role. The version tag v=spf1 tells the receiving server this is an SPF record. What follows are mechanisms and modifiers that define authorized senders. The closing all tag tells the server what to do with any sender not explicitly listed.

• v=spf1 — The required version identifier. Every SPF record must start with this.
• ip4: or ip6: — Authorizes a specific IPv4 or IPv6 address or range.
• include: — References another domain’s SPF record, pulling in its authorized senders.
• a: — Authorizes the IP address(es) in the domain’s A record.
• mx: — Authorizes the mail servers listed in the domain’s MX records.
• redirect= — Replaces the entire SPF evaluation with another domain’s SPF record.
• all — The catch-all policy applied to any sender not matched by earlier mechanisms.

Reading an SPF record from left to right is how a receiving server processes it. It evaluates each mechanism in order, stopping at the first match. The qualifier attached to that match (or to all at the end) determines the outcome.

What are the most common SPF record mechanisms?

The most common SPF mechanisms are include:, ip4:, and mx:. These three cover the vast majority of real-world use cases. The include: mechanism is especially prevalent because it lets you delegate authorization to third-party sending services like Google Workspace, Mailchimp, or SendGrid without manually listing every IP they use.

Here is how each of the most common mechanisms works in practice:

• include:_spf.google.com — Authorizes all IPs Google uses to send on your behalf when using Google Workspace.
• ip4:203.0.113.0/24 — Authorizes every IP in that specific IPv4 subnet range.
• mx — Authorizes your domain’s own mail servers, useful when your inbound and outbound mail servers are the same.
• a — Authorizes the IP address your domain’s A record points to, sometimes used for small self-hosted setups.

The include: mechanism is the most powerful and the most commonly misused. Each include triggers an additional DNS lookup, which matters a great deal once you start adding multiple third-party senders (more on that below).

What’s the difference between ~all, -all, and ?all?

The difference between ~all, -all, and ?all is the strictness of the policy applied to senders not matched by earlier mechanisms. -all is a hard fail that tells receiving servers to reject unauthorized senders outright. ~all is a soft fail that flags the message but typically still delivers it. ?all is neutral and offers no policy guidance at all.

Choosing between them depends on your confidence in your SPF record’s completeness and your overall email authentication strategy:

• -all (hard fail): The strictest option. Receiving servers should reject mail from any IP not listed. Best used when you are certain your record covers every legitimate sending source.
• ~all (soft fail): The most common choice in practice. Non-matching senders are flagged rather than rejected, giving you a safety net if you have missed a sending source. Many organizations use this while building toward a stricter posture.
• ?all (neutral): Essentially no policy. Receiving servers are free to do whatever they want with non-matching senders. This offers no real protection and is generally not recommended.

For most organizations focused on improving email deliverability, -all is the goal once all legitimate sending sources are confirmed and documented. Starting with ~all while auditing your sending infrastructure is a sensible and common approach.

Why does an SPF record stop working after too many lookups?

An SPF record stops working correctly when it triggers more than 10 DNS lookups during evaluation. This limit is defined in the SPF specification (RFC 7208), and exceeding it causes an SPF permerror, which many receiving servers treat as a failure. Each include:, a:, mx:, and redirect= mechanism counts as one lookup, and nested includes count too.

This is called the SPF 10-lookup limit, and it catches many organizations off guard as they add more third-party senders over time. A single include: for a major ESP like SendGrid or Mailchimp might itself contain two or three nested lookups, consuming your budget quickly.

Common ways to stay within the limit include:

• Auditing your record regularly to remove includes for services you no longer use
• Replacing include: mechanisms with direct ip4: entries where the IP ranges are stable
• Using SPF flattening tools that resolve all includes into a single flat list of IP addresses
• Consolidating sending infrastructure to reduce the number of third-party services that need authorization

SPF flattening solves the lookup problem but introduces a maintenance challenge: flattened records need to be updated whenever a sending provider changes its IP ranges. Automation or a managed service is usually the practical answer for high-volume senders.

How do you check if your SPF record is set up correctly?

To check if your SPF record is set up correctly, run a DNS TXT lookup on your domain and then validate the result using an SPF checking tool. A correctly configured SPF record should return a single TXT record starting with v=spf1, pass validation without errors, stay within the 10-lookup limit, and accurately reflect every service authorized to send email on your behalf.

Here are the steps to verify your SPF configuration:

1. Look up the record: Use a command like nslookup -type=TXT yourdomain.com or dig TXT yourdomain.com to retrieve the raw TXT records for your domain.
2. Check for duplicates: You should have only one SPF record. Multiple TXT records beginning with v=spf1 will cause an SPF permerror.
3. Count your lookups: Use an online SPF validator to count how many DNS lookups your record triggers. Stay under 10.
4. Send a test email: Tools like Mail Tester or Google’s Postmaster Tools let you send a test message and see whether SPF passes, fails, or soft-fails.
5. Review DMARC reports: If you have DMARC set up, aggregate reports will show you which sending sources are passing and failing SPF alignment over time.

Checking your SPF record is not a one-time task. Any time you add a new email service provider, change hosting, or retire a tool, your SPF record needs a corresponding update to stay accurate.

How Email Industries helps with SPF configuration and email authentication

Getting SPF right is one piece of a broader email authentication puzzle, and small mistakes can have a significant impact on deliverability. At Email Industries, we help organizations audit, configure, and maintain their SPF records as part of a complete authentication strategy that includes DKIM and DMARC alignment.

Here is what we bring to the table:

• SPF audits: We review your existing record for errors, duplicate entries, lookup limit issues, and gaps in coverage across all your sending sources.
• Authentication setup and optimization: We configure SPF, DKIM, and DMARC together so they work as a cohesive system rather than isolated settings.
• Ongoing monitoring: Through our Deliverability Assurance Packages, we keep an eye on your authentication health and flag issues before they affect inbox placement.
• Expert consulting: Our team has spent over two decades solving complex deliverability challenges across SaaS, eCommerce, healthcare, and finance, so we understand the nuances that generic tools miss.

If your SPF record feels like a black box or you are not sure whether your authentication setup is actually protecting your sender reputation, explore our services to see how we can help, or reach out to get a conversation started.

Related Articles

• How does DKIM signing work in email authentication?
• What is DMARC and why do I need it?
• How do email advertising agencies integrate with existing marketing teams?
• Should you migrate your entire email list at once or in segments?
• Should you warm up a new domain before sending bulk email?
• What are the signs that your IP warming strategy is working?
• What post-purchase email sequences do ecommerce agencies recommend?
• What is an ecommerce email marketing agency?
• How do agencies optimize email conversion rates?
• How do you evaluate email marketing agency performance?
• How do agencies develop annual email marketing plans?
• What qualifications should email marketing agencies have?
• What is meant by email deliverability optimization?
• What are the warning signs your email delivery needs expert attention?
• How does an email deliverability agency improve inbox placement?