What SPF Should You Use? - aViewFromTheCave

In today’s interconnected digital landscape, email remains a critical communication channel for businesses, individuals, and organizations. However, the open nature of email also makes it a prime target for malicious actors seeking to exploit vulnerabilities for phishing, spamming, and spreading malware. Ensuring the legitimacy and trustworthiness of your outgoing emails is paramount, not only for effective communication but also for maintaining your sender reputation and preventing your messages from being flagged as spam. This is where Sender Policy Framework (SPF) enters the picture – a foundational technology in the ongoing battle for secure and reliable email delivery.

SPF is an email authentication method designed to detect forging sender addresses during email transmission. It works by allowing domain owners to specify which mail servers are authorized to send email on behalf of their domain. When an email arrives at a recipient’s server, that server can query the sender’s domain’s DNS records to check if the sending server’s IP address is listed as an authorized sender. If it’s not, the email can be rejected, quarantined, or marked as suspicious, thereby significantly reducing the chances of your legitimate emails being lost in spam filters and preventing others from impersonating your domain.

The “what SPF should you use” question, therefore, isn’t about personal preference but rather about understanding the technical intricacies of SPF record configuration to best protect your domain’s email reputation and security. This involves understanding the different SPF mechanisms, qualifiers, and best practices for creating a robust and effective SPF record.

Table of Contents

Understanding SPF Mechanisms and Qualifiers

At its core, an SPF record is a TXT record published in your domain’s Domain Name System (DNS). This record contains a series of mechanisms and qualifiers that define the rules for email authentication. Understanding these components is the first step to crafting an effective SPF policy.

SPF Mechanisms: The Building Blocks of Your Policy

Mechanisms are the core directives within an SPF record. They specify the conditions under which an IP address is considered authorized to send email for your domain. The most common SPF mechanisms include:

a: This mechanism matches if the “a” record (Address record) of the domain name in the mechanism matches the IP address of the sending server. For example, a:example.com would match if the sending server’s IP address is listed in the A record for example.com. If no domain is specified, it refers to the domain itself.
mx: This mechanism matches if the IP address of the sending server is one of the mail exchange (MX) servers for the domain specified. For example, mx:example.com would match if the sending server is an MX server for example.com. Again, if no domain is specified, it refers to the domain itself. This is a very common mechanism as it authorizes all your mail servers to send email.
ip4 and ip6: These mechanisms allow you to explicitly list IPv4 and IPv6 addresses or CIDR blocks of IP addresses that are authorized to send email for your domain. For example, ip4:192.168.1.1 or ip6:2001:db8::/32. This is useful for specifying dedicated mail servers or specific IP ranges used by third-party email providers.
include: This mechanism allows you to incorporate the SPF record of another domain into your own. This is incredibly useful when you use third-party services for sending emails, such as email marketing platforms (e.g., Mailchimp, SendGrid) or transactional email services. For example, include:spf.protection.outlook.com tells the recipient server to check the SPF record of spf.protection.outlook.com and consider any IPs listed there as authorized. This avoids the need to list out all the IPs provided by a service, which can change frequently.
exists: This mechanism checks for the existence of an A record for a given hostname. It’s less commonly used than the others for general SPF setup but can be useful in specific scenarios.

SPF Qualifiers: Defining the Action

Qualifiers are prefixes attached to mechanisms that specify how a match (or mismatch) should be interpreted. They define the action the recipient server should take. There are four types of qualifiers:

+ (Pass): This is the default qualifier and signifies that the sender is authorized. If a mechanism with a + qualifier matches, the email passes the SPF check. For example, +mx is equivalent to mx.
- (Fail): This signifies that the sender is not authorized. If a mechanism with a - qualifier matches, the recipient server should reject the email or mark it as spam. This is the most important qualifier for ensuring security. An SPF record should ideally conclude with a -all mechanism.
~ (SoftFail): This signifies that the sender is likely not authorized, but the recipient server should still accept the email and potentially mark it as suspicious. This is often used during SPF record migration or when you’re unsure about all your sending sources. It’s a less strict approach than Fail.
? (Neutral): This signifies that the SPF record provides no information about whether the sender is authorized or not. The recipient server should treat the email as if no SPF record was found. This is rarely used in practice for finalized SPF records.

Designing Your SPF Record: Best Practices and Considerations

Crafting an effective SPF record involves more than just listing your known sending servers. It requires a strategic approach to cover all legitimate sending sources while preventing unauthorized use, and adhering to certain technical limitations.

Identifying All Legitimate Sending Sources

The first and most crucial step is to comprehensively identify every server and service that sends email on behalf of your domain. This often involves a thorough audit of your IT infrastructure and any third-party services you utilize. Common sources include:

Your primary mail servers: This could be your on-premises Exchange server, a cloud-hosted email service like Microsoft 365 or Google Workspace, or a dedicated mail server.
Email marketing platforms: Services like Mailchimp, Constant Contact, HubSpot, SendGrid, Amazon SES, etc.
Transactional email services: For sending automated notifications, receipts, or password resets.
Customer Relationship Management (CRM) systems: Some CRMs have integrated email sending capabilities.
Web servers: If your website sends emails (e.g., contact forms, order confirmations).
Third-party applications: Any other software or service that sends emails using your domain.

For each of these sources, you’ll need to determine the IP addresses or hostnames they use. Many third-party providers will explicitly state in their documentation how to configure SPF for their services, often by providing an include: mechanism.

Structuring Your SPF Record for Maximum Effectiveness

Once you have your list of sending sources, you can begin constructing your SPF record. A common and recommended structure includes:

Start with v=spf1: This is the mandatory version identifier for your SPF record.
Include authorized mail servers: Use mx, a, ip4, ip6, and crucially, include: mechanisms for your known sending sources.
End with a strong qualifier: The most recommended qualifier for the end of your SPF record is -all. This instructs recipient servers to reject any email that doesn’t match any of the mechanisms in your record. For example: v=spf1 mx include:_spf.google.com -all.
Consider ~all during migration: If you are in the process of migrating email systems or are unsure about all your sending sources, using ~all (SoftFail) can be a safer interim step. This allows you to monitor potential legitimate sources that are currently missing from your SPF record without immediately rejecting valid emails. Once you’ve fine-tuned your record, you should transition to -all.

Example of a comprehensive SPF record:

Let’s say you use Microsoft 365 for your primary email, a marketing platform that uses spf.marketingplatform.com, and your website occasionally sends transactional emails from webserver.yourdomain.com.

Your SPF record might look like this:

v=spf1 include:spf.protection.outlook.com include:spf.marketingplatform.com a:webserver.yourdomain.com -all

This record states:

This is an SPF version 1 record.
Emails from Microsoft 365 (which is handled by spf.protection.outlook.com) are authorized.
Emails from your marketing platform are authorized.
Emails originating from the IP address associated with the A record for webserver.yourdomain.com are authorized.
Any other email source is not authorized and should be rejected.

Navigating the SPF Lookup Limit

A critical technical limitation of SPF is the 10 DNS lookup limit. Each mx, a, ptr, exists, and include mechanism in an SPF record counts as a DNS lookup. The ip4 and ip6 mechanisms do not count as lookups themselves, but the process of resolving a hostname in an a or mx mechanism can trigger further lookups.

Exceeding this limit will cause your SPF record to be invalidated, and recipient servers may fail SPF checks for your emails, regardless of whether they are legitimate. This means you need to be mindful of how many include mechanisms you use, as each include directive often translates to multiple lookups on the included domain’s SPF record.

Strategies to manage the lookup limit:

Consolidate your include mechanisms: If you use multiple services from the same provider (e.g., Google Workspace for email and Google Cloud for other services), they might offer a consolidated SPF record.
Avoid unnecessary include directives: Only include services that actually send email on behalf of your domain.
Use ip4 and ip6 where possible: If a service provides a static set of IP addresses, listing them directly can save lookups compared to an include mechanism. However, this requires diligent updating if the IPs change.
Be cautious with complex SPF records: If your SPF record is becoming very long and complex, it’s a good indicator that you might be approaching or exceeding the lookup limit. Use SPF record checker tools to analyze your record’s lookup count.

Implementing and Verifying Your SPF Record

Once you’ve designed your SPF record, the next critical steps are to implement it correctly in your DNS and then verify its effectiveness.

DNS Implementation: Where and How to Add Your Record

SPF records are published as TXT records within your domain’s DNS zone file. The exact method for adding a TXT record varies depending on your DNS hosting provider (e.g., GoDaddy, Cloudflare, Namecheap, your web host). Generally, you will need to log into your DNS management console and:

Navigate to the DNS records section.
Create a new record.
Select “TXT” as the record type.
For the “Host” or “Name” field:
- If it’s for your main domain (e.g., example.com), leave this field blank or enter @.
- If it’s for a subdomain (e.g., mail.example.com), enter the subdomain name.
For the “Value” or “Text” field: Enter your complete SPF record string (e.g., "v=spf1 mx -all"). Ensure it’s enclosed in double quotes.
Set the TTL (Time To Live): This determines how long DNS resolvers cache the record. A lower TTL (e.g., 300 seconds or 5 minutes) can be beneficial during testing, allowing changes to propagate faster. Once verified, you can increase it for better performance.

Important Note: You should only have one SPF record per domain. If you discover you already have an SPF record, you must edit the existing one to incorporate your new mechanisms and qualifiers, rather than creating a duplicate. Multiple SPF records will cause SPF checks to fail.

Verification and Ongoing Monitoring

Implementing the record is only half the battle. You need to ensure it’s working as intended and continues to do so.

DNS Propagation: After adding your SPF record, it can take some time for the changes to propagate across the internet. This can range from a few minutes to 48 hours, depending on DNS caching.
SPF Record Checkers: Numerous online tools can analyze your SPF record, check for syntax errors, and estimate the number of DNS lookups. Popular tools include MXToolbox, Kitterman SPF validator, and EasyDMARC’s SPF checker. These tools are invaluable for diagnosing issues.
Testing with Email Recipients: Send test emails from your domain through all your authorized sending sources to various email providers (Gmail, Outlook.com, Yahoo Mail). Check the email headers of the received messages. Look for the Authentication-Results header, which will indicate the outcome of SPF checks (e.g., spf=pass, spf=fail, spf=softfail).
DMARC Integration: SPF is most powerful when used in conjunction with Domain-based Message Authentication, Reporting, and Conformance (DMARC). DMARC builds upon SPF and DKIM (DomainKeys Identified Mail) to provide a framework for email authentication, reporting, and enforcement. By setting up a DMARC policy, you can instruct recipient servers on what to do with emails that fail SPF and/or DKIM checks (e.g., quarantine or reject them) and receive reports about email authentication activity for your domain. Implementing DMARC is the final, essential step to robustly protect your domain from email spoofing.

By understanding the technical underpinnings of SPF, carefully designing your record, and diligently verifying its implementation, you can significantly enhance the security and deliverability of your domain’s emails, building trust with your recipients and protecting your brand’s reputation in the digital sphere.

aViewFromTheCave is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com. Amazon, the Amazon logo, AmazonSupply, and the AmazonSupply logo are trademarks of Amazon.com, Inc. or its affiliates. As an Amazon Associate we earn affiliate commissions from qualifying purchases.