What is SPF? The email sender list in your DNS

SPF checks the domain used in the SMTP MAIL FROM command, sometimes called the return-path or envelope sender. That address is where bounces go. It is not necessarily the same as the visible From address in an email app.

This distinction explains why a message can say SPF=pass and still fail DMARC: the sending platform authenticated its own bounce domain instead of yours. Read SPF, DKIM, and DMARC compared for the complete picture.

v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all

Other mechanisms include ip6, a, mx, exists, and redirect. Each changes how evaluation works, and several cause DNS lookups. If you are creating a record, start from an inventory of real senders instead of copying an example blindly.

• Pass: the connecting IP was authorized.
• Fail: the record explicitly says the IP is unauthorized, normally through -all.
• Softfail: the IP was not authorized and the record ended in ~all; receivers usually treat this as a negative signal rather than an automatic rejection.
• Neutral or none: the domain made no usable assertion.
• TempError: a transient DNS problem prevented evaluation.
• PermError: the record is invalid, commonly because there are multiple records or more than 10 DNS-triggering mechanisms.

The final qualifier is often overstated. Once DMARC is enforcing, alignment and the DMARC policy matter more than softfail versus hardfail.

A forwarding server resends the message from its own IP address but may preserve the original envelope sender. The original domain's SPF record did not authorize that forwarding server, so SPF can fail even though the message is legitimate. Sender Rewriting Scheme can help, but it is not universal.

DKIM is more resilient because the signature travels with the message, provided the forwarder does not modify signed content. This is why a robust DMARC setup uses both SPF and DKIM rather than depending on SPF alone.

1. Publish exactly one SPF record per DNS name; merge providers into that one record.
2. Authorize every service that sends with your envelope domain, and remove services you no longer use.
3. Stay below the hard limit of 10 DNS-triggering mechanisms across the entire include tree.
4. Do not publish +all; it authorizes every server on the internet.
5. Recheck after adding a new CRM, helpdesk, billing service, or marketing platform.

Run the SPF checker to resolve the full include tree and count lookups. If no record exists, use the SPF generator or follow how to create an SPF record.