What are the best practices for SPF records and avoiding CNAMES for email authentication?
Updated on 21 Oct 2026: We clarified SPF lookup limits and CNAME delegation, added loop troubleshooting, and revised hard-fail guidance for current DMARC standards.
The best practice is to publish Sender Policy Framework (SPF) as a TXT policy on the domain that actually appears in the SMTP return-path, keep it short, and authorize only real sending sources. A direct TXT record keeps your policy visible in your DNS zone. If a provider requires a CNAME for a custom return-path, follow its documented setup and track the delegation through retirement.
Use dedicated return-path domains for senders that support them, publish literal IP ranges when you control stable dedicated sending IPs, and remove every include that is not tied to active mail. CNAMEs can make vendor onboarding easier, but their targets require ownership checks and removal when the sender is retired.
- Publish SPF as a TXT record wherever SPF is evaluated, usually the envelope sender domain.
- Do not point old subdomains at vendors, expired assets, or sender infrastructure you no longer control.
- Authorize only mail streams that use that domain in the return-path. A DKIM-based DMARC pass does not justify adding an unrelated SPF include.
- Review SPF, DKIM, DMARC, and sending sources continuously, not only during setup.
Where to publish SPF TXT records
For most domains, the right SPF pattern is a single TXT record that starts with v=spf1, contains only necessary mechanisms, and ends with -all or ~all according to your handling policy. Never publish +all, because it authorizes every sending IP that reaches it. The record should live on the domain used in the bounce address, because SPF checks the SMTP MAIL FROM domain, not the visible From header. For messages with an empty MAIL FROM, SPF uses the HELO/EHLO domain.
If your marketing platform sends mail with a custom return-path such as bounce.example.com, put the SPF authorization there. If your corporate mail uses the organizational domain in the return-path, authorize only that corporate mail system there. Do not blindly add every sender to the root domain just because a setup guide says to add an include.
-all produces SPF fail for unlisted sources; ~all produces softfail. Neither result satisfies SPF for DMARC, and final delivery depends on receiver policy. RFC 9989 warns that some receivers reject hard failures before checking DKIM or DMARC, including forwarded mail. Choose the qualifier after testing legitimate mail flows; use -all for domains that send no mail.
Direct SPF TXT recordDNS
example.com. TXT "v=spf1 ip4:203.0.113.25 ip4:203.0.113.26 -all"
Provider include used only where neededDNS
bounce.example.com. TXT "v=spf1 include:spf.sender.example -all"
The second example is common when a vendor manages a sending pool. It is still a TXT record, and it is placed on the return-path subdomain instead of bloating the root domain. Before publishing it, confirm that the vendor actually uses that return-path domain in live mail. The example domains and IP addresses are documentation placeholders; replace them with your provider's values.
CNAME delegation risks for SPF
CNAMEs are attractive because they let a provider move infrastructure without asking every customer to edit DNS. That convenience has real operational value. The tradeoff is that the domain owner loses direct visibility into what the name authorizes over time, and an abandoned CNAME can become a durable authentication gap. A TXT record using include or redirect also trusts an external policy, so publishing TXT directly does not remove vendor dependencies.
A hostname with a CNAME is an alias and cannot also publish an SPF TXT record, MX record, or other ordinary data at that same name. When an SPF lookup follows the alias, the TXT policy returned by the CNAME target controls the result. Do not try to combine a provider CNAME and your own SPF TXT record at one hostname. A standard CNAME also cannot replace the zone apex, which must retain SOA and NS records. These DNS constraints are defined in RFC 1034.
The risky pattern is a delegated subdomain that remains published after the related account or target is no longer controlled by the original owner. If someone can reclaim the target or linked account and control its SPF policy, they can authorize their own sending IPs. Under relaxed DMARC domain matching, that subdomain can also authenticate mail using the organizational domain in the visible From header. RFC 9989 describes this subdomain delegation risk.
CNAME delegation flowchart showing how a forgotten provider record can lead to email sender abuse.
Direct SPF TXT
- Your DNS zone contains the visible authorization rule.
- Reviewers can see IPs, includes, and fail mode in one place.
- External includes and redirects remain dependencies that need ownership reviews.
CNAME-delegated SPF
- Providers can update the target SPF policy without another customer DNS request.
- Authorization can change outside your normal review process.
- Old targets, accounts, or subdomains can remain trusted too long.
A CNAME adds DNS resolution work, but the alias itself is not one of SPF's lookup-counting terms. SPF permits at most 10 evaluated DNS-triggering terms, including nested records: include, a, mx, ptr, exists, and redirect. The initial SPF TXT query, ip4, ip6, and all do not count toward that limit. Evaluation stops at a matching mechanism, so test paths that reach later terms as well. Exceeding 10 evaluated terms produces permerror. RFC 7208 defines these processing limits.
How to diagnose SPF CNAME loops
A CNAME loop points back to a name already in the alias chain, preventing the TXT lookup from reaching a final SPF policy. DNS resolvers signal an error instead of following the loop indefinitely. This behavior is described in RFC 1034.
Inspect the return-path and provider targetBASH
dig +noall +comments +answer TXT bounce.example.com dig +noall +comments +answer CNAME bounce.example.com dig +noall +comments +answer TXT spf.sender.example
- Replace bounce.example.com with the domain shown in smtp.mailfrom, then inspect both its TXT and CNAME answers.
- Query each CNAME target until you reach a TXT policy beginning v=spf1. A repeated name identifies a loop; an A record alone is not an SPF policy.
- Follow include and redirect targets separately. These are SPF terms, not CNAME records, and recursive policy references can exhaust the 10-term allowance.
- Correct the looping alias or policy reference, confirm the authoritative DNS answer, then retest received headers after cached answers expire.
A DNS SERVFAIL or timeout during SPF evaluation produces temperror. Exceeding the SPF term limit produces permerror. A missing SPF policy at an include target also produces permerror. These results do not guarantee message rejection; receiver handling and a passing DKIM signature with the required domain match still matter. See RFC 7208.
Best practices for SPF record structure
SPF works best when each record has one job. Do not make the root domain a dumping ground for every system that sends a notification, invoice, campaign, survey, and support ticket. Start by mapping which domain each mail stream uses for its envelope sender, then publish SPF where that envelope sender lives. SPF is not inherited: a policy at example.com does not cover bounce.example.com.
Keep corporate and third-party return-path domains separate where the sender supports it. Moving an include to another hostname without changing the actual return-path does not create a separate SPF evaluation or lookup allowance.
|
|
|
|---|---|---|
Dedicated IPs | Use ip4 or ip6 | Direct and easy to audit |
Shared pool | Use scoped include | Keeps the root policy smaller; still trusts the provider pool |
Unused sender | Remove it | Reduces stale trust |
Many vendors | Split by return-path | Avoids root-domain bloat |
No mail | Use -all | Signals no authorized senders |
SPF decisions that keep records small and auditable.
- A domain must not publish multiple SPF TXT records. Merge them into one, because selecting more than one produces permerror.
- SPF permits 10 DNS-triggering terms across the complete evaluation. The eleventh produces permerror, and nested includes count.
- Use ip4 or ip6 for stable public outbound sending IPs, including IPv6 where used. Keep CIDR ranges limited to authorized sending addresses.
- The mechanism is slow, fragile, and inappropriate for modern SPF records.
- Choose -all or ~all after testing legitimate mail flows. Both leave unlisted sources without an SPF pass for DMARC; never use +all.
- Use 3600 seconds as a normal TTL baseline unless your DNS change policy requires another value. Lower the TTL ahead of planned changes and allow the previous TTL to expire.
Each quoted TXT character-string is limited to 255 octets, but one SPF record can contain multiple strings. Receivers concatenate them without inserting spaces, so preserve any spaces needed between SPF terms. There is no SPF-wide 250-character limit. Keep the full DNS response small, and do not create a second TXT record that also begins with v=spf1. Publish the TXT record type rather than the obsolete SPF type 99. See RFC 7208.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
A quick SPF checker pass is useful before changing DNS, but it does not replace sending-source review. A syntactically valid record can still authorize the wrong sender, include a vendor that no longer sends for you, or pass only because the envelope sender is not the domain you assumed.
When a CNAME is acceptable
DKIM commonly uses CNAME delegation for selectors, because the provider rotates keys or manages signing infrastructure. A CNAME is also a valid documented setup for some custom return-path domains: the SPF TXT query follows the alias to the provider policy. Do not replace a required CNAME with TXT without confirming the provider supports that change.
For SPF, document why the provider needs delegation, who owns the target, how it is monitored, and what happens when the sending relationship ends. If the provider supports direct TXT, an include authorizes its passing sources while your local record retains the final all rule. A redirect delegates the remaining policy result and is ignored when your record contains an all mechanism.
A practical compromise is to keep root-domain SPF direct, then use dedicated return-path subdomains for third-party systems. If a sender requires delegation, delegate only the sender-specific subdomain and put it on an owner review schedule.
SPF configuration infographic showing root TXT policy, custom return-path, vendor include, and review date.
Suped's hosted SPF uses an SPF redirect published in a TXT record, rather than a CNAME at the return-path hostname. Teams manage sender authorization in Suped while the service refreshes the hosted policy. This still delegates SPF policy control, so document the owner and removal process.
The return-path decides where SPF matters
The most common SPF mistake is adding an include to the organizational domain when the sender never uses that domain as the envelope sender. That creates bloat with no authentication benefit. It can also hide a real problem, because the visible From domain can pass DMARC through DKIM domain match while SPF is being evaluated somewhere else.
When onboarding a sender, send a test message and inspect the headers. Check Return-Path and the receiving server's trusted Authentication-Results header for SPF and DMARC results. If the return-path is a vendor domain, your root-domain SPF record is not helping SPF pass DMARC. If the return-path is a branded subdomain, configure SPF on that subdomain using the supported TXT or CNAME setup.
Header fields to inspecttext
Return-Path: <bounces@bounce.example.com> Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
- Use the SMTP MAIL FROM domain, not the visible From header.
- Confirm whether SPF or DKIM matches the visible From domain for DMARC.
- Place SPF authorization on the domain used for envelope mail, with a separate policy for each sending subdomain.
- Delete includes for senders that do not use the domain in SPF evaluation.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A message can pass SPF on one domain, pass DKIM on another domain, and still fail DMARC if neither meets the visible From domain's matching requirements. DMARC needs either SPF or DKIM to pass with the required domain match. With default relaxed SPF matching, bounce.example.com and example.com share an organizational domain; with aspf=s, the SPF domain must match the visible From domain exactly. Forwarding often breaks SPF, so configure DKIM with a matching domain too. See RFC 9989.
How to clean up an existing SPF record
SPF cleanup should be methodical. Start with what mail is really being sent, then map each source back to the DNS record. Do not start by editing includes randomly. That turns a messy record into a fragile record.
A cleanup project should classify each sender as active, inactive, or unknown. Active senders stay only if they use the domain being evaluated. Inactive senders are removed. Unknown senders go through owner discovery, test sends, and DMARC report review.
SPF cleanup thresholds
These are operational review bands, not extra SPF limits. Count the terms reached on each evaluation path, including nested records.
Healthy
0-6 terms
One SPF record, fewer than 7 DNS-triggering terms, and all includes tied to active senders.
Watch
7-9 terms
Seven to nine evaluated terms are within the limit; review nested provider changes and remaining margin.
At the limit
10 terms
Ten terms are allowed, but the record has no room for another DNS-triggering term.
Over the limit
11+ terms
Evaluation beyond ten DNS-triggering terms returns permerror.
- List all TXT, CNAME, MX, and related sender records for the domain.
- Resolve every include and redirect, follow nested policies, and test the highest-lookup paths for all active senders.
- Investigate empty and nonexistent DNS answers. RFC 7208 recommends a two-void-lookup limit; exceeding an enforced limit returns permerror.
- Tie each sender to a team, account owner, and business purpose.
- Use DMARC aggregate data and sending logs across a representative sending cycle, including infrequent senders, before removal.
- Save the current record for rollback, apply removals in small batches, then test live headers after DNS caches expire.
If the record is near the lookup limit, SPF flattening can reduce lookup pressure, but it needs automatic refresh. A one-time manual snapshot gets stale when providers change IP ranges, so flatten only sources whose IP changes can be tracked and republished. Follow provider guidance before flattening dynamic shared pools, and check that the resulting TXT response remains small. Suped's hosted SPF workflow refreshes flattened output as sender IPs change.
Manage SPF changes with Suped
Suped's DMARC reporting platform connects SPF cleanup to observed sending sources. Use its SPF and DKIM results to investigate a failing mail stream, then manage approved senders through Suped's hosted SPF and automated flattening workflow when lookup pressure requires it.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
Keep a named owner for each authorized sender and compare authentication results before and after SPF changes. Use DNS alerts to investigate changed records, then confirm the effect in received-message headers and DMARC reports. Reports cover participating receivers and do not replace sending logs or DNS ownership checks.
Manual DNS workflow
- Every sender update needs DNS access or a ticket.
- Old includes stay because nobody owns removal.
- Without monitoring, failures surface after delivery or reporting problems.
Managed SPF workflow
- Authorized sources are managed in one place.
- Automated flattening reduces DNS-triggering terms while refreshing sender IP ranges.
- Issue detection points to the sender and fix steps.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For a first pass across DMARC, SPF, and DKIM, a domain health check helps surface obvious DNS and authentication issues. The deeper work is then deciding which senders deserve authorization and which old records need to be removed.
Examples of better SPF patterns
The right record depends on the mail stream. Each domain should authorize the smallest reasonable set of sources for the mail it actually sends. A single giant SPF record that authorizes everything everywhere makes ownership and lookup control harder.
Corporate mail onlyDNS
example.com. TXT "v=spf1 include:spf.protection.example -all"
Transactional sender on branded return-pathDNS
mail.example.com. TXT "v=spf1 ip4:198.51.100.40 ip4:198.51.100.41 -all"
No-mail subdomainDNS
old.example.com. TXT "v=spf1 -all" _dmarc.old.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
For a retired or parked domain that sends no mail, publish v=spf1 -all and a DMARC policy that rejects unauthorized use of its visible From domain. A DMARC policy can be inherited, but an SPF policy does not automatically cover child subdomains. Remove a stale CNAME before publishing TXT at the same name; the records cannot coexist.
The safest SPF record is often the shortest one that accurately covers active mail. If the record is long because nobody knows what can be removed, the problem is governance, not syntax.
SPF ownership review checklist
Best practices
Audit return-path domains before adding SPF includes to the organizational domain.
Publish dedicated IP ranges directly when stable dedicated IPs send mail for your domain.
Review old CNAMEs and sender subdomains during each scheduled DNS ownership review cycle.
Use DMARC reports and sending logs before removing a disputed sender from the SPF policy.
Common pitfalls
Blindly adding vendor includes creates SPF bloat without improving DMARC domain match.
Forgotten CNAME targets can remain trusted after the vendor relationship ends or expires.
A passing SPF result is misleading when it applies only to the wrong return-path domain.
Manual SPF flattening gets stale when providers change sending infrastructure later.
Expert tips
Treat provider CNAMEs as delegated trust and document the owner of each target name.
Keep root-domain SPF narrow and move third-party mail to scoped return-path subdomains.
Set restrictive SPF and DMARC policies on retired domains that should never send mail.
Pair SPF review with DKIM and DMARC domain checks, and test actual received messages.
Frequently asked questions
Use a direct TXT record where supported. A documented provider CNAME is valid for a custom return-path when its target returns an SPF TXT policy. Monitor the delegation, use a sender-specific subdomain, and remove it when the sender is retired.
No. A CNAME makes the hostname an alias and cannot coexist there with an SPF TXT record or other ordinary DNS data. Choose the alias or publish the TXT record directly at that hostname.
Publish SPF on the domain used in the SMTP return-path. SPF does not check the visible From header, so adding an include to the root domain helps only when that domain is evaluated. Subdomains do not inherit the parent SPF record. For an empty MAIL FROM, SPF uses the HELO/EHLO domain.
Publish ip4 or ip6 values when you control stable public sending IPs. Use provider includes for shared pools that change, on the correct return-path domain. Keep CIDR ranges narrow and follow provider guidance before flattening.
SPF permits at most 10 evaluated DNS-triggering terms, including nested include and redirect policies. The counting terms are include, a, mx, ptr, exists, and redirect. The initial TXT query and CNAME hops do not each consume a term. Exceeding 10 evaluated terms produces permerror; void lookups have a separate recommended limit of two.
No. SPF authenticates the envelope sender rather than the visible From address. DMARC needs either SPF or DKIM to pass with the required domain match. Configure both SPF and DKIM because forwarding commonly breaks SPF.
