Stripe payments and email on Namegarage domains

Stripe-hosted Checkout, Payment Links, and the customer portal now use pay.namegarage.com. Stripe customer emails now use our verified namegarage.com sender domain. Stripe continues to host the payment pages and send the provider emails.

The two changes share a brand, but they have separate DNS records and separate activation steps. A working payment hostname does not establish that an email sender is ready.

Prepare the applications before switching the hostname

Our applications validate the URLs returned by Stripe before redirecting a customer. Adding a custom hostname therefore required more than a DNS change. The sales site and the Namewrench customer portal needed to accept the chosen Stripe hostname, and the sales site's browser security policy needed to permit it as a payment destination.

We deployed those compatible builds before enabling Stripe's automatic switch. The existing Stripe-hosted destinations remain supported alongside the exact configured custom hostname. A similar-looking hostname does not qualify.

The payment domain uses a DNS-only CNAME and a verification TXT record. Stripe manages its TLS certificate and runs a DNS stability check before activation. We checked the authoritative DNS answers and a valid certificate for the exact hostname, then waited for the Dashboard to report Active for Checkout, Payment Links, and the customer portal.

Authenticate email without replacing the existing mail setup

The email domain required eight additional DNS records: one ownership TXT, six DKIM CNAMEs, and a CNAME for Stripe's bounce domain. We kept the existing MX records, apex SPF record, enforced DMARC policy, and other DKIM selectors. The new selectors let Stripe authenticate its mail alongside the other services that already send for Namegarage.

We inspected a saved OpenTofu plan containing exactly those eight DNS-only creates, applied it after review and merge, and checked each record at the authoritative nameserver. Stripe then completed its own verification. Only after it reported Verified did we select the domain and confirm Sending.

The sender prefix stays the same: a Stripe receipt previously sent from receipts@stripe.com can now come from receipts@namegarage.com. Replies continue to reach our existing support inbox. Selecting a sender domain does not create a mailbox or change which customer notifications are enabled.

Keep provider acceptance separate from deployment

The pinned Stripe Terraform provider we used, version 0.3.0, has no resource for these hosted-payment or customer-email domain settings. We used Stripe's Dashboard for registration, verification, and selection, while the Cloudflare provider manages the DNS through OpenTofu. Public record values live in configuration files; credentials stay in the existing secret workflow.

The payment domain became active before the email domain finished verification. We kept those results separate until both Stripe domain setups were complete. No customer checkout, portal session, payment, or email was created as a production test. The acceptance evidence covers deployed compatibility, authoritative DNS, exact-host TLS, and Stripe's active domain and sender states.

Stripe documents the two flows in its guides to custom payment domains and custom email domains. For a rollout like this, the useful milestone is the provider's accepted state for each service, followed by the final switch.