SPF: who can send emails for you

SPF (Sender Policy Framework, defined in RFC 7208) is a public guest list of the servers and services allowed to send email on behalf of your domain.

Standard email (SMTP) does not verify the sender address on its own. Without SPF and DKIM, an attacker can send messages that appear to come from your domain. Publishing an SPF record protects your domain from impersonation, improves deliverability, and is one of the building blocks required for DMARC and your BIMI inbox logo.

We strongly recommend configuring an SPF record for every domain you own, and always using your email provider's official documentation to get the exact value they require.

How SPF works#

When a mail server receives a message, it checks the domain in the message's Return-Path (also called the MAIL FROM or bounce address) rather than the visible From: header shown in the inbox:

1. You publish an SPF record: Add a single TXT record starting with v=spf1 on your domain (and on any subdomain that sends mail).
2. An email is sent: A server with IP address 192.0.2.1 connects to the recipient's mail server and specifies a Return-Path domain (or HELO/EHLO domain).
3. The receiving server checks your list: The receiver looks up the v=spf1 TXT record for that Return-Path domain and checks whether the sending server's IP address matches your authorized mechanisms.
4. The result is passed to DMARC: If the IP matches, SPF returns Pass. If it does not match, SPF returns SoftFail (~all) or Fail (-all), and DMARC decides whether to quarantine or reject the message.

Because SPF checks the Return-Path domain while readers see the From: header, DMARC also checks alignment: the Return-Path domain must match your From: domain (or be a subdomain of it) for SPF alone to satisfy DMARC.

How to configure an SPF record#

An SPF record must always be published as a DNS TXT record (the older dedicated SPF DNS record type was retired by RFC 7208). At the root of your domain (@), a typical record looks like this:

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

• v=spf1 identifies the TXT record as an SPF version 1 policy. Every SPF record must begin with v=spf1.
• include:_spf.google.com authorizes Google Workspace's sending servers. If you use more than one service (for example Google Workspace for team mail and Postmark for product emails), combine them into the same TXT record:
  textCopy

  v=spf1 include:_spf.google.com include:spf.mtasv.net ~all

• ~all (SoftFail) or -all (Fail) at the very end tells receiving servers that no other IP addresses are authorized to send mail for the domain.

Domains and subdomains that never send email#

If you own parked domains, or subdomains like www that never send email, publish a strict no-mail SPF record on them so attackers cannot spoof them:

v=spf1 -all

Reputable, developer-friendly email providers#

Always check the official documentation of each service that sends email for you, copy their recommended include: mechanism or custom return-path setup, and add it to your domain's DNS settings.

Postmark#

Resend#

Amazon SES#

SendGrid#

Mailgun#

Google Workspace#

Microsoft 365#

Technical reference: SPF syntax, mechanisms & results#

Receiving servers evaluate an SPF record from left to right. The first mechanism that matches the connecting server's IP address determines the result. If no mechanism matches and no redirect= modifier is present, the default result is Neutral (as if ?all were at the end).

Qualifiers#

Every mechanism can be prefixed with one of four qualifiers. When omitted, + (Pass) is the default.

Mechanisms#

Modifiers#

Modifiers are optional name=value pairs that may appear at most once per record.

SPF evaluation results#

Common issues#

• Multiple SPF records on the same domain (PermError). A domain or subdomain may only have one v=spf1 TXT record. Publishing two separate v=spf1 records causes SPF to fail immediately with PermError. Merge all include: and ip4:/ip6: entries into a single record. Note that long TXT records (>255 characters) split into multiple quoted strings inside a single DNS TXT record are concatenated automatically without spaces; make sure there is a space between terms at string boundaries.
• Too many DNS lookups: the 10-lookup limit (PermError). RFC 7208 allows at most 10 DNS-querying mechanisms and modifiers (include, a, mx, ptr, exists, and redirect) across the entire evaluation, including any nested lookups inside include: records. (all, ip4, and ip6 do not count toward this limit.) To stay under 10 lookups:
  • Remove include: statements for old tools and services you no longer use.
  • Use separate subdomains for different mail streams. Each subdomain (such as mail.yourcompany.com for marketing or send.yourcompany.com for transactional receipts) gets its own independent 10-lookup budget.
  • Prefer ip4: and ip6: over a or mx for static servers you control.
• Too many void lookups: the 2-void-lookup limit (PermError). RFC 7208 recommends failing with PermError if more than 2 DNS lookups return either an empty answer (0 records) or NXDOMAIN (non-existent domain). This usually happens when an include: or a: points to a decommissioned service or a typoed domain name.
• Using +all or omitting all. Ending an SPF record with +all authorizes every server on the internet to impersonate your domain. Omitting all (without redirect=) leaves the default as ?all (Neutral). Always end your record with ~all or -all.
• Unaligned Return-Path and email forwarding. Many third-party email tools use their own domain in the Return-Path unless you configure a custom return-path (or custom MAIL FROM) subdomain. In addition, when a recipient auto-forwards an email to another inbox, the forwarder's IP address often fails the original sender's SPF check. Configuring DKIM alongside SPF ensures your emails still pass DMARC even when forwarded.