Authentication Emails That Don't Break Login Flows

Magic links and OTP emails are high-trust, time-sensitive messages. MultiMail delivers them fast and keeps every send observable so agent-driven auth flows stay auditable.


Why this matters

Authentication emails sit on the critical path of user login. A 30-second delivery delay kills a 10-minute magic link. A poorly formatted message or a spoofable sender domain drops user confidence and completion rates. When an AI agent triggers these sends — as part of a self-service onboarding flow, an automated access request, or a session refresh — the stakes are higher: the agent cannot manually verify delivery or respond to a failed send the way a human operator would. You need infrastructure that is fast, observable, and correct by construction.


How MultiMail solves this

MultiMail's mailbox send endpoint handles authentication emails as first-class transactional messages. Sends return an id immediately, and delivery confirmation fires a webhook to your endpoint so your agent knows whether the token reached the inbox before proceeding. The gated_send oversight mode lets agents read inboxes and monitor delivery autonomously — low risk — while routing outbound authentication sends through a lightweight approval step. This keeps high-trust sends auditable without adding latency to the happy path.

1

Generate the token in your auth layer

Your backend or agent generates a cryptographically secure token — HMAC-SHA256, TOTP, or random bytes — and stores it with an expiry timestamp. MultiMail does not generate or store tokens. You own the secret material, expiry logic, and single-use enforcement.

2

Send from your authentication mailbox

Pass the token embedded in a magic link URL, or as a standalone OTP code, to the mailbox send endpoint (POST /v1/mailboxes/{mailbox_id}/send). The sender is the mailbox in the path plus your bearer key — there is no from field. MultiMail signs the outbound message with DKIM on your verified domain.

3

Receive delivery confirmation via webhook

MultiMail routes the message through hardened sending infrastructure and fires a delivery webhook to your endpoint when the message is handed off to the recipient's MX. Your agent correlates the id from the send response to the webhook event, confirming the token reached the inbox before the expiry window closes.

4

Handle failures explicitly

Bounced or deferred messages trigger a failure webhook with a status code and error detail. Your agent can act on this — retry with a secondary address, fall back to an alternative channel, or surface the failure to a human approver via the gated approval queue. MultiMail does not silently drop bounces.

5

Tag the message after login completes

If the recipient mailbox is a MultiMail address, read it via GET /v1/mailboxes/{mailbox_id}/emails/{email_id} and set tags via PUT /v1/mailboxes/{mailbox_id}/emails/{email_id}/tags to mark the authentication thread as consumed once login completes. This gives you a clean audit trail: sent, delivered, consumed — or expired without use.


Try it with your agent

Pick your platform, copy the prompt, and paste it to your AI agent — it sets up MultiMail and builds the whole flow. Nothing to fill in.

1. Get MultiMail ready: read https://multimail.dev/llms.txt, connect the MCP server, create a free inbox, and set up a verified sender. 2. In Auth0, use a Post Login Action for session refresh messages and the Authentication API passwordless email flow for login links or codes, keeping the Auth0 token generation and validation as the source of truth. 3. When Auth0 starts a passwordless login, have the agent compose a short branded message with the magic link or OTP, the expiration time, the requesting app name, and a warning to ignore the email if the user did not request it. 4. Send immediately through MultiMail, monitor delivery status before advancing any automated onboarding or access workflow, and retry only by generating a fresh Auth0 link or code. 5. Run MultiMail in gated_send mode; ask me only for Auth0 credentials, the app name, approved brand copy, and the verified sending domain when it is time to go live.

What you get

Delivery visibility before token expiry

Authentication tokens are typically valid for 10 minutes. MultiMail's fast transactional send path with webhook delivery confirmation gives your agent a confirmed delivery signal within seconds — not after the token has already expired.

DKIM-signed sends on your domain

Authentication emails are high-phishing-target messages. MultiMail signs every send with DKIM on your verified sender domain, improving deliverability and giving recipients a cryptographic signal that the message is legitimate, not a spoofed clone.

Auditable send history for security reviews

Every authentication email is logged with sender, recipient, timestamp, and delivery status. Under gated_send mode, outbound sends are also visible to a human reviewer, giving you an auditable trail for SOC 2 compliance and incident response.

Explicit failure handling, no silent drops

Bounced or deferred messages trigger webhooks with actionable status codes. Your agent can retry, fall back to an alternative channel, or escalate to a human approver. MultiMail does not silently discard delivery failures.

Isolated sending reputation for auth traffic

Dedicate a mailbox (e.g., [email protected]) to authentication sends to isolate reputation from marketing or notification traffic. A spam complaint on a newsletter cannot affect delivery rates for your login flows.


Recommended oversight mode

Recommended
gated_send
Authentication emails are high-trust messages delivered to real users in real time. gated_send lets your agent read inboxes and monitor delivery status autonomously — low risk — while routing outbound sends through a human approval step. In practice, authentication sends can be auto-approved instantly under a configured rule set, but the approval record exists for audit purposes. This is the right default for fintech and enterprise environments where outbound authentication emails are subject to SOC 2 or regulatory review requirements.

Common questions

Does MultiMail generate magic link tokens or OTP codes?
No. Token generation is your responsibility — use a cryptographically secure method such as HMAC-SHA256 or a TOTP library. MultiMail handles delivery only. You own the secret material, expiry logic, and single-use enforcement. MultiMail never stores the raw token value.
How fast is delivery for authentication emails?
Authentication sends are handled as first-class transactional messages. In typical conditions, messages are handed off to the recipient's MX within 3–5 seconds of the API call. Actual inbox arrival depends on the recipient's mail server. For 10-minute token windows, this is well within tolerance.
Can I send from my own domain instead of multimail.dev?
Yes. Add your domain to MultiMail, complete DKIM and SPF DNS setup, and you can send from any address on that domain. Authentication emails should use your product domain — [email protected] rather than a third-party domain — for both deliverability and user trust reasons.
What happens when an authentication email bounces?
A delivery failure webhook fires to your endpoint with a status code and error detail. Your agent can act explicitly: retry with a secondary address, trigger a fallback flow, or surface the failure to a human approver via the gated approval queue. MultiMail does not silently drop bounces or mask delivery failures.
Does CAN-SPAM apply to magic link and OTP emails?
CAN-SPAM covers commercial email. Authentication emails triggered by user action — magic links, OTPs — are generally considered transactional and exempt from CAN-SPAM opt-out requirements. However, accurate sender header information is required regardless of message type. If your authentication email contains any promotional content, CAN-SPAM opt-out requirements apply to the entire message.
What sending volumes are supported?
MultiMail is designed for high-volume transactional sends. Starter plan supports 200 emails/month; Builder supports 5,000; Pro supports 30,000; Scale supports 150,000. For authentication email workloads specifically, use a dedicated mailbox to isolate sending reputation from other traffic types.
How does gated_send affect delivery latency for auth emails?
Under gated_send, sends enter a brief approval queue. For authentication email workloads where speed is critical, you can configure approval rules that auto-approve sends from specific mailboxes or with specific tags (e.g., tag: 'auth') without human review. The approval record is created but the send is not blocked, keeping latency low while maintaining the audit trail.

Explore more use cases

The only agent email with a verifiable sender

Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.