---
title: Stripe payments and email on Namegarage domains
url: https://namegarage.com/blog/stripe-custom-domains
author: Namegarage
date: '2026-11-03'
description: How we moved Stripe-hosted payment pages and customer email onto Namegarage
  domains, with separate DNS and activation checks.
ai-disclosure: ai-assisted
---

# Stripe payments and email on Namegarage domains

This article was prepared with AI assistance and reviewed by a person before publication.

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](https://docs.stripe.com/payments/checkout/custom-domains)
and [custom email domains](https://docs.stripe.com/get-started/account/email-domain).
For a rollout like this, the useful milestone is the provider's accepted state
for each service, followed by the final switch.