SPF Records Explained: Stop Email Spoofing at Your Domain
SPF (Sender Policy Framework) is an email authentication standard that helps receiving mail servers determine whether a sending server is authorised to send email using your domain.
For a business, this matters because attackers can forge email addresses that appear to come from your company. They may impersonate your finance department, send fake invoices, or trick customers into sharing confidential information.
An SPF record helps receiving servers identify unauthorised sending sources. When combined with DKIM and DMARC, it forms part of a stronger email authentication strategy.
However, SPF does not guarantee that every spoofed message will be blocked or that every legitimate email will reach the inbox. Receiving servers consider other authentication results, domain reputation, message content, and their own filtering policies.
How Does SPF Work?
SPF works through your domain's DNS records.
When an email server receives a message, it can check the SPF policy for the domain used in the email's SMTP envelope sender. The policy identifies the sending sources authorised by that domain.
The process generally works as follows:
Your domain publishes an SPF record as a DNS TXT record.
Your email service sends a message to a recipient.
The receiving server checks the relevant SPF policy against the sending server's IP address.
The server returns an SPF result, such as pass, fail, softfail, or neutral.
The receiving server uses that result alongside other signals to decide how to handle the message.
One important detail: SPF does not directly authenticate the visible address in the email's From field. DMARC checks whether the authenticated domain aligns with the domain displayed to the recipient.
What Does an SPF Record Look Like?
A typical SPF record for a business using a hosting provider and a separate email marketing platform might look like this:
v=spf1 include:spf.example-host.com include:send.example-marketing.com ~allThis is an illustrative example only. Replace the example domains with the exact SPF mechanisms supplied by your email providers.
Here is what each part means:
SPF element | Purpose |
|---|---|
| Identifies the record as an SPF policy. |
| Incorporates the sending policy of an authorised provider. |
| Incorporates another authorised sending service. |
| Marks other sources as softfail. |
The order of the mechanisms matters because SPF evaluates them in sequence. The all mechanism matches any source not already matched by an earlier mechanism, so it normally appears at the end.
SPF Softfail vs. Hard Fail
The final mechanism determines the result for a sending source that has not matched an earlier mechanism.
Ending | Meaning | Practical consideration |
|---|---|---|
| Softfail | Marks unlisted sources as not authorised, but does not itself require rejection. |
| Fail | Explicitly marks unlisted sources as unauthorised. The receiving server decides how to handle the result. |
| Neutral | Does not express a definitive authorisation result for unmatched sources. |
| Pass | Authorises every source and generally defeats the purpose of SPF. Avoid it. |
If you are setting up SPF for the first time, inventory all legitimate senders before selecting a strict policy. A softfail ending is not a substitute for completing that inventory, and switching to -all does not guarantee that receiving servers will reject every unauthorised message.
Three Common SPF Mistakes
1. Exceeding the Ten-DNS-Lookup Limit
SPF limits the number of DNS-querying terms evaluated during a check to ten. These can include mechanisms such as include, a, mx, exists, and redirect. Nested records can also consume the limit.
For example, your business might send email through:
Its hosting provider
An email marketing platform
A customer relationship management (CRM) system
A support ticketing platform
An invoicing application
Each provider may introduce additional DNS lookups. Combining their SPF policies without checking the total can push your record over the limit, resulting in a permanent SPF evaluation error.
How to avoid it:
List every service that sends email using your domain.
Use only the SPF mechanisms required by those services.
Remove obsolete providers and unnecessary entries.
Check the complete lookup count, including nested
includerecords.Consider a properly maintained sending architecture if you have many providers.
Do not remove a provider from your SPF record simply to reduce the lookup count unless you have confirmed it no longer needs to send email for your domain.
2. Forgetting a Legitimate Sending Service
An SPF record can be syntactically correct and still cause authentication problems if it excludes a legitimate sender.
Imagine that your website sends order confirmations through your hosting provider, while your marketing team uses a separate newsletter platform. If the newsletter platform is missing from the SPF policy, its messages may fail SPF.
How to avoid it:
Identify all services that send email using your domain.
Check the sender-authentication instructions for each provider.
Add the required SPF mechanisms to your existing record, where appropriate.
Send test messages from each service and inspect their authentication results.
Repeat the checks whenever your business adopts a new email tool.
Remember that not every service needs its own SPF record. A domain should have one SPF policy for a given DNS name, combining the mechanisms required by its authorised senders.
3. Publishing Multiple SPF Records
A domain should not publish multiple independent SPF records at the same DNS name.
For example, adding one TXT record for your hosting provider and another TXT record for your marketing platform, with both beginning with v=spf1, can cause SPF evaluation to return a permanent error.
How to avoid it:
Combine the necessary mechanisms into one SPF record rather than creating separate SPF records for each provider.
Before changing DNS, review your existing TXT records. Make sure you do not overwrite unrelated TXT records used for services such as domain verification or other email authentication protocols.
SPF and Email Forwarding
SPF can fail when email is forwarded.
When a message is forwarded, the receiving server may see the forwarding server's IP address rather than the original sender's authorised server. If that forwarding server is not authorised by the original envelope-sender domain, SPF can fail.
DKIM can help because it uses a cryptographic signature that can remain valid when the signed message content and relevant headers are preserved. However, forwarding systems or mailing lists that modify the message can also cause DKIM verification to fail.
This is one reason SPF should not be used alone.
SPF vs. DKIM vs. DMARC
The three standards work together, but each has a different purpose.
Protocol | Main purpose |
|---|---|
SPF | Checks whether a sending IP address is authorised by the relevant envelope-sender domain. |
DKIM | Verifies a cryptographic signature associated with a signing domain and the signed parts of a message. |
DMARC | Checks alignment with the visible From domain and specifies a policy for messages that fail DMARC. |
DMARC can pass when either SPF or DKIM passes with the required domain alignment. Configuring all three gives your domain a more complete email authentication setup.
For more information, read our guides to SPF records, DKIM email signing, and DMARC enforcement.
How to Set Up or Check Your SPF Record
Follow these steps before making changes to your domain's DNS.
Step 1: Identify Your Email Providers
List every service that sends messages using your domain, including business mailboxes, website notifications, newsletters, CRM systems, and invoicing tools.
Confirm which domain each service uses as its SMTP envelope sender. Some providers use a separate sending subdomain, which may require its own SPF policy.
Step 2: Check Your Existing DNS Records
Use your DNS management panel or an SPF lookup tool to inspect the TXT records published for the relevant domain.
Confirm whether an SPF record already exists. If it does, update it rather than creating a second one.
Step 3: Build the Correct SPF Policy
Follow each provider's documented configuration instructions. Include only the sending sources that need authorisation, and ensure the record stays within SPF's DNS-lookup limit.
Avoid copying SPF records from another business. The correct policy depends on your own email services and sending configuration.
Step 4: Publish and Validate the Record
Save the SPF record in the authoritative DNS zone. DNS changes can take time to become visible because of caching and TTL settings.
Use an SPF validation tool to check for syntax errors, duplicate SPF records, and excessive DNS lookups.
Step 5: Test Your Email Authentication
Send test messages from each legitimate sending service to a mailbox where you can inspect the message headers.
Look for authentication results such as:
spf=pass
dkim=pass
dmarc=passThese results are illustrative. A successful test message should reflect your actual domain, sending service, and recipient's authentication checks.
If SPF fails, investigate the envelope-sender domain, sending IP address, DNS record, and any provider-specific configuration before changing the policy.
How SteboHost Can Help With SPF Configuration
Correct SPF configuration is an important part of running business email on your own domain. It helps receiving servers evaluate whether your messages come from authorised sending sources and supports a broader email security strategy.
With SteboHost business email hosting, businesses can explore email services for their domain. Before publishing or modifying SPF records, confirm which sending sources are covered by your specific service and whether any third-party platforms need additional DNS configuration.
If you use external email marketing, CRM, or transactional email tools, make sure their sending domains and authentication requirements are documented as part of your setup.
Frequently Asked Questions
Does an SPF record stop all email spoofing?
No. SPF helps receiving servers evaluate whether a sending source is authorised for the relevant envelope-sender domain. It does not authenticate every visible From address by itself, and it cannot prevent every form of impersonation. DMARC, DKIM, and appropriate email security controls provide additional protection.
Can I have two SPF records for one domain?
You should publish only one SPF record at a given DNS name. If multiple services send email for that domain, combine their required mechanisms into one policy. Multiple SPF records can cause a permanent evaluation error.
Is ~all better than -all?
Neither is universally better. ~all produces a softfail result for unmatched sources, while -all produces fail. Both should reflect an accurate inventory of your legitimate senders. The receiving server decides how to handle the result, and DMARC policy and alignment also affect the final outcome.
Does SPF improve email deliverability?
Correct SPF configuration can help email authentication and support deliverability. However, it does not guarantee inbox placement. DKIM, DMARC, sender reputation, message quality, recipient engagement, and receiving-server policies also matter.
What happens if my SPF record exceeds ten DNS lookups?
The SPF evaluation can return a permanent error, commonly reported as permerror. This can undermine authentication and affect DMARC results when SPF is the only aligned method that could pass. Review nested lookups and remove unnecessary mechanisms without excluding legitimate sending services.
Does every subdomain need an SPF record?
SPF policies are evaluated for the relevant domain used by the email transaction. A subdomain that sends email may need its own SPF policy, depending on its configuration. Do not assume that the root domain's record automatically authorises every subdomain.
Final Thoughts
SPF is a foundational part of email authentication, but it must be configured carefully. A valid record should authorise your legitimate sending services, avoid duplicate policies, and stay within the DNS-lookup limit.
Review your SPF record whenever you introduce a new email platform or change providers. Then test it alongside DKIM and DMARC to build a more reliable authentication setup for your business domain.
Explore SteboHost business email hosting to learn more about email services for your domain.
Written by Beth Wangui
SteboHost engineering and operations team. We write practical guides on hosting, domains, email and security for African businesses — based on what we see in the field, not marketing copy.
Ready to get started?
Browse our hosting plans or contact our team for help choosing the right one.