SPF Redirect vs Include: Which One Should You Use?

The short answer

One SPF word can hand a sender a narrow permission or hand another domain the whole policy decision.

Use include when a mail service sends for your domain. Use redirect when another domain you control should provide the complete SPF answer. For most teams comparing SPF redirect vs include, the right choice is include.

A common provider record looks like this:

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

That record says: evaluate Google's SPF policy, evaluate Microsoft's SPF policy, then soft fail other sources. It does not say that SPF is aligned with the visible From address. SPF checks the SMTP MAIL FROM or HELO identity. DMARC is what checks alignment with the visible From domain.

What include does

include asks another SPF record whether the sending IP gets SPF pass for that domain.

It does not paste the provider's SPF text into your record. During SPF evaluation, the receiver checks the included domain. If that check returns pass, your include matches. If it returns fail, softfail, neutral, or no match, your own SPF record keeps evaluating until another mechanism matches or the record ends.

Use include for services such as Google Workspace, Microsoft 365, Mailchimp, Postmark, SendGrid, and support desks that send as your domain. Microsoft documents include:spf.protection.outlook.com for most Microsoft 365 domains, and warns against flattening it because Microsoft 365 sending IPs change.

• Publish only one SPF TXT record per sending domain or subdomain.
• Add each provider with the exact include: value from that provider's docs.
• Use ip4: or ip6: only for mail servers you control.
• Avoid SPF flattening unless the sending IP ranges are stable and someone will review them.
• Count DNS-querying SPF terms before adding another sender.

What redirect does

redirect sends the SPF decision to another domain after no mechanism in the current record matches.

A redirect-only record can look like this:

v=spf1 redirect=_spf.example.com

That is useful when several domains you own should share one complete SPF policy. For example, example.com, example.net, and example.org can all redirect to a shared record that your team controls. You update the shared record, and each redirected domain follows it.

There are two common mistakes. First, redirect is ignored if the SPF record contains any all mechanism, no matter where it appears. So v=spf1 include:vendor.example -all redirect=_spf.example.com will never use the redirect. Second, redirect is a poor fit for a vendor you do not control because the target domain gives the final SPF result for your domain.

• Use no more than one redirect modifier in a record.
• Put it last so humans can read the record quickly.
• Do not combine it with ~all, -all, ?all, or +all.
• Make sure the redirect target has a valid SPF record.
• Use it mainly for domains your organization owns together.

The 10-lookup limit

Both include and redirect count toward SPF's 10-term DNS lookup limit.

RFC 7208 limits SPF evaluation to 10 DNS-querying terms. The terms are include, a, mx, ptr, exists, and redirect. If evaluation exceeds that limit, SPF returns permerror. The all, ip4, and ip6 mechanisms do not count because they do not cause DNS lookups during SPF evaluation.

Do not count only the terms you can see in your own record. A provider include can trigger more DNS-querying terms inside the provider's SPF policy. That is why a domain can break after a harmless-looking vendor add.

A cleaner setup is to put different mail streams on subdomains. Marketing mail can use news.example.com. Product mail can use mail.example.com. Each subdomain gets its own SPF record, DKIM keys, and DMARC monitoring.

SPF still needs DKIM and DMARC

SPF can pass while the visible From domain still fails DMARC alignment.

DKIM signs a message with a private key. The public key is published in DNS under a selector, such as selector1._domainkey.example.com. A valid DKIM signature shows that the signed headers and body survived transit and that the signing domain controlled the private key.

DMARC checks whether SPF or DKIM passes and aligns with the visible From domain. You can start DMARC at p=none for monitoring, then move to p=quarantine or p=reject after real mail is passing. Add a rua address if you want aggregate reports that show who is sending mail for the domain.

Google's sender guidelines require SPF or DKIM for all senders to personal Gmail accounts. Bulk senders to Gmail must use SPF, DKIM, and DMARC. Google also points to reverse DNS, TLS, spam rate, message format, unsubscribe support for bulk mail, and blocklist or reputation signals. Microsoft gives SPF setup guidance for Microsoft 365 and recommends DKIM plus DMARC for stronger protection. SPF is one signal, not an inbox guarantee.

If you want a quick read on your live DNS, run the free InboxRadar domain scorecard. It checks SPF, DKIM, DMARC, MX, and common blocklist signals without a login.

Decision guide

Choose based on who owns the policy you want to trust.

• If a SaaS provider sends mail for you, use include.
• If one of your own domains should reuse another SPF policy you own, use redirect.
• If a provider asks for redirect, understand that it controls the final SPF answer for that domain.
• If the record already has ~all or -all, do not add redirect.
• If SPF is near 10 DNS-querying terms, split mail onto subdomains or remove old senders.
• If mail still goes to spam after SPF passes, check DKIM, DMARC alignment, MX records, reverse DNS, spam complaints, reputation, and blocklists.

The safest path is boring: one SPF TXT record, only the provider includes you use, direct IPs only for servers you control, and a final ~all while you verify. Move toward -all after DMARC reports show your real mail is covered.