The Complete Guide to Setting up SPF Records with Multiple Includes and Domains

Have you ever tried to add multiple SPF records only to have authentication fail with pesky PermErrors, email rejects and email bounce?

Do you need to authorize more than one service to send emails from your domain? This guide will show you how to properly merge multi-domain SPF policies!

What are SPF Records and How Do They Work?

Sender Policy Framework (SPF) records are a critical component of modern email authentication and security. In this section, we’ll cover the basics of what SPF records are, how they function, and their syntax.

Definition and Purpose of SPF Records

An SPF record is a specific type of DNS TXT record used for email authentication. The purpose of SPF is to prevent unauthorized use of your domain in email envelopes.

Here’s a quick analogy to understand SPF – let’s say you run a furniture store called “FancyChairs.com.” SPF acts as the security guard, only letting through emails that legitimately come from your domain. Without it, spammers could pretend to send emails “from” FancyChairs.com and trick people.

When a receiving mail server gets an email claiming to be from your domain, it will look up your SPF record. This lists all the servers and IP addresses authorized to send emails from your domain. If the sending server is not included, the email will be flagged or rejected as invalid.

How SPF Authentication Works

When an email arrives, the receiving server will:

  1. Extract the domain from the email envelope FROM address (e.g. @fancychairs.com)
  2. Look up the DNS for TXT records matching “v=spf1” for that domain
  3. If no SPF records are found, the check returns “Neutral”
  4. If multiple SPF records exist, it’s a PermError failure (invalid config)
  5. If a valid SPF record is found, it parses the listed mechanisms and modifiers to check if the sender is authorized
  6. If the sending server/IP is authorized, the SPF check passes!
  7. If not, it fails and the email may be rejected or flagged as spam

So in summary, SPF gives you control to specify what servers are allowed to send mail from your domain. This prevents spoofing and forgery.

Common SPF Record Syntax and Format

SPF records have a standard format defined by RFC 7208. Here are some examples of common syntax:

v=spf1 ip4:192.168.1.1 -all

This authorizes the IPv4 address 192.168.1.1 to send mail as @fancychairs.com, and fails everything else.

v=spf1 include:spf.google.com -all

This imports Google’s SPF record, authorizing their servers, and excludes everything else.

v=spf1 a mx include:vendor.com ~all

This authorizes the A and MX records of @fancychairs.com, includes vendor.com’s SPF, and softfails everything else.

Some key points:

  • There can only be one SPF record per domain starting with “v=spf1”
  • Multiple mechanisms and modifiers can be included in one record
  • The total DNS lookups during a check must be 10 or less
  • Modifiers like -all (fail) or ~all (softfail) handle unchecked senders

Now that you understand SPF fundamentals, let’s look at…

Why You Shouldn’t Have Multiple SPF Records

While SPF is powerful for authentication, there’s one critical rule – you can only have a single SPF record per domain. Let’s look at why this is the case.

SPF Spec Only Allows One Record per Domain

The SPF specification outlined in RFC 7208 explicitly states that multiple SPF records are forbidden:

This is a strict requirement – the SPF protocol will not function properly with multiple records. Having two or more records starting with “v=spf1” will break authentication and cause PermError failures.

Multiple Records Cause Authentication Failure

When performing an SPF check, the receiving server will fetch all TXT records for your domain that start with “v=spf1”.

If multiple records are returned, the server will immediately fail the SPF authentication with a PermError result. It doesn’t matter if each record is valid on its own. The presence of multiple records trips up the authentication logic.

This PermError failure signals that your SPF configuration is invalid. None of your records will be applied. Emails will not pass SPF checks which could lead to rejections or spam folder deliveries.

Debugging Multiple Records is Challenging

Since each SPF record appears valid on its own, it can be tricky to catch the PermError caused by multiples. Many admins won’t realize they have an issue unless actively monitoring SPF authentication results.

SPF PermErrors can also be intermittent if records are added or removed. Debugging arbitrary failures is difficult compared to other definite issues like syntax errors.

In summary, avoid the pitfalls of multiple SPF records by…

Adding Multiple Authorized Domains and Servers

While you can only have one SPF record, that single record can include multiple authorized sending servers and domains. Here’s how to set this up correctly.

Using Multiple IP Addresses, Domains, and Includes

An SPF record supports listing multiple approvals using:

  • ip4 and ip6 for specifying IPv4 and IPv6 addresses
  • a and mx to allow domains’ A and MX records
  • include to authorize other domains’ SPF records

You simply add each mechanism, separated by spaces, into your SPF record’s value:

v=spf1 ip4:1.1.1.1 ip4:2.2.2.2 include:otherdomain.com -all

Now emails from 1.1.1.1, 2.2.2.2, and any server allowed by otherdomain.com will pass the SPF check.

You can specify any number of IPs, domains, and includes (within lookup limits). This allows your single SPF record to authorize multiple sources.

Example SPF Records with Multiple Entries

Here are some examples of valid SPF records using multiple mechanisms:

# Multiple IPs
v=spf1 ip4:192.168.0.1 ip4:198.51.100.4 -all

# Multiple domain names  
v=spf1 a:domain1.com mx:domain2.net -all 

# Multiple includes
v=spf1 include:google.com include:vendor1.net ~all

# Mixed mechanisms
v=spf1 ip4:192.168.0.1 a:domain.com include:amazonses.com -all

As long as everything is merged into one record, you can authorize any number of senders.

Watching Out for Lookup Limits with Includes

One caveat is that include statements count against the total limit of 10 DNS lookups during an SPF check. For example:

v=spf1 include:vendor1.com include:vendor2.net include:vendor3.org -all

Here there are already 3 lookups used, leaving only 7 left. If the vendors also have nested includes, you could hit the lookup limit. Carefully manage includes to avoid crossing the 10 lookup threshold.

Now that you know how to authorize multiple servers, let’s look at…

Merging Multiple Existing SPF Records

Uh oh! If you just discovered that your domain has multiple SPF records, here’s how to cleanly merge them into one valid policy.

Steps for Consolidating Records into One

If two SPF records exist like:

v=spf1 include:spf1.server.com -all
v=spf1 include:spf2.server.com -all

You need to merge them into a single record:

v=spf1 include:spf1.server.com include:spf2.server.com -all

The process is:

  1. Login to your domain registrar or DNS host
  2. Navigate to the TXT record management for your domain
  3. Create a new TXT record with the merged “v=spf1” value
  4. Delete the original duplicate SPF records
  5. Save the changes

And you’re done! This consolidated record is now valid and avoids SPF PermError results.

Waiting for DNS Changes to Propagate

After making SPF record changes, allow some time for the DNS changes to propagate across the internet. This usually takes under an hour, but can be up to 48 hours.

Until propagation completes, some mail servers will still see the old records and may apply incorrect SPF results. Be patient for the TTL expiry.

Verifying Records after Making Changes

Once suitable time has passed, double check that only your new merged SPF record is visible. Use an online SPF record checker tool and confirm no errors are reported.

You can also fetch TXT records directly using dig for verification:

$ dig txt example.com

;; ANSWER SECTION:
example.com.  3600    IN    TXT "v=spf1 [...merged record...] ~all"

With that, you’ve successfully consolidated multiple SPF records! Up next we’ll explore…

SPF Records for Common Email Providers and Services

When setting up SPF, you’ll likely need to include records from any external email services and providers you use. Here are some examples and tips.

SPF Syntax for Popular Email Apps and Tools

Many common email services publish SPF records you can include. Here are some examples:

Google Workspace:
  include:_spf.google.com

Microsoft 365:
  include:spf.protection.outlook.com

Amazon SES:
  include:amazonses.com

Mailgun:
  include:mailgun.org

SendGrid
  include:sendgrid.net

For others, check the provider’s documentation for their exact SPF syntax.

Special Considerations for Major Providers

When including major email providers, keep these tips in mind:

Google – Only include Google’s _spf.google.com record. Do not include the naked google.com domain, as this can cause issues.

Microsoft – Use Microsoft’s full spf.protection.outlook.com subdomain, not just outlook.com to avoid authentication problems.

Amazon SES – Note Amazon SES requires both its amazonses.com include and your dedicated IP address ranges.

SendGrid – SendGrid uses multiple domains in its record, so make sure to use their exact include:sendgrid.net syntax.

Rackspace – Rackspace hosts your domain’s DNS separately from email, so you may need to specify IP ranges manually instead of using its include.

In summary, always verify the exact include syntax from your providers’ documentation, and watch for any gotchas with the major ones above.

Now that we’ve covered the basics of SPF syntax, let’s look at…

Tools and Best Practices for Managing SPF

Properly configuring and maintaining SPF records requires using the right tools. Here are some options for SPF management:

Online SPF Record Generators and Checkers

The easiest way to validate your SPF syntax is to use online tools:

  • SPF record generators – These create properly formatted SPF records that you can simply copy-paste into your DNS records.
  • SPF record checkers – These analyze your current SPF record to check for issues. They identify problems like multiple records, syntax errors, or lookup limits.

One of the popular option to check SPF record is MXToolBox.

Using Command Line Tools to Validate Records

You can also use command line tools like dig and nslookup to fetch and inspect SPF records.

For example, dig txt example.com will retrieve all TXT records for a domain. Inspect the output for multiple “v=spf1” entries.

The nslookup -q=txt command offers similar SPF inspection capabilities on Windows and Linux systems.

Tips for Monitoring and Maintaining SPF Configs

Here are some tips for staying on top of your SPF records:

  • Check records after service changes – Verify your SPF syntax if you switch email providers or IP addresses.
  • Monitor records with DNS tooling – Use monitoring tools like DNS Spy to automatically alert on record changes.
  • Review authentication logs – Check mail server logs regularly for SPF failures or warnings.
  • Consolidate records if issues emerge – If deliverability problems emerge, double check you don’t have multiple SPF records.

Keeping your SPF tight and maintained takes work, but pays dividends through improved email deliverability and protection against abuse.

Now let’s look at some common issues and how to resolve them…

Troubleshooting Common SPF Record Errors

Even with proper SPF syntax, misconfigurations can lead to authentication failures. Here are some troubleshooting tips for common SPF issues:

Debugging PermError and Other Authentication Failures

A PermError occurs when your domain has multiple SPF records. Follow these steps:

  1. Use an SPF record checker tool to identify multiple records.
  2. Login to your DNS management console and merge the records as covered earlier.
  3. Re-check your record after DNS propagation to confirm the fix.

For other failures like TemporaryError or SoftFail, review your SPF syntax, check for typos, and confirm any included records are valid.

Handling Problems Caused by Typos or Syntax Issues

With SPF, a single typo can break your entire policy. Some things to verify:

  • The record starts with v=spf1 – This prefix is mandatory.
  • IPs and domain names are valid – Double check for typos or omissions.
  • Modifiers like -all are at the end – These must come last in your record.
  • Overall length is under 255 chars – Long records may get truncated.

Fixing Problems from Record Changes or Removals

If deliverability suddenly decreases, a change to your SPF record may be the culprit:

  • Verify no records were accidentally altered or deleted recently.
  • Check that services you include haven’t changed their own SPF syntax.
  • Use SPF logging on your mail server to compare recent authentication results with past ones.
  • Consider setting up monitoring to alert if your SPF record ever changes.

With attention to detail, you can quickly resolve most SPF issues. Just take it step-by-step.

Now that we’ve covered troubleshooting, let’s wrap up with…

Key Takeaways

SPF records are a foundational email security mechanism that every domain should utilize. Here are the key takeaways:

  • SPF prevents unauthorized use of your domain by listing approved sending servers. Emails from unverified sources will fail the SPF check.
  • Only one SPF record is allowed per domain. Multiple SPF records will break authentication with a PermError.
  • The single SPF record can authorize multiple servers by including their IP addresses, domain names, or other SPF records.
  • When including major email providers, always use their exact recommended syntax to avoid issues.
  • Validate your SPF record using online tools and command line utilities like dig. Monitor it for changes.
  • Watch out for typos, syntax errors, alterations to included records, and DNS misconfigurations as potential sources of SPF problems.
  • Consolidate multiple SPF records by merging all their mechanisms into one unified policy.

With a properly configured SPF record, you can stop spammers from sending fake emails pretending to be your domain. Implement SPF to improve your deliverability, avoid the spam folder, and ensure your From address is trusted.

Frequently Asked Questions

Q: Can I have multiple SPF records for subdomains?

A: No, each domain or subdomain can only have one SPF record. So your root domain and subdomains like mail.yourdomain.com need separate SPF records.

Q: What’s the difference between -all and ~all?

A: -all will fail the SPF check for unauthorized servers while ~all will softly fail. -all is safer but may cause some legitimate emails to be flagged.

Q: Do I need SPF records for domains I don’t send email from?

A: No. SPF is only needed for domains used in your email envelopes’ “From” addresses that recipients see.

Q: What happens if I exceed the 10 DNS lookup limit for SPF?

A: Your SPF record will fail with a PermError and none of your mechanisms will be applied. Trim down your total lookups.

Q: Can I include multiple service providers in my SPF record?

A: Yes, you can include multiple 3rd parties like Google and Amazon SES as long as you stay under the lookup limit.

Q: How quickly do SPF record changes take effect?

A: It depends on the TTL for your DNS records, but typically between a few minutes to 48 hours for the changes to fully propagate.

Q: What’s the maximum length of an SPF record?

A: SPF records can be up to 255 characters long. Anything longer may get truncated by certain DNS servers.

Q: Do I need to update SPF if I switch web hosts or email providers?

A: Most likely, yes. New services will use different IP ranges that need to be authorized in your SPF record.

Hopefully these answers help clarify some common questions around SPF records and multi-domain setups!