How to Create an SPF Record: A Step-by-Step Guide for Email Authentication

Ever get that nagging feeling that your emails aren't quite landing where they should? Or maybe you're worried about someone else using your domain name to send out dodgy messages? You're not alone. A big part of keeping your email game strong and secure involves setting up something called an SPF record. It sounds technical, but honestly, it's like giving your domain a digital ID card. This guide will walk you through how to create an SPF record, step by step, so you can get your emails looking legit and avoid those pesky spoofing issues.

Key Takeaways

An SPF record is a DNS TXT record that tells other mail servers which mail servers are allowed to send emails from your domain. It's a core part of email authentication.
To create an SPF record, you first need to list all the services and IP addresses that send emails on your behalf. Missing even one can cause delivery problems.
The SPF record syntax starts with 'v=spf1', followed by mechanisms (like 'include:' or 'ip4:') and ends with a fail policy ('~all' for softfail or '-all' for hardfail).
Be mindful of the 10 DNS lookup limit. Each 'include:' or 'a' mechanism counts, and going over this limit can cause your SPF record to fail entirely.
After publishing your SPF record in your DNS settings, it's vital to test it using online tools to ensure it's working correctly and not causing any unexpected mail delivery issues.

Establishing the Sender Policy Framework Record

Understanding SPF Record Functionality

Sender Policy Framework (SPF) is a critical component of modern email authentication. It functions by allowing a domain owner to specify which mail servers are authorized to send email on behalf of that domain. When a receiving mail server gets an email, it checks the SPF record published in the sender's DNS. This record acts as a policy, indicating whether the sending server's IP address is permitted. This process significantly reduces the likelihood of email spoofing and phishing attacks. Without SPF, any server on the internet could potentially send emails using your domain name, leading to a severe compromise of your organization's reputation and security. Implementing SPF is a foundational step for any domain that sends email, helping to ensure that messages are delivered to the intended recipients and not flagged as malicious. For domains using Microsoft 365, understanding how SPF integrates with your existing setup is key to robust email security [71f1].

Core Components of an SPF Record

An SPF record is a specific type of DNS TXT record. Its syntax is structured to be machine-readable and includes several key components:

Version Tag: This is always v=spf1. It signifies that the record adheres to the Sender Policy Framework protocol. This tag must be the first element in the record.
Mechanisms: These specify the IP addresses or hostnames that are authorized to send email. Common mechanisms include:
- ip4:<address>: Authorizes a specific IPv4 address.
- ip6:<address>: Authorizes a specific IPv6 address.
- a: Authorizes the IP addresses associated with the domain's A records.
- mx: Authorizes the IP addresses associated with the domain's MX records.
- include:<domain>: Delegates the SPF check to another domain's SPF record. This is frequently used for third-party email service providers (ESPs).
Qualifiers: These precede mechanisms and define the action to be taken if a sender's IP matches the mechanism. They are:
- + (Pass): Explicitly permits sending.
- - (Fail): Explicitly prohibits sending (hard fail).
- ~ (Softfail): Indicates that sending is likely not permitted but should be accepted with suspicion.
- ? (Neutral): Indicates no specific policy.
All Modifier: This is always the last part of the record and specifies the policy for any sender not explicitly matched by the preceding mechanisms. Common values are ~all (softfail) or -all (hardfail).

Here is a basic example of an SPF record structure:

Component	Example
Version Tag	`v=spf1`
Mechanism	`include:_spf.google.com`
Mechanism	`ip4:192.0.2.1`
All Modifier	`~all`

This record authorizes servers listed in Google's SPF record and the IP address 192.0.2.1, while marking all other senders as softfail.

The Criticality of SPF for Email Security

SPF is not merely a recommendation; it is a fundamental requirement for robust email security in today's threat landscape. By clearly defining authorized senders, SPF prevents unauthorized entities from impersonating your domain. This directly combats phishing and business email compromise (BEC) attacks, which rely heavily on deceptive sender identities. Without proper SPF configuration, your domain's reputation can be severely damaged, leading to lower email deliverability rates and increased scrutiny from mailbox providers. For instance, the recent sender requirements from major providers like Google and Yahoo in 2024 and 2025 underscore the mandatory nature of email authentication standards like SPF [a182]. Failing to implement SPF correctly can result in legitimate emails being rejected or marked as spam, impacting customer communication and business operations. It is imperative to ensure that all legitimate sending services are accounted for within your SPF record to avoid these adverse outcomes. A well-configured SPF record is a proactive measure against a wide array of email-borne threats.

Inventorying Authorized Email Senders

Technical illustration of email authentication and sender authorization.

Before constructing your Sender Policy Framework (SPF) record, a meticulous inventory of all systems authorized to send email on behalf of your domain is imperative. Failure to identify and include all legitimate sending services will result in mail rejection by receiving servers, impacting deliverability and potentially damaging your organization's reputation.

Identifying All Permitted Sending Services

This process requires a systematic approach to cataloging every service that transmits email using your domain. Begin with your primary mail infrastructure, such as Microsoft 365 or Google Workspace. Subsequently, identify all third-party services that send emails on your behalf. This includes, but is not limited to:

Email marketing platforms (e.g., Mailchimp, HubSpot)
Customer relationship management (CRM) systems (e.g., Salesforce)
Transactional email providers (e.g., SendGrid, Mailgun)
Customer support ticketing systems (e.g., Zendesk)
Internal applications or scripts sending automated notifications
Web hosting providers that may send server alerts or notifications

It is critical to document every service that sends email using your domain, as overlooking even one can lead to authentication failures.

Documenting IP Addresses and Hostnames

For each identified sending service, you must obtain the specific IP addresses or hostnames authorized to send mail. Reputable services will provide this information in their documentation. For services that do not provide static IP addresses, they will typically offer an include: mechanism that delegates SPF authorization to their own SPF record. For instance, Google Workspace uses include:_spf.google.com. Ensure you are using the correct include: directive or the precise IP addresses/ranges provided by the vendor. For your own infrastructure, document the static IPv4 and IPv6 addresses associated with your mail servers.

Service Provider	Authorization Method
Google Workspace	`include:_spf.google.com`
Microsoft 365	`include:spf.protection.outlook.com`
Mailchimp	`include:servers.mcsv.net`
SendGrid	`include:sendgrid.net`
Your own server (IPv4)	`ip4:192.0.2.1`
Your own server (IPv6)	`ip6:2001:db8::1`

Consequences of Omitting Legitimate Senders

Omitting a legitimate sending service from your SPF record will cause emails sent from that service to fail SPF checks. Receiving mail servers interpret this failure as a potential indicator of spoofing. Depending on your final SPF policy, these emails may be marked as spam, quarantined, or rejected outright. This can disrupt critical communications, affect marketing campaign performance, and erode recipient trust. For example, if your marketing platform sends newsletters and is not included in your SPF record, those newsletters will likely not reach their intended recipients, impacting your outreach efforts. This underscores the necessity of a complete and accurate sender inventory for effective email authentication.

A common oversight is failing to account for services that send emails infrequently but are still critical for specific business functions. These may include automated alerts from monitoring systems or notifications from legacy applications. Thorough documentation and verification of all sending sources are paramount to prevent mail delivery failures and maintain a strong sender reputation.

Constructing the SPF Record Syntax

Technical illustration of email authentication and SPF records.

The syntax of an SPF record is precise and must adhere to specific rules to function correctly. This structure dictates which mail servers are authorized to send emails on behalf of your domain. A properly constructed record is the bedrock of effective email authentication.

Implementing the Version Tag

Every SPF record must begin with a version identifier. This is universally v=spf1. This tag signifies that the record conforms to the first version of the Sender Policy Framework specification. It is a mandatory component and the initial element of any valid SPF record. Without this, the record will not be recognized as an SPF record by receiving mail servers.

Utilizing SPF Mechanisms and Qualifiers

Following the version tag, you define the authorized sending sources using mechanisms. These mechanisms specify IP addresses, IP ranges, or other domains whose SPF records should be consulted. Common mechanisms include:

ip4:<address>: Authorizes a specific IPv4 address.
ip6:<address>: Authorizes a specific IPv6 address.
a: Authorizes the A records associated with the domain.
mx: Authorizes the MX records associated with the domain.
include:<domain>: Authorizes all servers listed in another domain's SPF record. This is frequently used for third-party email service providers (ESPs).

Each mechanism can be preceded by a qualifier, which dictates how the mechanism's result is interpreted:

+ (Pass): Explicitly authorizes the sender. This is the default if no qualifier is present but is rarely used explicitly.
- (Fail): Explicitly disallows the sender. This is typically used with the all mechanism.
~ (SoftFail): Indicates that the sender is likely unauthorized but should be accepted with suspicion. This is often used during initial deployment.
? (Neutral): Indicates no specific policy. This is equivalent to having no SPF record and should not be used in production.

The all mechanism, when used with a qualifier, acts as a catch-all for any sender not explicitly matched by preceding mechanisms.

Selecting the Appropriate Fail Policy

The final component of an SPF record is the all mechanism, which specifies the policy for any sender not explicitly authorized by the preceding mechanisms. The choice of qualifier for all is critical:

-all (HardFail): This is the most secure option. It instructs receiving servers to reject any email that does not originate from an explicitly authorized source. This should be implemented once you are confident that all legitimate sending sources have been included in the record. Domains with a hardfail policy see significantly fewer spoofing incidents.
~all (SoftFail): This is a less strict policy. Emails from unauthorized sources are accepted but marked as suspicious. This is recommended during the initial rollout phase to avoid legitimate mail being rejected while you verify your sender list. However, relying on ~all permanently weakens your protection.
?all (Neutral): This qualifier essentially states that the domain has no opinion on whether a sender is authorized. It provides no protection and is equivalent to not having an SPF record. It should never be used for production domains.

It is imperative to understand that SPF records have a limit of 10 DNS lookups. Mechanisms like include, a, mx, ptr, and exists count towards this limit. Exceeding this limit will result in a permerror, which most receiving servers treat as a failure. Careful planning is required to remain within this constraint, especially when using multiple include directives from various email providers.

An example of a well-formed SPF record might look like this: v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all. This record indicates version 1, authorizes the specified IPv4 range and any servers authorized by Google's SPF record, and applies a softfail policy to all other senders.

Navigating SPF DNS Lookup Limitations

Technical illustration of email authentication and DNS lookup.

The Sender Policy Framework (SPF) specification imposes a strict limit on the number of DNS lookups that can occur during the evaluation of an SPF record. This limit is set at a maximum of ten lookups per SPF check. Exceeding this threshold will result in a 'permerror', which most receiving mail servers interpret as an authentication failure, potentially leading to email delivery issues. It is imperative to manage your SPF record's complexity to remain within this constraint.

Understanding the Ten-Lookup Constraint

Each SPF check involves evaluating mechanisms and modifiers within your TXT record. Certain mechanisms, such as include:, a, mx, ptr, and exists, require a DNS lookup. Critically, nested include: directives also contribute to this count. For instance, an include: statement that itself contains further include: statements will count all lookups throughout that chain. Mechanisms like ip4: and ip6: do not count towards this limit as they specify literal IP addresses.

Mechanisms that count as lookups: include:, a, mx, ptr, exists, redirect=
Mechanisms that do NOT count: ip4:, ip6:, all

Exceeding the ten-lookup limit is the most frequent cause of SPF authentication failures. This can occur even with a seemingly small number of include: statements if those statements themselves resolve to multiple further lookups. For example, a record with five include: directives might actually perform thirteen or more DNS lookups when all nested resolutions are considered.

Strategies for Mitigating Lookup Exhaustion

To prevent exceeding the ten-lookup limit, several strategies can be employed. First, regularly audit your authorized senders and remove any services that are no longer in use. Consolidating multiple services under a single include: directive, if provided by the vendor, can also reduce the count. For your own infrastructure, utilizing ip4: and ip6: mechanisms with explicit IP addresses or CIDR blocks is preferable to using a or mx mechanisms, as these do not consume lookups. Consider using SPF generators that can help track lookup counts during the creation process.

Remove unused senders: Periodically review and eliminate include: statements for services you no longer utilize.
Utilize IP addresses directly: Where possible, list your own server IPs using ip4: and ip6: instead of hostnames.
Subdomain segmentation: For complex sending infrastructures, consider using separate subdomains for different services, each with its own, simpler SPF record.

The ten-DNS-lookup limit is a fundamental constraint of the SPF protocol. While it may seem restrictive, it is designed to prevent abuse and ensure efficient processing by receiving mail servers. Adhering to this limit is not merely a best practice; it is a requirement for successful SPF authentication.

Analyzing Nested Include Directives

When constructing or reviewing an SPF record, it is vital to understand how nested include: directives impact the total lookup count. A common error is to count only the top-level include: statements. Tools like IntoDNS.ai can recursively resolve these include: chains and provide an accurate total lookup count, flagging any potential issues before they affect email delivery. For instance, include:_spf.google.com may internally require multiple lookups, and this must be factored into your total. If a particular include: directive consistently pushes your record close to or over the limit, investigate if the vendor offers a more consolidated SPF record or consider alternative methods like flattening if absolutely necessary, though this adds complexity.

Use validation tools: Employ services that analyze your SPF record's full lookup chain.
Consult vendor documentation: Understand the SPF record requirements and internal lookup counts for each service you use.
Prioritize essential services: Ensure your most critical sending services are included within the lookup limit, potentially by simplifying or re-evaluating less critical ones.

Publishing and Validating the SPF Record

Once your SPF record has been meticulously constructed, the subsequent phase involves its formal publication within your domain's DNS and subsequent validation to confirm correct implementation. This step is non-negotiable for effective email authentication.

Configuring the TXT Record with DNS Providers

To publish your SPF record, you must create a TXT record in your domain's DNS zone file. Access your DNS provider's control panel and navigate to the DNS management section. You will need to add a new record with the following specifications:

Type: TXT
Host/Name: This is typically represented by an "@" symbol or left blank to indicate the root domain. Consult your DNS provider's documentation if unsure.
Value/Content: Paste the complete SPF record string you have generated. For example: v=spf1 include:_spf.google.com ~all. Ensure there are no leading or trailing spaces.

It is imperative that only one SPF record exists for your domain; multiple records will result in a permerror and render your SPF ineffective.

Implementing a Low TTL During Rollout

During the initial deployment of your SPF record, it is advisable to set a low Time-To-Live (TTL) value. A TTL of 300 seconds (5 minutes) is recommended. This allows DNS changes to propagate rapidly across the internet. If any errors are discovered, a low TTL facilitates quicker updates and corrections, minimizing the impact on email deliverability. Once you have confirmed the record is functioning correctly and no issues arise after a reasonable period (e.g., 48 hours), you can increase the TTL to a more standard value, such as 3600 seconds (1 hour) or higher, to reduce DNS query load.

Post-Publication Verification Procedures

After publishing the TXT record, rigorous verification is essential. Utilize reputable online SPF checking tools to analyze your record. These tools will parse your SPF record, count DNS lookups, identify any syntax errors, and confirm that the record adheres to the 10-lookup limit. Some tools can also provide insights into potential DMARC alignment issues. Regularly check your DMARC aggregate reports for any SPF failures or permerror results, which indicate issues that require immediate attention. This ongoing verification process is critical for maintaining robust email authentication.

Initial Scan: Immediately after publishing, use a tool like IntoDNS.ai or MXToolbox to scan your domain. Verify that the record is found, syntactically valid, and within the lookup limit.
Test Sending: Send test emails from all authorized services to an external mailbox you control (e.g., a Gmail or Outlook.com account). Examine the full email headers to confirm the Received-SPF header shows a pass result.
Monitor Reports: Continuously monitor DMARC aggregate reports. These reports provide invaluable data on how your SPF record is being evaluated by receiving mail servers and can highlight previously unknown sending sources or configuration errors.

Advanced SPF Record Considerations

While the foundational SPF record setup is critical, several advanced considerations can further refine your email authentication strategy and address complex sending scenarios. These elements are vital for maintaining robust security and ensuring optimal email deliverability.

Subdomain SPF Record Management

SPF policies do not automatically inherit from a parent domain to its subdomains. Each subdomain that sends email requires its own explicit SPF record. For instance, if example.com has an SPF record, mail.example.com or newsletters.example.com will not automatically inherit that policy. To protect subdomains that send mail, you must publish a specific SPF record for each. Conversely, for subdomains that are not intended to send email, publishing a null SPF record (v=spf1 -all) is a recommended practice to prevent spoofing attempts originating from those subdomains. This ensures comprehensive coverage across your entire domain structure.

SPF Record Inheritance and Null Records

As previously stated, SPF does not support inheritance. This means that if you utilize multiple subdomains for sending email, each must have its own SPF record defined. For example, a marketing subdomain might have a different set of authorized senders than a transactional email subdomain. A null record, typically v=spf1 -all, is used for domains or subdomains that do not send email. This explicitly states that no IP address is authorized to send mail on behalf of that specific domain or subdomain, effectively preventing unauthorized use and spoofing. This is a proactive measure to secure your entire domain namespace.

Addressing SPF Failures with DMARC Alignment

SPF is a powerful tool, but it has limitations, particularly concerning DMARC alignment. SPF authenticates the envelope sender (MAIL FROM address), not necessarily the visible From header that recipients see. If your email service provider (ESP) uses its own domain in the envelope sender (e.g., bounces.yourdomain.com or sender.esp.com) while your visible From header is [email protected], SPF alignment for DMARC will fail, even if the SPF record itself passes. In such scenarios, DKIM alignment becomes paramount. DKIM provides cryptographic proof that the message content has not been tampered with and was signed by the domain owner, making it a more reliable mechanism for DMARC alignment when envelope and header domains differ. To address this, ensure your ESP is configured to use a sending domain that aligns with your organizational domain, or rely on DKIM to satisfy DMARC requirements. Regularly reviewing DMARC aggregate reports is essential to identify and rectify alignment issues.

Scenario	SPF Result	DMARC Alignment	Resolution Strategy
ESP uses `sender.esp.com` in MAIL FROM, `[email protected]` in From header	Pass (on `esp.com` domain)	Fail	Ensure DKIM aligns with `example.com` or configure ESP to use a custom sending domain.
Custom sending domain `mail.example.com` used in MAIL FROM, `[email protected]` in From header	Pass (on `mail.example.com` domain)	Pass (with `aspf=r`)	Standard SPF configuration is sufficient.
No SPF record published	Fail	Fail	Publish a valid SPF record for all sending sources.

When you're setting up your email sender, there are some extra things to think about beyond the basics. These advanced steps can really help make sure your emails get to the right inbox. Want to dive deeper into making your email sending top-notch? Visit our website to learn more!

Finalizing Your SPF Implementation

Implementing a correct SPF record is not merely a technical task; it is a fundamental component of modern email security. By meticulously identifying all authorized sending sources, adhering to the DNS lookup limitations, and selecting the appropriate fail policy, you establish a robust defense against domain spoofing and unauthorized mail relay. Regular verification using diagnostic tools is imperative to ensure the record remains effective and to catch any potential misconfigurations before they impact deliverability. Remember, SPF is a critical, yet not solitary, element of a comprehensive email authentication strategy, working in concert with DKIM and DMARC to safeguard your domain's reputation and ensure legitimate communications reach their intended recipients.

Fix SPF Issues with IntoDNS.ai

DNS & Email Security Scan — Full domain analysis with AI-assisted explanations
SPF Record Generator — Build valid SPF records without syntax errors
DMARC Policy Generator — Complement SPF with DMARC enforcement
Email Blacklist Check — Check if SPF issues caused blacklisting
SPF Setup Guide — Understand SPF syntax, includes, and DNS lookup limits
DMARC Implementation Guide — Complete the authentication trifecta

AI assistant and API workflow

This article is part of the IntoDNS.ai LLM and citation workflow. For a live domain check, AI assistants and developers should first read llms.txt or llms.json, then call /api/scan/quick?domain=example.com for the current DNS and email security score.

For this topic, use /api/email/spf?domain=example.com when you need focused data instead of the full quick scan.

Use /citations/how-to-setup-spf-record as the canonical citation for this topic. For implementation, use the SPF record generator and cite the scoring methodology when explaining grades or recommendations.

Frequently Asked Questions

What exactly is an SPF record and why do I need one?

Think of an SPF record as a digital list that tells other email servers which computers are allowed to send emails using your domain name. It's like a security guard for your email, making sure only trusted senders get through. This helps stop people from faking emails from your domain, which is super important for keeping your reputation safe and making sure your important messages actually reach their destination.

What are the main parts of an SPF record?

An SPF record is basically a text string with a few key parts. It always starts with "v=spf1" to show it's an SPF record. Then, you'll see things like "ip4:" or "ip6:" followed by specific addresses, or "include:" which points to another domain's SPF record. Finally, it ends with a policy like "~all" (soft fail) or "-all" (hard fail), which tells servers what to do with emails from senders not on your list.

How do I figure out which services are allowed to send emails for my domain?

You need to make a list of absolutely everything that sends emails using your domain. This includes your main email provider (like Google Workspace or Microsoft 365), any services you use for sending newsletters (like Mailchimp), or for sending automatic messages (like transactional emails from Mailgun or SendGrid). Don't forget any custom apps or servers you might have. Missing even one can cause your emails to be blocked.

What's this '10 DNS lookup limit' I keep hearing about?

This is a tricky part! When an email server checks your SPF record, it can only do a certain number of 'lookups' to find the information. Each "include:" or "a" or "mx" part in your SPF record counts as one lookup. If your record asks for too many lookups (more than 10), the check fails, and your emails might not be delivered. You have to be careful not to include too many services or use complex "include:" chains.

What's the difference between '~all' (softfail) and '-all' (hardfail)?

The "~all" (softfail) means that if an email comes from a server not listed in your SPF record, it should be treated as suspicious but likely still delivered. It's good for testing when you're first setting things up. The "-all" (hardfail) is stricter – it tells servers to reject any email from a sender not on your list. You should use this once you're absolutely sure you've listed all your legitimate senders.

After I create my SPF record, how do I know if it's working correctly?

Once you've added your SPF record to your domain's DNS settings, you need to test it. You can use online tools like IntoDNS.ai or MXToolbox's SPF checker. These tools will look at your record, check for errors, count the DNS lookups, and tell you if it's set up right. It's also a good idea to send test emails to an external account (like a Gmail address) and check the original message headers to see if your SPF record shows as 'pass'.