Source review: 8 November 2026. This is documentary guidance, not evidence of a configured SparkPost account. Live DNS, tenant execution, received-message, visual and owner acceptance gates remain unverified.
Establish the account and injection route
Authenticate the domain used by the actual application, not merely the domain displayed in a dashboard. Record the visible From address, application, account region, subaccount and transport. SparkPost and SparkPost EU accounts are independent. Their API bases are https://api.sparkpost.com/api/v1 and https://api.eu.sparkpost.com/api/v1 respectively; Enterprise customers may have their own endpoint. Check credentials and domain configuration in the same region. SparkPost API overview
For SMTP, the documented hosts are smtp.sparkpostmail.com and smtp.eu.sparkpostmail.com. Use STARTTLS on port 587, or the documented alternative 2525, with AUTH LOGIN, username SMTP_Injection and an API key permitted to send via SMTP. Enterprise connection details require the account's technical contact. SMTP login proves client authorization, not the authenticity of a delivered message. Never put the key in DNS, an acceptance worksheet or a support screenshot. SparkPost SMTP configuration
Before changing anything, assign an application owner and DNS owner. Save the current domain records and sending configuration. Decide which workflow will produce a controlled test and which configuration can be restored if the change interrupts delivery. A successful test through a different client or region is not acceptance for this workflow.
Create and verify the sending domain
The Sending Domains API documents POST /api/v1/sending-domains. Create the intended domain in the correct account context, or retrieve its existing configuration rather than creating an unnecessary replacement. Default creation generates a DKIM key pair and returns the public key, selector and signing domain. Publish the corresponding public-key TXT record at the selector under _domainkey for that signing domain. Use the issued values, never the documentation's example key. Then call POST /api/v1/sending-domains/{domain}/verify with dkim_verify set to true and preserve the returned statuses. SparkPost sending domains
SparkPost’s creation documentation requires domain verification within two weeks; an unverified domain is otherwise removed from the account. Give the account owner a verification deadline rather than leaving a newly created domain indefinitely pending. Creation and verification requirement
DNS administrators should compare the fully qualified owner with their editor's relative Host field to avoid duplicating the domain suffix. A DKIM selector locates the public key; the private key remains with the signer. Preserve another active sender's selector instead of overwriting it. Long TXT values may be represented as multiple character strings within one record; inspect the assembled value rather than interpreting the editor's visual wrapping as missing data. DKIM key publication DNS TXT strings
Treat verification output as separate observations. An ownership result is not a received-message DKIM pass, and a DNS failure is not an SMTP credential failure. Retain the exact error and timestamp. Resolve the failing stage before changing unrelated authentication settings.
Configure the bounce identity deliberately
A custom bounce domain controls the envelope identity and Return-Path, not the visible From address. SparkPost documents CNAME verification for bounce use, with region-specific targets; Enterprise can also use MX verification. Obtain the correct target from the account's supported configuration. Use a dedicated subdomain and check existing records before delegating it. Do not replace the organization's ordinary inbound-mail routing to accommodate an outbound test. Bounce-domain requirements
For the Transmissions API, return_path sets the envelope address. The standard service requires its domain to be CNAME-verified and overwrites its local part. Enterprise handling differs, so do not promise a preserved local part on a standard account. The content From address must use a verified sending domain. Check stored templates and overrides as well as application code when the observed sender differs from the intended sender. Transmission identities
For SMTP, use the verified bounce domain in MAIL FROM rather than trying to control it by inserting a Return-Path header into the message. When sending on behalf of a subaccount, the SMTP documentation describes including its ID in the injection username and using an assigned sending domain. The documentation specifies the primary account’s API key as the SMTP password even when the subaccount ID is included in the username. Keep the key secret and confirm its permitted scope. Record this context explicitly; a primary-account test does not establish subaccount behavior. SMTP subaccounts Bounce-domain selection
Prove alignment at the receiving mailbox
Send synthetic content through the actual application to a controlled recipient. Retain a sanitized original message and the receiver's trusted Authentication-Results. Compare the visible From domain with the SPF-authenticated envelope domain and each passing DKIM d= signing domain. Record every selector s= so that an unexpected signer is not hidden by a single green summary.
SPF authenticates the envelope identity, not the displayed From. Adding an include to the visible From domain cannot repair a different envelope's alignment. Maintain one valid SPF policy at each relevant owner and assess its DNS lookup budget before any SPF edit. SPF evaluation and limits
DMARC needs an aligned passing SPF or DKIM path. Evaluate the actual strict or relaxed alignment settings; a related subdomain is not necessarily sufficient under strict mode. A provider's acceptance response, a DNS checker and a recipient's authentication result answer different questions. None guarantees inbox placement. DMARC identifier alignment
SparkPost acceptance worksheet
Complete one record for each application, region and subaccount combination. These fields are a proposed operational artifact, not completed test results.
- Ownership: application owner ___; DNS owner ___; change approval ___; rollback owner ___.
- Scope: region ___; account/subaccount ___; SMTP or API ___; template/version ___.
- Intended identities: visible From ___; DKIM signing domain ___; bounce domain ___; alignment modes ___.
- DNS evidence: issued selector/public record ___; bounce target ___; authoritative answers and timestamp ___.
- Provider evidence: domain-verification output ___; separate DKIM and bounce status ___; unresolved errors ___.
- Injection evidence: SMTP endpoint or API base ___; sanitized response ___; transmission/message reference ___.
- Receiver evidence: From ___; envelope ___; each d=/s= ___; SPF ___; DKIM ___; DMARC ___.
- Decision: expected identity matched ___; retry/rollback test ___; owner sign-off ___; next review date ___.
Accept only when the expected route and identities match, an aligned path passes, and the workflow owner confirms delivery behavior. Leave missing evidence pending rather than filling it with a documentation example.
Fictional diagnosis: a passing signature that does not align
This scenario is entirely fictional. A test message displays notices@billing.example, while the receiver reports passing DKIM for unrelated.example and passing SPF for another unrelated domain. DMARC fails. Those passes establish authenticated identities, but neither authenticates billing.example for DMARC.
The operator compares the application payload with the worksheet and discovers an unintended sender configuration. The recovery plan is to restore the approved From, confirm its SparkPost sending-domain configuration, and retest the exact application route with the intended signer and bounce identity. The operator does not weaken the organizational DMARC policy or invent an SPF include. A second test remains required; this fictional diagnosis supplies no live evidence for any account.
Preserve a reversible recovery route
If sending fails before delivery, investigate endpoint, credentials, domain status and the precise provider response first. If delivery succeeds but alignment fails, investigate observed identities instead. Restore the previous approved application configuration when needed, while preserving records still required by queued mail or other workflows. Remove obsolete selectors and bounce delegations only after the owners confirm dependencies are retired. Keep this draft unpublished until independent review and the outstanding live, visual and owner gates are completed.