When managing your domain's email sending permissions, you'll often need to authorize third-party services to send emails on your behalf. The Sender Policy Framework (SPF) has a specific mechanism designed for this purpose. The short answer is that the include mechanism is what you use to refer to another domain's SPF record.
This mechanism is a fundamental part of SPF, allowing you to incorporate SPF rules from other domains into your own. It's how you tell receiving mail servers, "In addition to my own sending servers, also trust the servers listed in the SPF record of this other domain."
How the 'include' mechanism works
The include mechanism is one of several types of mechanisms you can use in an SPF record. As Kinsta explains, these mechanisms describe which hosts are designated as authorized senders. When a receiving email server evaluates your SPF record, it checks each mechanism in order.
When the server encounters an include statement, such as include:_spf.google.com, it performs a new DNS lookup for the SPF record at _spf.google.com. It then evaluates that record. If the sending IP address matches a rule in the included record, the SPF check passes. If it doesn't match, the evaluation continues with the next mechanism in your original record.
For example, a typical SPF record for a business using Google Workspace and another third-party email service might look like this:
v=spf1 include:_spf.google.com include:sendingservice.com ~all
In this case, you are authorizing servers defined in Google's SPF record and servers defined in the sending service's record.
The 'redirect' modifier: a related concept
It's also worth mentioning the redirect modifier. While it also points to another domain's SPF record, it functions very differently from include. A redirect essentially delegates your domain's entire SPF authentication to another domain. If a redirect is present, any other mechanisms in your record are ignored.
A record using redirect looks like this: v=spf1 redirect=example.com. This tells receiving servers to use the SPF record at example.com as the sole authority for your domain. You can't have both include and redirect in the same record. You use include to add sources and redirect to replace them entirely.
The critical 10 DNS lookup limit
The most important consideration when using include is the hard limit of 10 DNS lookups per SPF check. Each include mechanism adds one lookup to the count. Other mechanisms like a, mx, ptr, exists, and the redirect modifier also count towards this limit. Crucially, any lookups within an included record also count toward your total.
If your SPF record requires more than 10 DNS lookups to resolve, it will return a permanent error (PermError). This will cause your SPF check to fail, potentially damaging your email deliverability. To manage this, you should follow a few best practices:
- Audit regularly: Check your SPF record periodically to remove any include statements for services you no longer use.
- Be wary of nested lookups: Be aware that an included SPF record might itself contain more includes, which can quickly exhaust your lookup limit.
- Avoid redundancy: When combining records, ensure you don't repeat any mechanisms. Each include should only appear once.
- Use IP addresses directly: If a third-party service provides a static IP address, using the ip4 or ip6 mechanism instead of include does not consume a DNS lookup.
In summary, the include mechanism is the standard way to refer to and authorize other domains' SPF records. It's an essential tool for managing a modern email infrastructure, but it must be used carefully to stay within the 10 DNS lookup limit and ensure your emails are authenticated correctly.
What is the maximum number of DNS lookups allowed in an SPF record?
What does a '~all' mechanism in SPF signify?
What SPF mechanism allows for IP addresses?
What DNS record type is used for SPF?
Does the 'all' mechanism in SPF always mean a hard fail?
Can an SPF record contain multiple 'v=spf1' declarations?
