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.

Provider paths​

Switera has two sender-domain paths:

PathUse forStatus
Switera managedFast launch from a Switera-controlled senderAvailable
Azure Communication ServicesSwitera first-party transactional mail from switera.comDNS verified and linked
Stalwart SMTPBuilder-owned and tenant-owned sending domainsPlanned first customer-domain route
Azure custom domainsManaged customer-domain sending through AzurePlanned after lifecycle automation

The first customer-domain route should use Stalwart. It lets Switera create the domain record, generate a per-domain DKIM key, show copyable DNS records, verify DNS, and route mail without asking a builder to manage Azure resources.

Azure custom domains remain useful for a managed route, but they need more automation before we expose them to builders: domain creation, ownership TXT capture, SPF/DKIM/DKIM2 verification polling, sender username setup, Communication Service 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: