Key takeaways
- SPF evaluates whether a sending IP is authorized for the relevant SMTP domain.
- It does not directly authenticate the visible From address or encrypt the message.
- Keep one valid policy and test every legitimate sending stream after changes.
Overview
SPF is evaluated against the sending IP and the relevant envelope identity, not simply the visible From address a recipient sees. A DNS record describes allowed senders. Forwarding can complicate evaluation because the forwarding server may not be authorized by the original domain. DMARC uses alignment to connect authentication with the visible author domain.
How it works
Inventory the services legitimately sending for the domain.
Publish a valid SPF policy covering those services within protocol limits.
Test actual messages and monitor authentication results after changes.
Distinguish the envelope sender from the visible author
Email carries several identities. The address shown in a mail client’s From field is not necessarily the domain evaluated by SPF during SMTP delivery. SPF checks the sending infrastructure against the relevant envelope identity. DMARC adds an alignment requirement connecting a passing authentication result to the visible author domain.
This distinction explains why a message can show SPF pass but still fail DMARC. A provider may be authorized to send for its own return-path domain while that domain is unrelated to the visible From domain. Inspect the received authentication results and actual domains instead of treating a green SPF indicator as proof that the complete sender setup is correct.
| Check | Primary question | Separate concern |
|---|---|---|
| SPF | Is this infrastructure authorized for the evaluated domain? | Visible-author alignment |
| DKIM | Does this domain-linked signature verify? | Whether the signing domain aligns |
| DMARC | Does passing authentication align with the author domain? | Whether the message is wanted or safe |
Source material: IETF / RFC Editor — RFC 7208: Sender Policy Framework ↓ · IETF / RFC Editor — RFC 9989: DMARC ↓
Inventory senders before editing DNS
List the systems sending legitimate mail: employee mail, support, invoices, product notifications and marketing may use different providers. Confirm which domains each stream uses and follow each provider’s current setup instructions. Avoid adding a new SPF record for every service; the domain needs one valid policy that represents the intended senders.
Review the protocol’s DNS lookup limits, including lookups caused by nested includes. A record can look short while triggering more work than expected. Remove obsolete authorization carefully after confirming that the service is no longer used. Treat a sending-provider migration as a coordinated change rather than a copy-and-paste DNS task.
Test the message path that users actually rely on
Use controlled test messages from each legitimate service and inspect the headers at the receiving end. Check the evaluated domain, sending IP and result. Forwarding can change the sending IP seen by the final receiver, so a direct-delivery test may not cover every path. DKIM and DMARC results provide additional context for those cases.
An illustrative support-provider change may leave employee mail passing while support replies fail. Testing only one mailbox would miss the defect. Keep a sender inventory and a record of the configuration change, then monitor failures by stream. A DNS lookup tool confirms the published record; it does not prove every real message uses the intended identity.
What this looks like in practice
A company adds a support-mail provider to its sending setup. Administrators update the existing SPF policy and test a real message rather than publishing a second competing SPF record.
Examples explain the concept; they are not reported customer results.What to check
Check record validity, authorized services and DNS lookup behavior. Remove obsolete senders carefully and verify that all legitimate mail streams still authenticate.
Common mistake
Assuming SPF pass alone proves that the visible From address belongs to the authenticated domain or that the message content is trustworthy.
Sender Policy Framework vs. DomainKeys Identified Mail
SPF authorizes sending infrastructure for an envelope domain. DKIM uses a cryptographic signature tied to a domain and selected message content. They provide different authentication evidence.
Read the DomainKeys Identified Mail definition →Questions answered
What is Sender Policy Framework?
Sender Policy Framework, or SPF, is an email authentication mechanism that lets a domain publish which mail servers are authorized to send for the envelope sender domain used in an SMTP transaction.
Does SPF encrypt email?
No. SPF checks whether a sending server is authorized for the evaluated domain. It does not encrypt message contents.
Should each provider create a separate SPF record?
A domain should have a valid single SPF policy rather than multiple competing SPF records. Incorporate legitimate senders according to the protocol and provider instructions.
Can SPF stop all spoofing?
No. SPF checks authorization for the evaluated SMTP domain, while visible-author alignment and other forms of impersonation are separate concerns. Use DMARC context and broader mail controls. Authentication also does not establish that an otherwise valid sender’s message is harmless or desired.
Why can forwarding cause an SPF failure?
The final receiver may see the forwarding server’s IP rather than the original sender’s, and that IP may not be authorized by the original envelope domain’s policy. Forwarding implementations vary. Inspect the actual message path and other authentication results rather than assuming the original sender’s policy alone explains the outcome.
References and further reading
Primary documentation and source material for this topic. Sources checked September 14, 2026; provider requirements can change.
- RFC 7208: Sender Policy Framework ↗IETF / RFC Editor
- Email sender guidelines ↗Google
- RFC 9989: DMARC ↗IETF / RFC Editor
Current DMARC specification; replaces RFC 7489 together with the separate reporting specifications.
Continue reading on the blog
- Email verification and deliverability in outbound workflows →
- Personalize outreach with supporting evidence →
Put the concept to work.
Explore the relevant AstroFabric workflow and see how the pieces connect.
Help keep this guide useful. Suggest a correction or browse the full glossary.