CreateSendingDomainAPI registers a sending domain for the caller's org and
returns the DKIM/SPF (and, for receiving, MX) records the customer must create at their own DNS provider. The domain comes back pending_dns and nothing is sent from it until those records exist and verify — sends keep going out from Erdo’s address in the meantime.
Authorizations
An Erdo API key (erdo_api_...) or scoped token (erdo_token_...).
Body
Response
Success response
provider. Kept after verification too, so a domain that regresses can be compared against what should exist.
punycode) — an apex ("acme.com") or a subdomain ("hello.acme.com"). It is the identifier every other sending-domain endpoint takes.
(e.g. the DKIM record was not found); empty otherwise.
at a mailbox provider (Google Workspace, Microsoft 365) when it was registered. Adding Erdo's MX to that same name would break the customer's existing mail, so receiving must instead be set up on a subdomain ("hello.acme.com") or left off — say so rather than handing over the MX record.
business reads its own mail in the place it already works. Empty means replies are stored in Erdo only.
active — from_local_part@domain.
means the address shows alone.
provider (RFC 3339); empty if never checked yet.
Erdo. It requires the MX record among dns_records, which cannot coexist with an existing mailbox provider's MX on the same name — see existing_mx_detected.
the provider, fixed for the registration's life. False means receiving can never be enabled on this registration — to receive, remove the domain and register it (or a subdomain) again.
customer to create the listed DNS records), "active" (verified — mail now leaves from this domain), "failed" (a record is missing or wrong; see error_reason), or "disabled" (deregistered upstream). Only "active" changes what recipients see; every other state means sends still go out as hello@mail.erdo.ai.

