SPF records

Start by listing every service and address that can send for the domain. Publish the full set as a single TXT record,¹ then test it against the envelope sender domain. A common mistake is pasting a provider's value into DNS before finding every sending path. Forwarding between mail servers can make SPF verification fail.² Treat the record as one policy for every path that uses the domain.

Run the setup in order

Use this sequence to move from scope to verification. Each stage gives you a point to stop and fix the record before a missing sender becomes a delivery problem.

Stage	What you are trying to learn	Example question
Scope	Which domain and sending paths belong in the policy	Which services, servers, and addresses send mail for this domain?
Inspect	Whether a policy already exists	What SPF value does public DNS return right now?
Compose	Whether the value covers the complete sender inventory	Does this value include every real sending source?
Publish	Whether the DNS edit was accepted	Did the provider save the TXT record on the intended domain?
Verify	Whether receiving systems recognize each source	Does mail from each sending path pass SPF?
Review	Whether forwarding or downstream systems change the result	Where does the message travel after the original sender?

Define the sending scope

SPF answers a narrow question: is this sending source authorized for the domain used by the envelope sender? Keep that question in front of you while building the record.

SPF identifies valid sources for the MAIL FROM domain.³ Receiving systems use the SPF TXT record to check whether the SMTP sender address came from a known, designated source for that domain.⁴

List every service, server, IP address, and address range that sends mail for the domain. Include systems that send through a provider, since the record must cover the complete sending set. The record can contain permitted IP addresses and hostnames.⁵

For a Microsoft 365 custom domain, create an SPF TXT record that identifies Microsoft 365 as an authorized source for that domain.⁶ Apply the same approach to every other provider: find its approved sending sources and add only sources that genuinely send mail for the domain.

Check what already exists

Inspect public DNS before creating a new value. This tells you whether to edit an existing policy, leave a default configuration alone, or investigate a missing record.

Use a free internet tool to check whether SPF is already set up for the domain.⁷ Read the returned value and compare it with your sender inventory. A record that contains one provider's source can still be incomplete if another system also sends mail.

If you use only the Microsoft Online Email Routing Address domain for email, its SPF TXT record is already configured.⁸ In that situation, no action is needed.⁹ Check other domains as well, since a hosted email signup may have added a default configuration.

Compose the TXT value

Once the scope is clear, build the value from the real sending sources. Keep provider examples as references and use a provider's value when that provider is part of the domain's sending path.

An SPF record is a line of text added to the domain according to the domain provider's instructions, and its syntax lists the servers that send mail for the domain.^{10, 11} A permitted source can appear as an IP address or hostname.⁵

A Google example is v=spf1 include:_spf.google.com ~all.¹² Do not copy that value for a domain whose mail does not use Google. Replace the example with the sources in your inventory, then review the complete value as one policy.

Mechanisms are evaluated in order. When a mechanism matches, its qualifier determines the result, and the default qualifier is plus, meaning Pass.¹³ A tilde means SoftFail.¹⁴ A minus means Fail.¹⁵ These endings affect how receiving systems interpret an unmatched source, so preserve the qualifier you intend to use when adapting a provider's value.

A malformed or incomplete value can produce a PermError. An SPF evaluation returns None when the domain has no SPF record, TempError during a temporary DNS processing problem, and PermError after a syntax or evaluation error.¹⁶

Publish and verify

Compare the value with the sender inventory before publishing. Then check the record from the receiving side, where the authorization decision is made.

Create the SPF record in public DNS using every IP address or address range from which the domain sends email.¹⁷ The record must use the TXT type.¹⁸ Follow the domain provider's field names and save the value on the domain that appears in the MAIL FROM address.

Receiving servers check the SPF record to verify that messages came from authorized servers.¹⁹ Test mail from each sending path after the DNS change, then compare the result with your inventory. When a receiving email service cannot confirm that the sending IP is valid, it marks the email according to the DMARC policy implemented for the sending domain.²⁰

A failed result gives you a specific place to look. Check whether the sending source is absent from the value, whether the record was published on the wrong domain, or whether the message took a path your inventory missed.

Account for forwarding and downstream systems

Forwarding deserves its own review because the message can reach the recipient through a server that was absent from the original sending path. Trace those paths during verification and inspect the domains and systems that handle the message after it leaves the original sender.

Configure SPF for the email domains and any downstream servers involved in delivery.²¹ SPF also needs to sit alongside the other authentication controls. Set up DKIM and DMARC with SPF for comprehensive email security.²² Together, SPF, DKIM, and DMARC help protect a domain from spoofing and improve email deliverability.²³

What not to do

The common failures are configuration mistakes that a DNS screen will not explain clearly. Use this list as the final check before leaving the record in production.

• Do not create a second SPF record for the same domain. Only one SPF record works on a domain at a time.²⁴
• Do not use the dedicated SPF RR type 99. Major email providers and DNS services no longer support that record type as of August 11th, 2025, and SPF records must use TXT.^{25, 18}
• Do not stop after authorizing the most visible provider. The record needs the complete set of genuine sending sources, including downstream paths.
• Do not treat SPF as the whole authentication setup. DKIM and DMARC still need to be configured.²²