How to set up SPF DNS records, includes, and ~all vs. -all

Find the domain SPF will actually check

Email has a visible From address and a transfer address called MAIL FROM, used between mail servers and for delivery failure notices. In a received message, MAIL FROM is usually reflected in Return-Path.

From: news@example.com
Return-Path: bounce@bounce.example.com

SPF TXT lookup: bounce.example.com

The receiver compares the connecting IP with the SPF policy at bounce.example.com. It does not substitute example.com merely because that is what the reader sees in From. SPF records are not automatically inherited by subdomains.

If a provider uses its own MAIL FROM domain, that is the domain being checked. Adding the provider's include to your company's root SPF may have no effect on those messages. Compare the provider's custom MAIL FROM or bounce-domain settings with the headers of a received message first.

When MAIL FROM is empty, as it can be for delivery failure notifications, SPF uses the HELO identity announced by the sending server. For normal business mail, start your investigation with MAIL FROM. The sender identity SPF evaluates ↗

Read an SPF record from left to right

The following fictional policy authorizes one directly managed server and a sending service. v=spf1 identifies the record. The remaining mechanisms are evaluated from left to right until one matches. A mechanism without an explicit qualifier uses +, meaning pass.

v=spf1 ip4:192.0.2.40 include:_spf.news.example.net -all

An IP of 192.0.2.40 matches the first mechanism and passes. Another IP reaches include. This tells the receiver to evaluate that domain's SPF for the same sending IP. If the referenced policy returns pass, the include matches and this policy also returns pass.

An include does not simply paste another record's text into yours. If the referenced policy returns fail, softfail, or neutral, evaluation continues to your next mechanism. Its internal -all does not automatically fail your policy. A missing SPF record or invalid referenced policy can instead produce permerror; a temporary DNS failure can produce temperror. How include is evaluated ↗

The final all matches any IP that has reached it. Here the - qualifier makes that result fail. Place authorized-sender mechanisms before all; anything after it will not be reached.

~all and -all describe the senders that did not match

~all produces softfail, a weaker statement that the sender is probably not authorized. -all produces fail, explicitly stating that it is not authorized. Neither is an SPF pass. Neither is a command that guarantees deletion or spam placement; the receiving system considers the result alongside its other rules.

Google and Microsoft recommend different endings. Follow the guidance appropriate to your actual services and complete sender inventory, rather than assuming a stricter-looking string removes the need to test. A domain that sends no mail can publish v=spf1 -all to authorize no sender for SPF. That alone does not prevent spoofing of the visible From domain. Google: SPF record syntax ↗

The a and mx mechanisms authorize IPs through DNS lookups, but your website or inbound mail servers are not necessarily your outbound servers. Unneeded mechanisms expand authorization and consume lookup capacity. redirect= delegates evaluation to another policy; it is different from adding a provider with include. A policy containing all does not use redirect.

Combine the right senders into one SPF record

Save the current policy before editing. Ask the relevant teams about newsletters, website notifications, and billing tools as well as employee mail. Record the actual MAIL FROM for each route so you can distinguish senders that share a policy from those using separate domains.

A company sending only through Google Workspace can use Google's official example:

Type: TXT
Name: @
Value: v=spf1 include:_spf.google.com ~all

Many DNS control panels use @ for the domain itself. Others expect an empty field or a full name. Follow the DNS host's input convention and check the resulting name. Google: publishing SPF ↗

Type: TXT
Name: @
Value: v=spf1 include:spf.protection.outlook.com -all

These are alternatives for different environments. Do not authorize both services unless both send for the domain. Government, China-operated, and gateway configurations can require different Microsoft values. Microsoft: SPF values by environment ↗

Add the newsletter to the existing policy, not to a second SPF record

For our three-source example, the combined structure keeps the existing employee-mail authorization and adds the other approved sources before the final all.

v=spf1 ip4:192.0.2.40 include:_spf.google.com include:_spf.news.example.net ~all

A desktop's private IP or the website's hosting IP is not a substitute for the public IP that actually sends mail. If the provider asks you to set up a separate MAIL FROM subdomain, publish the required policy at that name instead.

1. Open the active DNS host

   Confirm the domain's current nameservers. The registrar and the company hosting DNS may differ.

2. Find the existing SPF at the exact name

   Look for a TXT record beginning v=spf1. Keep unrelated TXT records, such as ownership verification, intact.

3. Edit the single policy

   Retain existing approved senders, add verified new ones, and save the previous value and change time. Follow your provider's TTL guidance.

Two quoted strings can still be one TXT record

A TXT record can contain several character strings, each limited to 255 bytes. A DNS tool may show a long value split into quoted parts. That is different from publishing two separate SPF records.

One TXT record:
"v=spf1 ip4:192.0.2.40 " "include:_spf.news.example.net ~all"

Two TXT records — incorrect:
"v=spf1 ip4:192.0.2.40 ~all"
"v=spf1 include:_spf.news.example.net ~all"

Strings within one record are joined without adding spaces. The first example keeps a space at the end of the first string so the mechanisms do not run together. Two separate SPF records do not offer the receiver a choice; they produce permerror. Check actual record boundaries, not just line breaks in a control panel. SPF TXT strings and record boundaries ↗

Three includes can use all ten lookup terms

SPF limits the number of evaluated terms that cause DNS lookups to ten. The limit covers include, a, mx, exists, ptr, and redirect, including terms reached inside referenced policies. Counting only the includes visible in your own record misses that recursion.

Consider this separate fictional structure. The top-level record has only three includes. Assume all DNS responses are valid, none of the authorized IPs matches, and every leaf policy contains only ip4 and -all.

example.com
├─ include:a.example (1)
│  ├─ include:a1.example (2)
│  └─ include:a2.example (3)
├─ include:b.example (4)
│  ├─ include:b1.example (5)
│  └─ include:b2.example (6)
└─ include:c.example (7)
   ├─ include:c1.example (8)
   ├─ include:c2.example (9)
   └─ include:c3.example (10)

A uses three terms, B uses three, and C uses four: ten in total. If provider C adds include:c4.example, a message reaching that eleventh term produces permerror. Your own DNS can remain unchanged while a provider's update pushes the policy over the limit.

Conversely, if the IP matches inside a1, evaluation can finish after two terms. One passing test IP therefore does not prove that every path fits the limit. Check each legitimate sending path and the path that reaches the end.

This counts evaluated DNS-causing terms, not network packets. Do not add the initial TXT lookup of your policy to this total or deduct a term because its DNS answer was cached. ip4, ip6, and all do not consume this ten-term allowance. Additional limits apply to some address lookups and empty DNS answers, and use of ptr is discouraged. SPF lookup limits ↗

Check public DNS, then send through every real route

Saving a DNS record and having every receiver see it are different events. TTL controls how long an answer may stay in a cache. Record the change time and check the exact name through public resolvers.

dig @8.8.8.8 TXT example.com +short
dig @1.1.1.1 TXT example.com +short

Confirm that there is one SPF record, existing authorized senders remain present, and new mechanisms appear before all. If answers differ, consider caches and whether you edited the active DNS zone. Agreement between two resolvers does not prove every receiver has refreshed its cache.

Next, send a new message from each sending service to an external mailbox. An employee test does not test the newsletter route. In Gmail, Show original exposes the headers. Read the receiver's SPF result together with smtp.mailfrom. Google: checking SPF results in headers ↗

Before: newsletter sender missing from SPF
Authentication-Results: mx.receiver.example.org;
  spf=softfail smtp.mailfrom=example.com

After: authorized newsletter sender added
Authentication-Results: mx.receiver.example.org;
  spf=pass smtp.mailfrom=example.com

Here the newsletter uses example.com as MAIL FROM, but a Google-only policy does not authorize its fictional sending IP, 198.51.100.20. It reaches ~all and receives softfail. After adding the provider's approved include, a new message from that route passes. DNS changes do not retroactively alter an old message's recorded result.

Use authentication results trusted by the final receiving service. A message can contain results from several intermediaries, and senders can insert misleading headers. Cross-check the source IP with the receiving system's Received-SPF or logs; ask its administrator where the trustworthy result is unclear. Authentication result trust boundaries ↗

After SPF passes, check alignment

DMARC compares the authenticated domain with the visible From domain. Under default relaxed alignment, bounce.example.com can align with example.com when they share the same organizational domain. Strict alignment requires an exact match.

A provider-domain SPF pass for mailer.example.net does not align with From example.com. Repeatedly editing the company's root SPF will not change that relationship while the provider's MAIL FROM stays the same.

Configure a supported company-domain MAIL FROM, or enable DKIM signing with an aligned company domain. DMARC needs an SPF pass plus alignment, or a DKIM pass plus alignment. SPF softfail does not count as a pass for this purpose. SPF alignment in DMARC ↗

Use the result to narrow down the next check

A failed SPF result is not automatically a spoofing attempt. A missing sender, invalid policy, DNS outage, and forwarding route require different responses. After making a correction, test again through the same sending service.

If only forwarded mail fails, the connecting IP may have changed

A newsletter can pass when delivered directly and fail after automatic forwarding. The final receiver sees the forwarder's IP, not the newsletter server's.

Do not add arbitrary forwarding servers to the company's SPF to eliminate these failures. A forwarder may rewrite MAIL FROM and pass SPF for its own domain, but alignment with the original From is a separate issue. An intact, aligned DKIM signature may allow DMARC to pass despite SPF failure. If forwarding also changes signed content, DKIM can fail too.

Finish by recording the service, owner, domain tested, and date of the result. Employee mail, newsletters, and automated notifications should each have evidence from their actual route. That record makes the next service addition or retirement much easier to handle.