Sending domain and DNS

Every email SendTruss sends comes from your own domain, never ours. You register one sending domain for your platform on the console’s domain screen, publish the DNS records it shows, and email can go out once they verify.

The records

The domain screen lists seven records, each with its name, type, the value to copy, and its status:

• three DKIM CNAME records, which let mail servers check that the email really came from your domain;
• an MX and a TXT record on your bounce host (bounce by default), the return path mail servers report bounces to;
• a DMARC TXT record, which tells mail servers what to do with mail that fails those checks;
• a tracking CNAME (email by default), the host the links in your email go through.

You choose the bounce and tracking labels when you register the domain, and the screen fills in the defaults. Copy each value exactly as the screen shows it.

How long it takes

We check the records every five minutes until they verify, and daily after that. The screen also has a check-now button. DNS changes usually show up within minutes. If your DNS changes go through a ticket queue, it can take days, and there’s nothing we can do to speed it up, so start this first.

While you wait, you can still build everything else: create workspaces, push contacts, register event types, save templates and register a webhook endpoint. You can even emit to our simulator addresses, which play a delivery, a bounce or a complaint without sending anything. An emit to anyone else is refused with domain_not_sendable until the domain verifies.

When a record fails

A record that fails shows the fix in plain words on the domain screen. If a record that had verified stops verifying later (someone edits your DNS, say), sending stops until it is fixed, and we tell your backend with a sending_domain.changed webhook that carries each record’s status. The same webhook tells you when sending is possible again. See Webhooks.

A workspace’s sending.state says the same thing per workspace. While your domain is missing or unverified it is blocked, with the reason no_identity (no domain registered) or identity_not_sendable (a record isn’t verified). Once the domain can send it is ready, after at most a short waiting while the workspace itself is set up. Get a workspace to read it.

Each workspace sends from its own subdomain

A workspace doesn’t send from your bare domain. It sends from a subdomain made from its name when it was created: a workspace named Pine Valley sends as bookings@pine-valley.yourplatform.com, where bookings is the from local part its template sets. The subdomain is fixed for the workspace’s life, even if you rename it, because mail servers judge reputation by sending domain and a silent move would reset it. You don’t publish any DNS records for these subdomains.

Who can change it

Only your platform’s owners can register the domain or change the bounce and tracking labels. Changing a label resets that record to pending, which stops sending until the new record verifies, and you can’t change them at all once your domain has sent its first email. Members of your team can see the screen and press check-now.