# SPF



> SPF is a DNS record that lists the servers and services that may 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 Mailrith free tool, pair that specific free-tool result with the relevant issue or step section from this guide.



### SPF

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

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

SPF does not check the From address that subscribers see. SPF checks the envelope sender domain, also called the return-path, bounce domain, or MAIL FROM domain. Delivery failure messages go to this hidden domain.

This hidden domain can make SPF confusing. For example, subscribers may see `newsletter@example.com`, but your email delivery service may send the message with a return-path under `mailer.provider.com`. SPF may pass for `mailer.provider.com`, but that pass does not prove that `example.com` allowed the message.

For DMARC, SPF 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 a domain owned by the email delivery service does not align.

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

Use only one SPF TXT record on the same domain. If two services send email for the same domain, merge both services into one SPF record. Two separate SPF records can cause SPF to fail.

SPF is useful, but SPF is not enough by itself. Forwarding can break SPF because the forwarded message may arrive from a server that your SPF record does not list. SPF also has DNS lookup limits. For these reasons, 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 your domain, including email delivery services 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 that your email delivery service requires. The host name 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 that host name on your domain. A custom return-path or bounce domain usually lets SPF align with DMARC.
5. Add the SPF TXT record or CNAME records exactly as your email delivery service provides them.
6. If an SPF record already exists at that host name, add the new email delivery service to the existing SPF record instead of creating a second SPF TXT record.
7. Remove email delivery services and other senders that no longer send email for your domain so the SPF record stays accurate.
8. Send a test email and inspect the original headers. Confirm that SPF passes, then note the domain shown near `smtp.mailfrom` or Return-Path.
9. Compare the SPF domain with the visible From domain by 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 helps DMARC only when the SPF domain aligns with the From domain.
- If the From domain is `example.com` and SPF passes for `bounce.example.com`, SPF usually aligns in relaxed mode.
- If the From domain is `example.com` and SPF passes only for `mailer.provider.com`, SPF does not align with your domain.
- Add only email delivery services and systems that actually send email for your domain.
- Do not publish multiple SPF TXT records at the same host name. SPF should be one combined record.
- Keep the SPF record short enough to stay within SPF DNS lookup limits.
- Do not treat SPF pass alone as a complete authentication setup. Check DKIM, DMARC, and alignment too.

## Fix Common Issues
### Invalid SPF Domain

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

1. Remove `https://`, `www.`, page paths, spaces, and email mailbox names from the domain or host name you entered.
2. Enter 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 that screen.
4. Run the SPF checker again with that host name.
5. After the SPF record passes, send a real test email. If you want SPF to help DMARC, confirm that the SPF domain aligns with the visible From domain.

### Missing SPF Record

An SPF checker says no SPF record was found. 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 your domain and find its SPF, return-path, bounce domain, or domain authentication instructions.
2. Copy the exact DNS host name and TXT record content that the service provides. Do not copy a generic SPF example from another site.
3. Open the DNS provider that hosts your 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. If you want SPF to help DMARC, confirm that the SPF domain lines up with the visible From domain.

### Multiple SPF Records

An SPF checker found more than one SPF TXT record at the same host name. Receivers can treat multiple SPF records 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 email for your domain.
2. Create one combined SPF record that includes all approved senders.
3. Save only one `v=spf1` TXT record at that host name.
4. After the combined SPF record is saved, delete the extra SPF TXT records.
5. Run the SPF checker again and confirm that the SPF result reports exactly one SPF record.
6. Send a test email from each email delivery service or system that still sends email for your domain.

### SPF Lookup Limit

An SPF checker says SPF is close to or above the 10 DNS lookup limit. SPF can fail when receivers expand all includes, redirects, `a`, `mx`, `ptr`, or `exists` mechanisms and the lookup count is too high.

1. Remove email delivery services and systems that no longer send email for your domain.
2. Remove 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 sending systems.
5. Do not manually flatten SPF unless you have a process to update the SPF record when email delivery service IP addresses change.
6. Run the SPF checker again before you add another sender to the same SPF record.

### SPF Ending Policy

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

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

### SPF PTR Mechanism

An SPF 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 fail to 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): Read 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 what inbox providers learn to trust. Authentication proves that your email delivery service is allowed to send email for your domain.

- [From, Reply-To, and Return-Path](https://mailrith.com/guides/from-reply-to-and-return-path.md): An email can include several sender-related addresses. Each address has a separate role for delivery, authentication, or replies.

- [DNS, PTR, and Reverse DNS](https://mailrith.com/guides/dns-and-reverse-dns.md): DNS records identify your domain. Reverse DNS helps inbox providers check that a sending IP address has a valid hostname.
