SPF setup starts with an inventory of who sends mail for the domain and ends with that inventory published in DNS. SPF's primary purpose is to validate email sources for a domain.1 Receiving systems inspect the sender address used during SMTP transmission, called the MAIL FROM address.2 Start by identifying the domain each sending system uses for its envelope sender, then build the inventory before editing DNS. Turn it into the record and test the result from a receiving system's perspective.
How to run the setup
Use this order to work through the setup. Each stage answers a different question before the next step.
| Stage | What you are trying to learn | Example question |
|---|---|---|
| Inspect | the domain's current authorization state | Is there already an SPF record? |
| Inventory | every system that sends mail | Which systems send for this domain? |
| Assemble | the complete authorization line | What value represents each sending source? |
| Publish | who controls the DNS change | Where should the record be entered? |
| Verify | what a receiving system sees | Does the sending source pass? |
| Diagnose | why a check failed | Is the result missing, temporary, or permanent? |
Check the current state
First check whether SPF work is needed and whether a record already exists. This prevents changes to a record managed elsewhere.
If you use only the Microsoft Online Email Routing Address domain, known as MOERA, for email, you do not need to take action because its SPF TXT record is already configured.3, 4 For other domains, use a free tool on the internet to check whether SPF is already set up.5 You also do not need to set up SPF when the domain already has it configured by default or was bought from a Google partner during Google Workspace signup.6
Inventory the sending systems
Build the source list from actual mail flow. Include ordinary mail systems and services that send on the domain's behalf.
Record every IP address or address range from which email is sent.7 Add the hostnames permitted to send from the domain.8 Include both IPv4 and IPv6 sources when they are part of the sending setup.9 Use the MAIL FROM domain as the domain you are authorizing.10
Keep this list with the team that manages email and DNS. Every sending system should have a source that can be represented in the record.
Assemble the record
Turn the inventory into one authorization line. Follow the provider's instructions for the syntax instead of creating a value from memory.
SPF uses a TXT record in DNS to identify valid mail sources for the domain.11 The record is a line of text with special syntax that lists the servers sending email for the domain.12 SPF publishes the authorized sources as a single TXT record on the domain.13 Follow your domain provider's instructions when adding that line.14
If the sending service is Google, an example record is v=spf1 include:_spf.google.com ~all.15 Use it as a provider specific example and replace it only with values that match the systems in your inventory.
Mechanisms are evaluated in order. When a mechanism matches, its qualifier supplies the result; when nothing matches, the result is Neutral.16 Review the line from left to right before publishing it and confirm that every intended sender appears in the syntax.
Publish the DNS change
Enter the completed record where the domain's public DNS is managed. It should match the inventory you checked.
Create the SPF record in public DNS using all IP addresses or address ranges from which email is sent.7 For an email domain in Microsoft 365, create the DNS SPF TXT record for that domain and identify Microsoft 365 as an authorized mail source.17
After entering the record, check the published value rather than relying on what was pasted into the DNS editor. Confirm that it contains the intended sources and uses the expected syntax.
Verify the receiver's result
Check the published record against the source used by the message, then investigate the result returned by the receiving system.
Receiving servers check a domain's SPF record to verify that messages came from authorized servers.18 When the sending IP appears in the acceptable list, the receiving email service forwards the message to the recipient's inbox.19 When the service cannot confirm that the IP is valid, it marks the message according to the DMARC policy implemented for the sending domain.20
A domain with no SPF record produces None. A temporary DNS processing problem produces TempError, while a syntax or evaluation problem produces PermError.21 Use the result to add a missing source, fix the record syntax, or investigate the DNS problem. Correct SPF can also help prevent outgoing email from being marked as spam by receiving email servers.22
What not to do
These mistakes can create false confidence or cause valid mail to fail authentication.
- Do not publish a second SPF record to add another sender. Only one SPF record works on a domain at a time.23
- Do not use the dedicated SPF RR type 99. As of August 11, 2025, major email providers and DNS services no longer support it.24
- Do not use a record type other than TXT for SPF.25
- Do not choose authorized sources from the visible From field alone. SPF checks the sender address used during SMTP transmission, the MAIL FROM address.2
- Do not assume forwarding preserves SPF verification. SPF verification fails when email is forwarded between mail servers.26
- Do not leave downstream servers outside the configuration when they are part of the delivery path.27
For broader domain protection, set up DKIM and DMARC alongside SPF.28 Together, these protocols help protect the domain from spoofing and improve email deliverability.29