Scope and provider-specific configuration
Stripe custom email domains cover customer emails such as invoices, receipts and failed-payment notifications. The default sender domain is stripe.com. This is not a guide for replacing mailbox hosting or moving an entire company's outgoing email onto Stripe.
In Dashboard Customer email settings, add the domain you want Stripe to use. Retrieve the generated DNS records. Stripe distinguishes an ownership TXT record, a Mail From Domain CNAME for the envelope source and SPF policy, and DKIM CNAME records. Each serves a separate purpose; an ownership TXT alone does not prove an authenticated message. Use DNS-only records where applicable: Stripe explicitly says not to proxy the supplied records through Cloudflare.
Publish each exact owner, type and target at the authoritative DNS service. Check that the editor has not appended the domain twice. An owner assigned a CNAME must not retain conflicting record types. Use Verify domain in Customer emails to narrow validation problems. Stripe allows up to 72 hours for confirmation but recommends checking typos, conflicts and actual DNS publication when verification fails.
Stripe requires a DMARC policy for a custom email domain and explicitly says strict SPF alignment is unsupported: its documentation warns against aspf=s. Do not silently relax an organization's established policy. If the domain already requires strict alignment, obtain a design decision from its mail/security owner, potentially using an appropriately governed separate sending domain. DKIM alignment must still be checked on received mail; a product limitation is not a reason to assume that any signature will align.
After the domain is Verified, use the overflow menu to send a test email and confirm the active sending domain. Replies go to the support address in public business information, so test that destination separately from authentication. Keep all generated records: Stripe checks them repeatedly and says unresolved invalid or missing records cause fallback to stripe.com after its 48-hour correction window. To retire a domain, switch sending first, remove it in Customer email settings, then remove only its unused DNS records.
The decision that matters
Stripe’s strict-SPF-alignment limitation and fallback behavior must be explicit acceptance criteria.
Verify the published records and the real sending path
Record the change owner, sending product, domain, approved maintenance window and prior DNS answers before editing. Obtain the current record values from the named account or documented provider workflow. Separate values supplied by the provider from choices your organization controls, such as DMARC policy and reporting recipients. Existing mailbox MX, unrelated verification TXT records and active DKIM selectors are not cleanup candidates merely because a new service is being added.
Query the authoritative name servers for each exact owner and record type after publication. Record the query time, responding server and complete answer. Compare TXT strings as one logical value where the DNS response splits them into character strings. Check CNAME targets as well as the starting alias. Then compare a recursive-resolver answer to identify caching differences. A successful provider validation is useful evidence of configuration, but it does not establish what an actual recipient received.
Send only an authorized test to a controlled recipient using the intended product route. Retain the raw message and the trusted receiving system's Authentication-Results. Record the visible From domain, SMTP MAIL FROM or observed Return-Path domain, every DKIM d= and s= value, SPF and DKIM outcomes, and the receiver's DMARC result. A passing SPF or DKIM check supports DMARC only when its authenticated domain aligns with the visible From domain under the applicable policy. Reply-To and a branded display name are not alignment identities. RFC 7208, RFC 6376 and RFC 9989 provide the protocol basis for these distinctions.
Acceptance worksheet, recovery and evidence limits
This is an original acceptance worksheet, not a report of live testing. Mark each gate pending until evidence exists: account scope confirmed; previous DNS captured; exact new owner/type/value published; provider verification complete; intended route exercised; received identities recorded; aligned authentication confirmed; other senders unaffected. Assign a person and evidence file to every gate. A red gate blocks rollout even when the provider dashboard is green.
If a test fails, first distinguish missing publication, stale cached data, inactive provider configuration, wrong outbound route and nonaligned authentication. Correct the smallest demonstrated defect and test again. Do not weaken DMARC or delete other senders' records simply to make one test pass. If a change harms existing mail, use the approved recovery plan and the captured pre-change configuration, coordinating any provider-side sender change as well as DNS. Retain old keys while queued messages or an approved overlap still require them.
No customer tenant, authoritative before/after change or real received message was available for this manuscript. The retained sources support the documentary workflow; they do not satisfy the commissioned live-evidence gate. Independent checker review and human SME approval remain pending. Do not describe this guide as field-validated or publish it as having passed those gates.
Separate a protocol outcome from supported setup
Written case ST-01 assumes From receipts@example.com, MAIL FROM bounce@bounce.example.com with a trusted SPF pass, and a passing DKIM signature d=example.com, s=demo1. Under aspf=s the SPF identity is not an exact match, while that DKIM signature still supplies an aligned DMARC path. This protocol example does not make aspf=s a supported Stripe configuration: its current documentation expressly says otherwise. If the owner must retain strict SPF alignment on the shared domain, stop the rollout and obtain a separately governed design decision rather than silently changing policy. Also verify the approved reply destination independently. No Stripe configuration, invoice, receipt or payment action was performed.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.