SPF Records for Subdomains: Configuration Guide
SPF Records for Subdomains: Configuration Guide

SPF records are essential for email authentication, ensuring that only approved servers can send emails for your domain or subdomains. Each subdomain you use for sending emails requires its own SPF record, as they don’t inherit configurations from the main domain. Without proper setup, emails risk being flagged as spam or rejected, harming deliverability.

Key Takeaways:

  • SPF Basics: SPF (Sender Policy Framework) is a DNS TXT record that lists authorized email servers for a domain or subdomain.
  • Why Subdomains Need SPF: Subdomains like marketing.example.com or sales.example.com require separate SPF records to pass authentication checks.
  • Setup Steps:
    1. Access your DNS management console.
    2. Identify all email services (e.g., SendGrid, Google Workspace) used by the subdomain.
    3. Create a TXT record with the format:
      v=spf1 include:<service> -all
    4. Validate the record using tools like MXToolbox.
  • Best Practices:
    • Avoid exceeding the 10 DNS lookup limit.
    • Use -all for stricter security.
    • Regularly audit and update records to reflect changes in email services.

Properly configured SPF records improve email deliverability and protect against spoofing. Validate and monitor your setup to ensure continued effectiveness.

How To Add SPF Record To Domain? – TheEmailToolbox.com

Prerequisites and Planning

Before diving into SPF record configuration, it’s crucial to gather the necessary information and prepare your DNS resources. This ensures smooth authentication and avoids potential delivery issues.

What You Need Before You Start

Step one: Access your DNS management console. Log in to your domain registrar’s control panel – whether it’s GoDaddy, Namecheap, or another provider. Navigate to the DNS settings, which might be labeled as "DNS Management", "DNS Settings", or "Zone File." Make sure you have the credentials to add or modify TXT records.

Confirm that your subdomain is registered and active before attempting to add an SPF record. Without this, your configuration efforts may fail.

Next, collect details about all services sending emails from your subdomain. This includes third-party email service providers (ESPs) like Google Workspace or Microsoft, as well as internal mail servers. For example, Google Workspace requires _spf.google.com, while Microsoft uses spf.protection.outlook.com. Similarly, services like SendGrid or Zendesk have their own specific SPF values, which you can find in their documentation.

To stay organized, document these details in a spreadsheet. Include the service name, the corresponding SPF include mechanism or IP address, and the subdomain(s) associated with each service. This reference will help ensure your SPF record is complete and accurate, avoiding any missed entries that could block legitimate emails.

Plan for DNS propagation time. Once you publish your SPF record, allow up to 48 hours for DNS changes to propagate, though most updates are completed within 24 hours. If you’re making major changes or migrating email services, publish your SPF record well in advance to minimize disruptions. During propagation, some servers may still rely on outdated or missing records, which could temporarily impact email delivery.

Use tools like SPF record generators to create error-free TXT records. These tools guide you through entering the required details and ensure the syntax is correct. After publishing, validate your setup using an SPF record checker to catch any mistakes.

With all this preparation, you’re ready to move on to designing your SPF setup.

Planning Your SPF Setup

Once you’ve gathered the essential resources, it’s time to design your SPF records with precision.

Each subdomain can only have one SPF record. If you’re managing multiple subdomains – such as sales.example.com, support.example.com, and newsletter.example.com – each subdomain needs its own SPF record in its DNS zone. For subdomains using the same services, you can replicate the SPF structure, but each one still requires an individual record. Subdomains that don’t send emails don’t need an SPF record at all.

Document your setup thoroughly. Use a centralized spreadsheet or document to track key details. For each subdomain, record its authorized sending services, the associated SPF mechanisms or IP addresses, and the current SPF record status. For example:

"sales.example.com | Marketing emails | Google Workspace (_spf.google.com), SendGrid (sendgrid.net) | v=spf1 include:_spf.google.com include:sendgrid.net -all | Published: 11/15/2025 | Verified: Yes"

This kind of documentation ensures consistency, avoids duplication, and provides a quick reference for troubleshooting any authentication issues down the road.

Tailor SPF records to the subdomain’s purpose. For example, marketing subdomains might use ESPs like Mailchimp or Constant Contact, while transactional subdomains often rely on Amazon SES or internal mail servers. Customer support subdomains may use helpdesk tools like Zendesk or Freshdesk, each with its own SPF requirements.

Keep in mind that SPF records have limitations. The value field is capped at 512 characters, and only ASCII characters are supported. Additionally, SPF records can’t exceed 10 DNS lookups. To stay within these limits, optimize your record by using the "include" mechanism to group multiple IP addresses under a single reference.

Share your documentation with IT and email administrators so everyone knows which services are authorized for each subdomain. Update the document whenever you add new sending services or modify existing SPF records.

For a more comprehensive approach to email deliverability, tools like MailMonitor (https://mailmonitor.com) can help track inbox placement and sender reputation after implementation.

How to Configure SPF Records for Subdomains

Now that you’ve done the groundwork, it’s time to set up SPF records in your DNS. This involves accessing your DNS management console, creating a TXT record with the correct syntax, and verifying that it works as expected.

Access Your DNS Management Console

Log in to your domain registrar account and navigate to the DNS management section. Whether you’re using platforms like GoDaddy or Namecheap, you’ll need admin credentials to make changes.

Once inside, find where DNS records are listed. This area typically shows existing entries like A, CNAME, MX, and TXT records. Your task will be to add a new TXT record specifically for the subdomain you’re working on.

Take a moment to check the TTL (Time to Live) settings for your records. TTL determines how long it takes for changes to propagate. While the default is often 1 hour (3,600 seconds), you can adjust it. A shorter TTL speeds up updates but increases DNS queries, while a longer TTL reduces server load but delays changes.

Create and Edit the SPF TXT Record

In your DNS console, add a new TXT record. SPF records are always added as TXT entries.

  • Name/Host Field: Enter the subdomain prefix. For example, if the subdomain is mail.example.com, type "mail." The system will append your root domain automatically.
  • Value/Text Field: Enter the SPF record in proper syntax. It starts with v=spf1, followed by authorized sending mechanisms, and ends with a policy qualifier.

Here’s an example for allowing Mailgun to send emails from news.example.com:

v=spf1 include:mailgun.org -all

This tells receiving servers that only Mailgun is authorized to send emails on behalf of this subdomain. Any unauthorized sources will be rejected.

If you’re using multiple services, combine them into a single record. For example, if sales.example.com uses both Google Workspace and SendGrid:

v=spf1 include:_spf.google.com include:sendgrid.net -all

For specific IP addresses, use ip4 or ip6 mechanisms. For instance:

v=spf1 mx ip4:111.13.109.12 include:_spf.google.com -all

This record authorizes your MX servers, a specific IPv4 address, and Google Workspace. You can add more mechanisms as needed, but ensure the syntax is correct. Mistakes like extra spaces, misspelled domains, or multiple SPF records for the same subdomain can cause errors. Remember: only one SPF record is allowed per subdomain – having more will result in a PermError.

Keep the record under 512 characters and within the 10 DNS lookup limit. Each include counts as a lookup, and some services may add extra lookups. If you exceed the limit, receiving servers might reject your emails. Consolidate entries or remove unnecessary mechanisms if needed.

Finally, set the TTL value. The default of 1 hour (3,600 seconds) works for most setups, but you can increase it to 24 hours (86,400 seconds) for stability.

Once the record is ready, save and publish it.

Publish and Validate Your SPF Record

After saving your changes, DNS propagation begins. This process can take anywhere from a few minutes to 48 hours. Wait at least an hour before validating to allow servers to update.

Use tools like MXToolbox or MailMonitor to check your SPF record. Enter your subdomain (e.g., mail.example.com) into the tool, and it will display the published record. Look for syntax issues, excessive DNS lookups, or multiple records. If errors are found, fix them in the DNS console and wait for propagation before re-validating.

Another way to test is by sending emails from your subdomain using platforms like Gmail or Outlook. Check the message headers for SPF results, such as spf=pass or SPF: PASS, to confirm everything is working.

For ongoing monitoring, services like MailMonitor offer tools for inbox placement testing, SPF validation, and reputation tracking. These insights help ensure your emails reach inboxes rather than spam folders.

Lastly, document the publication date and validation results. Keep track of when the SPF record was published, tested, and confirmed. This audit trail will be useful for troubleshooting in the future.

If you manage multiple subdomains, repeat this process for each one. SPF records are not inherited from parent domains, so every subdomain that sends email needs its own SPF record.

Advanced SPF Techniques and Best Practices

Once your SPF records are set up, there are ways to fine-tune them for better performance and adaptability. Handling SPF records for subdomains can get complicated, especially if you rely on multiple email services or have a complex infrastructure. The challenge lies in staying within technical limits while ensuring your records remain accurate and easy to manage.

Managing Complex SPF Records

One of the biggest hurdles when working with SPF records is the 10 DNS lookup limit. Each time a mail server checks your SPF record, it counts how many DNS queries are needed to process all the mechanisms. If the total exceeds 10, the SPF check fails, and your emails might be rejected or flagged as unauthenticated.

Mechanisms like include, mx, and a contribute to this lookup count. For instance, the mechanism include:_spf.google.com doesn’t just add one lookup; it also includes the lookups within Google’s SPF record. If Google’s record has three additional includes, your single mechanism results in four lookups.

Here’s an example: if your sales.example.com subdomain uses Google Workspace, Microsoft 365, SendGrid, and Mailgun, your SPF record might look like this:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org -all

While this setup seems straightforward, it’s essential to verify how many lookups each service adds. Nested includes can quickly push you past the 10-lookup limit.

To manage this, consider the following strategies:

  • Combine similar mechanisms: If you use multiple IP addresses from the same provider, ask if they offer a single include mechanism that covers all their IPs. Many services provide optimized SPF records to reduce lookups.
  • Use ip4 and ip6 mechanisms: Unlike includes, these don’t require DNS lookups. For example:
    v=spf1 ip4:203.0.113.5 ip4:198.51.100.10 include:_spf.google.com -all
    This setup uses two IP addresses and one include, making it more efficient than multiple includes.

Another advanced method is SPF flattening, which replaces include mechanisms with the actual IP addresses they resolve to. For example, instead of include:sendgrid.net, you’d list SendGrid’s specific IPs directly. While this reduces DNS queries, it comes with trade-offs. Third-party services like SendGrid or Mailgun often change their IP addresses, so a flattened record can quickly become outdated. Keeping these records accurate requires either manual updates or automated tools that monitor and refresh flattened records regularly.

Flattening can also lead to lengthy records. If you authorize many IPs, your SPF record might exceed the 255-character limit for a single DNS TXT string. Although DNS allows splitting records into multiple strings, not all email servers handle this correctly, which could cause authentication issues.

If you manage multiple subdomains, tailor each SPF record to its specific needs. For example, marketing.example.com might only use SendGrid, while support.example.com relies on Zendesk. Avoid duplicating the same SPF record across all subdomains, as this adds unnecessary complexity and makes maintenance harder.

Best Practices for SPF Records

To keep your SPF records efficient and reliable, follow these best practices:

  • Stay within the 255-character limit per string: While DNS can technically handle longer records split into multiple strings, some older mail servers may not process them correctly. Keep records concise by removing extra spaces and using shorthand where possible.
  • Audit your SPF records regularly: Check your records at least twice a year or whenever you add or remove email services. Verify that all include mechanisms are still necessary, and remove any outdated entries. This helps you stay within the lookup limit and reduces security risks.
  • Avoid multiple SPF records for a single subdomain: DNS allows multiple TXT records, but SPF validation only uses one. If two SPF records exist, mail servers might ignore both or choose one at random, leading to authentication failures. Consolidate all mechanisms into a single SPF record for each subdomain.
  • Use the -all qualifier (hard fail): This ensures unauthorized emails are rejected. While some organizations use ~all (soft fail) during testing, leaving it in place long-term weakens email security and can harm your deliverability.
  • Maintain an SPF record log: Keep track of when records were created, which services they authorize, and when they were last updated. This makes troubleshooting easier and ensures continuity if team members change.
  • Centralize SPF management: For organizations with frequent changes, use automation tools to generate and update records. Establish a review process to catch errors before publishing changes.
  • Monitor SPF records continuously: Tools like MailMonitor can alert you to SPF failures, track changes, and integrate with DMARC and DKIM monitoring. These platforms provide insights into email deliverability and reputation, helping you address issues early.
  • Test after every change: Send test emails from your subdomain and review the message headers to confirm SPF passes. Use SPF checker tools to validate syntax and ensure you’re within the lookup limit.

Lastly, stay updated on third-party sender policies. If a service changes its SPF record or IP ranges, your record may need adjustments. Subscribe to service notifications or use monitoring tools to track these updates automatically.

Troubleshooting and Monitoring

SPF configuration problems can crop up from time to time, and resolving them quickly is key to keeping your email deliverability intact. Beyond fixing issues, regular monitoring ensures your SPF records keep working as your email setup evolves.

Common SPF Configuration Issues

When troubleshooting, it’s helpful to revisit your initial SPF setup documentation for reference. Some of the most frequent problems include:

  • Multiple SPF records: While DNS allows multiple TXT records for a subdomain, SPF validation only recognizes one. If two SPF records exist, mail servers may ignore both or randomly pick one, leading to authentication failures. For instance, if news.marketing.example.com has both v=spf1 include:_spf.google.com -all and v=spf1 include:sendgrid.net -all, neither will work properly. To fix this, combine all authorized senders into a single record: v=spf1 include:_spf.google.com include:sendgrid.net -all.
  • Syntax errors: Simple mistakes like missing the v=spf1 tag, misspelling mechanisms (e.g., writing incldue instead of include), or forgetting spaces between mechanisms can break your SPF record. These errors can cause failed authentication, sending your emails straight to spam. Always use tools like MXToolbox, DMARCLY‘s SPF Record Checker, or Google CheckMX to validate your records before publishing.
  • DNS propagation delays: Changes to SPF records can take 1 to 48 hours to propagate across DNS servers. During this time, some mail servers might see the old record while others see the updated one, leading to inconsistent results. To minimize disruption, schedule updates during low-traffic periods and wait at least 24 hours for changes to take effect. If you need faster propagation, consider lowering your DNS provider’s TTL (Time to Live) setting beforehand.
  • Exceeding the 10 DNS lookup limit: SPF checks fail with a PermError if more than 10 DNS lookups are required. This is a common issue when adding multiple services to your SPF record.
  • Missing or incomplete records: Every sending subdomain needs its own SPF record. Without it, authentication will fail for emails sent from that subdomain.
  • Character limit violations: SPF TXT strings must stay under 255 characters each, with a combined total limit of 512 characters. If your record is too long, some servers may not recognize it. Keep records concise by removing unnecessary spaces and using shorthand where appropriate.

Once you’ve addressed these common issues, validate your SPF configuration to ensure everything is in order.

Validating SPF and Monitoring Deliverability

After resolving any configuration problems, validation becomes the next critical step. Use SPF record checkers like MXToolbox, DMARCLY’s SPF Record Checker, or Google CheckMX to confirm your record is correctly published and free of syntax errors. These tools can also simulate SPF checks to ensure all authorized senders are covered.

Send test emails from your subdomain and inspect the message headers for SPF=pass results. If you see SPF=fail or SPF=softfail, dig deeper by checking for syntax mistakes, verifying authorized sending IPs, and ensuring you haven’t exceeded the DNS lookup limit.

Monitoring doesn’t stop after the initial validation. Email infrastructures change frequently – third-party services may update their IP ranges, new senders might be added, or DNS records could be modified. Without regular monitoring, these changes could disrupt SPF authentication and harm your email deliverability.

Platforms like MailMonitor offer tools to track email performance and authentication results. They monitor inbox placement rates across hundreds of inboxes, track sender reputation in real time, and provide alerts for SPF failures before they affect your campaigns.

For example, Fusion HCS improved inbox placement rates by 90% across 1 million contacts using MailMonitor. Dan Westenskow, CEO of Fusion HCS, shared:

"MailMonitor helps us identify and fix our spam issues. It’s like having a deliverability expert on our team. The weekly check-in calls allow us to take feedback, implement it and then follow up the next week with additional items to clarify or get help with. This cadence helps our team get better email results."[1]

To maintain strong deliverability, keep an eye on key metrics like inbox placement rates, bounce rates and their causes, authentication results (SPF, DKIM, and DMARC), and blacklist status. Regularly reviewing these metrics can help catch issues early and keep your emails out of spam folders.

For businesses with complex email infrastructures or multiple subdomains, MailMonitor’s managed services offer ongoing optimization. Their platform actively monitors email health, ensuring emails consistently land in recipients’ inboxes.

Set up custom alerts to notify you of SPF failures or drops in deliverability. Document all SPF records, noting their authorized senders and update history. Keeping a log of these details simplifies troubleshooting and ensures continuity if team members change. Regular audits of your SPF records can also help identify unnecessary include mechanisms and remove outdated entries.

Conclusion

Setting up SPF records for subdomains involves three critical steps: identifying authorized sending servers, creating a properly formatted SPF TXT record, and publishing and validating it within your DNS settings. Each step plays a key role in ensuring email authentication runs smoothly. Skipping even one can lead to authentication errors, increasing the risk of emails landing in spam folders.

It’s important to note that every subdomain requires its own SPF record. Without this, the subdomain defaults to "none" during SPF checks, which can result in rejected or quarantined emails. To avoid this, make sure to configure separate records for each subdomain.

When crafting your SPF record, begin with the v=spf1 tag, include your authorized senders using the include mechanism, and finish with a strict policy like -all. Here’s an example:

sales IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Once your SPF record is set up, validation is the next step. Keep in mind that DNS changes can take anywhere from 1 to 48 hours to propagate. And as your email infrastructure evolves – whether through new services or IP address changes – ongoing monitoring is essential. Neglecting this can disrupt SPF authentication and harm your email deliverability.

To stay ahead of potential issues, tools like MailMonitor can be invaluable. They provide real-time tracking across hundreds of inboxes, monitor authentication results, and send alerts for SPF failures. This kind of proactive monitoring is especially helpful for organizations managing multiple subdomains with complex email-sending needs, ensuring emails consistently reach recipients’ inboxes instead of being flagged as spam.

Finally, document your SPF records and any updates to simplify troubleshooting and prevent misconfigurations. Conduct quarterly audits of your SPF records to remove outdated entries and avoid exceeding the 10 DNS lookup limit, which could otherwise lead to SPF check failures.

FAQs

Why do subdomains need separate SPF records instead of using the main domain’s record?

Subdomains need their own SPF (Sender Policy Framework) records because SPF authentication operates on a domain-by-domain basis. When an email server checks the SPF record, it looks at the domain or subdomain in the ‘From’ address to confirm if the sending server has permission to send emails on its behalf. If a subdomain lacks its own SPF record, emails sent from it might fail authentication, causing delivery problems or getting flagged as spam.

Setting up dedicated SPF records for subdomains ensures proper email authentication and improves the chances of successful delivery. This is especially crucial for businesses that use subdomains for specific functions, like sending marketing campaigns or transactional emails.

What mistakes should I avoid when setting up SPF records for subdomains?

When setting up SPF records for subdomains, there are a few common mistakes you’ll want to steer clear of to maintain effective email authentication and delivery:

  • Skipping a dedicated SPF record for the subdomain: If your subdomain is used to send emails, it needs its own SPF record. Don’t just rely on the primary domain’s SPF record – it won’t cover the subdomain’s email activity.
  • Hitting the DNS lookup limit: SPF records are capped at 10 DNS lookups. Adding too many "include" statements or mechanisms can push you over this limit, causing the SPF check to fail.
  • Neglecting to test the setup: Always verify your SPF record after configuring it. Testing ensures it’s correctly set up to cover all your email-sending sources and works as intended.

By addressing these issues upfront, you’ll improve your chances of successful email authentication and help your messages reach the inbox.

How can I keep my SPF records up to date as my email setup evolves?

To keep your SPF records working as intended, it’s important to review and update them whenever there are changes to your email services or infrastructure. If you add or remove domains, IP addresses, or third-party email providers, make sure to adjust your SPF record to reflect these updates.

Regularly testing your SPF setup is equally important. Tools like MailMonitor can help you check your configuration, monitor email deliverability, and spot any issues. This ensures your emails continue to land in recipients’ inboxes without a hitch.

Related Blog Posts

Do subdomains inherit SPF records from the parent domain?
What is the correct SPF record format for a subdomain?
What is the 10 DNS lookup limit for SPF and why does it matter?
How long does it take for a new subdomain SPF record to take effect?