Sending domains and sender identities over the API
Nine new endpoints put the whole sending setup under your own scripts: add a domain, read back the DNS records to publish, poll for verification, and create, update, delete or default a sender identity. Provisioning a workspace end to end no longer needs anyone clicking through a dashboard.
Two new scopes, on purpose
The nine endpoints sit behind sending:read and sending:write, kept separate from emails:send because changing who mail comes from is a different privilege from sending it. A key that can send should not also be able to point your domain somewhere else.
Keys issued before this carry neither scope, so an existing integration has to add them explicitly. That is the safe direction for a permission change: nothing silently gains an ability it did not have when it was issued.
The verify call is rate limited differently
Verification is capped at 6 a minute rather than the usual 100, because each call queries the provider and resolves DNS rather than reading our own database. Poll it on a timer rather than in a loop, and treat a pending result as normal: DNS propagation is measured in minutes, not milliseconds.
Everything else in the group runs on the standard per-key ceiling.
Also in this release
- A workspace with no sender identity is refused with the block reason SENDER_NOT_CONFIGURED rather than falling back to a platform address. Mail leaves on an address you own, or it does not leave, so setting up sending is now step one of any integration rather than an afterthought.
Related: Add a sending domain, EU data residency
Private beta
See the next one land
Beta members get the release note in the same batch email that opens their account.