How do you set up an SPF record for your domain?

To set up an SPF record for your domain, you create a DNS TXT record that lists the mail servers authorized to send email on your behalf. The record starts with v=spf1, includes your approved sending sources, and ends with a policy like ~all or -all. Once published, receiving mail servers check this record to verify that incoming messages from your domain are legitimate. The sections below walk through every key question you are likely to have along the way.

What exactly does an SPF record do to your email?

An SPF (Sender Policy Framework) record tells receiving mail servers which IP addresses and services are allowed to send email from your domain. When a message arrives, the receiving server looks up your domain’s SPF record in DNS and checks whether the sending IP is on the approved list. If it is not, the server can reject or flag the message as suspicious.

SPF is one of the three core email authentication standards alongside DKIM and DMARC. Its primary job is to prevent domain spoofing, which is when bad actors send email that appears to come from your domain without your permission. Without an SPF record in place, your domain has no way to signal to the internet which senders you trust, making it easier for spammers to impersonate you and harder for your legitimate messages to reach the inbox.

Beyond security, SPF directly affects email deliverability. Major inbox providers like Gmail and Microsoft use SPF pass or fail results as one of the signals in their spam filtering decisions. A missing or broken SPF record can cause legitimate campaigns, transactional messages, and automated notifications to land in junk folders or get rejected outright.

Where do you add an SPF record in DNS?

You add an SPF record in the DNS management area of whichever registrar or hosting provider controls your domain’s DNS zone. This is typically found in your domain registrar’s control panel (such as GoDaddy, Namecheap, or Cloudflare) under a section labeled DNS, DNS Records, or Zone Editor. You add it as a TXT record at the root of your domain (@).

The steps vary slightly by provider, but the process generally follows this pattern:

1. Log in to your DNS provider’s control panel.
2. Navigate to the DNS management or zone editor section for your domain.
3. Create a new TXT record.
4. Set the host or name field to @ (representing your root domain).
5. Paste your SPF record value into the value or content field.
6. Set the TTL (time to live) to a standard value such as 3600 seconds (one hour).
7. Save the record and allow time for DNS propagation.

DNS changes can take anywhere from a few minutes to 48 hours to propagate globally, though in practice most updates are visible within an hour or two.

What should an SPF record actually look like?

A basic SPF record is a single line of text that follows a specific syntax. A typical SPF record for a domain that sends through Google Workspace looks like this: v=spf1 include:_spf.google.com ~all. Every SPF record begins with v=spf1 to declare the version, lists one or more sending sources, and closes with an all mechanism that defines what to do with mail from sources not listed.

The key components of an SPF record are:

• v=spf1 — Required version tag that must appear first.
• ip4: or ip6: — Authorizes a specific IP address or range (e.g., ip4:203.0.113.0/24).
• include: — References another domain’s SPF record, used when you send through a third-party service like Mailchimp or SendGrid.
• a: — Authorizes the IP address behind a specific domain’s A record.
• mx: — Authorizes the IP addresses of your domain’s mail exchange servers.
• ~all — Soft fail: mail from unlisted sources is accepted but marked as suspicious.
• -all — Hard fail: mail from unlisted sources is rejected outright.

Most organizations start with ~all while they are building out their authentication setup, then move to -all once they are confident all legitimate sending sources are covered.

How do you add multiple senders to one SPF record?

You add multiple senders to one SPF record by chaining include: statements and IP addresses together in a single TXT record. Each sending service you use (your email platform, CRM, transactional mail provider, and so on) provides its own SPF include value, and you list them all in the same record separated by spaces.

For example, a company sending through both Google Workspace and Mailchimp would use a record like: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all.

There is one important constraint to be aware of: SPF has a DNS lookup limit of 10. Every include:, a:, and mx: mechanism triggers a DNS lookup, and if your record exceeds 10 lookups, receiving servers will return a PermError, effectively breaking your SPF authentication. If you use many third-party sending services, you may need to flatten your SPF record (replacing include references with the actual IP addresses they resolve to) or use a service that manages this automatically.

Also remember: you can only have one SPF TXT record per domain. If you create a second SPF record instead of editing the existing one, both records will conflict and cause authentication failures.

How do you test if your SPF record is working correctly?

You can test your SPF record using free online tools such as MXToolbox, Google Admin Toolbox, or Mail-tester.com. These tools look up your domain’s DNS records, parse the SPF syntax, count your DNS lookups, and flag any errors or warnings. You can also send a test email and check the message headers for the Authentication-Results field, which shows whether SPF passed, failed, or returned a soft fail.

When reviewing your SPF test results, look for the following:

• SPF pass — The sending IP was found in your record. Authentication succeeded.
• SPF softfail (~all) — The IP was not listed, but the message was accepted with a warning.
• SPF hardfail (-all) — The IP was not listed and the message was rejected.
• PermError — Your record has a syntax error or exceeds the 10 DNS lookup limit.
• TempError — A temporary DNS resolution issue occurred; this usually resolves on its own.

Testing after any change to your DNS records is a good habit. Even a small syntax error, like a missing space or a duplicate record, can silently break your authentication and affect deliverability across all your sending streams.

What are the most common SPF record mistakes to avoid?

The most common SPF record mistakes are exceeding the 10 DNS lookup limit, creating duplicate SPF records, and forgetting to include all third-party sending services. Each of these errors can cause authentication failures that are invisible to the sender but actively harm deliverability and domain reputation.

Here are the mistakes that come up most often in practice:

• Having more than one SPF record: DNS only supports a single SPF TXT record per domain. Two records create a PermError.
• Exceeding 10 DNS lookups: Each include, a, and mx mechanism counts toward the limit. Going over causes a PermError and breaks authentication.
• Missing a third-party sender: If you add a new email tool (a CRM, support platform, or marketing automation service) and forget to update your SPF record, mail from that service will fail authentication.
• Using +all instead of ~all or -all: The +all mechanism authorizes every server on the internet to send on your behalf, which completely defeats the purpose of SPF.
• Forgetting to update after changing providers: If you switch email platforms or stop using a service, leaving old include statements in your record wastes lookup budget and creates unnecessary risk.
• Not pairing SPF with DKIM and DMARC: SPF alone is not enough. Without DKIM and a DMARC policy, your domain remains vulnerable to certain spoofing techniques even with a valid SPF record.

How Email Industries helps with SPF configuration and email authentication

Getting SPF right is one piece of a much larger email authentication puzzle, and small configuration errors can have a significant impact on deliverability, sender reputation, and revenue. At Email Industries, we help organizations of all sizes get their authentication infrastructure built correctly from the ground up and keep it working as their sending environment evolves.

Here is what we bring to the table:

• Full SPF, DKIM, and DMARC audits to identify gaps, syntax errors, and lookup limit issues across all your sending domains.
• Third-party sender mapping so every service sending on your behalf is properly authorized and accounted for.
• Ongoing monitoring to catch authentication failures before they affect inbox placement.
• Expert guidance on when to move from softfail to hardfail and how to enforce a DMARC policy without disrupting legitimate mail flow.
• Deliverability consulting that connects authentication setup to broader inbox performance goals.

Whether you are setting up authentication for the first time or troubleshooting a configuration that has quietly been broken for months, our email deliverability services are designed to give you clarity and confidence. Explore our Deliverability Assurance Packages to see how we can support your authentication setup long term, or contact us directly and we will take a look at where things stand.

Related Articles

• How can you tell if your emails are being monitored?
• How do you check if your SPF record is working correctly?
• What triggers DMARC?
• How does a strict DMARC policy reduce phishing and fraud risk?
• What are the benefits of BIMI for email authentication?
• What does a DMARC reject policy actually do to emails?
• Can DKIM setup prevent your emails from going to spam?
• How does SPF work with third-party email sending services?
• How do you evaluate full service email marketing proposals?
• How do email advertising agencies handle campaign budgets?
• What happens if you skip domain warmup?
• How does IP warming affect your sender reputation?
• How does IP warming work for email deliverability?
• How do agencies segment email subscriber lists?
• What is email blacklist removal and how does it work?