Suped

How to set up DMARC/DKIM/SPF for Stripe

Published 23 Jun 2026
Updated 25 Oct 2026
11 min read
Summarize with
Stripe SPF, DKIM, and DMARC setup for a custom email domain.
Updated on 25 Oct 2026: We clarified Stripe DNS verification, added message header checks, and revised the guidance for safe DMARC enforcement.
Stripe custom email domains need four DNS pieces: a proof TXT record, a Mail From CNAME for SPF, DKIM CNAME records, and a DMARC TXT record on the domain customers see in the From address. Configure SPF through Stripe's Mail From record and DKIM through Stripe's CNAME rows. Start DMARC at p=none unless the domain already uses p=quarantine or p=reject.
Use Stripe's custom email domain documentation for the workflow and your Dashboard for the account-specific DNS names and values. Do not copy example CNAME targets into DNS. Copy the values shown inside your own Stripe Dashboard.
Stripe supports a custom Mail From domain for relaxed SPF domain matching. Stripe does not support strict SPF domain matching, so omit aspf or use aspf=r in DMARC, and configure DKIM as well.

Add your domain

Start in Stripe so the Dashboard generates the account-specific TXT and CNAME values for your sending domain. Publish them at the DNS host that manages the domain's authoritative nameservers; records at an inactive DNS provider have no effect.
  1. In Stripe Dashboard, go to Settings, then Customer email.
  2. Enter the domain customers see after the @ sign, such as example.com.
  3. Stripe shows ownership, Mail From, and DKIM records after you save the domain.
  4. Add the proof-of-ownership TXT record with the exact host and value from Stripe. Keep the DNS provider's default TTL unless your DNS administrator specifies another value.
  5. Do not remove existing SPF, DKIM, or DMARC records for other mail systems while adding Stripe.
Stripe Customer email settings with a custom domain being added.
Stripe Customer email settings with a custom domain being added.

Record

Type

Purpose

Ownership
TXT
Proves domain control
Mail From
CNAME
Lets SPF pass
DKIM
CNAME
Signs Stripe mail
DMARC
TXT
Sets receiver policy
Stripe DNS record categories after adding a custom email domain.
Verify the same domain separately on every Stripe account. Add each account's proof TXT value as a separate record, or on separate lines where your DNS provider's interface supports multiple TXT values. Do not concatenate ownership tokens into one string.

Set up SPF

For Stripe, SPF is handled through the Mail From Domain CNAME that Stripe provides. Do not add a guessed include: value to the root SPF record unless Stripe explicitly shows it in the Dashboard.
  1. In Stripe's domain verification panel, locate the Mail From Domain row.
  2. Add the exact name and target Stripe provides in your DNS provider.
  3. A CNAME name must not also have TXT, A, AAAA, or MX records.
  4. If DNS appends the domain, enter only the left-side host label.
  5. If your DNS provider has proxy mode for CNAME records, keep Stripe DNS records DNS-only.
Stripe Mail From Domain CNAME row used for SPF setup.
Stripe Mail From Domain CNAME row used for SPF setup.

SPF checker

Find SPF syntax issues, lookup limits, and weak records.

?/16tests passed
After publishing the Mail From CNAME, check the exact Mail From host shown by Stripe. This host is separate from any SPF TXT record at the root domain. If you audit the root record as part of the wider setup, keep one SPF TXT record at that hostname and stay within SPF's 10-DNS-lookup limit. Nested includes count toward the limit; exceeding it returns PermError. See RFC 7208 for the lookup rules.
Good SPF state
  1. The Mail From name resolves to the Stripe target.
  2. Each hostname has only one SPF TXT record.
  3. The Return-Path domain shares the visible From domain's organizational domain under relaxed SPF matching.
Bad SPF state
  1. A Stripe SPF include was added without being provided by Stripe.
  2. The Mail From host already has another DNS record type.
  3. DMARC contains aspf=s, which Stripe says is not supported.

Set up DKIM

DKIM adds a cryptographic signature to Stripe customer emails so receivers can detect changes to signed content. DMARC passes when either DKIM or SPF passes and its authenticated domain matches the visible From domain under the configured DMARC domain matching mode.
  1. In Stripe, copy every DKIM CNAME row shown for the custom email domain.
  2. Add each CNAME with the exact host and value Stripe provides.
  3. If the DNS form already adds example.com, paste only the selector host.
  4. Stripe can take up to 72 hours to confirm DNS changes.
  5. Do not delete the DKIM CNAMEs after verification because Stripe keeps checking them.
Stripe DKIM CNAME records in the custom email domain verification table.
Stripe DKIM CNAME records in the custom email domain verification table.
Do not replace existing DKIM records for your mailbox provider, marketing tools, or app mail. Add Stripe's DKIM CNAME records beside them. DKIM selectors are meant to coexist.
Publish Stripe's DKIM CNAMEs rather than generating a separate DKIM key. Replace the example selector names below with the names from your Dashboard.
Optional DKIM DNS checkbash
dig CNAME selector1._domainkey.example.com +short dig CNAME selector2._domainkey.example.com +short

Set up DMARC

Stripe requires a DMARC policy for a custom email domain. If the domain has no DMARC policy, start with monitoring. If it already uses quarantine or reject and legitimate mail passes, keep that stronger policy in place.
  1. Check for an existing policy at _dmarc.example.com for a From domain of example.com, and check any inherited parent policy for a sending subdomain.
  2. If there is no applicable policy, publish the monitoring policy below with p=none.
  3. If you already use p=quarantine or p=reject, do not reduce it just for Stripe.
  4. Do not add aspf=s because Stripe says strict SPF domain matching is not supported.
  5. Use the DMARC record generator if you need a clean policy string.
Starter DMARC record for the example.com DNS zonedns
Type: TXT Name: _dmarc Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
For a From domain of billing.example.com, publish a separate policy at _dmarc.billing.example.com. In the example.com DNS zone, enter _dmarc.billing as the host. Check the parent policy before creating an override.
RFC 9989 replaced RFC 7489 and makes the pct tag historic. Do not use pct to phase in enforcement. Keep p=none while monitoring, then change the policy after legitimate Stripe traffic and other approved senders authenticate.
Stripe custom email domain page showing the DMARC TXT requirement.
Stripe custom email domain page showing the DMARC TXT requirement.

DMARC checker

Look up a domain's DMARC record and catch policy issues.

?/7tests passed
The DMARC checker should show one record, valid syntax, and a policy value. If it shows multiple records, remove duplicates and keep one TXT record at the DMARC hostname.
The example reporting address is a placeholder. Replace it with a mailbox you monitor or the exact reporting endpoint assigned by Suped. External reporting destinations must authorize reports for your domain. Authorization is published in the destination's DNS; the reporting provider supplies the setup details.

Confirm the sending domain

DNS publication is only part of the setup. After Stripe verifies the records, confirm that customer emails use the custom domain and that replies reach the support address in your public business information.
  1. Check for the Verified badge in the Customer email settings.
  2. Use the domain's overflow menu to send a test customer email.
  3. Confirm that the domain after the @ sign is your verified custom domain.
  4. Confirm that a reply reaches the support email set in Stripe's public business information.
Stripe uses supported local parts such as billing, invoice, receipts, and support. The custom setting controls the domain, not an arbitrary local part for every automated customer email.

Verify and troubleshoot

Verification has two parts: Stripe must accept the DNS records, and real Stripe emails must pass authentication at mailbox providers. Check both before treating the setup as complete.
  1. Open Customer email settings and use Verify domain to recheck records.
  2. Wait for the Verified badge under the Verification column.
  3. Use Stripe's overflow menu to send a test email when the option is available.
  4. Confirm DKIM passes and DMARC passes on a received Stripe message.
  5. Stripe keeps checking the records. Fix an invalid or missing record within 48 hours, or Stripe sends customer email from stripe.com until the problem is resolved.
Stripe Customer email settings showing a verified custom email domain.
Stripe Customer email settings showing a verified custom email domain.
Use Stripe's built-in test email in a mailbox you control. If an email tester requires a specific recipient and Stripe's test cannot target it, inspect the original message headers in that mailbox instead.

Email tester

Send a real email to this address. Suped shows a results button when the test is ready.

?/43tests passed

Symptom

Cause

Fix

Pending after publishing
DNS caching or records in the wrong zone
Check authoritative DNS; allow up to 72 hours, then use Verify domain
Not found
Bad host
Remove duplicate suffix
CNAME fails
Record clash
Keep CNAME only
DMARC policy not found
Missing, invalid, or incorrectly named TXT record
Check the policy at _dmarc.<From domain>, including inherited policy
DMARC fails on a received message
Neither SPF nor DKIM passes with a matching From domain
Compare smtp.mailfrom and DKIM d= with From; repair authentication or domain matching
SPF fails on a direct message
Mail From CNAME missing or incorrect
Compare the exact Mail From host and target with Stripe; inspect smtp.mailfrom
Fast checks for common Stripe email domain failures.
Optional terminal checks, replace example hosts with Stripe valuesbash
dig TXT _dmarc.example.com +short dig CNAME bounce.example.com +short dig CNAME selector1._domainkey.example.com +short
Compare Stripe with the rest of the domain's senders when troubleshooting a wider mail setup. The verification guide is useful when the issue is not isolated to Stripe.

Read Stripe email authentication headers

Open the received message's full headers and read the Authentication-Results added by the receiving mailbox provider. Use that provider's results, since senders can insert untrusted header lines.
Illustrative authentication results, not Stripe DNS valuestext
From: receipts@example.com Return-Path: <bounce@bounce.example.com> Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com header.s=stripe-selector; dmarc=pass header.from=example.com
SPF checks the envelope sender shown in Return-Path. DKIM uses the d= signing domain, shown as header.d here. DMARC checks these authenticated domains against the visible From domain. Under relaxed SPF matching, bounce.example.com and example.com share an organizational domain.
Forwarding often breaks SPF. A valid DKIM signature with a matching domain still lets DMARC pass if the signed content is unchanged. A pass for an unrelated domain does not establish a DMARC pass for your From domain.

Monitor Stripe authentication

Stripe notifies you when required domain records become invalid. Keep those notifications enabled and review DMARC reports alongside DNS checks, because aggregate reports arrive after messages are processed.
  1. Review Stripe authentication results in DMARC aggregate reports and investigate changes in pass rates.
  2. Assign a DNS owner to respond to Stripe's notifications within its 48-hour repair window.
  3. Keep Stripe results separate from other approved senders so failures can be investigated by source.
  4. Monitor the ownership TXT, Mail From CNAME, DKIM CNAMEs, and DMARC policy for accidental changes.
Suped's DMARC monitoring product groups reports by sending source. Use the Stripe results to review failed authentication and identify records to investigate. Report-based alerts depend on when receivers send their data, so they do not replace direct DNS checks or Stripe notifications.

Move to DMARC enforcement safely

Stripe accepts p=none; enforcement is a separate decision for the whole sending domain. Use reports to verify approved senders before changing the policy.
RFC 9989 advises against p=reject for domains with users who send to Internet mailing lists. Consider a dedicated Stripe sending subdomain if the parent domain also handles general-purpose email. Domains using p=reject must apply valid DKIM signatures rather than rely solely on SPF.
  1. Let DMARC data run long enough to see normal Stripe receipts, invoices, and payment events.
  2. Identify unknown senders and fix legitimate services. Moving a sender to a subdomain still requires authentication and a review of its inherited DMARC policy.
  3. Consider p=quarantine after legitimate mail passes, and review actual delivery outcomes before a stronger policy.
  4. Use p=reject only after legitimate senders pass with matching DKIM domains and forwarding or mailing-list effects have been assessed. It requests rejection of DMARC failures; receivers apply their own handling rules.
  5. Use Suped's Hosted DMARC to change policy without repeated manual DNS edits.
DMARC enforcement readiness
Use these checks before changing the DMARC policy on a Stripe sending domain.
Do not enforce
Unknown sources
Legitimate senders still fail or their ownership is unknown.
Fix first
Known failures
Remaining failures are tied to approved systems that still need authentication fixes.
Ready to stage
Consistent pass
Approved senders pass with matching DKIM domains, and indirect delivery effects have been assessed.
Example reject policy for the example.com DNS zonedns
Type: TXT Name: _dmarc Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com
After each policy change, compare authentication reports and delivery outcomes. Investigate new legitimate failures before continuing enforcement.

FAQ

Yes. Stripe requires a DMARC policy before sending customer emails from a custom domain. Start with p=none if there is no applicable policy; keep an existing stronger policy while verifying Stripe's authentication.

No. Use the Mail From Domain CNAME shown in your Stripe Dashboard. Do not invent a Stripe SPF include value.

Stripe does not support strict SPF domain matching. Omit aspf or use aspf=r for relaxed matching, and configure DKIM as well.

Yes, if the policy is appropriate for the domain and legitimate senders pass. Add Stripe's records and verify passing DKIM with a matching From domain before relying on reject. Review forwarding and mailing-list effects for other senders sharing the policy.

Stripe notifies you. Fix the records within 48 hours, or Stripe sends customer email from stripe.com until the issue is resolved. Use direct DNS checks alongside DMARC reporting; report-based alerts depend on receiver reporting delays.

Check for the Verified badge, send a test email from the overflow menu, and inspect the visible From address. A reply should reach the support address in your public business information.
DMARC monitoring

Start monitoring your DMARC reports today

Suped DMARC platform dashboard
What you'll get with Suped
Real-time DMARC report monitoring and analysis
Automated alerts for authentication failures
Clear recommendations to improve email deliverability
Protection against phishing and domain spoofing