UpdateSendingDomainAPI edits a sending domain's identity settings — from
name, mailbox part, forwarding mailbox, receiving — named by the domain itself. Absent fields are left unchanged. Mirrors erdo_update_sending_domain.
Authorizations
An Erdo API key (erdo_api_...) or scoped token (erdo_token_...).
Path Parameters
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.

