Email authentication for SparkPost: SPF, DKIM and DMARC

25 April 2026 · 13 min read

SparkPost (now part of MessageBird/Bird) is a high-throughput sending platform built on the Momentum MTA, and it is engineered to authenticate mail under your own domain rather than its own. That is good news: unlike some platforms where DKIM signs under the vendor's domain, SparkPost is designed to sign with a key published in your DNS and, with one extra record, to make the envelope sender (Return-Path) align too. The catch is that none of this happens until you add a Sending Domain, publish the records SparkPost generates, and verify them. Skip a step and your mail still leaves SparkPost, but DMARC sees it as unaligned and, once you enforce, your recipients stop seeing it.

This guide is SparkPost-specific. It uses SparkPost's real SPF include (_spf.sparkpostmail.com), its real DKIM selector convention (scph0316 and similar), the exact DKIM TXT record format SparkPost generates, and the bounce-domain CNAME that points to sparkpostmail.com (or eu.sparkpostmail.com on the EU stack). By the end you will know precisely which DNS records to publish, which one controls SPF alignment, and how to get to p=reject without losing a single SparkPost-sent message.

If you want a baseline before you change anything, run your domain through the DMARC checker, SPF checker and DKIM checker. Those three will tell you in under a minute whether SparkPost is already aligned on your domain or whether you have work to do.

The concept that decides everything: alignment, not just "pass"

DMARC does not pass or fail on whether SPF or DKIM individually pass. It passes when at least one of them passes and aligns with the domain in your visible From: header. This single idea is what separates a working SparkPost setup from one that silently breaks at enforcement.

There are two alignment checks, and DMARC needs only one to hold:

• SPF alignment: the domain in the SMTP envelope sender (the Return-Path, also called MAIL FROM or the bounce address) must match your From: domain. Under relaxed alignment, the default, matching the organisational domain is enough.
• DKIM alignment: the domain in the d= tag of a valid DKIM signature must match your From: domain, again by organisational domain under relaxed alignment.

Here is the SparkPost-specific reality. When you create a Sending Domain and publish the DKIM TXT record, SparkPost signs every message with d=yourdomain.com, so DKIM aligns out of the gate. SPF is the part that is conditional. By default SparkPost uses its own bounce infrastructure, which means the Return-Path lives on a sparkpostmail.com address. SPF passes for that address, but sparkpostmail.com is not your From: domain, so SPF does not align. To make SPF align as well, you add a custom bounce domain (a CNAME that moves the Return-Path onto a subdomain of yours).

The practical consequence: with DKIM published and verified, you can reach p=reject on SparkPost mail even if you never touch SPF alignment, because DKIM alone satisfies DMARC. But you want both aligned for resilience, and for the cleaner aggregate reports that come from belt-and-braces authentication. For the deeper mechanics, see DMARC alignment explained.

Step 1: Create a Sending Domain in SparkPost

Everything starts in Configuration, Sending Domains, Add a Domain (the API equivalent is a POST to the Sending Domains endpoint). Enter the domain you send From:, for example mail.yourdomain.com if you use a subdomain for bulk sending, or yourdomain.com directly. A dedicated subdomain for SparkPost traffic is a sound choice because it isolates your reputation and keeps the DNS tidy, but the authentication mechanics are identical either way.

Once the domain exists, SparkPost generates the DNS records you need on the domain's detail page under the DNS or Domain Verification section. There are three things SparkPost can ask you to publish, depending on how thorough you want to be:

1. A DKIM TXT record (always; this is what makes DKIM align).
2. A bounce CNAME (optional but recommended; this is what makes SPF align).
3. An SPF TXT record on your own domain (so SparkPost's sending IPs are authorised).

Take each in turn.

Step 2: Publish the DKIM record (the record that carries you)

SparkPost auto-generates a DKIM key pair when you create the Sending Domain and shows you the public half as a TXT record to publish. The selector follows SparkPost's scph convention. You will see selectors like scph0316, scph0421 or scph0717. The four digits are not random month codes you can choose; they are assigned to your account and domain, so copy whatever SparkPost shows you rather than typing one from a guide.

The record SparkPost generates looks like this. Substitute your real selector and the full public key SparkPost displays:

; DKIM public key for your SparkPost Sending Domain
scph0316._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+W6scd...IDAQAB"

A few SparkPost-specific points that trip people up:

• The hostname is <selector>._domainkey.<your sending domain>. If your Sending Domain is mail.yourdomain.com, the record host is scph0316._domainkey.mail.yourdomain.com, not scph0316._domainkey.yourdomain.com. Match the Sending Domain exactly.
• Do not let your DNS panel double-append the zone. Cloudflare and many registrars auto-add the zone suffix. Enter only the host label (scph0316._domainkey or scph0316._domainkey.mail) where the panel expects a name. If you paste the fully qualified host into a panel that appends the zone, you end up with scph0316._domainkey.yourdomain.com.yourdomain.com and verification fails.
• The public key is long. SparkPost supports 1024-bit and 2048-bit RSA keys, and a 2048-bit key produces a value longer than the 255-character limit of a single DNS string. Many DNS panels split it for you automatically; if yours does not, you must break the p= value into multiple quoted strings inside one TXT record. Our DNS record splitter does this correctly so the joined value stays byte-for-byte identical.
• Keep h=sha256. SparkPost signs with SHA-256. The TXT record advertises that with h=sha256. Do not edit it.

After the record propagates, return to SparkPost and click Verify (or call the API verification with dkim_verify). SparkPost queries your DNS, compares the published key to the one it holds, and flips the DKIM status to verified. Until that is green, SparkPost is not signing your mail with an aligned key, and you should not move on.

Confirm it independently with the DKIM checker: enter your domain and the selector (scph0316) and you should see the published key resolve and parse cleanly.

Step 3: Publish SPF so SparkPost's IPs are authorised

SPF on your own domain authorises the IP addresses that are allowed to send as you. SparkPost publishes its outbound IPs behind a single include:

yourdomain.com.  IN  TXT  "v=spf1 include:_spf.sparkpostmail.com ~all"

That include costs one DNS lookup against SPF's hard limit of ten. SparkPost keeps its sending ranges inside _spf.sparkpostmail.com, so you never have to list individual IPs or update this record when SparkPost rotates infrastructure.

Two things to get right:

• Merge, do not duplicate. A domain may have exactly one SPF record. If you already send through other providers, add the SparkPost include to your existing v=spf1 record rather than publishing a second TXT record. Two SPF records is a permerror, which fails SPF entirely. For example, alongside Google Workspace it becomes "v=spf1 include:_spf.google.com include:_spf.sparkpostmail.com ~all".
• Mind the lookup budget. SparkPost only costs one lookup, but if you stack several providers you can blow past ten and hit a permerror. Run the merged record through the SPF checker to see your live lookup count, and if you are close to the ceiling, our SPF flattening keeps you under it automatically.

Important nuance: publishing this SPF record makes SPF pass, but on its own it does not make SPF align, because SparkPost's default Return-Path is still on sparkpostmail.com. Alignment is the job of Step 4.

Step 4: Add a bounce domain to make SPF align

This is the SparkPost-specific step that closes the SPF alignment gap, and it is the one most setups skip. By default SparkPost handles bounces on its own domain, so the envelope sender (MAIL FROM / Return-Path) reads something like bounces@sparkpostmail.com. SPF passes for sparkpostmail.com, but because that is not your From: domain, SPF does not align and your aggregate reports will show SPF failing alignment even though the SPF check itself passes. That mismatch is the single most common SparkPost confusion: SPF "passes" in a header inspector, yet DMARC counts it as an SPF alignment failure.

To fix it, configure a bounce domain. In Configuration, Sending Domains, open your domain and add a bounce subdomain, for example bounce.yourdomain.com or mail.yourdomain.com. SparkPost then asks you to publish a CNAME that points your bounce subdomain at SparkPost's bounce handler:

; US (sparkpost.com) stack
bounce.yourdomain.com.  IN  CNAME  sparkpostmail.com.

; EU (eu.sparkpost.com) stack
bounce.yourdomain.com.  IN  CNAME  eu.sparkpostmail.com.

Use eu.sparkpostmail.com only if your account is on the EU stack (you log in at app.eu.sparkpost.com); otherwise use sparkpostmail.com. After it propagates, verify it in the dashboard (or via the API with cname_verify). Once verified, SparkPost rewrites the Return-Path to use your bounce subdomain, the envelope domain becomes a subdomain of yours, and SPF aligns by organisational domain under relaxed alignment.

One detail worth knowing: because the bounce subdomain is a CNAME to sparkpostmail.com, the SPF evaluation for your envelope follows that chain and still resolves to SparkPost's authorised IPs, so the SPF check passes and aligns at the same time. You do not need a separate SPF TXT record on the bounce subdomain; the CNAME handles it.

After this step, a SparkPost message has:

• From: you@yourdomain.com
• DKIM signature with d=yourdomain.com (selector scph0316), aligned.
• Return-Path on bounce.yourdomain.com, which passes and aligns SPF.

That is full dual alignment, which is exactly what you want before enforcement.

Step 5: Publish a DMARC record in monitoring mode

With authentication in place, publish a DMARC policy that does nothing punitive yet but turns on reporting. The record lives at _dmarc.yourdomain.com:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1;"

p=none tells receivers to take no action, only report. The rua address is where aggregate (RUA) XML reports land daily. fo=1 asks for a failure report whenever any underlying check fails, which is useful while you are tuning SparkPost. You can generate a complete, valid record with the DMARC generator if you would rather not hand-write the tags.

Crucially, leave the policy at p=none until the reports prove SparkPost is aligning. Enforcing before you have evidence is how legitimate mail gets rejected. If you would rather not stand up your own mailbox and XML parser, point rua at our monitoring service; it ingests the reports, shows you per-source pass and alignment rates in plain language, and alerts you the moment a record changes.

Step 6: Read the aggregate reports and confirm SparkPost aligns

Aggregate reports are grouped by sending source, so SparkPost traffic shows up as its own row. For each source the report tells you, per message group:

• whether DKIM passed and whether it aligned, and
• whether SPF passed and whether it aligned.

For SparkPost you are looking for two specific confirmations:

1. DKIM: result pass, with the signing domain (d=) equal to your domain and the selector reading scph.... That confirms Step 2 worked.
2. SPF: result pass, with the envelope/MAIL FROM domain now on your bounce subdomain rather than sparkpostmail.com. That confirms Step 4 worked.

If DKIM aligns but SPF still shows the sparkpostmail.com envelope, your bounce CNAME is missing or unverified: go back to Step 4. If DKIM itself is failing, the published key does not match the one SparkPost holds, usually a copy-paste truncation or a double-appended zone in the hostname: recheck Step 2 with the DKIM checker.

Drop the raw XML into the DMARC report analyser to read it without squinting at angle brackets, and use the DMARC checker to confirm your policy record itself is valid and discoverable.

Watch for stray sources. A very common surprise in the first week of reports is a second tool sending as your domain that you forgot about: a CRM, a helpdesk, an invoicing app. Identify and authenticate every legitimate source before you tighten the policy, or enforcement will silently bin it.

Step 7: Move to quarantine, then reject

Once the reports show SparkPost (and every other legitimate source) passing and aligning consistently for one to two weeks, tighten the policy in stages. Never jump straight from none to reject.

First, quarantine a slice of traffic with pct:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; fo=1;"

pct=25 applies the quarantine policy to a quarter of failing mail, so any oversight surfaces as a small, recoverable signal rather than a mass diversion to spam. Watch the reports for a few days, confirm SparkPost is unaffected, then raise to pct=100, then move to full rejection:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=s; aspf=s;"

At p=reject, receivers refuse mail that fails DMARC outright. Because SparkPost is signing with an aligned DKIM key (and, if you did Step 4, aligning SPF too), your SparkPost mail sails through while spoofed mail using your domain is blocked at the door.

A note on the strict tags adkim=s and aspf=s: they require an exact domain match rather than an organisational-domain match. With SparkPost this is usually safe only if your DKIM d= and your bounce subdomain are on exactly the same domain as your From: address. If you send From: you@yourdomain.com but sign and bounce under mail.yourdomain.com, strict alignment will fail; keep the default relaxed alignment (omit adkim/aspf) in that case. For a structured walk-through of the staged rollout, see the enforcement journey.

SparkPost-specific gotchas, collected

• DKIM selectors are assigned, not chosen. You cannot pick scph0316. Whatever selector SparkPost shows on the Sending Domain page is the one you publish. If you rotate keys later, SparkPost issues a new scph selector and you publish the new TXT record alongside the old one.
• EU stack uses different targets. On the EU platform the include and bounce target differ. SPF still uses _spf.sparkpostmail.com, but the bounce CNAME points to eu.sparkpostmail.com. Verify which stack your account is on before copying records.
• One SPF record, always. The most damaging mistake is publishing a second v=spf1 TXT record for SparkPost when one already exists. Merge the include into the single existing record.
• 2048-bit keys need splitting. A 2048-bit DKIM public key exceeds 255 characters and must be split into multiple strings within one TXT record, or your panel must do it for you. A botched split silently breaks DKIM. Use the DNS record splitter.
• Subdomain mismatch breaks alignment. If your Sending Domain, your DKIM host and your bounce subdomain are not on the same organisational domain as your From:, relaxed alignment still works but strict alignment will not. Keep them consistent.
• Verify in the dashboard, then verify independently. SparkPost's own green tick confirms the record matches what SparkPost expects. The SPF checker and DKIM checker confirm the wider internet sees the same thing, including propagation and lookup-count problems SparkPost will not flag.

Optional hardening: MTA-STS, TLS-RPT and BIMI

Once DMARC is at p=reject, two more layers are worth adding, and they are domain-level rather than SparkPost-specific.

MTA-STS tells sending servers to require TLS when delivering to your domain, closing the door on downgrade attacks against inbound mail. It is independent of SparkPost (it governs mail coming to you), but a domain serious about authentication should publish it. Check or generate yours with the MTA-STS checker, and pair it with a TLS-RPT record so you get reports on TLS failures via the TLS-RPT checker.

BIMI lets your verified logo appear next to authenticated mail in supporting inboxes, but it has a hard prerequisite: DMARC must be at enforcement (p=quarantine with pct=100, or p=reject). Because SparkPost signs with aligned DKIM, reaching that prerequisite is straightforward, after which you can publish a BIMI record and, for the major mailbox providers, a Verified Mark Certificate. Validate the pieces with the BIMI checker. See our BIMI product for the logo and VMC requirements.

The practical takeaway

SparkPost is one of the friendlier platforms for DMARC because it is built to authenticate under your domain. The whole job comes down to four records and one discipline:

1. Create the Sending Domain and publish the DKIM TXT record at scphXXXX._domainkey.yourdomain.com. This makes DKIM align and is the record that gets you to p=reject.
2. Add include:_spf.sparkpostmail.com to your single SPF record so SparkPost's IPs are authorised.
3. Add a bounce domain CNAME to sparkpostmail.com (or eu.sparkpostmail.com) so the Return-Path moves onto your domain and SPF aligns too.
4. Publish DMARC at p=none, read the reports until SparkPost shows pass and align on both, then ramp quarantine to reject.

The discipline is simply this: never enforce on a hunch. Let the aggregate reports prove SparkPost is aligned first.

Start by checking what is live right now with the DMARC checker, SPF checker and DKIM checker. If you would rather hand the whole enforcement journey to someone who does it daily, our done-for-you DMARC service takes your domain from p=none to p=reject, SparkPost and every other source included, without an email outage, and our monitoring watches the reports and alerts you the moment anything changes. For sibling provider guides, see how the same alignment rules play out for Amazon SES, Mailgun and Postmark.