Against which domain is SPF checked?
Updated on 14 Oct 2026: We clarified SPF domain checks and added guidance for forwarded email.
SPF normally checks the domain in the SMTP MAIL FROM command, which is commonly seen after delivery as the Return-Path domain. SPF does not check the visible From address in the message header. For a null reverse-path, as used by many bounce messages, SPF constructs the MAIL FROM identity from the HELO or EHLO domain. A receiver can also check HELO as a separate SPF identity on ordinary mail.
Some senders add every email platform to their main domain's SPF record and assume that authenticates mail using info@example.com in the visible From header. That record applies when the same domain is used in MAIL FROM. If the message uses bounce.mailer.example as its MAIL FROM domain, the SPF record at that bounce domain is what the receiver evaluates.
- Normal mail: The message-level SPF result checks the domain used in MAIL FROM, often shown later as Return-Path.
- Null sender: SPF uses the HELO or EHLO domain to construct the MAIL FROM identity.
- Separate HELO check: A receiver can evaluate the sending host's HELO domain independently.
- Visible From: SPF does not authenticate the From header directly.
Which domain SPF checks
The usual SPF domain is the domain part of RFC5321.MailFrom, the SMTP envelope sender address. Its domain is often called the bounce domain or MAIL FROM domain. If the reverse-path is <>, RFC 7208 defines the MAIL FROM identity as postmaster at the connecting host's HELO or EHLO domain. SPF checks whether the connecting server's IP address is authorized to send for this domain.
|
|
|
|---|---|---|
Campaign with a custom bounce address | MAIL FROM bounce domain | SPF TXT on bounce domain |
Direct mailbox | MAIL FROM domain | SPF TXT on that domain |
Bounce with a null reverse-path | HELO name | SPF TXT on HELO host |
Provider-owned return path | Provider bounce domain | Provider maintains SPF for its domain |
Which domain SPF uses in common message cases.
Plain rule
If a message has From: alerts@example.com but the SMTP envelope sender is bounce@send.example.net, SPF checks send.example.net. The SPF record at example.com does not decide that SPF result.
SPF starts its DNS TXT lookup at that exact domain. An include or redirect can consult another domain's SPF policy, but it does not change the authenticated SPF identity. A name such as _spf.example.com is a policy reference, not the default SPF lookup location.
How HELO SPF differs from MAIL FROM SPF
SPF has two SMTP identities. RFC 7208 recommends that a receiver check the HELO identity separately and, when both identities are checked, evaluate it before MAIL FROM. A valid multi-label HELO name can therefore have its own SPF result even when MAIL FROM is not empty.
Keep those results separate when reading headers. RFC 9989 defines the SPF Domain for DMARC as the domain of the validated MAIL FROM identity. A passing separate HELO check can inform a receiver's filtering decision, but it does not supply SPF alignment for DMARC.
Null reverse-path nuance
When the SMTP reverse-path is <>, SPF constructs a MAIL FROM identity such as postmaster@mx.example.com from the HELO domain. That MAIL FROM evaluation is distinct from a separate HELO-only check.
Two SPF identities in Authentication-Resultstext
Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=send.example.com; spf=pass smtp.helo=mx.example.com
How Return-Path relates to MAIL FROM
The Return-Path header is normally added by the server making final delivery. During the SMTP transaction, the sender gives the receiver a MAIL FROM value. At final delivery, the receiving system writes that value into the Return-Path header. So when people say SPF checks Return-Path, they are using the practical post-delivery name for the same envelope identity.
The visible From address has a different job. RFC 9989 calls its domain the Author Domain and uses it as the anchor for DMARC alignment. A message can pass SPF and still fail DMARC when the SPF Domain lacks the required domain alignment and no passing DKIM signature has the required domain alignment.
SPF identity flowchart covering MAIL FROM and the HELO domain for a null reverse-path.
Illustrative SPF TXT records for MAIL FROM domainsdns
example.com. TXT "v=spf1 include:_spf.mail.example -all" send.example.com. TXT "v=spf1 ip4:198.51.100.25 -all" mailer.example.net. TXT "v=spf1 include:_spf.provider.example -all"
These domains and IP addresses are documentation examples. Use your sender's published values for production DNS.
What receivers actually check
The SPF protocol has defined identities, but receivers also run their own filtering logic. A receiver can look at the visible From domain, HELO, reverse DNS, DKIM, content, IP history, blocklist (blacklist) signals, user engagement, and other signals. Those extra checks do not change what an SPF pass means. They are separate filtering decisions around the SPF result.
Publish SPF includes on both the visible From domain and the return-path domain only if legitimate mail actually uses both as SMTP envelope sender domains. Extra filtering checks are not a reason to add unused senders to the visible From domain's SPF record.
SPF result
- Identity: Uses the envelope sender domain, or the HELO domain for a null reverse-path.
- Record: Reads the SPF TXT record published at that exact SPF domain.
- Output: Returns pass, fail, softfail, neutral, permerror, temperror, or none.
Mailbox filtering
- Signals: Combines authentication, reputation, complaint history, and content checks.
- Rules: Each receiver chooses its own private acceptance and placement rules.
- Output: Decides inbox, spam folder, quarantine, rejection, or rate limiting.
Avoid unnecessary SPF includes
If a third-party platform uses its own return-path domain, adding that platform to your main domain SPF record does not make SPF pass for that platform's return path. It adds unnecessary lookup cost and authorizes the platform to use your main domain as MAIL FROM.
Why adding every sender to the From domain SPF record backfires
SPF has a hard DNS lookup limit. Mechanisms such as include, a, mx, ptr, and exists, plus the redirect modifier, count toward that limit. Nested includes count toward the same evaluation-wide total. When the receiver encounters more than 10 DNS-querying terms while evaluating the record, SPF returns a permanent error. In practice, that turns a record meant to help authentication into a delivery risk. The ip4, ip6, and all mechanisms do not count toward this term limit. The ptr mechanism is supported but discouraged.
SPF DNS lookup pressure
Planning ranges, not SPF validation grades. Count evaluated DNS-querying terms, including nested includes; the protocol limit is 10.
Lower usage
0-6
Room below the term limit; syntax and other DNS limits still apply.
Near limit
7-9
Review includes before adding another sending source.
At term limit
10
No room for another DNS-querying term during evaluation.
Over limit
11+
SPF returns permerror when the limit is exceeded.
The cleaner pattern is to publish SPF on the exact return-path domain each sender uses. If your application sends with bounces.app.example.com, put the application SPF policy there. Each active return-path subdomain needs an SPF policy available at that exact name because SPF does not automatically inherit the parent domain's policy. Follow the sender's DNS instructions for a custom return path. If your newsletter platform uses a provider-controlled return path, your visible From domain SPF record is not involved in that SPF pass.
When a legitimate SPF record is near the 10-lookup limit, use SPF flattening carefully. Flattening is not a reason to keep unnecessary senders in the wrong record. Static flattened IP addresses can become stale when a provider changes its sending network, so the flattened record needs active maintenance.
How DMARC checks SPF domain alignment
For an SPF-based DMARC pass, SPF must pass and the MAIL FROM domain must have domain alignment with the visible From domain, called the Author Domain in RFC 9989. Under relaxed alignment, both have the same organizational domain. Under strict alignment, the domains are identical. The aspf=r setting is relaxed and is the default; aspf=s requires strict alignment.
For example, SPF can pass for mailer.example.net without passing SPF-based DMARC for an Author Domain of example.com. A passing DKIM signature with the required domain alignment can still provide the DMARC pass.
SPF passes and helps DMARC
The visible From domain is example.com. The return-path domain is bounce.example.com. SPF passes for the bounce domain, and relaxed DMARC alignment passes.
SPF passes but does not help DMARC
The visible From domain is example.com. The return-path domain is mailer.example.net. SPF passes for the provider domain, but DMARC needs a passing aligned DKIM signature or a custom return path that passes SPF with the required domain alignment.
Keep the SPF setup question separate from the DMARC result question. SPF belongs on the return-path domain. DMARC then checks whether that SPF Domain has domain alignment with the Author Domain, or whether aligned DKIM gives the message its DMARC pass.
Which domain SPF checks after forwarding
SPF uses the connecting IP and MAIL FROM identity at the receiving server. If a forwarder preserves bounce@send.example.com, the destination still checks send.example.com but tests the forwarder's IP. If the policy does not authorize that IP, SPF will not pass even if it passed at the first receiver.
A forwarder using Sender Rewriting Scheme (SRS) rewrites MAIL FROM to a domain it controls. SPF then checks that domain against the forwarder's connecting IP. When that domain lacks the required domain alignment with the original visible From domain, the rewritten SPF pass does not give DMARC a pass. An intact, passing DKIM signature with the required domain alignment can still provide the DMARC pass. RFC 7960 explains these forwarding identity changes.
Compare direct and forwarded test messages before editing DNS. Do not add an unrelated forwarder to your SPF record just to make one forwarded copy pass.
How to check your own sending setup
Inspect a real delivered message, find the Return-Path value, and read the destination receiver's Authentication-Results field. The smtp.mailfrom property records the MAIL FROM identity evaluated by that receiver. It can contain a full email address or just its domain; for a full address, use the part after @ for the DNS lookup. Do not start with the visible From address unless the same domain is also used as the envelope sender.
- Find the identities: Open the original message source and locate Return-Path plus the trusted Authentication-Results field added by the destination receiver.
- Read the property: Use smtp.mailfrom for the MAIL FROM result and do not confuse it with a separate smtp.helo result.
- Check SPF: Look up that MAIL FROM domain with Suped's SPF checker to review syntax and DNS lookup count. Use the destination receiver's SPF result to confirm authorization for the actual connecting IP.
- Check record count: Confirm the domain publishes exactly one v=spf1 TXT record because multiple SPF records cause permerror. Other TXT records at the same name are allowed.
- Check DMARC: Compare the SPF Domain with the visible From domain under the configured alignment mode.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
After the SPF-specific check, Suped's domain health checker can review the related DKIM and DMARC configuration.
Header fields to comparetext
From: Marketing <news@example.com> Return-Path: <bounce@send.example.com> Authentication-Results: mx.example; spf=pass smtp.mailfrom=send.example.com
For a manual SPF lookup using the header example above, query send.example.com, not the visible From domain. These commands retrieve DNS TXT records; they do not evaluate whether a particular sending IP passes SPF or follow every nested include.
Look up the exact MAIL FROM domainbash
dig +short TXT send.example.com nslookup -type=TXT send.example.com
When Suped helps
Suped's DMARC reporting and email authentication platform helps teams compare the SPF domains and source IPs reported for their visible From domains. That comparison separates SPF authentication failures from SPF domain alignment failures.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
DMARC aggregate reports identify affected sending sources, but they do not replace inspection of a message's envelope sender or the current DNS record. In Suped, use reports to find the source, then verify the actual return-path domain before correcting missing includes, duplicate SPF records, or lookup-limit errors.
For a return-path domain you control, Suped's hosted SPF lets teams manage approved senders after the initial DNS configuration. Apply it to the actual MAIL FROM domain and verify a test message after changes.
A useful Suped workflow
- Monitor sources: Review which IPs and platforms are sending for each domain.
- Find mismatch: Spot when SPF passes on a provider domain but fails DMARC alignment.
- Fix record: Publish SPF at the actual return-path domain you control, or configure a custom return path with the required DMARC domain alignment.
- Track policy: Raise DMARC enforcement after the real sending sources are verified.
Views from the trenches
Best practices
Check the return-path domain before editing the visible From domain's SPF record.
Keep sender-specific SPF records on subdomains to protect the main domain lookup budget.
Use DKIM with DMARC domain alignment when a provider cannot offer a custom bounce domain.
Common pitfalls
Adding every provider include to the main domain creates lookup failures and noise.
Treating a provider SPF pass as a DMARC pass hides domain matching failures later.
Reading only the From header misses the envelope sender that SPF actually evaluates.
Expert tips
Review real headers and DMARC reports together before changing production DNS records.
Use a custom bounce domain when SPF domain matching is needed for a third-party sender.
Keep HELO SPF valid for mail servers that send bounce notices with an empty sender.
Marketer view
Marketer from Email Geeks says SPF checks the return-path domain, so adding a sender to the visible From domain does not help when a provider controls the bounce domain.
2020-12-03 - Email Geeks
Marketer view
Marketer from Email Geeks says many setup guides put SPF includes on the wrong domain, which pushes records close to the 10-lookup limit without improving authentication.
2020-12-03 - Email Geeks
Practical recommendation
Start with the exact SPF identity. If the return path is under your domain, make the SPF policy available there and keep it within the 10-lookup limit. If the return path belongs to a provider, your SPF include on the visible From domain does not authenticate that provider's return path. Either configure a custom aligned return path or rely on aligned DKIM for DMARC.
Only add SPF includes to the visible From domain when that domain is also used as the envelope sender. Review the record whenever sending services or infrastructure change. After a DNS change, allow for the record's cache lifetime (TTL) and send a new test message to verify the result.
