Email Authentication SPF: How to Set Up, Test, and Maintain Your Record

Email authentication SPF is the DNS-based control that tells receiving mail servers which IP addresses and services may send mail using your domain in the SMTP envelope. It is simple to publish one TXT record, but getting the right result depends on mapping every legitimate sender, staying inside DNS lookup limits, and understanding what SPF cannot protect on its own.

What email authentication SPF is

Sender Policy Framework, usually called SPF, is an email authentication standard defined in RFC 7208. A domain owner places a policy in DNS that identifies hosts authorized to send mail for that domain. When a receiving server gets a message, it compares the server that connected to it with the sender domain used in the SMTP transaction, then evaluates the domain's SPF policy.

The important qualification is that SPF authenticates the envelope sender, also known as the SMTP MAIL FROM, return-path, or bounce domain. It does not directly authenticate the visible From: address that a person sees in an email client.

For example, a recipient might see this header:

From: Acme News <news@acme.com>

But the message could have an envelope sender of:

MAIL FROM:<bounce@marketing.acme-mail.example>

SPF is checked against marketing.acme-mail.example, not necessarily acme.com. That distinction explains many apparently confusing SPF results and is why SPF alone is not sufficient protection against visible-address spoofing.

An SPF evaluation returns one of several results: pass, fail, softfail, neutral, none, temperror, or permerror. A pass means the connecting host matched the published policy. It does not mean the message is safe, welcome, or guaranteed to reach the inbox; spam filters also assess content, reputation, user engagement, IP reputation, links, and other signals.

SPF's role in modern email authentication

SPF is one member of a three-part system:

• SPF authorizes sending infrastructure for the envelope sender domain.
• DKIM adds a cryptographic signature to selected message headers and body content. A receiver verifies that signature through a public key in DNS.
• DMARC checks whether SPF and/or DKIM passes and aligns with the visible From: domain. It also lets the domain owner request monitoring, quarantine, or rejection of failing mail.

For practical domain protection, implement all three. SPF is still valuable because it can validate legitimate sending infrastructure and can satisfy DMARC when its authenticated domain aligns with the visible From: domain. But DKIM is generally more resilient when messages are forwarded, and DMARC is the layer that turns authentication results into a policy tied to the displayed sender identity.

How SPF authentication works, step by step

Understanding the actual SMTP and DNS flow makes SPF configuration and troubleshooting much easier.

1. A mail server connects to the recipient's server from an IP address.
2. During SMTP, it identifies itself with HELO or EHLO and supplies an envelope sender using MAIL FROM.
3. The recipient extracts the domain in MAIL FROM and queries DNS for its SPF TXT record.
4. The recipient evaluates the mechanisms in that record from left to right, using the connecting IP address and, where relevant, additional DNS lookups.
5. The first matching mechanism determines the result. If nothing matches, the all mechanism, normally placed at the end, provides the default outcome.
6. The recipient can then combine SPF with DKIM and DMARC results before deciding whether to accept, filter, quarantine, or reject the message.

A simplified transaction looks like this:

Client IP: 203.0.113.25
EHLO smtp.example-sender.net
MAIL FROM:<bounces@acme.com>
RCPT TO:<reader@example.net>

If acme.com publishes v=spf1 ip4:203.0.113.25 -all, the receiving server finds a match for ip4:203.0.113.25 and records SPF pass. If the connection came from 198.51.100.44, it reaches -all and returns SPF fail.

The special case of empty envelope senders

Delivery status notifications and some automated messages use an empty envelope sender:

MAIL FROM:<>

In that case, SPF uses the domain named in the SMTP HELO or EHLO identity for its check. This is one reason every mail server should use a legitimate, resolvable hostname in HELO/EHLO and should publish appropriate DNS where it sends mail directly.

What you see in received messages

Many receiving systems add an Authentication-Results header. Its exact format varies by recipient, but a message might contain something like:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=acme.com;
  dkim=pass header.d=acme.com;
  dmarc=pass header.from=acme.com

This is useful evidence, but inspect it on mail received by an independent mailbox rather than relying only on a copy saved by your own sending platform. Google Workspace message headers, Microsoft 365 message tracing and headers, Gmail's “Show original” view, and mail-testing services can help reveal the actual receiving-side result.

SPF record syntax explained

An SPF policy is a DNS TXT value beginning with the version tag v=spf1. It contains mechanisms, optional qualifiers, and limited modifiers separated by spaces.

A minimal record that says no host is authorized to send mail is:

v=spf1 -all

That is valid syntax, but do not use it for a domain that sends mail until every valid sending path has been addressed.

Qualifiers: what pass, fail, and softfail mean

Each mechanism can have a qualifier. If no qualifier is present, + (pass) is assumed.

The final all mechanism always matches, so it must be last. These two policies differ in operational intent:

v=spf1 include:_spf.google.com ~all
v=spf1 include:_spf.google.com -all

The first permits Google's infrastructure and marks everything else as a softfail. The second permits Google's infrastructure and returns a fail for all other sources. -all is the clearer end state once the sending inventory is complete, but changing to it before discovering a billing platform, CRM, support desk, or transactional service can disrupt legitimate mail.

SPF mechanisms you will use most

The common mechanisms are below. They are evaluated in order.

• ip4:203.0.113.25 authorizes one IPv4 address. CIDR notation authorizes a network, such as ip4:203.0.113.0/24.
• ip6:2001:db8:1234::/48 authorizes an IPv6 address or network.
• a authorizes addresses returned by the domain's A or AAAA records. a:mail.acme.com checks the named host instead.
• mx authorizes the IP addresses of the domain's MX hosts. mx:acme.com is explicit; mx uses the current SPF domain.
• include:domain.example evaluates another domain's SPF policy. It matches only if that policy produces SPF pass.
• exists:domain.example matches if the specified domain has an A record. It is mostly used in advanced provider-managed policies.
• all matches every source and is used as the final default.

A practical policy may look like this:

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

It authorizes a dedicated application server at 203.0.113.25, Google Workspace mail infrastructure through Google's published SPF policy, and SendGrid through its published policy. The names after include: are examples of provider-specific settings: always use the hostname your own provider documents, because services can use different domains, custom return paths, or account-specific instructions.

Mechanisms to avoid unless you have a specific reason

The ptr mechanism performs reverse-DNS-style checks and is strongly discouraged by RFC 7208 because it is expensive and unreliable at Internet scale. Avoid adding it to new records.

The redirect= modifier hands evaluation to another domain only if no earlier mechanism matched. It is not interchangeable with include:. An include asks whether another policy passes as one condition among your policy's conditions; redirect replaces the remainder of your policy. Use a redirect only when another domain deliberately owns the complete SPF policy.

The exp= modifier can point to explanatory text for failures, but receiver support is not assured and it has little value for most domain owners. Keep production SPF records understandable rather than clever.

Before publishing SPF: build a complete sender inventory

The technical edit is easy. The hard part is finding every system that sends with your domain in its envelope sender or visible From: address. A record copied from a mail provider's onboarding page often authenticates employee mail but misses the services that cause the most important failures: password resets, invoices, support replies, product alerts, and marketing campaigns.

Create an inventory before editing DNS. Include both systems controlled by IT and services selected by sales, marketing, finance, customer success, and engineering.

For each sender, answer four questions:

1. Does it send mail using the organizational domain, a subdomain, or the vendor's own domain?
2. What is the envelope MAIL FROM / return-path domain?
3. Does the vendor require an SPF include, a dedicated IP address, a CNAME-based configuration, or no SPF change at all?
4. Can the sender DKIM-sign with an aligned domain, and can it use a custom bounce domain?

That final question matters. A platform that sends From: receipts@acme.com but uses an envelope sender at a vendor-owned domain can still achieve DMARC through aligned DKIM. In some cases, adding an SPF include for that vendor is unnecessary. Do not add includes merely because a generic blog says to; check the provider's authenticated-domain documentation and inspect a delivered test message.

How to create an SPF TXT record

SPF is published in public DNS as a TXT record at the domain being evaluated. The obsolete dedicated SPF DNS record type is not the publication method to use; RFC 7208 specifies TXT records.

Find your DNS host and existing record

Log in to the provider that is authoritative for your domain's DNS. This may be your registrar, Cloudflare, Amazon Route 53, a hosting company, or a corporate DNS platform. It is not necessarily the company that hosts your website or email.

Search the zone for TXT records at the root domain, often displayed as @, the bare domain, or a blank host field. Query it independently before making a change:

dig TXT acme.com +short

On Windows PowerShell, use:

Resolve-DnsName -Name acme.com -Type TXT

Look for a string beginning exactly with v=spf1. A domain must have one SPF policy record. Multiple TXT records are normal for unrelated services such as Google verification or DKIM, but publishing two separate TXT values that both begin v=spf1 causes an SPF permerror.

Combine existing authorization, never replace it blindly

If the existing value is:

v=spf1 include:_spf.google.com ~all

and you must authorize SendGrid as well, edit that same SPF value to:

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

Do not create a second record such as:

v=spf1 include:sendgrid.net ~all

A receiver that finds multiple SPF records for the same domain must return a permanent error rather than choosing one. This is among the most common SPF configuration errors.

DNS entry fields in a typical control panel

Although labels differ by DNS provider, the values normally look like this:

Type: TXT
Name/Host: @
Value: v=spf1 include:_spf.google.com include:sendgrid.net -all
TTL: 3600

@ conventionally means the zone apex, such as acme.com. In some interfaces you enter acme.com instead; in others, entering the full domain while the UI appends it automatically creates the incorrect name acme.com.acme.com. Check the DNS host's preview or record name after saving.

A TTL of 3,600 seconds is one hour and is a common operational choice, but use the TTL your DNS policy requires. Propagation is not a fixed global timer: recursive resolvers can keep the previous response until its cached TTL expires. Plan a change window and validate from more than one resolver if mail is business-critical.

Root domains and subdomains are separate

SPF does not automatically inherit from a parent domain. If you send mail as mail.acme.com in the envelope sender, publish SPF for mail.acme.com as well, unless its policy intentionally uses redirect= to another domain.

This allows useful separation. For example, an organization can keep employee mail at acme.com while placing marketing mail at mail.acme.com with a narrowly scoped policy. Subdomain delegation and provider-specific CNAME arrangements can affect where records are managed, so verify the exact queried name.

A worked email authentication SPF example

Assume Acme Studio has the domain acmestudio.example. It uses Google Workspace for employee mail, SendGrid for application receipts, and one self-managed monitoring system at public IPv4 address 203.0.113.25. It wants a defensible SPF policy without breaking mail.

Step 1: inspect the current state

The administrator runs:

dig TXT acmestudio.example +short

The output includes:

"v=spf1 include:_spf.google.com ~all"

This confirms there is already one SPF record and that Google Workspace is currently authorized. The administrator also reviews message headers from a successful product receipt and confirms the platform documents include:sendgrid.net for the account's sending configuration. The monitoring system's outbound NAT address is verified as 203.0.113.25.

Step 2: calculate the intended policy

The combined draft is:

v=spf1 ip4:203.0.113.25 include:_spf.google.com include:sendgrid.net ~all

At this stage, ~all is retained during verification. It does not authorize unknown sources; it returns softfail when they do not match. It gives the team a chance to spot unlisted legitimate traffic in authentication reports and recipient headers before moving to a strict failure policy.

Step 3: publish one TXT record

In the DNS zone for acmestudio.example, the administrator edits—not duplicates—the existing root TXT SPF record. The fields are:

Type: TXT
Host: @
Content: v=spf1 ip4:203.0.113.25 include:_spf.google.com include:sendgrid.net ~all
TTL: 3600

If the UI automatically adds quotation marks around TXT values, that is normal. Do not manually add escaped quotes unless the provider explicitly requires them.

Step 4: verify DNS and send tests

After the prior TTL has had time to expire, query public DNS:

dig TXT acmestudio.example @1.1.1.1 +short
dig TXT acmestudio.example @8.8.8.8 +short

Then send separate messages from: a Google Workspace mailbox, the application receipt workflow, and the monitoring system. Deliver each to an external test mailbox. In the received headers, look for results comparable to:

spf=pass smtp.mailfrom=acmestudio.example

For the monitoring server, test from the exact production network, not a developer laptop. For the SaaS platform, trigger a real transactional event because a preview email may use different infrastructure from live delivery.

Step 5: add DKIM and DMARC, then tighten policy

The team enables DKIM in Google Workspace and configures the transactional platform to sign with d=acmestudio.example or an aligned subdomain where supported. It publishes a DMARC monitoring record such as:

v=DMARC1; p=none; rua=mailto:dmarc-reports@acmestudio.example; adkim=r; aspf=r

DMARC aggregate reports identify sources claiming to send for the visible domain. After the team has reviewed reports and confirmed all legitimate sources, it can change SPF's ending to -all:

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

The SPF change is not a substitute for moving DMARC from monitoring to enforcement. A staged DMARC rollout—p=none, then p=quarantine, then p=reject when appropriate—is a separate policy decision based on authenticated traffic and organizational risk.

SPF lookup limits and record design

SPF is intentionally constrained to prevent a receiver from being forced into excessive DNS work. RFC 7208 limits an SPF evaluation to 10 DNS-querying terms. Mechanisms and modifiers that can consume this budget include include, a, mx, ptr, exists, and redirect. Direct ip4, ip6, and all terms do not require SPF DNS lookups themselves.

The important trap is that includes are recursive. Your record may show only three includes, but each provider's policy can include other policies. If evaluation exceeds the limit, the result is permerror, not pass. A receiver should not continue evaluating it as if the policy were valid.

Keep the policy short and auditable

Use these design rules:

• Use direct ip4 or ip6 mechanisms for stable, owned outbound addresses rather than unnecessary DNS indirection.
• Remove a vendor's include when that vendor no longer sends for the domain.
• Prefer a provider's documented include to guessing individual provider IP ranges, which may change.
• Avoid ptr and avoid sprawling nested include chains.
• Count lookup-producing terms across all nested policies with an SPF validation tool before publishing.
• Separate mail streams by subdomain where that reduces complexity and matches your operational architecture.

A TXT character-string has a 255-octet limit, but DNS providers can split a longer TXT record into multiple quoted strings that resolvers concatenate. That does not solve SPF's lookup limit and can make records difficult to maintain. Keep the logical policy compact; RFC 7208 also advises keeping DNS responses small enough to avoid avoidable transport problems.

Several online SPF checkers and DMARC platforms calculate lookup depth and expose nested includes. Treat their result as a diagnostic, then also inspect the actual DNS record with dig or Resolve-DnsName. A tool may correctly report that a provider's published include consumes several lookups even though your visible record looks short.

Common SPF failures and how to fix them

Multiple SPF records

Symptom: A checker returns permerror, or recipient headers show SPF permanent error.

Cause: More than one TXT record at the same name starts with v=spf1.

Fix: Merge all legitimate mechanisms into one SPF record. Do not merge unrelated TXT records such as site verification tokens or DKIM keys.

A legitimate service is missing

Symptom: Marketing emails, help desk replies, invoices, or alerts show spf=fail or softfail.

Cause: The platform sends with your domain in its envelope sender, but its sending infrastructure is not represented in the policy.

Fix: Determine the exact envelope sender from a received message and follow the platform's domain-authentication instructions. Add the documented include or IP only after checking lookup budget. Configure DKIM at the same time.

You authorized the visible From domain but not the return path

Symptom: The From: address looks correct, but SPF is not passing for the expected domain.

Cause: SPF evaluates smtp.mailfrom, not header.from.

Fix: Examine Authentication-Results and Return-Path. Configure a custom MAIL FROM or bounce domain where the provider supports one, or rely on aligned DKIM to satisfy DMARC. Do not assume changing the visible From address changes SPF.

Forwarded mail breaks SPF

Symptom: Mail sent directly passes SPF, but copies forwarded by a recipient fail.

Cause: The forwarding server, rather than your authorized server, is now connecting to the final recipient. SPF is IP-based and was not designed to survive ordinary forwarding.

Fix: Ensure legitimate mail is DKIM-signed and aligned for DMARC. Forwarders can implement Sender Rewriting Scheme (SRS), which changes the envelope sender to preserve SPF semantics, but that is controlled by the forwarder, not usually by the original sender. Do not weaken your SPF policy merely to accommodate arbitrary forwarding.

Too many DNS lookups

Symptom: SPF validation reports more than 10 lookups or permerror.

Cause: Excessive nested includes, a/mx mechanisms, or a vendor policy chain that grew over time.

Fix: Remove unused senders, move distinct streams to subdomains, use direct IP authorization for infrastructure you control, and ask vendors whether a more efficient approved authentication pattern exists. Do not flatten provider SPF records into copied IP lists unless you accept the ongoing responsibility to track every provider IP change.

SPF passes but DMARC fails

Symptom: Headers say spf=pass, while dmarc=fail.

Cause: The SPF-authenticated envelope domain does not align with the visible From: domain, and aligned DKIM did not pass.

Fix: Configure an aligned custom return-path domain or aligned DKIM signing domain. Under relaxed SPF alignment, an organizational domain and its subdomain can align; under strict alignment, they must match exactly. DMARC's aspf tag controls this behavior.

How to test and monitor SPF correctly

Testing has two layers: DNS correctness and real-world message authentication. You need both.

First, query the DNS record and use an SPF analyzer to identify syntax errors, duplicate records, and lookup counts. Second, generate real messages from each production sender to inboxes at major receiving providers and inspect full headers. Delivery to one inbox is not proof of universal inbox placement, but authentication headers reveal whether the core control worked.

Use a repeatable testing checklist:

1. Query the intended domain and every sending subdomain for TXT records.
2. Confirm exactly one v=spf1 record exists at each relevant name.
3. Check syntax and recursive DNS lookup count.
4. Send a message from every mailbox provider, application, marketing platform, support system, and direct server.
5. Read Authentication-Results, Return-Path, and DKIM information in the recipient headers.
6. Verify DMARC alignment for the visible From: domain, not only SPF pass.
7. Review DMARC aggregate reports continuously for unknown sources and configuration drift.

DMARC aggregate reports are XML files sent by participating receivers to the address in the rua tag. Most teams use a DMARC reporting service to parse them rather than reading raw XML. The reports are especially useful after mergers, vendor migrations, new product launches, or changes in email routing because these are the moments when an unlisted sender often appears.

SPF does not provide a standard aggregate reporting mechanism of its own. DMARC reporting is therefore the practical monitoring layer for an SPF deployment, while provider logs and received-message headers provide source-level evidence.

SPF, DKIM, DMARC, and ARC: what each solves

It is tempting to ask which one to set up, but they address different failure modes.

ARC, or Authenticated Received Chain, is relevant when mailing lists and forwarders alter a message after it was originally authenticated. ARC can preserve evidence about earlier authentication results for receivers that choose to trust the chain. It does not make an SPF record unnecessary, and domain owners should not treat it as a replacement for DKIM and DMARC.

Large mailbox providers increasingly expect senders to use domain authentication, especially for substantial sending volume. Requirements differ by provider and can change, so verify the current published requirements for the destinations that matter to your business. In practice, an SPF-only strategy is fragile: use SPF as a clean authorization baseline, DKIM for durable message authentication, and DMARC for alignment, visibility, and enforcement.

A maintenance plan for SPF records

SPF is not a one-time DNS task. It is an operational asset that changes whenever email architecture changes.

Assign ownership to a person or team that can approve DNS changes and coordinate with marketing, engineering, and IT. Keep the sender inventory in a shared system, record why each mechanism exists, and include a change-review step for new SaaS tools that send branded mail.

Review the record at least when you:

• migrate mailbox providers or outbound SMTP relays;
• add a CRM, marketing automation, support, billing, or transactional-email vendor;
• introduce a new sending subdomain;
• retire a platform or IP address;
• see SPF, DKIM, or DMARC failures in message headers or DMARC reports;
• change DMARC alignment or enforcement policy.

A useful internal record might say: include:_spf.google.com — Google Workspace employee mail — owner: IT, or include:sendgrid.net — production receipts — owner: Engineering. That context prevents a future administrator from deleting an apparently mysterious include that still handles password-reset mail.

Conclusion

Email authentication SPF starts with one DNS TXT record, but a successful deployment is a process: inventory every sender, publish one valid policy, stay below the DNS lookup limit, test actual production mail, and monitor for drift. Use -all only after you understand every legitimate path, and remember that an SPF pass by itself does not prove the visible From domain is authentic.

The durable configuration is SPF plus aligned DKIM plus DMARC reporting and, when your traffic is understood, DMARC enforcement. That combination gives creators, marketers, and product teams a reliable way to protect their brand identity while preserving legitimate delivery.

FAQ

What is an SPF record for email authentication?

An SPF record is a DNS TXT record beginning with v=spf1 that lists the IP addresses and mail services allowed to send mail for a domain used in the SMTP envelope sender. Receivers compare the connecting server's IP address with that policy.

What should a basic SPF record look like?

A basic example is v=spf1 include:_spf.google.com -all for a domain whose only sender is Google Workspace. The correct value is always specific to your actual mail providers and infrastructure; do not copy an example without inventorying senders.

Can a domain have more than one SPF record?

No. A domain can have many DNS TXT records, but only one may be an SPF policy beginning with v=spf1. Multiple SPF policies cause SPF permerror; combine the authorized mechanisms into one record.

Should I use ~all or -all in SPF?

Use ~all while validating a new or incomplete sender inventory if your operational policy calls for a transition period. Use -all when you have verified every legitimate sender and want unauthorized sources to receive an SPF fail. Neither choice replaces DKIM and DMARC.

Why does SPF pass but email still go to spam?

SPF confirms only that the sending IP is authorized for the envelope domain. Mailbox providers also assess DKIM, DMARC alignment, domain and IP reputation, content, links, complaint rates, engagement, and other anti-abuse signals. An SPF pass is necessary for many legitimate senders but is not an inbox-placement guarantee.