POST /api/v1/mailboxes and returns an initial bearer token plus matching mailbox password. Additional credentials use POST /api/v1/mailboxes/{public_id}/keys. The current mailbox permission taxonomy includes email.send, email.receive, mailbox.read, and mailbox.settings.update.
[OpenAgent](https://github.com/openagentemail/openagentemail) documents an Apache-2.0 self-hosted REST and MCP stack. [AgentMail](https://docs.agentmail.to/introduction) documents hosted agent inboxes, while [MailSlurp](https://www.mailslurp.com/llms.txt) documents programmable inbox and testing APIs. Confirm current deployment, tenant, retention, and production-delivery terms directly.
Delivery-first products may receive or parse inbound mail without owning the mailbox lifecycle your agent needs. Test provision, receive, retrieve, reply, suspend, and delete semantics as separate operations.
### Two-way threading and message model
[RFC 5322](https://www.rfc-editor.org/rfc/rfc5322) defines Message-ID, In-Reply-To, and References identification fields. Sendmux clean-content endpoints return deterministic JSON, and mailbox sends accept the reply fields needed to preserve conversation context.
Store the RFC message identifiers, Sendmux message and thread identifiers, application conversation ID, and tenant ID together. Subject matching can remain a diagnostic fallback, not the primary correlation key.
### Webhooks, SSE, and event reliability
Sendmux exposes inbound mailbox events at GET /api/v1/mailbox/events using SSE and supports Last-Event-ID for reconnection. Outbound delivery changes use HMAC-SHA256 signed webhooks. Verify the raw request body before parsing, then deduplicate by event ID.
Other products expose different combinations of webhooks, WebSockets, polling, or provider-native events. Compare signed payload shape, retry policy, replay, reconnect, and full-content retrieval from each official contract.
**Pro Tip:** *Reject an event integration that cannot explain authentication, deduplication, retry, replay, and full-content retrieval separately.*
### Routing, failover, and multi-tenancy
Sendmux configured accounts include custom SMTP, Gmail API, Outlook API, and managed Amazon SES. Accounts expose routing weight plus per-second, per-minute, per-hour, and per-day quota windows. The sending implementation filters blacklisted or quota-exhausted accounts and selects from available accounts by weight.
That is verified availability-aware selection. It is not a promise that every provider error triggers universal automatic failover. Define which failures are retryable, which account remains eligible, and what evidence the application receives when no route is available.
email.send, email.receive, mailbox.read, and mailbox.settings.update. Configured accounts include custom SMTP, Gmail API, Outlook API, and managed Amazon SES. The implementation excludes blacklisted or quota-exhausted accounts before weighted selection.
Pro costs $7 per team each month plus usage. Each provider-accepted recipient through an owned or connected provider costs $0.000500; the Sendmux-managed Amazon SES route costs $0.000750 per accepted recipient. Storage costs $0.02 per decimal GB-month.
The [platform overview](https://sendmux.ai/solutions/platform-builders) describes the product model. Use the owning repositories for technical behavior, then run a non-production mailbox journey before committing traffic.
## Sources
- [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322)
- [OpenAgent repository](https://github.com/openagentemail/openagentemail)
- [AgentMail introduction](https://docs.agentmail.to/introduction)
- [AgentMail MCP integration](https://docs.agentmail.to/integrations/mcp)
- [AgentMail multi-tenancy](https://docs.agentmail.to/multi-tenancy)
- [MailSlurp machine-readable documentation](https://www.mailslurp.com/llms.txt)
- [Resend Send Email API](https://resend.com/docs/api-reference/emails/send-email)
- [Postmark Message Streams](https://postmarkapp.com/support/article/how-to-create-and-send-through-message-streams)
- [Mailgun Routes](https://documentation.mailgun.com/docs/mailgun/user-manual/receive-forward-store/routes)
- [Amazon SES pricing](https://aws.amazon.com/ses/pricing/)
- [Google email sender guidelines](https://support.google.com/mail/answer/81126?hl=en)
- [Sendmux platform overview](https://sendmux.ai/solutions/platform-builders)
## FAQ
### What makes Sendmux different from Resend or Postmark for agents?
Sendmux owns application mailboxes, clean message and thread state, mailbox-scoped credentials, inbound SSE, signed outbound webhooks, and configured sending accounts in one reviewed contract. Resend and Postmark expose delivery and inbound-processing features, but verify whether your application also needs retained mailbox lifecycle and thread operations.
### Can OpenAgentMail replace a hosted inbox API in production?
OpenAgent can be a production foundation when the team deliberately accepts responsibility for deployment, relays, DNS, security updates, backups, abuse handling, observability, and deliverability. Review its current Apache-2.0 repository and test the exact production topology rather than treating self-hosting as feature parity with a managed service.
### How does multi-tenant reputation isolation work?
Separate mailbox credentials, provider eligibility, quotas, logs, recipient policy, and billing at the tenant boundary. A distinct mailbox does not automatically create a distinct sending reputation; confirm the actual domain, provider account, and IP-pool arrangement used for each tenant.
### What is the minimum setup for SPF, DKIM, and DMARC?
Publish the exact SPF, DKIM, DMARC, ownership, and bounce-handling records required by the chosen provider and verify their status before sending. Then follow each destination's current sender rules, including [Google's email sender guidelines](https://support.google.com/mail/answer/81126?hl=en), instead of copying a universal policy sequence.
### Which provider fits a high-volume outbound-only agent?
[Amazon SES pricing](https://aws.amazon.com/ses/pricing/) lists $0.10 per 1,000 outbound messages before data and optional features. The best complete fit also depends on events, dedicated IPs, support, destination mix, and the routing or mailbox infrastructure the application would otherwise build.
---
title: "Team Inbox Management for AI Agents and Platforms"
description: "Streamline your AI agents' communication with team inbox management, ensuring reliability and efficiency through API-driven solutions."
canonical: "https://myagent.mx/blog/team-inbox-management"
publishedAt: "2026-08-14T00:00:00.000Z"
updatedAt: "2026-08-14T00:00:00.000Z"
category: "agents"
topic: "how to streamline team inbox"
author: "Roshan Jonnalagadda"
authorProfile: "https://myagent.mx/blog/author/roshan-jonnalagadda"
keywords:
- "how to streamline team inbox"
- "managing team emails"
- "team email management tips"
- "collaborative inbox solutions"
- "shared inbox best practices"
- "effective team communication"
- "inbox organization tools"
- "shared inbox strategies"
- "Hiver alternatives"
- "Hiver vs Front"
- "shared inbox for support"
- "Hiver competitors"
- "team inbox management"
---
# Team Inbox Management for AI Agents and Platforms
Streamline your AI agents' communication with team inbox management, ensuring reliability and efficiency through API-driven solutions.
Message-ID, In-Reply-To, and References when replying. |
| Delivery routing | Configured sending accounts expose weights and quota windows; selection excludes unavailable accounts before choosing by weight. |
## What "team inbox management" actually means for developers
For developers, the useful definition is programmatic mailbox infrastructure for agents and platforms. It covers mailbox lifecycle, clean content, thread state, event delivery, sending, and least-privilege access. A human-facing support inbox may add assignment, collision detection, and agent dashboards, but those UI workflows do not prove a mailbox API contract.
**In scope:** mailbox identities, mailbox-scoped credentials, message and thread content, inbound SSE, outbound webhooks, provider accounts, quotas, logs, and tenant controls.
**Out of scope:** deciding whether Hiver alternatives, Hiver vs Front, or other collaborative inbox solutions have the right human support UI. Evaluate those products against their current official contracts when the buyer is a support team.
Current Sendmux API primitives include:
- POST /api/v1/mailboxes to provision a mailbox through the Management API
- POST /api/v1/mailboxes/{public_id}/keys to mint another mailbox credential
- GET /api/v1/mailbox/messages/{message_id}/content for deterministic clean JSON content
- POST /api/v1/mailbox/messages/send for a mailbox send with optional idempotency
- GET /api/v1/mailbox/events for inbound SSE with Last-Event-ID reconnection
Message-ID, In-Reply-To, and References; [RFC 5322](https://www.rfc-editor.org/rfc/rfc5322) defines those identification fields.
4. **Clean message content** — Fetch deterministic text and HTML content plus attachment metadata without making the agent parse raw MIME for its normal path.
5. **Inbound notification** — Use SSE or another documented push mechanism with reconnect and deduplication behavior.
6. **Outbound event verification** — Validate signatures over the raw webhook body before parsing or acting.
7. **Provider selection** — Verify account types, weights, quota windows, blacklisting, and the exact behavior when no account remains available.
8. **Delivery evidence** — Query message-level logs and test CSV export before production.
9. **Safe retries** — Use Idempotency-Key on supported create and send requests.
10. **Tenant controls** — Keep team roles, mailbox ownership, provider access, and recipient policy explicit.
The reviewed Sendmux permission taxonomy includes email.send, email.receive, mailbox.read, and mailbox.settings.update. Its Management API provisions a mailbox and initial credential atomically, while the Mailbox API separates clean content, sends, events, quotas, and usage into documented operations.
## Questions to ask providers before you commit
Ask for exact contracts and artifacts, not yes-or-no feature answers.
**Mailbox model:** Which API creates the mailbox, and which credential can read, receive, send, or update it?
**Inbound delivery:** Which events use SSE or webhooks? How does a client reconnect, deduplicate, and fetch full content?
**Threading:** Which request and response fields carry message_id, in_reply_to, references, and the platform thread identifier?
**Outbound routing:** Which account types are supported? How do weights, quota windows, blacklisting, and alternate selection work in committed code?
**Observability:** Can operators query logs by message attributes and export the filtered result as CSV?
**Security:** Which system roles and mailbox permissions exist, and are webhook signatures verified over the raw body?
**Commercial terms:** What is charged per recipient occurrence, mailbox, seat, managed provider, storage tier, or support plan?
Red flags to investigate:
- Undocumented endpoints or event names
- Raw MIME as the only normal content interface
- Credentials that silently widen across tenants
- Retry behavior without idempotency semantics
- Provider routing claims without implementation and test evidence
- Latency, compliance, residency, or roadmap claims absent from the current contract
Before you commit, ask for a sample event envelope, a clean-content response, a send response, a failed-delivery record and a CSV export.
## Reference implementation patterns for agents and platforms
Most agent and platform designs fall into three ownership patterns.
| Pattern | Identity boundary | Application work | Main trade-off |
| --- | --- | --- | --- |
| Per-agent mailbox | One mailbox per agent | Map agent state to mailbox state | More mailbox resources |
| Shared mailbox with actor IDs | One mailbox for several actors | Enforce actor ownership in application data | Shared sender and reputation boundary |
| Mailbox per tenant | One or more mailboxes per customer | Map credentials and provider access to the tenant | More lifecycle automation |
**Per-agent mailbox** gives each agent a durable address and a narrow credential. Use it when agents need independent conversations or sender identity.
**Shared mailbox with actor IDs** fits workflows where several workers process one queue. Store the internal actor and lease state outside the mailbox so two workers cannot act on the same message concurrently.
**Mailbox per tenant** keeps customer identities and provider choices separate. Sendmux's [platform overview](https://sendmux.ai/solutions/platform-builders) describes that model; technical behavior in this article remains bound to the reviewed owners.
**Thread correlation store:** Persist the outbound platform message ID, the RFC 5322 message identifier, the internal conversation ID, and the tenant ID. On reply, resolve In-Reply-To and References before falling back to provider thread metadata.
**Routing:** Configure eligible sending accounts and quota windows. The reviewed implementation filters blacklisted or quota-exhausted accounts, then selects from the accounts still available by weight.
Implementation guidance:
- Supply Idempotency-Key on supported outbound calls
- Treat event IDs as deduplication keys
- Fetch attachment bytes from the documented attachment endpoint rather than assuming they are embedded in an event
- Keep tenant and actor identifiers in application state even when custom headers are also allowed
## Scaling, observability, and troubleshooting your inbox infrastructure
Track metrics at both mailbox and tenant boundaries.
- Inbound event rate and consumer lag
- SSE reconnects and webhook delivery failures
- Outbound accepted, delivered, bounced, complained, rejected, and delayed outcomes
- Account selection failures and quota utilization
- Clean-content and attachment-fetch failures
- Mailbox storage usage and export completion
Operational checklist:
- Reconnect SSE clients with Last-Event-ID and deduplicate received event IDs
- Verify signed webhook bodies before parsing them
- Query delivery logs for expected and failed messages
- Export a filtered CSV and confirm its rows match the same query
- Turn bounce and complaint events into an explicit recipient policy
- Load-test only with approved non-production limits and consented recipients
The reviewed sending owner records a 10M+ accepted messages per day capacity target. Treat that as owner evidence for capacity planning, not as a guarantee for every tenant, provider, destination, or workload.
## Security, deliverability, and compliance requirements
Security checklist:
- Mailbox-scoped credentials with explicit permissions
- Owner, Admin, Developer, and Member team-role boundaries
- HMAC-SHA256 verification for outbound webhook events
- OAuth only for provider connections that require it
- Idempotency on supported mutations
- Audit and delivery evidence kept inside the correct tenant boundary
Deliverability checklist:
- Verify the exact sending domain and publish its required SPF, DKIM, DMARC, and bounce-handling records
- Follow [Gmail's current sender guidelines](https://support.google.com/mail/answer/81126?hl=en) for authentication and sending practices
- Keep hard-bounce and complaint handling in an explicit recipient policy
- Warm a dedicated IP only under the chosen provider's official process
Commercial email must also satisfy the sender's legal obligations. The FTC's current [CAN-SPAM guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) requires accurate headers and subject lines, a valid postal address, a clear opt-out, and prompt opt-out processing. Confirm privacy, retention, residency, deletion, and transfer terms in the actual contract for every region where the platform operates.
**Pro Tip:** *Authorize the action before classifying message content. A useful classifier does not make an over-broad credential safe.*
## How pricing works and what drives your costs
Compare billable units before comparing totals. Pro costs $7 per team each month plus usage. Each provider-accepted recipient through an owned or connected provider costs $0.000500; the Sendmux-managed Amazon SES route costs $0.000750 per accepted recipient. Each event is billed individually.
The main workload drivers are:
- **Outbound recipients:** one message with several recipients creates several billable recipient occurrences
- **Inbound messages:** replies, bounces, and automated responses add processing work
- **Attachments:** transfer and retention can dominate storage and egress
- **Managed delivery:** provider ownership can change the delivery unit price
- **Mailbox count:** per-agent and per-tenant models create more lifecycle resources even without a per-mailbox fee
Cost-control guidance:
- Deduplicate recipients before send
- Classify non-actionable inbound without invoking an expensive downstream model
- Set explicit attachment and message retention rules
- Enforce tenant quotas at the same boundary used for billing and provider access
- Reconcile provider-accepted recipients against the platform's delivery evidence
## Advanced features worth prioritizing on your roadmap
Think of these as evaluation items, not Sendmux capabilities or roadmap promises.
- **Cross-mailbox search** — Define which roles may query across tenant mailboxes and how results stay isolated.
- **Filter-scoped delivery** — Decide whether filters reduce event delivery, API visibility, or both.
- **Mailbox import** — Specify source providers, history depth, attachment handling, and duplicate detection.
- **Existing-mailbox connectors** — Verify Gmail, Microsoft 365, or IMAP ownership and OAuth scopes independently.
- **Automation hooks** — Require explicit event schemas, retry behavior, and tenant boundaries.
- **Conversation-level events** — Define how a conversation update relates to message-level delivery and replay.
An MCP tool can be a useful agent-facing interface, but it does not replace the underlying HTTP contract, permission boundary, idempotency behavior, or delivery evidence. Verify each callable operation against the same public implementation.
## Verdict and next steps for teams ready to build
A mailbox-first model is the right fit when the application must own durable inbound state and send replies under its own identity. It is not automatically the right fit for a human support team that mainly needs assignment and collaboration UI.
Three concrete next steps:
1. **Map ownership** — Record which tenant, agent, credential, provider accounts, and recipient policy own each mailbox.
2. **Run one complete journey** — Provision, receive, fetch clean content, reply with thread headers, and observe delivery without a live-customer mutation.
3. **Exercise failure paths** — Reconnect inbound events, replay an idempotent request, exhaust a test quota, and inspect the resulting log evidence.
Reject a platform if the contract, implementation, and targeted check do not agree on the exact method, path, field, event, or limit your integration needs.
## Why the mailbox-first model is the right long-term bet
Mailbox-first architecture concentrates message state, thread operations, events, and access around a durable identity. That can remove application glue when an agent must receive and reply, but it also makes mailbox ownership a first-class production responsibility.
The alternative is often a delivery API plus a consumer inbox, parser, event relay, and correlation store. That stack can be valid, especially when existing provider mailboxes are the source of truth. Compare the operational boundary, not the number of products.
For multi-tenant platforms, isolate mailbox credentials, provider eligibility, logs, and quotas by tenant. A shared mailbox can still work, but the application must then own actor leases, data isolation, and reputation impact explicitly.
Infrastructure-level classification can reduce downstream model work, but only after access checks and with a documented fallback for ambiguous messages. Keep the original message retrievable for diagnosis.
## Sendmux gives your agents a real mailbox API, not a workaround
The reviewed Sendmux owners expose mailbox provisioning, one-time credential issuance, clean message and thread content, inbound SSE, signed outbound webhooks, thread-aware sends, configured provider accounts, quota windows, delivery logs, and CSV export.
Mailbox-scoped permissions include email.send, email.receive, mailbox.read, and mailbox.settings.update. Configured sending accounts include custom SMTP, Gmail API, Outlook API, and managed Amazon SES types. The sending implementation excludes blacklisted or quota-exhausted accounts and selects available accounts by weight.
First-party SDK repositories cover TypeScript, Python, Go, PHP, Ruby, and Rust. Connected outbound usage costs $0.000500 per provider-accepted recipient, and Sendmux-managed Amazon SES costs $0.000750 per accepted recipient.
Use the [platform overview](https://sendmux.ai/solutions/platform-builders) to understand the product model, then verify every technical integration claim against the public contract and owning implementation.
## Useful sources
- [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322)
- [Email sender guidelines — Google](https://support.google.com/mail/answer/81126?hl=en)
- [CAN-SPAM Act: A Compliance Guide for Business — FTC](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business)
- [Amazon SES dedicated IP warmup](https://docs.aws.amazon.com/ses/latest/dg/dedicated-ip-warming.html)
- [Sendmux platform overview](https://sendmux.ai/solutions/platform-builders)
## FAQ
### What is the difference between a mailbox API and a sending API?
A sending API primarily accepts outbound messages. A mailbox API also owns inbound message state, message and thread retrieval, mailbox identity, events, and reply operations. Some products provide both surfaces; verify the exact public contract rather than inferring capability from the category name.
### Why do per-mailbox API keys matter for multi-tenant platforms?
A mailbox-scoped credential narrows what a compromised workload can access. The application must still map that credential to the correct tenant, protect the one-time plaintext value, rotate it when required, and keep team-level management credentials out of mailbox workers.
### How does Sendmux handle outbound routing and failover?
Configured sending accounts expose routing weights and per-second, per-minute, per-hour, and per-day quota windows. The sending implementation filters blacklisted or quota-exhausted accounts and selects among the available accounts by weight. Publish that verified behavior instead of promising universal automatic failover for every provider error.
### What is the reliable method for thread correlation across mail clients?
Preserve the RFC 5322 Message-ID, In-Reply-To, and References fields and store the platform message and thread identifiers beside the application's conversation ID. Subject matching alone is not a reliable correlation strategy.
### How should I classify inbound messages to control LLM costs?
Authorize mailbox access first, then classify categories such as human reply, out-of-office, bounce, complaint, or spam. Route only the categories that need model inference, retain an auditable fallback for ambiguous messages, and treat bounce and complaint events as recipient-policy inputs.
---
title: "Domain Verification Email: DNS, DKIM, and DMARC for Developers"
description: "Learn how to properly verify your email-sending domain using DNS, DKIM, and DMARC for secure and efficient message delivery."
canonical: "https://myagent.mx/blog/domain-verification-email"
publishedAt: "2026-08-13T00:00:00.000Z"
updatedAt: "2026-08-13T00:00:00.000Z"
category: "deliverability"
topic: "domain verification email"
author: "Roshan Jonnalagadda"
authorProfile: "https://myagent.mx/blog/author/roshan-jonnalagadda"
keywords:
- "best email domain verification"
- "domain authentication email"
- "domain verification notice"
- "verify email address"
- "email validation for domains"
- "domain verification steps"
- "dns records for email"
- "setting up domain email"
- "domain verification link"
- "email domain verification"
- "domain verification email"
- "domain verification process"
- "how to verify domain email"
- "importance of domain verification"
- "domain ownership confirmation"
- "spf dkim dmarc setup"
---
# Domain Verification Email: DNS, DKIM, and DMARC for Developers
Learn how to properly verify your email-sending domain using DNS, DKIM, and DMARC for secure and efficient message delivery.
selector._domainkey.example.com as a CNAME for a provider-hosted key or TXT for a self-published public key
- **SPF TXT record** — at the provider-specified domain, authorising your sending IPs and providers
- **DMARC TXT record** — at `_dmarc.example.com`, with a policy and, when you want aggregate feedback, an `rua` reporting address
**Quick rule of thumb:** Use DNS TXT verification if you control the domain's DNS and the provider issues an ownership token. Set up DKIM if the provider requires signing. If the service supports email validation and DNS access is unavailable or restricted, use an emailed domain verification link.
## Key Takeaways
To verify an email-sending domain, demonstrate control using the record type your provider specifies, then check DKIM, SPF, and DMARC separately. The complete domain verification process keeps ownership confirmation, message signing, sender authorisation, and policy enforcement separate.
| Point | Details |
| --- | --- |
| Publish the provider's complete record set | A provider may require an ownership TXT record, DKIM selectors, SPF, DMARC, or additional bounce-handling records. Copy the exact set it supplies. |
| Stage DMARC enforcement | Current DMARC guidance recommends monitoring at `p=none` for at least one month, then comparing an equally long `p=quarantine` period before considering `p=reject`. |
| Test before you verify | Query an authoritative nameserver directly with `dig` to confirm records exist before triggering provider verification. |
| Rotate DKIM keys safely | Publish the new selector, wait out the existing DNS TTL, switch signing, and retain the old key until messages signed with it no longer need validation. |
| Myagent (Sendmux) automates the checks | Sendmux exposes the required ownership, SPF, DKIM, DMARC, and bounce-handling records through its Management API, supports on-demand verification, and rechecks domains every six hours. |
## What domain verification email methods should you use?
Domain authentication email has several verification paths. Taking the wrong path wastes time and can leave signing incomplete. [DNSimple's DNS records reference](https://support.dnsimple.com/articles/email-dns-records-quick-reference/) gives a practical overview of record types, while your provider's current instructions remain the authority for exact names and values.
| Method | Record(s) to add | Scope | Timing | Pros | Cons |
| --- | --- | --- | --- | --- | --- |
| DNS TXT ownership token | TXT at `@` or a provider subdomain | Provider-defined domain | Depends on DNS TTL and provider checks | No mailbox needed; automatable | Requires DNS access; some providers recheck the token |
| DKIM configuration | CNAME or TXT at `selector._domainkey` | Messages signed with that selector | Depends on DNS TTL and provider checks | Enables cryptographic signing; a CNAME can let the provider manage public-key publication | A wrong selector or value prevents verification |
| Email validation | None; the service sends email to an approved address | Service-defined address or domain | Depends on email delivery and token lifetime | Works when the service supports it and DNS access is unavailable | Requires a working mailbox and human action; tokens can expire |
Programmatic setups often use **DNS TXT verification**. The provider gives you a unique value, you publish it as a TXT record, and the provider queries DNS to confirm control of the domain. Depending on the provider, that token may need to stay published, so do not remove it unless the documentation says you can.
**DKIM configuration** shows that mail can be signed for a domain. A provider may ask you to publish CNAME records pointing to public keys it hosts, or a TXT record containing the public key for a private key you control. A CNAME delegates public-key publication to the provider; BYODKIM keeps the signing key under your control.
**Email validation** is supported in some products when DNS access is restricted or controlled by a third party. [AWS Certificate Manager's email validation](https://docs.aws.amazon.com/acm/latest/userguide/email-validation.html) sends messages to five common administrative addresses, and each token expires after 72 hours. DNS-validated ACM certificates can renew automatically while the required CNAME remains available; email-validated certificates require owner action at renewal.
Use email validation for domains only when the service explicitly supports it. A standard mailbox workflow that can verify email address ownership is not equivalent to DNS control over an entire sending domain.
## How do you publish a DNS TXT verification record?
There are three primary fields in the record: **Name/Host**, which indicates where it lives; **Value**, which is the exact verification token; and **TTL**, which tells resolvers how long they can cache the answer. These are the basic domain verification steps for a TXT challenge.
### Common field values
- **Name/Host:** `@` for a zone apex when the provider requests it, or a label such as `_provider-verify`
- **Value:** the exact string supplied by the provider, such as `provider-verification=abc123xyz`
- **TTL:** use the provider's recommended value or your DNS host's default; a shorter TTL shortens future cache lifetimes but does not purge records already cached under an older TTL
### Adding the record in common DNS panels
1. **Cloudflare:** Open **DNS** > **Records** > **Add record**. Choose TXT, enter the provider-supplied name and content, and select an allowed TTL. Cloudflare's [email records guide](https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/) explains the related DNS records for email.
2. **Route 53:** Open the hosted zone and create a TXT record at the required name. Route 53 represents each TXT string inside double quotation marks; its console and API documentation show how to split values longer than 255 characters into quoted chunks within one record.
3. **GoDaddy:** Open the domain's DNS records and add a TXT record. Use `@` only when the provider requires the zone apex; for a named challenge, enter the host label in the format GoDaddy expects. Select an available TTL rather than assuming a universal value.
### Confirming the record from the command line
```text
dig +short TXT example.com
nslookup -type=TXT example.com
```
Query the exact record name the provider gave you. If the expected string is absent, either the name or value is wrong, the authoritative nameserver has not been updated, or a recursive resolver still holds a cached answer.
**Common mistakes to avoid:**
- Appending the root domain to the Name field in a panel that already appends it
- Changing punctuation, spacing, case, or quoting inside the provider-supplied value
- Removing a token that the provider periodically rechecks
- Publishing multiple policy records where a protocol requires one record
**Pro Tip:** *Before selecting **Verify** in a provider dashboard, query the authoritative nameserver for the exact record. A public resolver such as `8.8.8.8` is useful for checking recursive visibility, but its cached answer can lag behind the authority.*
When setting up domain email, record the authoritative answer separately from the provider's status. DNS can be correct even while the provider is waiting for its next check.
## How does DKIM work, and what records do you need?
DKIM (DomainKeys Identified Mail) adds a digital signature to outbound messages. Receiving servers retrieve the public key from DNS, verify the signature, and check whether signed parts of the message changed in transit. The lookup name is `selector._domainkey.example.com`, where the selector identifies the key.
### CNAME vs. TXT: which approach applies to you?
Amazon SES and other managed sending platforms may use CNAME records pointing to provider-hosted DKIM public keys. This lets the provider manage those keys without requiring you to replace the DNS name. With a self-published TXT record, you publish the public key and retain the private key.
Self-published TXT records can look like this:
```text
Name: mail2026._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
```
The `p=` field contains the base64-encoded public key. DNS limits each label to 63 octets and the full wire-format domain name to 255 octets, including length octets and the terminating root label. A long DKIM key in a TXT record can be split across multiple quoted character-strings in one TXT resource record.
### Key length and rotation
- **1024-bit RSA keys** meet the DKIM interoperability minimum but should not be the default for a new deployment when the provider and DNS host support 2048 bits.
- **2048-bit RSA keys** are the recommended choice in current Google Workspace and Salesforce setup guidance, and Amazon SES uses 2048 bits by default for Easy DKIM.
- **Rotation:** generate the new key pair, publish a new selector, confirm it through DNS, switch the signer, keep the old public key available while old signatures can still be evaluated, and remove it only after that overlap window.
**Pro Tip:** *Rather than assuming a fixed 48-hour wait, base the overlap on the selector's previous TTL and your message transit expectations. Confirm the new selector from an authoritative nameserver before signing with it.*
## How do SPF and DMARC complete the authentication stack?
SPF, DKIM, and DMARC work together, but test different identifiers. [Proofpoint's authentication guide](https://www.proofpoint.com/us/threat-reference/spf-dkim-dmarc) gives a practical overview; the current SPF, DKIM, and DMARC RFCs define the protocol rules. SPF authorises hosts for an envelope domain, DKIM validates a domain signature, and DMARC requires at least one passing result to align with the visible author domain.
### SPF record structure
```text
v=spf1 include:_spf.google.com include:amazonses.com ip4:203.0.113.10 ~all
```
Publish the policy your active senders need. SPF implementations count DNS-querying terms—`include`, `a`, `mx`, `ptr`, `exists`, and `redirect`—including recursive evaluation, and must return `permerror` when the total exceeds 10. The mechanisms `all`, `ip4`, and `ip6` do not count toward that limit.
**SPF best practices:**
- Keep one SPF policy record at each owner name; multiple SPF records at one name produce `permerror`
- Remove providers you no longer authorise and retain every active sender's required mechanism
- Use a dedicated sending subdomain when you need separate policy and reputation boundaries
- Do not replace provider-managed `include:` mechanisms with copied IP ranges unless the provider explicitly supports that configuration
### DMARC record for monitoring
```text
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; sp=none; adkim=r; aspf=r"
```
At `p=none`, a domain expresses no DMARC-specific handling preference for failing messages and can receive aggregate reports through `rua`. Current DMARC guidance recommends collecting `p=none` data for at least one month and then comparing an equally long `p=quarantine` period before considering `p=reject`, especially where legitimate mail can pass through intermediaries such as mailing lists.
### The alignment trap most teams miss
DMARC passes when SPF or DKIM both passes and aligns with the visible `From:` domain. Under default relaxed alignment, the authenticated domain and author domain can differ while sharing the same organisational domain. Under strict alignment, they must be identical. SPF and DKIM can therefore pass individually while DMARC still fails if neither passing identifier aligns. For SPF, the relevant authenticated identity is the `MAIL FROM` domain.
If a third-party sender uses its own return-path, configure DKIM signing with your domain or another supported aligned identity. Do not diagnose alignment using exact string comparison unless the DMARC record requests strict alignment.
## How do you verify and test DNS and authentication after publishing?
Publishing records is step one; validating each layer before live traffic is step two. Query the exact ownership, DKIM, SPF, and DMARC names, then inspect a real test message.
```text
dig NS example.com
dig @ns1.example.com TXT example.com
dig @ns1.example.com CNAME mail2026._domainkey.example.com
dig @ns1.example.com TXT _dmarc.example.com
```
DNSimple's quick reference lists common email-related DNS records. After sending a test message, inspect the `Authentication-Results` header in the received message. A passing stack can look like:
```text
Authentication-Results: mx.example.com;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com header.s=mail2026;
dmarc=pass header.from=example.com
```
If `dmarc=fail` appears despite a passing SPF or DKIM result, use the alignment mode in your DMARC record to compare the authenticated domain with the visible author domain. A domain verification notice in a provider dashboard may summarise these checks, but the DNS answers and received-message header show the underlying state.
**Recommended tools:** `dig` and `nslookup` expose DNS answers directly. Header analysers can make a long `Authentication-Results` field easier to read, and validators can flag SPF or DMARC syntax mistakes, but verify every recommendation against the applicable RFC and provider documentation.
## Why aren't your DNS records showing up yet?
There is no single universal propagation time for DNS updates. Authoritative servers can update quickly, while recursive resolvers continue serving an older answer until its TTL expires. A provider may also check on its own schedule after public DNS is ready.
### Stepwise troubleshooting
1. **Query an authoritative nameserver directly.** Find it with `dig NS example.com`, then run `dig @ns1.example.com TXT example.com`. If the record appears there but not through a recursive resolver, inspect the prior TTL and cached answer.
2. **Check for duplicate SPF records.** Run `dig +short TXT example.com` and count strings beginning with `v=spf1`. More than one SPF record at the owner name is a protocol error.
3. **Verify the Name field.** If a panel appends the zone, entering `_dmarc.example.com` can create `_dmarc.example.com.example.com`. Use the format documented by that host.
4. **Check for CNAME conflicts.** A CNAME owner name cannot coexist with other data. Zone-apex SPF and DMARC therefore use TXT records, not CNAME records.
5. **Confirm delegation.** Query the domain's NS records and make changes at the DNS host those records identify, not merely at the registrar.
6. **Check provider-specific CNAME handling.** Keep email-authentication CNAME records DNS-only where a DNS host offers HTTP proxying, and follow the sending provider's exact name/value format.
7. **Account for TTL caching.** Lowering TTL affects answers cached after the change; it does not shorten the lifetime of an older cached answer.
These checks matter for email domain verification because a green ownership check does not prove DKIM, SPF, or DMARC is correct. Treat each signal independently.
## Provider-specific notes for Amazon SES, ACM, Google Workspace, and Salesforce
Each provider has its own domain ownership confirmation and signing workflow. Follow its current primary documentation rather than copying example records from another account.
**Amazon SES** treats identities as regional resources. To send from a domain in more than one AWS Region, create and verify an identity in each Region, unless you deliberately use the documented Deterministic Easy DKIM replica workflow. Easy DKIM generates three CNAME records. SES uses 2048-bit keys by default, while BYODKIM accepts RSA private keys from 1024 through 2048 bits.
**AWS Certificate Manager (ACM)** supports DNS and email validation for public certificates. DNS validation uses a CNAME for ownership and ongoing automated renewal when the certificate remains in use and the record remains publicly available. Email validation sends links to five common administrative addresses; its token expires after 72 hours and renewal requires owner action.
**Google Workspace** separates domain ownership from DKIM signing. First, verify the Workspace domain using the unique `google-site-verification=` TXT value. Then open **Apps** > **Google Workspace** > **Gmail** > **Authenticate email**, generate the DKIM record, publish it, and select **Start authentication**. Google recommends 2048-bit keys when the DNS host supports them.
**Salesforce** requires email-sending domain verification for each organisation, including sandboxes. An active DKIM key whose domain matches the complete `From` domain satisfies domain-level verification. Create a primary and alternate selector under **DKIM Keys**, publish both generated CNAME records, wait until Salesforce sees them, then activate the key. Salesforce uses the alternate selector for automatic rotation.
forward(), store(), and stop(). Forwarding to a URL sends a parsed version of the received email over HTTP. Confirm current validation products, limits, and pricing directly with Mailgun.
### SendGrid
[Twilio SendGrid's v3 Mail Send](https://www.twilio.com/docs/sendgrid/for-developers/sending-email/v3-mail-send-faq) is its current HTTP sending surface, while [Marketing Campaigns Single Sends](https://www.twilio.com/docs/sendgrid/api-reference/single-sends/create-single-send) handles one-time sends to a list or segment. The Marketing API exposes an ip_pool field, so any stream-separation design remains an explicit configuration responsibility.
### Amazon SES
[Amazon SES pricing](https://aws.amazon.com/ses/pricing/) lists $0.10 per 1,000 outbound messages before data and optional features. Shared IPs are ready immediately; standard dedicated IPs require warmup and consistent sending. SES documents standard dedicated-IP warmup as roughly two to six weeks depending on receiving provider, with automatic warmup percentage progressing over 45 days.
### Brevo
[Brevo's official guidance](https://help.brevo.com/hc/en-us/articles/360021196220-What-are-the-differences-between-marketing-transactional-and-automation-emails) distinguishes Campaigns, its Transactional platform, and Automations. Marketing and transactional messages can both use API-backed paths, but their purpose and consent treatment differ. Confirm the current plan, regional terms, and feature limits directly.
### Mailtrap
[Mailtrap Email Sandbox](https://docs.mailtrap.io/getting-started/email-sandbox) catches staging messages so teams can inspect content, spam signals, and HTML/CSS without delivering to recipients. The source draft's never-expiring-free-tier and production-maturity judgments are not retained.
### Resend
[Resend's Send Email API](https://resend.com/docs/api-reference/emails/send-email) accepts HTML, text, hosted templates, and a React component in its Node.js SDK. Its current docs also publish an Idempotency-Key header. This guide does not turn those documented interfaces into a deliverability ranking.
### Mailjet
Current official primary documentation was not confirmed during this import, so this guide does not publish a capability, residency, compliance, price, or deliverability claim for Mailjet. Evaluate its current official documentation and contract directly.
### Mailchimp Transactional Email
[Mailchimp Transactional](https://mailchimp.com/help/about-transactional-email/) is a delivery API and a paid add-on to a Standard or Premium monthly Marketing plan. It can use API or SMTP integrations; confirm current credit-block pricing before comparison.
### Dreamlit
Current official primary documentation was not confirmed during this import, so this guide does not publish an AI-sequence, SES, price, or deliverability claim for Dreamlit. Evaluate its current official documentation and contract directly.
### Loops
[Loops](https://loops.so/docs/quickstart) documents Campaigns, Workflows, and Transactional email. Workflows are event- or contact-triggered sequences; transactional messages use a separate API surface and support an optional idempotency key. Loops also notes that its default transactional and marketing traffic share reputation signals through the verified domain and a small shared IP pool.
### MailerSend
[MailerSend's official template guidance](https://www.mailersend.com/help/how-to-create-a-template) documents drag-and-drop, rich-text, and custom HTML editors, API instructions, test sends, and template analytics tags. Confirm current verification, routing, inbound, and pricing terms directly.
### SendLayer, SMTP.com, SMTP2GO
Current official primary documentation was not confirmed for the source draft's grouped claims. This guide therefore does not publish a dedicated-IP, global-infrastructure, support, inbound, compliance, or price comparison for these services.
### Elastic Email
Current official primary documentation was not confirmed during this import, so the source draft's price and developer-experience judgments are not retained.
### Zepto (by Zoho)
Current official primary documentation was not confirmed during this import, so the source draft's integration and competitive judgments are not retained.
### Maileroo, Scaleway TEM, rapidmail, Sweego, Lettermint
Current official primary documentation was not confirmed for the source draft's grouped capability, residency, pricing, and suitability claims. Verify each provider's current official documentation, data-processing terms, supported regions, and contract directly.
## How do you choose the right Postmark alternative for your team?
Start with four engineering questions, in order.
**1. Who owns the mailbox?** Decide whether the application needs its own mailbox state, an authorized user's Gmail or Microsoft 365 mailbox, or only a delivery API.
**2. How are traffic types separated?** Postmark documents Transactional and Broadcast Message Streams on different infrastructure. Other providers expose different controls, so verify domain, subdomain, configuration-set, IP-pool, suppression, and reporting boundaries directly.
**3. What happens on retry and overload?** Require documented idempotency, rate limits, backpressure, and event semantics. Test only with consented seed addresses and provider-approved non-production limits.
**4. What is actually billable?** Compare recipients, messages, data, inbound processing, attachments, retention, dedicated IPs, mailboxes, seats, and support using current official terms.
**Red flags to investigate:**
- No official API or SMTP contract for the path you need
- No documented domain-authentication workflow
- No clear suppression and complaint handling
- No documented event-signing or retry model
- Compliance or residency claims that are absent from the current contract
The FTC's [CAN-SPAM compliance guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) requires accurate header information and subject lines, a valid postal address, a clear opt-out, and processing of opt-out requests within 10 business days. A provider can expose tools, but the sender remains responsible for compliant use.
## Transactional vs. marketing email: why the distinction matters for your stack
Transactional messages are one-to-one messages triggered by a user action; broadcast or marketing messages are one-to-many sends to a list or segment. [Postmark Message Streams](https://postmarkapp.com/support/article/how-to-create-and-send-through-message-streams) make that distinction explicit: Transactional and Broadcast streams use separate infrastructure, and the sender selects the stream at send time.
The practical consequence is that traffic classification belongs in the architecture. Use separate streams, domains, subdomains, configuration sets, or IP pools when the provider's official contract supports them. Keep suppression, complaint, and reporting views aligned with the same boundary.
Template workflows can differ too. Transactional templates are commonly triggered from application data. Marketing and lifecycle tools add list, segment, campaign, and workflow controls. Twilio SendGrid documents Single Sends, Brevo documents Campaigns and Automations, and Loops documents Campaigns, Workflows, and Transactional messages.
A two-tool stack can be sensible when one provider handles delivery and another handles lifecycle workflows. The benefit is a clearer responsibility boundary; the cost is another integration, credential set, event model, and contract.
email.send, email.receive, mailbox.read, and mailbox.settings.update. Clean message and thread content, inbound SSE, signed outbound webhooks, configured sending accounts, quota windows, and delivery observability are present in the reviewed owners.
Configured accounts can use custom SMTP, Gmail API, Outlook API, or managed Amazon SES. The implementation filters blacklisted or quota-exhausted accounts and selects available accounts by weight. Treat this as verified availability-aware routing, not a universal automatic-failover promise.
Sendmux Pro costs $7 per team each month plus $0.000500 per connected-provider accepted recipient. For multi-tenant products, the [platform overview](https://sendmux.ai/solutions/platform-builders) describes the operating model; the owning repositories remain the authority for technical claims.
## Sources
- [CAN-SPAM Act: A Compliance Guide for Business — FTC](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business)
- [Postmark Message Streams](https://postmarkapp.com/support/article/how-to-create-and-send-through-message-streams)
- [Amazon SES pricing](https://aws.amazon.com/ses/pricing/)
- [Amazon SES dedicated IP warmup](https://docs.aws.amazon.com/ses/latest/dg/dedicated-ip-warming.html)
- [Mailgun Routes](https://documentation.mailgun.com/docs/mailgun/user-manual/receive-forward-store/routes)
- [Twilio SendGrid v3 Mail Send](https://www.twilio.com/docs/sendgrid/for-developers/sending-email/v3-mail-send-faq)
- [Twilio SendGrid Marketing Campaigns Single Sends](https://www.twilio.com/docs/sendgrid/api-reference/single-sends/create-single-send)
- [Brevo marketing, transactional, and automation email](https://help.brevo.com/hc/en-us/articles/360021196220-What-are-the-differences-between-marketing-transactional-and-automation-emails)
- [Mailtrap Email Sandbox](https://docs.mailtrap.io/getting-started/email-sandbox)
- [Resend Send Email API](https://resend.com/docs/api-reference/emails/send-email)
- [Mailchimp Transactional Email](https://mailchimp.com/help/about-transactional-email/)
- [Loops quickstart](https://loops.so/docs/quickstart)
- [Loops transactional versus marketing guidance](https://loops.so/docs/guides/transactional-vs-marketing-email)
- [MailerSend transactional templates](https://www.mailersend.com/help/how-to-create-a-template)
## FAQ
### What is the cheapest Postmark alternative at high volume?
[Amazon SES](https://aws.amazon.com/ses/pricing/) lists a base outbound price of $0.10 per 1,000 messages before data and optional features. Sendmux Pro costs $7 per team each month plus $0.000500 per connected-provider accepted recipient. The cheapest complete system depends on data, inbound processing, dedicated IPs, support, mailboxes, and the operational work your team owns.
### Which Postmark alternative is best for AI agents that need to send and receive email?
Sendmux is a practical fit when agents need application-owned mailboxes, clean JSON message content, scoped mailbox credentials, inbound SSE, signed outbound webhooks, and configured sending accounts in one public contract. Gmail API or Microsoft Graph can be more direct when an agent should act through an existing provider mailbox.
### How do I keep transactional emails out of spam when switching providers?
Authenticate the exact sending domain, preserve suppression state, classify traffic correctly, and follow the destination provider's current sender requirements. Keep transactional and broadcast traffic on distinct supported streams, then increase dedicated-IP volume gradually under the chosen provider's official warmup guidance.
### Do any Postmark alternatives offer EU data residency for GDPR compliance?
Do not infer EU data residency from a provider's headquarters or marketing category. Confirm the exact processing region, subprocessors, transfer mechanism, retention terms, and data-processing agreement in the provider's current official contract; the source draft's grouped residency claim was not retained without that evidence.
### What is the difference between a transactional email provider and a lifecycle email tool?
A transactional provider handles one-to-one messages triggered by a user action, such as password resets and receipts. A lifecycle tool adds campaigns or event-driven sequences such as onboarding and re-engagement. Postmark documents Transactional and Broadcast streams, while Loops documents separate Campaign, Workflow, and Transactional message types; teams may use one platform or a two-tool stack while keeping responsibilities explicit.
---
title: "Best Email APIs for Developers: 2026 Comparison Guide"
description: "Discover the best email APIs for developers in 2026. Compare features like real mailboxes, parsing, and delivery options to find your ideal choice."
canonical: "https://myagent.mx/blog/best-email-api"
publishedAt: "2026-08-12T00:00:00.000Z"
updatedAt: "2026-08-12T00:00:00.000Z"
category: "apis"
topic: "best vercel email api"
author: "Roshan Jonnalagadda"
authorProfile: "https://myagent.mx/blog/author/roshan-jonnalagadda"
keywords:
- "best vercel email api"
- "best email api for agents"
- "best email api for gmail"
- "best email api for outlook"
- "best microsoft 365 email api"
- "best email integration services"
- "best email api"
- "affordable email API solutions"
- "email API for developers"
- "email API comparison"
- "top email API providers"
- "best email api for developers"
---
# Best Email APIs for Developers: 2026 Comparison Guide
Discover the best email APIs for developers in 2026. Compare features like real mailboxes, parsing, and delivery options to find your ideal choice.
Your confirmation link is ready.
" } ``` Store the accepted message identifier with your own request record. Then handle `message.delivered`, `message.bounced`, `message.complained`, `message.rejected`, and `message.delivery_delayed` as asynchronous webhook events. ## Key Takeaways A REST-based transactional email API is the clearest fit when developers need structured requests, idempotent retries, delivery telemetry, and code-owned workflows. | Point | Details | | --- | --- | | API over SMTP for observability | An HTTP API can return structured acceptance data and pair it with delivery webhooks. | | Domain authentication comes first | Publish SPF, DKIM, and DMARC before moving production traffic. | | Keep streams separate | Transactional vs marketing email traffic should use separate identities when marketing complaints could affect critical mail. | | Use least-privilege credentials | Give a mailbox or service only the exact permissions it needs. | | Keep delivery handling asynchronous | Verify the webhook signature, persist the event, acknowledge it, and process it outside the HTTP request. | ## What qualifies as a transactional email API use case? A transactional email is a one-to-one message triggered by a user action or system event. Common examples from applications and microservices include: - One-time passwords (OTPs) and magic links - Order confirmations and receipts - Password reset and account recovery messages - Shipping updates and delivery notifications - Account verification emails - Subscription renewal and payment failure alerts - Webhook-triggered system alerts Broadcast promotions belong on a marketing stream. That distinction matters operationally and legally. The [FTC's CAN-SPAM guidance](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) uses a message's primary purpose to distinguish transactional or relationship content from commercial content. If promotional material dominates, the exemption for transactional content may no longer apply. Teams searching for transactional messaging solutions or an email transaction service should first decide whether the application only sends or must also receive replies. A conventional API for email delivery covers outbound events. A mailbox API adds inbound messages, threads, and reply state for agents and support workflows. ## How does a transactional email API actually work? Your application authenticates an HTTP request, the provider accepts and queues the message, and later state changes arrive through webhooks. The API response confirms acceptance, not inbox delivery. Delivery, bounce, complaint, rejection, and delay are separate events. | Dimension | Transactional API | SMTP relay | Mailbox / unified inbox API | | --- | --- | --- | --- | | Request surface | HTTPS and JSON | SMTP submission | HTTPS, JSON, and mailbox state | | Observability | Acceptance response plus webhooks | Server replies plus provider-specific logs | Delivery events plus inbound conversation state | | Safe retry | Provider contract can support idempotency | Application/provider dependent | Provider contract can support idempotency | | Receiving email | No | No | Yes | | Best fit | Event-triggered application mail | Legacy integrations and simple relays | AI agents and two-way workflows | Use a fresh `Idempotency-Key` for each logical send and reuse it only when retrying that same send. This keeps a timeout retry from producing a duplicate password reset or receipt. ## What features should you require from any email API provider? The best transactional email providers make the delivery contract explicit. Evaluate the public specification and real event payloads, not only the dashboard. | Feature | Why it matters | What to verify | | --- | --- | --- | | Stable API contract | Prevents request drift | Versioned OpenAPI, required fields, error schemas | | Templating and substitution strategy | Keeps content changes controlled | Provider templates or application-rendered HTML, variable validation, escaping, and versioning | | Idempotency | Makes retries safe | Header semantics, retention window, conflict behavior | | Signed webhooks | Protects event ingestion | Signature algorithm, timestamp, retry policy | | Delivery event model | Supports incident response | Delivered, bounced, complained, rejected, delayed | | Authentication guidance | Supports inbox placement | SPF, DKIM, DMARC setup and status | | Credential scopes | Limits blast radius | Per-mailbox or application permissions | | Throughput and rate limits | Bounds application concurrency | Per-second, per-minute, per-hour, and per-day quotas | | Routing controls | Handles provider failure | Weights, health, quotas, and failover behavior | | Sandbox and testing | Catches failure-path bugs before launch | A documented test mode or provider-supported bounce and rejection scenarios | | Multi-tenant controls | Isolates customer workloads | Credential, mailbox, domain, and quota boundaries | | Logs and time-to-inbox | Makes support queries answerable | Message ID, recipient, provider, event history, and latency on critical paths | Before the first production send, verify all three domain-authentication layers. [SPF](https://www.rfc-editor.org/info/rfc7208/) authorizes sending infrastructure for a domain. [DKIM](https://www.rfc-editor.org/info/rfc6376/) attaches a domain signature that receivers can validate. [DMARC](https://www.rfc-editor.org/info/rfc9989/) aligns SPF or DKIM with the author domain, publishes handling policy, and enables aggregate reporting. Use the exact records supplied by the selected provider rather than copying example values. An integrated email API should also document limits, error codes, and how it behaves when a downstream provider returns `429` or `5xx`. If your product is multi-tenant, verify isolation at the credential, mailbox, sending-domain, and quota layers. ## How do you get a test transactional email working? Start with one real request through the documented production-shaped endpoint. Do not rely on a guessed provider test address or a template field copied from another vendor. 1. Create a mailbox or sending identity and store its key in a secrets manager. 2. Grant only the required Sendmux permissions, such as `email.send`; use `email.receive`, `mailbox.read`, or `mailbox.settings.update` only when the workflow needs them. 3. Verify the sending domain and publish the required SPF, DKIM, and DMARC records. 4. Choose a content-rendering strategy. If the provider supports templates, validate and version every substitution variable. For Sendmux's current strict request schema, render the content in your application and send it as `html_body`; `template_id` and `personalizations` are rejected as unknown fields. 5. Send the minimal request shown above with a unique idempotency key. 6. Register a webhook destination, verify its HMAC signature over the raw request body, persist the event, and return success promptly. 7. Exercise bounce, rejection, delay, and retry paths using scenarios explicitly documented by the chosen provider rather than assuming a universal sandbox address. Treat templates as part of the product interface: preview rendered output, reject missing variables, and keep transactional content concise. If the provider offers an SDK, compare its generated request with the public HTTP schema. Knowing how to use email API clients is useful, but the wire contract remains the source of truth. ## How do you maximize inbox placement and avoid rejections? Authenticate first, send to recipients who expect the message, and watch mailbox-provider feedback as volume changes. Separate important transactional traffic from promotional campaigns so one stream's complaint pattern does not damage the other. Google recommends keeping spam rates below `0.1%` and requires bulk senders to avoid reaching `0.3%` or higher. Yahoo requires complaint rates below `0.3%`. These are not interchangeable thresholds. Follow [Google's sender guidelines](https://support.google.com/a/answer/81126) and [Yahoo's sender requirements](https://senders.yahooinc.com/best-practices/) for the current rules. For a new domain or dedicated IP, start with a low sending volume to engaged recipients, increase gradually, and monitor reputation plus server responses. There is no universal numeric warm-up recipe that fits every sender history and provider mix. Transactional email best practices also include immediate hard-bounce handling, complaint processing, DMARC aggregate-report review, and a clear separation between acceptance and delivery metrics. ## How do you monitor delivery and troubleshoot failures? Persist an application correlation ID, idempotency key, provider message ID, recipient, and event history. That lets support staff trace one message without searching raw logs across several services. Monitor four distinct signals rather than collapsing them into one delivery percentage: - API send attempts and acceptance responses - Signed delivery events for delivered, bounced, complained, rejected, and delayed states - Complaint feedback and domain-reputation changes - Time-to-inbox for critical paths such as one-time passwords and password resets Treat webhook ingestion as a short boundary: 1. Read the raw request body. 2. Verify the signature and timestamp. 3. Store the event idempotently. 4. Return a success response. 5. Update application state asynchronously. Outbound delivery uses webhooks. Sendmux mailbox SSE is for inbound mailbox events such as `message.received` and spam-state changes, not outbound delivery confirmation.
