Skip to main content

Sender domains and delivery routes

Open your app, then Products > Email > Sender & Brand. These settings apply to messages your app sends to its end users. They do not customize Switera's own account notifications to builders.

You need permission to edit the app. For a custom domain, you also need access to its DNS provider. Use a monitored inbox for delivery tests.

Choose the right view​

ViewConfigure
SenderDefault from name, from address, reply-to address and additional senders.
BrandHeader, logo, footer, colors and typography, with a sample preview.
DeliveryDelivery route, connector settings, sending domains and test delivery.

Save settings stays at the top as you scroll. It saves all three views together. Switching views keeps your edits; it does not save them. Unsaved changes remains visible until a successful save. If saving fails, your fields remain available for correction and retry. Leaving or reloading the page before saving can lose edits.

Set the default sender​

  1. In Sender, enter the From name your customers recognize.
  2. Set From email to an address authorized for your delivery route.
  3. Set Reply-to email to a monitored mailbox, or leave it empty to use the sender address.
  4. Select Save settings.

Expected result: a confirmation appears and the unsaved indicator clears. Saving an address does not by itself authorize its domain for delivery.

Switera Sender view with from name, from email, reply-to and visible Save settings
Start with the default sender. Delivery readiness, sender activity and additional senders are separate from the three everyday fields.

Open Sender activity to review workflow usage and recent delivery signals. To use another identity, expand Additional senders, choose Add another sender, fill its label and addresses, and save. Assign it to the relevant workflow in Automation. A sender already used by a workflow cannot be removed until that workflow is reassigned.

Set the email brand​

  1. Open Brand.
  2. Set Header title, an HTTPS Logo URL, and Footer text.
  3. Expand Colors and typography only when needed. Color swatches and values, font family, dark theme, and Reset to app defaults are available here.
  4. Select Preview to inspect the current draft. Switch between Email and Plain text; return to Edit to continue changing the fields.
  5. Select Save settings to apply the brand.
Switera Brand editor with header, logo, footer, color swatches and typography settings
Brand settings have their own focused editor. Styling changes remain drafts until saved.

The sample uses your active invitation content, or starter content when there is no active invitation. It is an isolated browser approximation of the email shell, not a mail-client emulator or an inbox-delivery test. Sample actions are inert. Fonts can fall back to an installed font, and insecure HTTP logo URLs are not loaded in the sample.

App defaults are copied into the draft when you choose Reset to app defaults; save afterward to apply them. Preview does not send email. To inspect an actual built-in message, use Built-in after saving; its preview uses saved settings.

Choose a delivery route​

Open Delivery, then choose Delivery route. The selector includes each route's current status. Only the selected connector's settings are expanded.

For a connector that requires a key, enter its sender name/address and API key. A blank key field preserves a saved key. Remove saved key schedules its removal when you save; typing a replacement updates it on save. Do not put keys in template copy, screenshots or client-side application code.

A saved route preference is not proof that the connector is active. Review the status and setup message before sending; an unavailable/planned route can remain a saved preference while live delivery continues on the managed path.

CapabilityCurrent boundary
Switera managed deliveryAvailable; use the active route's authorized sender.
Sending-domain ownership and DNS healthOwnership TXT verification and SPF/DMARC health are available.
Custom-domain delivery lifecycleDo not infer signing, route linking or production readiness from a saved domain or ownership check alone. End-to-end onboarding remains a separate rollout.

Add and verify a domain​

  1. In Delivery, find Sending domains and select Add domain.
  2. Enter a label and the domain, then select Save settings. Saving generates the ownership record shown by Switera.
  3. Select Show verification. Use the copy icons beside TXT name and TXT value, and create that exact record at your DNS provider.
  4. Wait for propagation, then select Verify now.
  5. For a verified domain, use Show DNS and Check DNS to inspect it again.

Expected result: the ownership status updates. If verification fails, the DNS values remain visible with the error so you can correct them and retry.

Switera Delivery view with route selector and domain ownership TXT fields with copy actions
Copy the exact record values from your app. The example values in this screenshot are test fixtures, not records for your domain.

Expand DNS health details for the ownership, SPF and DMARC signals returned by the service. Connector-specific DKIM guidance appears when the selected connector supplies it. Do not invent records or replace an existing SPF policy with the screenshot's example.

Verification is disabled while settings are unsaved, so a check cannot be mistaken for verification of an edited domain that has not been saved yet. Ownership verification alone does not configure DKIM, authorize every sender, link a delivery route or guarantee inbox placement.

Test saved delivery settings​

  1. Save all edits, then open Delivery > Test delivery.
  2. Confirm that the selected route is available for testing.
  3. Enter a monitored address in Send to.
  4. Select Send route test once and review its result.
  5. Check the received email's sender, reply-to, brand, links and spam placement.

Testing uses the last saved configuration, and the send action is disabled while settings are unsaved. A successful API response is not proof of inbox arrival; check delivery activity and the receiving mailbox.

This test does not prove a login code, verification challenge or workflow trigger works. Test those real user actions separately before launch.

Troubleshooting​

SymptomCheck
Save failsRead the error above the views, correct the affected fields, then retry. Drafts are retained.
Verification or test button is disabledSave pending edits; confirm the route's readiness or that the domain has a generated token.
TXT verification failsCheck the exact host and value, duplicated DNS suffixes, and propagation.
Ownership is verified but mail failsReview SPF/DMARC, connector DKIM and delivery authorization; ownership is only one check.
Clipboard is unavailableSelect and copy the displayed value manually.
The preview differs from an inboxThe browser sample is approximate; inspect the saved template and a real delivery in your target mail clients.
A test succeeds but no email arrivesInspect activity, suppression/bounce results, and spam folders. Avoid repeated sends without checking the previous attempt.

Related pages: