SparkPost SPF, DKIM and DMARC setup, step by step

For a legacy SparkPost integration, publish the account-generated DKIM TXT record and configure a verified bounce domain appropriate to the account's region and product. For current Bird Email, use its own generated DKIM, return-path and DMARC requirements instead. Do not replace working SparkPost records with Bird examples merely because the product branding changed. Verify the actual sending route, public DNS and a delivered message before calling the setup complete.

On this page

• First identify SparkPost or current Bird
• Configure legacy SparkPost DKIM and bounce identity
• Configure current Bird Email separately
• Protect DMARC during setup or migration
• Verify DNS and receiver evidence
• Troubleshooting
• Frequently asked questions

First identify SparkPost or current Bird

A redirected help page is not evidence that an application has migrated. Inspect the actual account, API base URL or SMTP hostname, sending region, subaccount or workspace, and From domain. Keep that inventory beside the DNS change request. Existing SparkPost credentials and resource IDs do not simply become Bird credentials and IDs; Bird publishes an explicit migration workflow. Bird's SparkPost migration guide.

The legacy SparkPost SMTP documentation identifies smtp.sparkpostmail.com for its standard route and smtp.eu.sparkpostmail.com for SparkPost EU. These are SMTP server names, not bounce-domain CNAME destinations. Enterprise configurations have additional distinctions. Do not infer account region from the sender's postal address or the geographic location of a recipient. SparkPost SMTP reference.

For this legacy SMTP route, use STARTTLS on port 587 or the documented alternate 2525, AUTH LOGIN and username SMTP_Injection, with an API key permitted to Send via SMTP. For a subaccount, the documented username is SMTP_Injection:X-MSYS-SUBACCOUNT=SUBACCOUNT_ID (replace the placeholder); the password remains the primary account’s API key, and the sending domain must be assigned to that subaccount. Keep keys out of DNS and evidence. Enterprise connection details require the account’s technical contact. These connection checks do not prove delivered-message authentication. SMTP and subaccount configuration.

Current Bird Email uses workspace-scoped sending domains and separate us1 and eu1 registrations. The same customer domain registered in both regions has separate DNS requirements. An account's plan allowances and domain quotas also matter. Confirm the relevant account team or documentation before planning tenant, dedicated-IP or region changes. Bird sending domains.

This guide separates the two workflows because conflating them can break an otherwise valid sender. It is not a recommendation to migrate. Preserve the existing working selectors, bounce records, suppression handling and application configuration until a separately approved transition is ready.

Configure legacy SparkPost DKIM and bounce identity

Publish the account's DKIM key

Open the sending-domain configuration in the correct SparkPost account. Add the intended From domain if it is not already registered, then obtain its generated selector and complete public DKIM TXT value. Publish that record at the supplied owner and request domain verification. Check DKIM status separately from general ownership or bounce-domain status. SparkPost's API explicitly distinguishes those results. Sending Domains API.

For the API workflow, create only a genuinely new domain with POST /api/v1/sending-domains; default creation generates a key pair and returns the public key, selector and signing domain. After DNS publication, request POST /api/v1/sending-domains/{domain}/verify with dkim_verify set to true, substituting the actual registered domain. Retain the separate status fields. A new legacy domain must be verified within two weeks or it is removed. Mailbox ownership verification alone permits sending but does not enable branded DKIM signing, so it does not complete this guide’s DKIM requirement. Creation and verification.

For an issued owner shaped like SELECTOR._domainkey.example.com, use SELECTOR._domainkey only if your DNS editor appends example.com. Otherwise enter the full hostname. SELECTOR is an explanatory placeholder. Never copy a sample public key from an article, and never publish a private signing key.

For signing domain mail.example.com, SELECTOR._domainkey.mail.example.com is relative SELECTOR._domainkey.mail in the parent example.com zone, or SELECTOR._domainkey in a separately delegated mail.example.com zone. In a delegated _domainkey.mail.example.com zone it is simply SELECTOR. Query the actual delegated authority and preserve NS records and existing selectors. DNS authority boundaries.

If the DNS editor splits a long TXT value into quoted chunks, keep those chunks within one logical record. Do not introduce spaces into the key material or create multiple independent DKIM records at the same selector. A new selector can coexist with another provider's selector; an exact owner collision needs investigation rather than deletion.

Verify the bounce domain in the right region

Use a dedicated, unused subdomain for bounces. SparkPost's official CNAME verification table distinguishes:

• Standard SparkPost: target sparkpostmail.com.
• SparkPost EU: target eu.sparkpostmail.com.
• Enterprise: tenant-specific target in the form <public_tenant_id>.mail.e.sparkpost.com.

Copy the exact value supplied for your account. The Enterprise placeholder is not a literal DNS value. MX-based verification is Enterprise-only and requires consultation with the technical account manager. A CNAME-verified sending domain can serve as a bounce domain. SparkPost DNS and bounce-domain requirements.

A bounce CNAME belongs at its dedicated owner, not at a root domain already serving a website or mailboxes. It cannot coexist with ordinary TXT, MX or A records at the same hostname. Do not add a second SPF policy at that CNAME owner.

For an Enterprise MX-based design, consultation with the technical account manager supplies requirements, not routing approval. Obtain separate routing-owner approval for the exact owner, destination and complete numeric-priority/target MX set before changing DNS. Preserve ordinary mailbox routes. Compare the entire authoritative and recursive MX answers with that approved set and stop on any missing, extra or different tuple. Do not accept a merely nonempty MX response. Enterprise applicability.

Select the identity in the actual sending integration

Verification makes a domain available; it does not prove the application is using it. For SMTP, SparkPost documents that the envelope MAIL FROM is ordinarily rewritten unless the specified custom domain was CNAME-verified. Enterprise has a different rewriting rule. Check the production transport's configuration and the final received envelope identity rather than editing a visible Return-Path header in message content. SparkPost SMTP MAIL FROM behavior.

For an API sender, inspect the transmission’s return_path address: its domain must be CNAME-verified for the standard route. Enterprise permits a different envelope-address workflow. SparkPost Transmissions API. Confirm the bounce-domain selection used by that transmission or its applicable account configuration. Do not assume a setting observed in a different subaccount applies. Obtain a fresh sample after the change; previously delivered headers remain evidence of the old route.

On standard SparkPost, the API rewrites the local part of return_path; Enterprise can preserve it and supports its distinct envelope workflow. The content From domain must be a verified sending domain. Reconcile stored-template and override From values with the intended sender rather than checking only the top-level application setting. Transmission sender fields.

Configure current Bird Email separately

In the current Bird workspace, use Email → Domains to register the sending domain and inspect the generated records. The API exposes the same DNS instructions on the domain resource. Select the correct region and consider a dedicated sending subdomain rather than the company mailbox root. Bird sending-domain setup.

Bird's current outbound requirements are a generated DKIM TXT record, a return-path CNAME, and a valid DMARC policy, including a qualifying inherited policy. A tracking CNAME is optional for branded links. Optional receiving MX records are not required merely to authenticate outbound mail; publishing them at the company root can divert incoming mail. Bird authentication requirements.

For the return path, Bird documents regional targets us1.bounce.bird.com and eu1.bounce.bird.com. Its default label is send beneath the registered sending domain, but an account can choose another label. Copy the workspace's generated owner and destination. These are not interchangeable with SparkPost's legacy targets. Bird bounce domains.

Bird's documented return-path alias supplies the SPF authorization path without a new SPF include at your root. Preserve root SPF used by other services. Likewise, do not create a separate SPF TXT record alongside the return-path CNAME. Keep return-path CNAMEs DNS-only, unproxied and unflattened. Cloudflare CNAME guidance.

Apply CNAME processing checks to both legacy SparkPost bounce aliases and current Bird return-path aliases. Where literal CNAME answers are required, use DNS-only and turn the relevant per-record Flatten control off when available; ensure whole-zone flattening does not suppress those aliases. Cloudflare always flattens apex and same-zone-target aliases, and the latter can ignore the selected setting. If mandatory behavior prevents the required CNAME answer, stop and coordinate a supported configuration with the DNS and provider owners. Do not invent a switch or change shared settings or delegations blindly. Re-query the exact owner after any approved change. Cloudflare controls and mandatory behavior.

Bird’s top-level verified status proves DKIM ownership only. Wait for capabilities.sending, which additionally requires return-path and DMARC verification; tracking status is separate. Unverified registrations are removed after about 14 days, so complete setup promptly. Verification lifecycle. If changing the return-path hostname, follow its staged verification workflow instead of removing the working alias first.

If migrating, use distinct bounce and tracking names where needed, retain legacy DNS, and test both paths during the overlap. Bird's migration guide also calls for reviewing templates, suppressions, webhooks, scheduled sends and dedicated IPs. Authentication alone is not a completed application migration. Migration boundaries.

Protect DMARC during setup or migration

Start by looking up the visible From domain's DMARC record and relevant parent-policy discovery path. Preserve existing enforcement, sp, alignment settings and reporting destinations. An absent subdomain record does not mean no policy applies. Bird explicitly accepts existing or inherited policy; there is no need to replace it with a vendor's example.

Only for a domain with no existing or inherited policy, where the domain owner approves an appropriate monitoring plan as the initial stage, publish:

• Type: TXT.
• Full owner: _dmarc.example.com for From domain example.com.
• Relative host: _dmarc within that DNS zone.
• Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com.
• TTL: the DNS provider's ordinary default.

Substitute your domain and an authorized reporting mailbox. For From mail.example.com, a local policy belongs at _dmarc.mail.example.com, relative _dmarc.mail in the parent zone or _dmarc in a separately delegated mail.example.com zone. Never publish duplicate policies or override inherited enforcement merely to clear a setup warning. Compare the Organizational Domain of the report destination URI host with the Organizational Domain of the domain where the policy was found. Different Organizational Domains require the report-generating receiver to check DNS authorization; destinations within the same Organizational Domain are excepted. Separately obtain the owner’s data-sharing approval for the recipient. Report authorization and exception.

DMARC passes with an aligned SPF pass or an aligned DKIM pass. Relaxed alignment allows matching organizational domains; strict alignment requires identical domains. Thus a bounce subdomain can align in relaxed mode without meeting aspf=s. p=none does not request DMARC-based blocking. Current RFC 9989 replaces RFC 7489 and removes pct; preserve an established policy and plan any modernization separately.

Where SPF TXT editing is actually required for other routes, retain one policy per owner and preserve legitimate authorizations. SPF has a ten-DNS-querying-term evaluation limit, including nested includes. Do not add a guessed SparkPost or Bird include solely to satisfy a generic checker. SPF standard.

If the existing SPF policy uses redirect, any all mechanism makes that redirect ignored. Preserve legitimate redirected authorizations and approved terminal semantics in a reviewed policy design rather than appending all blindly. SPF precedence.

Verify DNS and receiver evidence

Replace these placeholders with the issued names; these are read-only queries, not DNS changes:

dig +short NS example.com
dig +short TXT SELECTOR._domainkey.example.com
dig +short CNAME BOUNCE-HOST.example.com
dig +short TXT BOUNCE-HOST.example.com
dig +short TXT _dmarc.example.com
dig +short TXT _dmarc.mail.example.com

The selector TXT must match the account's public key. The bounce CNAME must match the correct product and region; follow its DNS resolution to inspect SPF. A TXT lookup at the bounce owner may return an alias as part of resolution. Do not mistake that for permission to publish a local TXT alongside the CNAME. Compare authoritative-server answers with recursive results if caches disagree.

If an independently approved Bird receiving deployment needs optional inbound MX, keep it separate from outbound authentication. Obtain routing-owner approval of the exact owner and complete priorities/targets; compare authoritative and recursive MX sets with that plan, stopping on any extra, missing or different tuple. Do not publish optional receiving MX merely because it appears in the generated record list. Optional inbound records.

After provider verification and application configuration, send an authorized sample through the intended API or SMTP route to a controlled mailbox. In raw headers, use the Authentication-Results added by the trusted receiving system, not an arbitrary sender-provided field. Record:

• spf=pass and the evaluated smtp.mailfrom domain.
• dkim=pass, header.d and the signature's s= selector.
• dmarc=pass for the intended header.from domain.

Evaluate the actual domains under the published alignment modes. DNS publication does not prove that a signature verifies on a message. A provider-owned SPF pass may be unaligned while aligned DKIM still passes DMARC. Two unrelated passing identities may fail DMARC. DKIM standard.

Use only results produced inside the actual receiving service’s known processing boundary, with its documented handling or exclusion of externally supplied Authentication-Results. Use receiver-controlled diagnostics or an administrator-confirmed trace if raw headers cannot establish that boundary. Matching authserv-id text or header position alone is not proof; ignore attacker-supplied or otherwise untrusted fields. Receiver trust boundary.

Keep redacted evidence per product, region and transport. A test in the US account cannot certify the EU route. Authentication success is not an inbox-placement or reputation guarantee.

For setup acceptance, require the intended SparkPost or Bird signature to pass, with observed d= and s= reconciled to that account’s issued signing configuration and aligned with the unchanged intended visible From, plus trusted dmarc=pass. An unrelated passing signature, an unnoticed provider From rewrite or SPF-only DMARC pass is insufficient. Independently diagnose SPF at the actual envelope owner: fail/softfail indicates an unauthorized connecting sender under that policy, temperror a transient DNS/evaluation failure, and permerror a permanent syntax, duplicate-policy or lookup-budget defect. Investigate these even when DKIM carries DMARC; an unaligned SPF pass is a different diagnosis. SPF results.

Troubleshooting

DKIM valid, bounce invalid: inspect the bounce CNAME separately, especially its regional target and owner conflicts. Changing DKIM does not repair a bounce alias.

SPF passes for an unexpected domain: verify application bounce selection and legacy SMTP rewriting behavior. Do not assume the From-domain SPF record controls that envelope identity.

Bird remains unable to send: inspect DKIM, return-path and DMARC verification, not only overall DNS propagation or optional tracking status.

Migration breaks existing mail: compare old and new DNS ownership. Restore only the affected approved configuration, keep both platforms' necessary selectors, and investigate queued traffic before retiring records.