SummarySPF lets you publish which servers may send for a domain. Include every service you use, from your mailbox to your newsletter and website forms.
In this guide
How SPF checks an email
Suppose a studio uses one service for its mailbox and another for its newsletter. Each service has sending servers. The studio’s SPF record lists which servers are allowed to send for its domain.
DNS (the Domain Name System) holds a domain’s public settings. SPF is stored there as a TXT record: text that receiving mail servers can look up.
- The service sends
The newsletter server connects to the recipient’s mail server.
The recipient’s server can see the sending IP address. - The receiver checks DNS
The newsletter uses
The receiver looks up that domain’s SPF TXT record.studio.examplefor its envelope sender. - SPF returns a result
If the record allows the sending IP, SPF passes.
The receiver uses this alongside other checks to decide what to do with the email.
Which domain does SPF check?
SPF checks the domain in the envelope sender, the return address used for bounced mail. This can differ from the visible From address. Your provider may use your domain, a subdomain or its own domain. Its setup instructions will tell you which SPF record to update.
The technical detail: MAIL FROM, Return-Path and HELO
During SMTP delivery, the receiver compares the connecting server’s IP address with the SPF policy for the domain in MAIL FROM. The delivered message’s Return-Path header normally records that envelope address; it is distinct from the visible From header.
SPF also recommends a separate check of the HELO/EHLO hostname used to introduce the sending server. A receiver must check MAIL FROM when HELO was not checked or did not give a definitive result. With an empty reverse-path, such as a bounce message, SPF constructs postmaster@ plus the HELO domain as the MAIL FROM identity. SPF standard, sections 2.3–2.4.
List the services that send your everyday mail, newsletters, invoices and website notifications. Keep each provider’s domain setup instructions with the list, including any dedicated return-path subdomain it uses.
Download email service list template (CSV). Use a row for each service and add another if it sends from several domains.
Read the parts of a record
v=spf1 include:work.example include:news.example ~allv=spf1- Identifies this TXT record as an SPF record.
include:- Checks another domain’s SPF record. If that check passes, the include matches the sending server.
~all- Gives other senders a softfail result: they are probably unauthorised.
-all- Gives other senders a fail result: they are unauthorised.
The receiving server decides how to handle these results. Changing ~all to -all changes your rule for unlisted senders, so make sure legitimate services are included first. SPF mechanisms and qualifiers.
Keep one SPF policy at each name
Use one SPF TXT record for each domain name. Two records starting with v=spf1 produce an error instead of combining their rules. Other TXT records can coexist with SPF. Subdomains need their own SPF settings; they do not inherit the parent’s record. Microsoft’s SPF setup guidance.
Website forms, invoicing software and booking systems can all send email. Check these services when setting up SPF, including tools you use only occasionally.
Before changing DNS
- Save the current record. Keep its DNS name, TXT value and TTL (time to live, which controls how long DNS answers are cached).
- Check the provider’s instructions. Use the values for your account and domain.
- Inspect the record. The SPF checker helps you read the published record and its includes. It does not replace testing your email.
- Test after the change. Check public DNS, send a message from each service and inspect the authentication results on the received messages.
Read how SPF, DKIM and DMARC work together, or see how Emailmetry keeps SPF up to date automatically.