What is an example of a SPF domain?

An example of an SPF domain record looks like this: v=spf1 include:_spf.google.com include:mailchimp.com ~all. This tells receiving mail servers that emails sent from your domain are authorized to come from Google’s and Mailchimp’s mail servers, with a soft fail for any other source. Understanding how to read and build SPF records is a core part of solid SPF configuration, and the sections below break down exactly what each component means.

What does an SPF record actually look like?

An SPF record is a DNS TXT record published on your domain that lists which mail servers are authorized to send email on your behalf. A typical SPF record looks like this: v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all. It always starts with v=spf1 to identify it as an SPF record, followed by one or more mechanisms, and ends with an “all” policy.

Here is a slightly more complex real-world example for a business using multiple sending services:

• v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.5 ~all

In plain language, this record says: “Emails from this domain are authorized to come from Google’s mail servers, SendGrid’s mail servers, or the specific IP address listed. Anything else should be treated with suspicion.” Each mechanism is evaluated left to right, and the first matching result wins.

What are the different parts of an SPF domain record?

An SPF domain record is made up of several distinct components, each playing a specific role in telling receiving servers how to handle your email. Breaking down the record v=spf1 include:_spf.google.com ip4:203.0.113.10 -all reveals four key parts: the version tag, include mechanisms, IP mechanisms, and the all qualifier.

Version tag and mechanisms

The v=spf1 tag is mandatory and must always appear first. It tells the receiving server that this is a version 1 SPF record. Without it, the record is not recognized as SPF at all.

The include: mechanism delegates authorization to another domain’s SPF record. When you use include:_spf.google.com, you are telling receiving servers to look up Google’s own SPF record and treat those IP addresses as authorized for your domain. This is how businesses authorize third-party email service providers without having to list every individual IP address.

The ip4: mechanism directly authorizes a specific IPv4 address or range. You can also use ip6: for IPv6 addresses. These are useful when you send from a dedicated server with a fixed IP address.

The all qualifier

The all mechanism at the end of the record acts as a catch-all for any sending source not matched by the earlier mechanisms. The qualifier in front of it determines what happens to those unmatched sources. This is one of the most important decisions in your SPF configuration, and it is covered in detail in the next section.

What is the difference between ~all and -all in SPF?

The difference between ~all and -all is the strictness of the policy applied to emails that do not match your authorized senders. ~all is a soft fail, meaning unmatched emails are accepted but flagged as suspicious. -all is a hard fail, meaning unmatched emails should be rejected outright by the receiving server.

Here is a quick breakdown of all four qualifiers you can use with the all mechanism:

• +all (pass): Authorizes all senders, including unauthorized ones. This effectively disables SPF protection and should never be used.
• ~all (soft fail): Unmatched emails pass but are marked, often moving them to spam. This is the most common choice during initial setup.
• -all (hard fail): Unmatched emails are rejected. This is the strictest and most secure option once you are confident your record is complete.
• ?all (neutral): No policy is stated. Receiving servers treat unmatched senders as neither authorized nor unauthorized.

For most organizations, starting with ~all while you audit your sending sources is a sensible approach. Once you are certain every legitimate sending service is listed in your record, moving to -all gives you stronger protection against spoofing and unauthorized use of your domain.

How many domains can you include in an SPF record?

An SPF record has a hard limit of 10 DNS lookups. Each include:, a:, mx:, and redirect= mechanism that triggers a DNS lookup counts toward this limit. If your SPF record exceeds 10 lookups, it results in a “PermError,” which can cause legitimate emails to fail authentication and hurt your deliverability.

This limit is one of the most commonly misunderstood aspects of SPF configuration. It is not a limit on the number of IP addresses or the character length of the record (though there is a 255-character per string limit to be aware of). It is specifically about DNS queries made during evaluation.

If you use several email service providers, such as Google Workspace, a marketing automation platform, a transactional email service, and a CRM, you can easily approach or exceed this limit without realizing it. Some included domains themselves trigger additional lookups when their own SPF records are evaluated.

The practical solution is to audit your record regularly, remove any services you no longer use, and consider using SPF flattening tools that consolidate multiple lookups into direct IP addresses. However, flattened records require maintenance whenever a provider changes their IP ranges.

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

To check whether your SPF domain record is set up correctly, use a DNS lookup tool or an SPF validation tool to query the TXT records on your domain. Look up your domain’s TXT records, locate the record starting with v=spf1, and then run it through a validator to check for syntax errors, lookup count violations, and missing authorized senders.

Here are the key things to verify during an SPF record check:

1. Only one SPF record exists: Having multiple SPF records on the same domain causes an automatic PermError. If you need to add a new sender, edit the existing record rather than creating a new one.
2. The DNS lookup count is 10 or fewer: Run your record through a lookup counter to confirm you are within the limit.
3. All active sending services are included: Cross-reference your record against every platform or service that sends email on behalf of your domain.
4. The record ends with an all qualifier: A record without a closing all mechanism leaves the policy undefined.
5. No syntax errors are present: Typos in mechanism names or domain names cause silent failures that are difficult to diagnose.

Beyond manual checks, sending a test email and reviewing the authentication headers in the received message is a reliable way to confirm your SPF record is working end-to-end. Most email clients let you view raw message headers, where you will see a line showing whether SPF passed, failed, or soft-failed for that specific message.

How Email Industries helps with SPF configuration

Getting SPF configuration right is rarely a one-time task. As your sending infrastructure evolves, records drift out of date, lookup counts creep toward the limit, and gaps appear that leave your domain vulnerable to spoofing. We help organizations take control of their email authentication from the ground up. Here is what we bring to the table:

• Full SPF record audits: We review your existing record against all active sending sources to identify unauthorized entries, missing services, and lookup count violations.
• Authentication alignment: We ensure your SPF, DKIM, and DMARC records work together correctly, which is essential for strong deliverability and domain protection.
• Ongoing monitoring: We help you stay ahead of changes, whether a provider updates their IP ranges or a new tool is added to your stack without updating your DNS.
• Deliverability consulting: SPF is one layer of a broader email health strategy. We connect authentication fixes to real inbox placement outcomes.

If you are unsure whether your current SPF setup is protecting your domain or quietly hurting your deliverability, we are happy to take a look. Reach out and contact us to start the conversation.

Related Articles

• What are the most reputable domains?
• How does DKIM setup improve email deliverability?
• How does BIMI implementation improve email security?
• What are the biggest DMARC policy mistakes email senders make?
• How do you fix DMARC failures without breaking email delivery?
• How does DKIM work with DMARC to stop email spoofing?
• When should you escalate your DMARC policy to full enforcement?
• What should my DMARC policy be?
• Is SPF still relevant for email security?
• What questions should you ask potential full service email agencies?
• How do email advertising agencies handle creative development?
• How do email advertising agencies adapt to algorithm changes?
• When should you use a new domain for email migration?
• What is the difference between IP warmup and domain warmup?
• How many IPs do you need to warm up for a large email program?