Deliverability guide

Passing authentication is necessary, not sufficient. Providers also judge reputation and content.

1. Authenticate. Mail you send today leaves from the shared service domain, whose authentication the operator manages; open a test message in your mailbox provider's "show original" view and confirm SPF, DKIM and DMARC all pass. Publishing the records the API generates for your own domain does not authenticate mail yet, because sending from custom domains is not connected (see domains).
2. Warm up. A new domain that suddenly sends thousands of messages looks like spam. Start with low volume to engaged recipients and increase over weeks.
3. Send to people who expect it. Do not buy lists. Complaints hurt every sender on a shared reputation. Complaints and hard bounces automatically suppress the address here (422 recipient_suppressed), and you should stop mailing it.
4. Write like a person. Send text and html together, keep a real Reply-To, avoid link shorteners and all-caps subjects.
5. Make replies work. Replies to your messages reach the inbox and join the thread. Use extracted_text to read only the new text.
6. Watch events. Subscribe to message.bounced and message.complained, and act on them. GET /v0/metrics/rates shows your rolling bounce and complaint rates; see open tracking for why tracking pixels are not recommended.
7. Use a subdomain for agent traffic once custom-domain sending exists, so problems cannot damage your main domain's reputation. Today all mail shares the service domain's reputation, which is another reason to keep complaint and bounce rates low.

Inbound checks#

Inbound mail is classified using the SPF, DKIM and DMARC verdicts and spam and virus flags the mail forwarder supplies. Messages can be labelled spam, unauthenticated or blocked, or dropped (authentication failure plus virus). The quality of this depends on what the operator's forwarder reports; no content-based spam scoring is done beyond the provider verdicts.

Sending limits#

Beyond your plan's monthly allowance, every inbox is capped at 100 messages in any rolling 24 hours by default (the operator can change it). Exceeding it returns 429 rate_limited.

What does not exist#

There is no warm-up scheduler, no inbox-placement or spam-score testing, no dedicated IP and no feedback-loop dashboard. What exists is: automatic suppression after hard bounces and complaints, GET /v0/metrics/rates for rolling bounce and complaint rates (charted on the dashboard overview, and available in the API and both SDKs), the events message.bounced and message.complained, and DNS record generation for custom domains.