SPF record for SparkPost

The exact SPF record

Copy the example that matches your setup. Each one is a single TXT record; the host is shown as your DNS provider usually expects it (@ means the domain itself).

Bounce domain on a subdomain (CNAME, not TXT)

Type: CNAME · Host: bounces Copy

sparkpostmail.com

SparkPost EU accounts point to eu.sparkpostmail.com. Enterprise accounts use <public_tenant_id>.mail.e.sparkpost.com.

Your main domain on Microsoft 365 stays as it is

Type: TXT · Host: @ · 1 of 10 DNS lookups Copy

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

Your main domain on Google Workspace stays as it is

Type: TXT · Host: @ · 1 of 10 DNS lookups Copy

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

How SPF applies to SparkPost mail

SparkPost sends with a bounce (MAIL FROM) address on a domain it manages, so receivers check SPF there, not on your domain. You don't add anything to your SPF record for it; your domain is authenticated with DKIM instead.

• A bounce domain can be used only once its CNAME status is valid; MX verification is limited to Enterprise accounts.
• Because the bounce subdomain is a CNAME, SPF lookups for it follow the CNAME to SparkPost's own published record. On 3 November 2026, sparkpostmail.com published v=spf1 exists:%{i}._spf.sparkpostmail.com ~all.
• A CNAME can't share a name with other records, so use a subdomain that has no MX, TXT or A record.

How to add it

1. Create the sending domain in SparkPost and publish its DKIM TXT record (see our SparkPost DKIM page).
2. Pick a subdomain for bounces, such as bounces.example.com, and create a CNAME there pointing to sparkpostmail.com, or eu.sparkpostmail.com for SparkPost EU.
3. Add the subdomain as a sending domain and verify it with CNAME verification (cname_verify in the API).
4. Once its CNAME status is valid, set it as your default bounce domain (is_default_bounce_domain) or pass it in each transmission's return_path.
5. Verify within two weeks: SparkPost removes sending domains that stay unverified longer. Leave your root SPF record unchanged.

DKIM and DMARC alignment

SparkPost signs with your domain once its DKIM TXT record is verified, and that aligned DKIM pass is what DMARC needs. A bounce subdomain of your From domain adds SPF alignment under relaxed mode. SparkPost warns that verifying a domain by mailbox instead of DNS means it can't DKIM-sign your mail. See our SparkPost DKIM page.

DMARC passes when SPF or DKIM passes and the domain it checked matches your From domain. Our guide to SPF, DKIM and DMARC explains how the three fit together.

Common mistakes

• Two SPF records. A domain may publish only one record that starts with v=spf1. With two, receivers return a permanent error and SPF fails for all your mail (RFC 7208 section 3.2). Merge every sender into one record.
• More than 10 DNS lookups. Each include, a, mx, exists and redirect costs a lookup, nested ones included; over 10 is a PermError (section 4.6.4). SparkPost adds nothing to your count, which is one more reason not to add an include for it. See how to fix too many SPF lookups.
• Choosing ~all or -all without a plan. -all asks receivers to reject unlisted servers; ~all asks them to accept but mark the mail. Once DMARC is enforced, receivers act on DMARC instead. Read SPF soft fail vs hard fail before you choose.
• Adding an include for SparkPost to your root SPF record. SPF is checked on the bounce domain, so the root include spends lookups without changing results.
• Using a US account target (sparkpostmail.com) on a SparkPost EU account, or the other way round. The CNAME must point at your account's own domain.
• Setting aspf=s in DMARC. A bounce subdomain only aligns with your From domain under relaxed SPF alignment.