SPF, DKIM & DMARC for Braze.
Braze doesn't hand you a shared SPF line to paste onto your root domain — its email channel runs on SparkPost's sending infrastructure, and Braze provisions your authentication records per account when it configures your IP(s) and sending domain during onboarding. You give Braze a dedicated sending subdomain (say email.yourdomain.com), Braze generates a unique DKIM public-key record and a bounce/Return-Path record for your account, and you publish those exact values at your DNS host. DKIM signed as your own domain is what carries the DMARC pass; a custom bounce/Return-Path subdomain (a CNAME to sparkpostmail.com) layers SPF alignment on top. DMARC itself is a record Braze never creates — you add it yourself.
Why authenticate Braze?
Braze is a high-volume lifecycle and marketing platform, so its mail is exactly the kind receivers scrutinize hardest — and authentication decides whether a campaign lands in the inbox or the spam folder. Since February 2024, Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft began enforcing the same on high-volume mail bound for Outlook.com, Hotmail, and Live in 2025. Braze's own guidance is blunt that the usual reason Braze mail gets blocked is a DMARC failure caused by SPF and DKIM being misconfigured. The trap specific to any ESP is DKIM signing with the provider's own domain instead of yours: if Braze's DKIM key isn't published and signing as your domain, nothing aligns and DMARC can't pass. Set it up correctly and both mechanisms align to your domain, DMARC passes, the reputation you build on your Braze sending IP accrues to your own domain, and forwarded mail keeps authenticating.
The SPF reality for Braze
Braze is a per-account sender, not a shared-include provider — so there is NO include:sparkpostmail.com to add to your ROOT SPF record, and you should not add one there. Because Braze runs on SparkPost's infrastructure, the SPF mechanism lives on your bounce/Return-Path subdomain, not your apex. By default Braze sends with an envelope MAIL FROM (Return-Path) on sparkpostmail.com, so a raw SPF check passes — but it passes for sparkpostmail.com, not your domain, which means it does not ALIGN and does nothing for DMARC on its own. That is fine, because DKIM (signed as your own domain via your scph selector) is what carries DMARC through alignment. If you also want SPF aligned to your domain — worth doing, since some receivers weight it and it survives certain forwarding paths — you set up a custom bounce/Return-Path subdomain: a CNAME like bounces.yourdomain.com pointing to sparkpostmail.com (which transparently inherits SparkPost's SPF, published as v=spf1 exists:%{i}._spf.sparkpostmail.com ~all), or, on the alternative MX method, an MX plus a v=spf1 include:sparkpostmail.com ~all TXT on that same subdomain. Either way the include sits on the bounce SUBDOMAIN, never your root — so Braze adds zero DNS lookups to your root SPF, which stays reserved for the senders that actually use your domain in the Return-Path (Google Workspace, Microsoft 365, a transactional relay). One region note: EU-hosted Braze instances use an EU-specific host (an eu.sparkpostmail.com target) in place of sparkpostmail.com — use whichever host Braze gives you.
Step by step
- 1
Pick a dedicated sending subdomain
Decide on a subdomain used only for Braze — email.yourdomain.com, news.yourdomain.com, mktg.yourdomain.com — and give it to your Braze onboarding or account team. Sending campaigns from a dedicated subdomain (Braze's recommended structure) isolates your marketing reputation from your corporate and transactional mail, so a bad blast can't drag down your root domain.
- 2
Get your per-account DNS records from Braze
Braze configures your IP(s) and your sending domain on its SparkPost-based infrastructure, then provides the exact records to publish: a DKIM public-key record, a bounce/Return-Path record, and SPF guidance for the bounce subdomain. There is no self-serve include to paste — the selector and key are unique to your account, and the host differs between the US and EU Braze instances. Copy the values exactly as Braze gives them to you.
- 3
Publish the DKIM record
Add the DKIM record Braze gives you on your sending subdomain — typically a TXT record at a SparkPost-style selector like scph0123._domainkey.email.yourdomain.com whose value is v=DKIM1; k=rsa; p=<your public key> (some accounts get a CNAME instead). Braze holds the matching private key and signs your mail as d=email.yourdomain.com (your sending subdomain), which is what aligns to your From address for DMARC.
- 4
Add the bounce / Return-Path record for SPF alignment
Create your bounce subdomain (e.g. bounces.yourdomain.com) as a CNAME pointing to sparkpostmail.com — or the EU-specific target for EU-hosted Braze. This makes your envelope Return-Path a subdomain of your own domain, so SPF aligns. The CNAME transparently inherits SparkPost's SPF, so there's nothing else to add. (If Braze gives you the MX-based method instead, you'll add an MX to sparkpostmail.com plus a v=spf1 include:sparkpostmail.com ~all TXT on that same bounce subdomain — never on your root.)
- 5
Leave your ROOT SPF alone
Do not add include:sparkpostmail.com to the SPF record on your apex domain — Braze doesn't authenticate SPF there, it uses the bounce subdomain. Adding it to the root does nothing useful and needlessly burns one of your 10 SPF DNS lookups. Keep exactly one SPF record on the root, holding only the senders that put your root domain in the Return-Path.
- 6
Publish your DMARC record
Braze never creates DMARC for you. Add a TXT record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Braze recommends setting the policy on the ROOT domain so it applies to all subdomains (including your Braze sending subdomain) through inheritance. p=none is monitor-only, so nothing is affected while you confirm alignment.
- 7
Turn off the Cloudflare proxy on the CNAME(s)
If your DNS is behind Cloudflare, set the bounce CNAME (and a CNAME-style DKIM record, if Braze gave you one) to 'DNS only' — the grey cloud. An orange-cloud proxied CNAME won't resolve to sparkpostmail.com and Braze's domain verification will fail.
- 8
Tell Braze the records are live, then confirm on a real message
Let your Braze team know the DNS is published so Braze can verify the domain and enable sending. Then send a test campaign, open it in Gmail, and choose More → Show original: you want DKIM: PASS with d= your own domain (e.g. email.yourdomain.com), SPF: PASS (showing your bounce subdomain if you set a custom Return-Path, or sparkpostmail.com if you didn't), and DMARC: PASS. Finally, warm your sending IP by ramping volume gradually over the first few weeks if Braze assigned you a fresh dedicated IP.
Records to add
Braze generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | scph0123._domainkey.email | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…(per-account public key)DKIM public key. The scph selector (SparkPost date-coded format) and key are generated per-account by Braze — copy the exact record from what Braze gives you. Braze holds the private key and rotates it. Some accounts receive a CNAME here instead of a TXT. Illustrative value. |
| CNAME | bounces | sparkpostmail.comBounce / Return-Path subdomain — this is what gives you SPF alignment, and it inherits SparkPost's SPF automatically (sparkpostmail.com publishes v=spf1 exists:%{i}._spf.sparkpostmail.com ~all). EU-hosted Braze uses an eu.sparkpostmail.com target. Illustrative — use the exact host/target Braze provides. Put this on a dedicated bounce subdomain, not your root. |
| TXT | bounces | v=spf1 include:sparkpostmail.com ~allALTERNATIVE to the CNAME above — use only if Braze gives you the MX-based bounce method (an MX to sparkpostmail.com plus this SPF). It lives on the bounce SUBDOMAIN, never your root. EU: use the eu.sparkpostmail.com host Braze provides. A subdomain can't have both a CNAME and this TXT — pick one method. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYou publish this yourself — Braze never creates it. Put it on the ROOT so it covers your Braze subdomain by inheritance. One _dmarc per domain; start at p=none, then tighten. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Braze's setup costs against that budget.
Braze's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.
DKIM
DKIM is the load-bearing record for Braze, because it's the mechanism that aligns to your domain and carries DMARC. When Braze configures your domain on its SparkPost-based infrastructure, it generates a unique DKIM key pair for your account, keeps the private key, and gives you the public key to publish in DNS. Most accounts get a TXT record at a SparkPost-style selector — something like scph0123._domainkey.email.yourdomain.com — whose value is v=DKIM1; k=rsa; p=<your public key>; some accounts are handed a CNAME instead. Either way you publish exactly what Braze provides: the scph selector is date-coded and unique to you, so you can't guess it, and Braze rotates the underlying key on its side. Once the record resolves, Braze signs every message as d=email.yourdomain.com (your sending subdomain), and because that shares the organizational domain of your visible From address, the signature aligns — which is what lets DMARC pass. The single most common Braze DKIM failure is the ESP-domain trap: if the key isn't published, the mail may be signed as the provider's domain instead of yours, so it passes DKIM but doesn't align — and DMARC gets no help from it. Confirm on a real message that the signing domain reads as your own domain (d=email.yourdomain.com or your root), not a sparkpostmail.com or braze address.
DMARC
DMARC is a separate policy record on your domain that Braze does not create — you add it at your DNS host. Publish a TXT record at _dmarc.yourdomain.com beginning v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Braze's own recommendation is to set the policy on your ROOT domain so it applies to every subdomain — including your dedicated Braze sending subdomain — through policy inheritance, rather than publishing a separate record on the subdomain (you'd only add a subdomain-specific _dmarc, or use the sp= tag on the root record, if you deliberately want a different subdomain policy). p=none is monitor-only: it changes nothing about delivery while you watch the aggregate (rua) reports to confirm Braze passes SPF and DKIM aligned to your domain. Remember DMARC passes when EITHER SPF or DKIM aligns — with Braze, DKIM aligns via your scph selector, and SPF aligns too if you set the custom bounce/Return-Path subdomain, so a fully configured setup passes on both. Once reports show Braze as a consistent, aligned source over a week or two, tighten to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole domain no matter how many senders you run. (Braze notes that BIMI, if you pursue it later, needs no special coordination on its end — but it does require a DMARC policy of p=quarantine or p=reject first.)
Check it actually worked
Don't rely on Braze reporting the domain as verified — confirm it on a real message. Send a test from your Braze sending subdomain, open it in Gmail, and choose More → Show original: you want DKIM: PASS with d= your own domain (typically your sending subdomain, e.g. d=email.yourdomain.com — not a sparkpostmail.com or braze domain, which would mean the key isn't aligning), and DMARC: PASS. SPF will show PASS for your bounce subdomain if you set a custom Return-Path, or for sparkpostmail.com if you didn't — the sparkpostmail.com case is expected and DMARC still passes because DKIM carries it, so don't treat it as a failure. Run your domain through Qualisend's domain health check to confirm the DKIM record, the bounce/Return-Path record, and your DMARC record all resolve cleanly, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — Braze (via SparkPost) should appear as an aligned, passing source before you ever tighten your policy toward p=reject.
Common gotchas
- Coverage
Your records are per-account and come FROM Braze — there is no self-serve include to paste. The scph DKIM selector, the key, and the bounce target are generated for your account during onboarding; copy them exactly. Guessing a selector or an SPF include won't authenticate anything.
- DNS setup
US vs EU instance matters. EU-hosted Braze runs on SparkPost's EU infrastructure and uses an eu.sparkpostmail.com target (and EU-specific record hosts); the US instance uses sparkpostmail.com. Publishing the wrong region's host breaks bounce/Return-Path resolution and SPF — use exactly what Braze hands you.
- DNS setup
SPF alignment is opt-in. By default Braze's envelope Return-Path is on sparkpostmail.com, so SPF passes but doesn't align and DMARC rides entirely on DKIM. Seeing 'SPF: sparkpostmail.com' is normal — set the custom bounce/Return-Path subdomain (the CNAME to sparkpostmail.com) if you want SPF aligned too.
- Breaks auth
Never add include:sparkpostmail.com to your ROOT SPF. It belongs only on the bounce subdomain (or is inherited via the bounce CNAME). On the root it does nothing useful and needlessly burns one of your 10 SPF DNS lookups.
- DNS setup
Cloudflare proxy breaks it. Set the bounce CNAME — and a CNAME-style DKIM record if Braze gave you one — to 'DNS only' (grey cloud). An orange-cloud proxied CNAME won't resolve to sparkpostmail.com and verification stays pending.
- Coverage
Send from a dedicated subdomain, not your bare root. Blasting Braze campaigns from yourdomain.com pools your marketing reputation with your corporate and transactional mail; a dedicated subdomain (email./news.) is Braze's recommended structure and keeps a bad send from tanking your root domain.
- Coverage
A fresh dedicated IP needs warming. Braze onboarding often provisions dedicated IP(s); ramp volume gradually over roughly two to four weeks. (Lower-volume accounts may sit on a Braze-managed shared IP pool, where warming is handled for you.) A new IP has no reputation, so perfect DNS won't save early delivery if you blast at full volume on day one.
- DNS setup
Set DMARC at the ROOT so it covers your Braze subdomain by inheritance (Braze's own recommendation). Don't publish a conflicting second _dmarc on the sending subdomain unless you specifically want a different subdomain policy via sp= or a subdomain record.
- DNS setup
If Braze offers you subdomain delegation instead, it's an alternative — not an addition. In that flow you delegate the whole sending subdomain to SparkPost's nameservers via NS records and Braze manages the DKIM/SPF/bounce records for you. If you delegate, don't also publish your own conflicting records for that subdomain; pick one approach.
Build your SPF record
Braze doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listBraze SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.