SparkPost explicitly separates two things most platforms conflate: the sending domain, the one that appears in the From: header, and the bounce domain, the one behind the return address. Configuring the first without the second is the most common case — and the one that leaves SPF unaligned.
The sending domain: DKIM as TXT
A TXT record carrying the public key, on the selector SparkPost provides. It verifies domain ownership and enables DKIM signing: one record does both.
(selector)._domainkey.yourdomain.com TXT v=DKIM1; k=rsa; p=MIGfMA0GCSq…The bounce domain: a CNAME on a subdomain
SparkPost recommends using a subdomain as the bounce domain, with a CNAME pointing at the host it gives you:
bounces.yourdomain.com CNAME (host provided by SparkPost)That subdomain becomes the envelope address of your messages. Under relaxed alignment — DMARC’s default mode — a subdomain matches the parent domain: SPF aligns, on top of DKIM.
With no bounce domain configured, the return address stays SparkPost’s. SPF passes, does not align, and DMARC rests entirely on DKIM.
DMARC
Publish the monitoring policy on _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:your-address@yourdomain.comOnly tighten once every sender is identified. The progression, step by step.
Common mistakes with SparkPost
- Stopping at the sending domain. Sending works, DMARC passes on DKIM, and compliance vanishes the day a relay breaks the signature.
- Using the root domain as the bounce domain. SparkPost recommends a dedicated subdomain: it isolates sending reputation from your mailbox reputation.
- A CNAME placed on a name that is already taken. A CNAME cannot coexist with any other record on the same name — not even a TXT.
- Verifying too early. The verification tool queries live DNS: until propagation completes it returns an error that is not one.
Once it is in place, Clarsend reads your reports and shows you what passes, what fails, and who is sending without your knowledge.