What Is SPF?

At a glance

SPF is normally published in a TXT record. Receiving servers use it to check whether the connecting sender is authorized by the relevant domain.

Which identity does SPF actually check?

SPF, the Sender Policy Framework, lets a domain declare authorized sending hosts in DNS TXT records. The receiving server compares the connecting IP address with the policy for the SMTP MAIL FROM domain or HELO identity. Results include pass, fail, softfail, neutral and temperror. SPF does not simply check the From header a person sees in an email client.

That distinction matters. An attacker can use an envelope sender different from the visible From address, pass SPF and still impersonate a displayed brand. DMARC adds alignment between the SPF-authenticated domain or DKIM signing domain and the visible From domain, addressing this identity gap.

How an SPF policy is evaluated

• The record begins with v=spf1. The ip4 and ip6 mechanisms directly authorize address ranges. Mechanisms such as a, mx, include and exists trigger different DNS lookups.
• Evaluation proceeds from left to right and stops at the first matching mechanism, returning its qualifier. A final -all normally fails unauthorized sources, while ~all produces a softfail.
• An include commonly authorizes a SaaS email platform. Changes to the referenced policy also affect the current domain, so references to retired services need periodic cleanup.
• SPF limits the mechanisms and modifiers that trigger DNS lookups. Excessive nesting can produce permerror and prevent otherwise legitimate mail from receiving a pass result.

Why forwarding, groups and multiple senders cause failures

With traditional forwarding, the forwarding server's IP is often outside the original sender domain's SPF authorization. SPF can then fail even when the message content is unchanged. SRS can rewrite the envelope sender to maintain a verifiable route. An intact DKIM signature may also allow DMARC to continue passing.

Organizations often send through website systems, support desks, marketing tools, billing services and recruitment platforms. Omitting a legitimate sender can cause failures, while retaining unused includes expands authorization. Maintaining an inventory of sending services is more reliable than accumulating provider records without review.

Practical use and interpretation

A complete SPF record exposes its authorization mechanisms, all policy and obvious syntax problems. An authorized address range has permission to send; it does not prove the address is actively sending. An include referencing a provider suggests an integration, but stale historical records are common.

If SPF cannot be found, check the queried name, TXT response and any temporary DNS errors first. A confirmed absence on a sending domain may indicate incomplete mail-identity protection. If the domain's purpose is unclear, its state remains unknown.

Points to consider

SPF helps reduce direct spoofing of a domain's sending identity, but normally needs to be combined with DKIM and DMARC.

Frequently asked questions

Can a domain publish multiple SPF records?

A single name should not publish multiple independent v=spf1 records, because that causes a permanent error. Combine authorized sending sources into one controlled policy.

What is the difference between ~all and -all?

~all produces softfail and is often used during observation or transition. -all explicitly marks unmatched sources as unauthorized. The recipient's final handling still depends on DMARC and local policy.

Why can DMARC fail when SPF passes?

DMARC also requires the SPF-authenticated domain to align with the visible From domain. SPF may pass for a different domain without providing DMARC alignment for the visible sender.