DKIM record for SparkPost

The DNS records

SparkPost returns the selector and public key when you create the sending domain. The values below follow the examples in SparkPost's API reference; publish the ones your account shows.

DKIM key generated by SparkPost

Type: TXT · Host: scph0316._domainkey Copy

v=DKIM1; k=rsa; h=sha256; p=<public key from SparkPost>

scph0316 is SparkPost's example selector. If you sign for a subdomain, the name becomes <selector>._domainkey.<subdomain>.

Your own key under your own selector (API)

Type: TXT · Host: <selector>._domainkey Copy

v=DKIM1; k=rsa; h=sha256; p=<your public key>

Supply the private key, public key and selector together when you create or update the sending domain.

Bounce domain (for the return path, not DKIM)

Type: CNAME · Host: bounces Copy

sparkpostmail.com

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

Set it up and turn on signing

1. Create the sending domain in SparkPost (in the app or with POST /api/v1/sending-domains). Let SparkPost generate the key, or send your own private, public and selector values.
2. Publish the TXT record at the _domainkey name SparkPost returns. Keys over 1024 bits need a TXT value split into several strings; SparkPost says to use 1024 bits if your DNS host can't do that.
3. Ask SparkPost to check it (dkim_verify in the API). Verify within two weeks, or SparkPost removes the domain from your account.
4. Optionally add a bounce subdomain with a CNAME to your account's SparkPost domain and verify it with cname_verify.

DMARC alignment

With the TXT key verified, SparkPost signs your messages with your domain, so the DKIM result can align with your From address under DMARC. SparkPost lets you verify a domain through a mailbox instead of DNS, but warns that it can't DKIM-sign mail for a domain verified that way. Use DNS verification if you want an aligned signature.

Key length and rotation

New sending domains default to a 2048-bit key, and keys you supply must be between 1024 and 4096 bits. A domain can hold up to 256 additional DKIM keys, which helps when you change keys: publish the new selector first, then switch. Replacing the main key means sending a new private key, public key and selector together, and that resets the domain's DKIM status to unverified until the new TXT record is checked. SparkPost doesn't publish a rotation schedule.

Common mistakes

• One string for a 2048-bit key. Many DNS hosts reject a TXT value that long. Split it into strings or choose a 1024-bit key.
• Mailbox verification. It lets you send, but SparkPost then can't DKIM-sign, so DMARC has nothing aligned to rely on.
• Changing the key fields without republishing. Any change to signing_domain or the key resets dkim_status to unverified.
• Waiting too long. Sending domains that stay unverified for two weeks are removed.