Authentication sending domains

If your company domain is example.com, Authreads uses the dedicated identity auth.example.com and sends from noreply@auth.example.com. Your root domain, website, employee mailboxes, and existing mail provider are not modified.

The sender name shown in an inbox is configured with the sending identity. It does not change when you turn optional email logo and colour presentation on or off.

1. Add your company domain and the sender name recipients should recognise under Admin → Branding → Email → Sending identity.
2. Publish the ownership TXT record shown there. No email-provider resource is created before this proof passes.
3. After ownership is verified, create the sender records. Copy each name and value separately, copy all records, or download the BIND zone fragment; create the records without overwriting anything already at those names.
4. Wait for DNS propagation, then run the checks. DNS can be correct while the sending provider is still verifying MAIL FROM; Admin reports that as “Waiting for provider.” Both checks must pass before activation is offered.
5. Read the activation warning and activate the sender separately for each user pool.

DNS providers and caches control propagation. Small changes are often visible in minutes, but allow several hours before treating a pending result as a defect.

Returning a pool to the Authreads sender is reversible and leaves the verified sending resources in place. Releasing a domain is separate and permanent: every pool must first use the Authreads sender, then release removes only sending resources carrying Authreads' exact ownership tags. A partial provider failure stays visible and can be retried safely.

Before activation, setup failures do not affect authentication mail. After activation, a required DNS, provider, event-routing, or reputation check that fails stops authentication email for that pool. Authreads does not silently substitute a different sender. An administrator can repair the records or deliberately return the pool to the platform sender.

Provider delivery events are best-effort. A recorded delivery, bounce, complaint, rejection, delay, or rendering failure is evidence that the provider reported it; a missing event is not proof of delivery. New domains also begin without established mailbox-provider reputation and may need a gradual warm-up period even when every DNS check is correct.

Sender-domain records expose a record purpose, whether it is required, its DNS type, exact name, and exact value. Pool settings expose the explicit platform or tenant_domain mode plus activation timestamps. Do not copy prose into an integration: the generated API reference is authoritative whenever an endpoint is part of the supported integration API.

• Ownership: one required TXT record under the dedicated auth label.
• DKIM: exactly three required CNAME records. Their selectors and targets are generated; never invent or derive them.
• Custom MAIL FROM: one required MX record and one required SPF TXT record under bounce.auth.<your-domain>.
• DMARC: an advisory TXT observation at the tenant domain. It is reported but is not an activation prerequisite.