SPF Records

SPF (Sender Policy Framework) lets a domain owner publish a list of mail servers authorized to send email on the domain's behalf. Receiving servers check this list to detect forged senders.

SPF answers one question: Is the server that delivered this message allowed to send mail for this domain? If not, the message is suspicious.

An SPF policy is published as a TXT record in your domain's DNS. There must be exactly one SPF record per domain.

A basic example:

When a receiving server gets a message, it performs the SPF check:

• Read the envelope MAIL FROM domain (the Return-Path)
• Look up that domain's SPF TXT record in DNS
• Compare the connecting server's IP against the authorized list
• Return a result: pass, fail, softfail, neutral, or none

Note SPF checks the envelope sender, not the visible From header, an important limitation covered later.

An SPF record is built from mechanisms that describe authorized senders:

Each mechanism can have a qualifier that sets the result when it matches:

Most organizations send mail through third-party services: Google Workspace, Microsoft 365, marketing platforms, ticketing systems. The include mechanism delegates to those vendors' own SPF records.

For example, include:_spf.google.com pulls in Google's authorized ranges. This keeps your record maintainable, the vendor updates its ranges and you do not have to.

Every legitimate sending service must be included, or its mail will fail SPF.

SPF imposes a hard limit: evaluating a record may trigger at most 10 DNS lookups. Mechanisms like include, a, and mx each consume lookups, and nested includes add up fast.

Exceeding the limit produces a permerror, and the SPF check effectively fails. Mitigations:

• Remove unused includes
• Use SPF flattening to replace includes with raw IP ranges
• Consolidate sending services

SPF has a well-known weakness: forwarding breaks it. When a message is auto-forwarded, the forwarding server becomes the new connecting IP, which is not in the original domain's SPF record.

The result is an SPF failure for a perfectly legitimate message. This is a key reason SPF alone is insufficient and why DKIM (which survives forwarding) and DMARC alignment are needed alongside it.

A critical limitation: SPF validates the envelope MAIL FROM domain, not the visible From header the user sees.

An attacker can pass SPF for their own domain in the envelope while still displaying your domain in the From header. SPF alone would say 'pass' even though the message is spoofed to the reader.

DMARC closes this gap by requiring the envelope or DKIM domain to align with the visible From.

Roll SPF out carefully to avoid blocking legitimate mail:

• Inventory every service that sends mail as your domain
• Build the record with all required includes
• Start with ~all (softfail) and monitor for missed senders
• Once confident, tighten to -all (hardfail)
• Stay under the 10-lookup limit

Test with a mail tester before and after each change. A wrong SPF record can silently send your own mail to spam.

Here is a record for an organization using Google Workspace plus a marketing and a support vendor:

Test your understanding of SPF.

You learned how SPF works:

• SPF publishes a DNS TXT record listing servers authorized to send for a domain
• Receivers check the envelope MAIL FROM domain against the connecting IP
• Built from mechanisms (ip4, a, mx, include) and qualifiers, ending in -all or ~all
• Beware the 10-lookup limit, forwarding breakage, and that SPF only checks the envelope, not the visible From
• Roll out with softfail, monitor, then tighten to hardfail

Next, you will learn how DKIM cryptographically signs messages.