[ Sending-service guides ]

Authenticate email sent through SparkPost: configuration and verification

Configure SparkPost sending and bounce identities for the correct region and transport, then verify DKIM, SPF and DMARC on a received message.

By the EmailAuth research team · 8 min read

[ Key points ]

  • Match region, account and injection route before changing DNS.
  • Verify DKIM and the custom bounce identity separately.
  • Accept the workflow only after an aligned received-message test.
On this page
  1. Key points
  2. Takeaway
  3. By role
  4. Frequently asked questions
  5. Sources
  6. Glossary
  7. Related guides

[ Takeaway ]

Use account-issued records and the correct SMTP or API envelope setting, then prove an aligned passing identity on the actual received workflow message.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Mail admin perspective on route evidence

Match the account, DNS configuration and received message.

Next steps

  1. Verify the issued DKIM record and bounce-domain status separately.
  2. Test the exact region and subaccount.
  3. Preserve before-and-after receiver evidence.

CISO / SecOps

CISO perspective on delegated sender authority

A passing provider check is not proof of aligned organizational identity.

Next steps

  1. Keep API keys out of evidence and DNS.
  2. Review expected DKIM and envelope identities.
  3. Preserve DMARC policy and controlled rollback.

Founder / Non-technical

Founder perspective on notification continuity

Authentication changes need business-workflow acceptance.

Next steps

  1. Identify critical notifications and their owner.
  2. Approve the recognized sender identity.
  3. Require controlled delivery testing before rollout.

[ FAQs ]

Frequently asked questions

Can my US SparkPost account authenticate against the EU service?

No. SparkPost documents independent accounts. Match the application endpoint, key and sending-domain configuration to the same region.

SparkPost API Overview

Which DNS values should I publish for DKIM?

Use the public key and selector returned for your sending domain. The documentation example is not your record, and a private key never belongs in DNS.

SparkPost Sending Domains API

Does DKIM verification also verify a custom bounce domain?

No. Keep the checks separate. The documented bounce-domain methods are CNAME verification or, for Enterprise, MX verification.

SparkPost Sending Domains API

Where does an API integration set its envelope identity?

Use return_path. Standard SparkPost requires a CNAME-verified domain and rewrites the local part; Enterprise has different handling. Do not confuse it with content.from.

SparkPost Transmissions API

How does SMTP choose the bounce identity?

Use the supported verified bounce domain in SMTP MAIL FROM. Editing a message header called Return-Path is not the documented selection method.

SparkPost Sending Domains API

Why can a SparkPost message pass SPF and still fail DMARC?

Its envelope domain may not align with the visible From, and there may be no aligned passing DKIM signature. Compare actual receiver results and alignment modes.

DMARC RFC 9989

Does a successful SMTP login prove domain authentication?

No. Login authorizes injection. The receiver still needs to evaluate the delivered message, and a subaccount test must use the correct assigned domain and account context.

SparkPost SMTP API

What remains unverified for this guide?

No tenant was configured and no live DNS or message test was run. Use the acceptance worksheet, complete visual review and obtain owner approval before publication or rollout.

[ Sources ]

Sources

  1. SparkPost Sending Domains API

    Sections Cited configuration and verification guidance

  2. SparkPost SMTP API

    Sections Cited configuration and verification guidance

  3. SparkPost Transmissions API

    Sections Cited configuration and verification guidance

  4. SparkPost API Overview

    Sections Cited configuration and verification guidance

  5. DMARC RFC 9989

    Sections Cited configuration and verification guidance

  6. SPF RFC 7208

    Sections Cited configuration and verification guidance

  7. DKIM RFC 6376

    Sections Cited configuration and verification guidance

[ Glossary ]

Glossary

Sending domain
The configured domain used for a message’s visible From identity.
Bounce domain
The domain used for the envelope return address and out-of-band bounce handling.
Injection
The application’s submission of a message to SparkPost through SMTP or the API.
Alignment
The required relationship between the visible From domain and an authenticated SPF or DKIM identity.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base