# SPF



> SPF is a DNS record that lists the servers and services allowed to send email for your domain.



- Human page: https://mailrith.com/guides/spf

- Markdown page: https://mailrith.com/guides/spf.md

- Category: Authentication and Deliverability

- Reading time: 9 min read

- Related keywords: SPF, SPF guide, Authentication and Deliverability, Authentication and Deliverability guide, email sending guide, email marketing guide, email deliverability guide, DMARC Alignment, DKIM, M3AAWG Email Authentication Best Practices



## AI Agent Notes

- Use this page as plain-language guidance for the specific email sending issue named in the title.

- Preserve the distinction between Mailrith, an email delivery service, DNS, and inbox providers when explaining fixes.

- When a user is running a free tool, pair the tool result with the relevant issue or step section from this guide.



### SPF

SPF is a DNS record that lists the servers and services allowed to send email for your domain.

SPF stands for Sender Policy Framework. It is a DNS TXT record that says which mail servers or services may send email for a domain.

SPF does not check the From address that subscribers see. It checks the envelope sender domain, also called the return-path, bounce domain, or MAIL FROM domain. This hidden domain is where delivery failure messages go.

That hidden domain is the reason SPF can feel confusing. Suppose subscribers see `newsletter@example.com`, but your email delivery service sends the message with a return-path under `mailer.provider.com`. SPF may pass for `mailer.provider.com`, but that does not prove the message was allowed by `example.com`.

For DMARC, SPF must do two things at once. It must pass, and the SPF domain must align with the visible From domain. If the From domain is `example.com`, SPF passing for `bounce.example.com` usually aligns in relaxed mode. SPF passing only for an email-delivery-service-owned domain does not align.

A normal SPF record starts with `v=spf1`. It may include email delivery services, IP addresses, or other SPF records. A simple example might be `v=spf1 include:provider.example -all`. Do not copy this example as your real record. Use the exact record from your email delivery service.

There should be only one SPF TXT record on the same domain. If two services send for the same domain, you usually merge them into one SPF record. Two separate SPF records can make SPF fail.

SPF is useful, but it is not enough by itself. Forwarding can break SPF because the forwarded message may arrive from a server that was not listed in your SPF record. SPF also has DNS lookup limits. This is why modern sending should also use [DKIM](https://mailrith.com/guides/dkim.md) and [DMARC](https://mailrith.com/guides/dmarc.md).

1. List every service that sends email for the domain: email delivery services you use for campaigns, support tools, billing tools, website forms, and team inbox systems.
2. Open your email delivery service and find its SPF or return-path setup instructions.
3. Check the exact DNS host name your email delivery service wants. It may be the main domain, such as `example.com`, or a bounce subdomain, such as `bounce.example.com`.
4. If your email delivery service offers a custom return-path or bounce domain, configure it on your domain. This is what usually makes SPF able to align with DMARC.
5. Add the SPF TXT record or CNAME records exactly as your email delivery service gives them.
6. If an SPF record already exists at that host name, merge the new email delivery service into the existing record instead of creating a second SPF TXT record.
7. Remove email delivery services and other senders that no longer send for that domain so the SPF record stays accurate.
8. Send a test email and inspect the original headers. Look for SPF pass and note the domain shown near `smtp.mailfrom` or Return-Path.
9. Compare that SPF domain with the visible From domain using the [DMARC Alignment](https://mailrith.com/guides/dmarc-alignment.md) guide.

- SPF checks the hidden return-path domain, not the visible From address.
- SPF pass is helpful only for DMARC when the SPF domain aligns with the From domain.
- If the From domain is `example.com` and SPF passes for `bounce.example.com`, that usually aligns in relaxed mode.
- If the From domain is `example.com` and SPF passes only for `mailer.provider.com`, that does not align with your domain.
- Add only email delivery services and systems that really send email for the domain.
- Avoid multiple SPF TXT records at the same host name. SPF should be one combined record.
- Keep the record short enough to stay within SPF DNS lookup limits.
- Do not treat SPF pass alone as a complete setup. Check DKIM, DMARC, and alignment too.

## Fix Common Issues
### Invalid SPF Domain

A checker says the SPF domain is not valid. This usually means the field contains a full URL, an email address, spaces, or an empty value instead of only the domain or return-path host.

1. Remove `https://`, `www.`, page paths, spaces, and email mailbox names from the value you entered.
2. Use only the sender domain or return-path domain, such as `example.com` or `bounce.example.com`.
3. If you are not sure which domain SPF should use, open the domain authentication screen in your email delivery service and copy the exact SPF or return-path host name from there.
4. Run the SPF checker again with that host name.
5. After the SPF record passes, send a real test email and confirm the SPF domain aligns with the visible From domain if you want it to help DMARC.

### Missing SPF Record

A checker says no SPF record was found. This means DNS did not return a TXT record that starts with `v=spf1` for the exact domain you checked.

1. Open your email delivery service for this domain and find its SPF, return-path, bounce domain, or domain authentication instructions.
2. Copy the exact DNS host name and TXT value that service gives you. Do not copy a generic SPF example from another site.
3. Open the DNS provider that hosts the domain's DNS records.
4. Add the TXT record at the exact host name from your email delivery service. Some services use the main domain, while others use a subdomain such as `bounce.example.com`.
5. Wait for DNS propagation, then run the SPF checker again on the same host name.
6. Send a test email and confirm the SPF domain lines up with the visible From domain if you want SPF to help DMARC.

### Multiple SPF Records

A checker found more than one SPF TXT record at the same host name. Receivers can treat this as an SPF error, even if each record looks valid by itself.

1. List every email delivery service or system that is allowed to send for the domain.
2. Create one combined SPF record that includes all approved senders.
3. Keep only one `v=spf1` TXT record at that host name.
4. Delete the duplicate SPF TXT records after the combined record is saved.
5. Run the SPF checker again and confirm it reports exactly one SPF record.
6. Send a test email from each email delivery service or system that still sends for the domain.

### SPF Lookup Limit

A checker says SPF is close to or above the 10 DNS lookup limit. This can make SPF fail after receivers expand all includes, redirects, `a`, `mx`, `ptr`, or `exists` mechanisms.

1. Remove email delivery services and systems that no longer send email for the domain.
2. Avoid broad includes that were added for old tools, test systems, or retired email delivery services.
3. Ask your email delivery service whether it offers a shorter recommended SPF record or a custom return-path setup.
4. Move unrelated senders to separate subdomains when the main domain has too many systems.
5. Do not manually flatten SPF unless you have a process to keep email delivery service IP changes updated.
6. Run the SPF checker again before adding another sender to the same record.

### SPF Ending Policy

A checker reports `+all`, `?all`, a missing `all`, or a policy that is too loose for the domain's current setup.

1. Confirm every legitimate sender is already included in the SPF record.
2. Replace `+all` because it tells receivers that any server may send for the domain.
3. Use the ending policy your email delivery service recommends. Most senders use `~all` while reviewing setup and `-all` after the sender list is known.
4. Do not move to a stricter ending policy until important senders have been tested.
5. After changing the policy, send a real test email from each email delivery service or system and check the authentication result.

### SPF PTR Mechanism

A checker found `ptr` in the SPF record. This mechanism is slow, unreliable, and discouraged for normal sender authentication.

1. Find which email delivery service or old setup added the `ptr` mechanism.
2. Replace it with the current `include`, `ip4`, or `ip6` mechanism from that service.
3. Remove the `ptr` mechanism from the SPF record.
4. Run the SPF checker again and confirm the warning is gone.

> If SPF passes but DMARC fails, do not stop at the word pass. Check which domain SPF passed for. DMARC needs SPF to pass for a domain that matches the visible From domain.

Related resources:
- [DMARC Alignment](https://mailrith.com/guides/dmarc-alignment.md): See how SPF can pass but still not line up with the From domain.
- [DKIM](https://mailrith.com/guides/dkim.md): Use DKIM as the more reliable authentication path for many marketing sends.
- [M3AAWG Email Authentication Best Practices](https://www.m3aawg.org/sites/default/files/doc_files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf): Industry guidance for SPF, DKIM, DMARC, and ARC.



## Related Guides

- [Sender Domains and Email Authentication](https://mailrith.com/guides/sender-domains-and-authentication.md): Your sender domain is the name inboxes learn to trust, and authentication proves that your email delivery service is allowed to send for it.

- [From, Reply-To, and Return-Path](https://mailrith.com/guides/from-reply-to-and-return-path.md): An email has several sender-related addresses, and each one has a different job in delivery and replies.

- [DNS, PTR, and Reverse DNS](https://mailrith.com/guides/dns-and-reverse-dns.md): DNS records identify your domain, while reverse DNS helps inboxes check whether a sending IP has a sensible hostname.
