Email authentication

What is SPF?

SPF lets you publish a list of servers authorized to send email as your domain. It's the first layer of email authentication — and the one most likely to break as your sending stack grows.

Why SPF matters in 2026

SPF has been around since 2006, but it became operationally critical when major mailbox providers started enforcing authentication:

• Gmail (February 2024): All senders must authenticate with SPF or DKIM. Bulk senders must also pass DMARC alignment.
• Yahoo (February 2024): All senders need SPF or DKIM at a minimum. Bulk senders must authenticate with both SPF and DKIM and have DMARC in place.
• Microsoft Outlook (May 2025): High-volume senders must pass SPF, DKIM, and DMARC.

SPF is also the authentication mechanism most likely to silently break in production. The 10 DNS lookup limit, vendor include bloat, and IP rotation all create recurring failure points that don't produce obvious errors until mail starts getting rejected.

How SPF works

SPF is a DNS TXT record that lists the servers authorized to send email for your domain. When a receiving server gets a message, it checks whether the sending IP is authorized by the domain's SPF record.

What SPF actually checks: SPF evaluates the domain in the Return-Path (RFC5321.MailFrom / envelope sender), not the visible From: header. This is a critical distinction — and the most common source of “we added the vendor to SPF but it still fails” confusion.

A basic SPF record:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

This authorizes Microsoft 365 and Google Workspace to send, and -all tells receivers to fail anything else.

How evaluation works: Mechanisms are evaluated left to right. The first match determines the result. If no mechanism matches and there's no redirect=, the default result is neutral.

SPF result types:

• pass — the sending IP is authorized
• fail (-all) — the sending IP is explicitly not authorized
• softfail (~all) — not authorized, but treat as suspicious rather than rejected
• neutral (?all) — no assertion either way
• permerror — the record is broken (too many lookups, syntax error, duplicate records)
• temperror — temporary DNS failure during evaluation

For DMARC purposes, SPF must both pass and align — the Return-Path domain must match the From: domain (under relaxed or strict alignment). A pass without alignment doesn't help DMARC.

The 10 DNS lookup limit

RFC 7208 limits SPF evaluation to 10 DNS-querying mechanisms total. The mechanisms that count: include, a, mx, ptr, exists, and redirect. Mechanisms that don't count: ip4, ip6, and all.

The limit is 10 across the entire recursive chain, not 10 in your visible record. Each include can contain nested includes of its own, and every one counts.

How quickly you hit the limit:

Example total: Google Workspace (4) + Microsoft 365 (3) + SendGrid (4) = 11 lookups → PermError

When you exceed 10, receivers return permerror — SPF fails for every message until the record is fixed.

There's also a lesser-known limit: RFC 7208 recommends no more than 2 void lookups (DNS queries returning NXDOMAIN or empty results). Stale includes pointing to decommissioned vendor domains accumulate these.

→ For troubleshooting: SPF PermError — Too many DNS lookups

Managing SPF across multiple vendors

Every SaaS vendor that sends email as your domain will tell you to add an include: to your SPF record. The challenge is keeping the total under 10 lookups as your vendor stack grows.

Three approaches that work:

1. Subdomain segmentation

Assign each vendor a subdomain (marketing.yourdomain.com, billing.yourdomain.com). Each gets its own SPF record with its own 10-lookup budget. This usually scales better than flattening because changes are isolated.

2. Hosted SPF (macro-based)

A hosted SPF service uses SPF macros to consolidate your vendor inventory into a single dynamic include. Your published SPF record stays short — typically one include plus an all — and the service handles changing IP inventories behind the scenes. DMARCit's hosted SPF works this way.

3. Removing unnecessary includes

If a vendor uses its own domain in the Return-Path (like Salesforce's bnc.salesforce.com), your SPF include for that vendor isn't contributing to DMARC alignment — DKIM alignment is doing the work. Removing it frees up lookups.

What about SPF flattening?

Flattening replaces include: mechanisms with raw ip4: and ip6: addresses. It reduces lookup counts but creates a maintenance burden — when vendors rotate IPs (which happens without notice), your flattened record goes stale and legitimate mail fails. Flattening should be a last resort, not a default approach, and it requires continuous automated re-resolution.

SPF macros

SPF macros are templated strings that receivers expand using connection-specific data before performing DNS checks. They're defined in RFC 7208 and supported by standards-compliant SPF evaluators.

How macros work:

Macro variables are enclosed in %{...} and expand to values from the current SMTP connection:

• %{i} — the connecting client's IP address
• %{s} — the full sender identity (email address)
• %{d} — the domain being evaluated
• %{l} — the local-part of the sender
• %{o} — the sender's domain
• %{h} — the HELO/EHLO domain

Transformers let you reverse and truncate: %{ir} reverses the IP for DNS-style lookups.

Practical use cases:

Dynamic authorization via exists:

The exists mechanism checks whether an A record exists for a macro-expanded domain name. This lets you replace include chains with a single DNS decision point:

v=spf1 exists:%{i}._spf.yourdomain.com -all

The receiver expands %{i} to the connecting IP and queries <ip>._spf.yourdomain.com. If an A record exists, the mechanism matches. This is how hosted SPF services keep your record short while authorizing many senders dynamically.

Hosted SPF consolidation

Several hosted SPF vendors build their products around macros. One common pattern is to encode connection attributes into a DNS lookup key. The exact format varies by provider, but conceptually it looks like:

include:%{i}._ip.%{h}._ehlo.%{d}._spf.vendor.example

This is illustrative — don't paste this into DNS. The point is that your top-level record becomes one include, and the vendor handles authorization logic server-side.

Abuse tracking

RFC 7208 describes a tracking pattern using exists: that encodes connection attributes into DNS queries for log analysis:

v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all

This is useful for investigations but increases DNS traffic and emits sender metadata into query names.

Risks and trade-offs:

• Macros are standards-defined and widely supported in practice — the fact that major hosted SPF vendors build products around them is strong evidence of interoperability. However macro expansion can generate invalid DNS names (empty labels, over-63-character labels), and behavior across implementations may vary.
• Macro-heavy designs create more DNS dependency and more opportunities for temporary failures.
• The exists mechanism is flagged by M3AAWG as an advanced feature that non-experts should approach carefully.
• Some intermediate mail gateways and SPF checker tools don't handle macro-based records well, which can complicate troubleshooting.

For MSP operations, macros are a legitimate and supported approach — but expect higher troubleshooting cost when downstream filters or compliance tools are involved.

SPF and DMARC alignment

SPF on its own doesn't check the visible From: header. It checks the Return-Path (envelope sender). DMARC adds the alignment requirement: the domain that passed SPF must match the From: domain.

Under relaxed alignment (default): bounce.yourdomain.com in the Return-Path aligns with yourdomain.com in the From: header.

Under strict alignment: the domains must match exactly.

A message can pass SPF but fail DMARC if the SPF-authenticated domain doesn't align with the From: domain. This is common when SaaS vendors use their own bounce domain in the Return-Path.

The fix: configure a custom Return-Path (custom bounce domain) under your organizational domain, or rely on DKIM alignment instead — which is often the more reliable path because it survives forwarding.

→ See: DMARC alignment failure

SPF baselines for Microsoft 365 and Google Workspace

Microsoft 365 (sending only through Exchange Online):

v=spf1 include:spf.protection.outlook.com -all

Google Workspace commonly uses:

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

For Google-managed domains, make sure your SPF record includes Google's sending infrastructure and any third-party senders for your domain. Add additional includes only for services that actually use your domain in the Return-Path.

Common mistakes:

• Adding includes for services that use their own Return-Path domain (the include does nothing for DMARC alignment)
• Adding a or mx mechanisms by default (they count toward the 10-lookup limit and are usually unnecessary)
• Believing SPF checks the visible From: header (it checks the Return-Path)

What breaks SPF in practice

Forwarding

Server-side forwarding changes the sending IP, breaking SPF because the forwarding server isn't in the original sender's SPF record. This is a structural limitation of SPF — it can't be “fixed,” only mitigated by relying on DKIM alignment for DMARC.

Mailing lists

List processors typically rewrite the envelope sender, which can break SPF alignment even if SPF passes for the list's domain.

Vendor IP rotation

Cloud sending platforms rotate IPs without notice. If you've flattened your SPF record to raw IPs, rotations cause silent failures.

SRS (Sender Rewriting Scheme)

Some forwarders (including Microsoft 365) use SRS to rewrite the Return-Path on forwarded mail, which can help SPF pass at the next hop but changes the alignment domain.

ARC (Authenticated Received Chain)

ARC preserves authentication results across forwarding hops. Some major providers and intermediaries validate ARC, which can reduce false failures on legitimate forwarded mail. It partially mitigates SPF breakage in forwarding, but relies on trust relationships between intermediaries.