Skip to main content

Sender domains and delivery routes

Sender setup decides who email appears to come from and how messages are delivered. Configure it before inviting real users.

Switera email sender and brand setup with sender preview
Use Sender & Brand to check the sender identity, reply-to behavior, and visible email preview.

Sender profile​

A sender profile should answer:

  • who is the message from?
  • what address receives replies?
  • does the sender name match the product?
  • does the template preview look trustworthy?
  • is the route safe for test or real users?

Recommended first values:

  • sender name: your app or company name
  • from email: a verified sender address
  • reply-to email: a monitored mailbox
  • footer text: short and product-specific

Domain verification​

If the app sends from your own domain, verify the domain before launch.

  1. Add the sender domain.
  2. Copy the DNS records shown in the product.
  3. Add the records in your DNS provider.
  4. Wait for DNS propagation.
  5. Return to Switera and verify the domain.
  6. Send a test email.

Do not send production traffic from an unverified or poorly configured domain.

Delivery paths​

Switera has two sender-domain paths:

PathUse forStatus
Switera managedFast launch from a Switera-controlled senderAvailable
Switera first-party transactionalPlatform-owned transactional mail from switera.comAvailable
Builder-owned sending domainsBuilder-owned and tenant-owned sending domainsPlanned
Managed custom-domain sendingSwitera-managed customer-domain deliveryPlanned after lifecycle automation

Builder-owned sending domains should let Switera create the domain record, generate signing material, show copyable DNS records, verify DNS, and route mail without asking a builder to manage delivery infrastructure.

Managed custom-domain sending remains useful for teams that want Switera to own more of the delivery lifecycle, but it needs more automation before we expose it to builders: domain creation, ownership TXT capture, SPF/DKIM verification polling, sender setup, delivery-route linking, and feedback handling.

Customer-owned domain DNS​

For a builder-owned domain, Switera should show all required records in one checklist:

RecordPurpose
Switera ownership TXTProves the builder controls the domain before Switera enables it
SPF TXTAuthorizes the active sending provider
DKIM TXT or CNAMELets recipients verify that Switera signed the message for that domain
DMARC TXTTells receivers how to handle SPF/DKIM failures and where to send reports

The exact host and value depend on the selected route. The UI should not ask a builder to infer DNS values from provider documentation.

Delivery routes​

Routes decide which provider or delivery path sends a message. Keep routes simple at first.

Use separate routes when:

  • test and production traffic must be separated
  • a customer requires a dedicated delivery path
  • high-volume transactional mail needs a different provider
  • a provider is being migrated

Route test​

Before launch, send a test to a monitored mailbox and check:

  • from name
  • from address
  • reply-to address
  • subject
  • body copy
  • links
  • spam placement
  • tracking behavior if enabled

Common mistakes​

  • Using a no-reply address when replies need support.
  • Testing only with internal inboxes.
  • Forgetting to verify DNS before inviting users.
  • Copying DNS records with extra spaces or missing quotes.
  • Sending production messages through a test route.

Related pages: