domains

GET /v1/domains/{domainId}/email-routing

Read a domain's inbound email routing, and what enabling it would cost.

All domains endpoints

Authentication

Send an API key as a bearer token. The key must carry the sites.view permission; a key without it is refused with 403, not 404.

This endpoint takes no organisation id. Your key already identifies the organisation it belongs to, and the response is scoped to it.

Try it

Replace anything in angle brackets with your own values, and the key placeholder with a key from your dashboard.

curl -X GET https://api.zinndigital.com/v1/domains/{domainId}/email-routing \
  -H "Authorization: Bearer zdk_live_…"

Signed in? The API console in your dashboard fills in your real organisation id and your own key, and runs the request against the live API so you can see the actual response. Open this endpoint in the API console

Details

Cloudflare Email Routing on the customer's **own** account: whether it is on, the forwarding rules, the catch-all, the verified destination addresses, and the DNS the provider would publish to make it work. Scoped to the domain rather than a site, because routing is a **zone-level** feature — one switch and one rule set per zone however many sites hang off it. `impact` is the important field. Email Routing's DNS plan is **apex-only**: turning it on republishes the apex `MX` set *and* an apex SPF `TXT`, so a domain whose mail is at Google Workspace or Microsoft 365 would lose it. `impact` compares the provider's own published plan against the zone's live records on every read, so what the customer is warned about and what the enable endpoint refuses are the same value and cannot drift. `impact.zone_unreadable` is reported separately from `impact.safe` because "we could not read your DNS" and "your domain already receives mail elsewhere" are both unsafe and need completely different copy. `addresses_readable` is likewise separate from an empty `addresses` list: a credential may legitimately lack the account-level scope, and "we could not look" must not render as "there are none". `rules_readable` is the same distinction for the forwarding rules, which sit behind a **different** Cloudflare permission again — so a partially-scoped token returns a usable `status`, `plan` and `impact` with the rule list honestly marked unreadable, rather than failing the whole read. Requires `sites.view`. ⛔ A credential that lacks a required scope answers **422**, never 503: a permission gap is the one failure a retry can never clear, and telling a customer to "try again shortly" sends them round a loop with no exit (D16780).

Parameters

NameTypeRequiredWhat it is
domainId (path)UuidYesThe domain's id.

Response

NameTypeRequiredWhat it is
domain_idUuidYesUUIDv7 identifier — sortable by creation time (docs/02 §8).
fqdnstringYes
supportedbooleanYes
enabledbooleanYes
statusstringYesThe provider's own word for the zone's state. Displayed, never branched on.
dns_readybooleanYesWhether the provider reports the required DNS actually live. Distinct from `enabled` — a zone can be switched on with its `MX` not yet resolving.
planDomainEmailRoutingDnsRecord[]Yes
rulesDomainEmailRoutingRule[]Yes
catch_allDomainEmailRoutingRuleYes
addressesDomainEmailRoutingAddress[]Yes
addresses_readablebooleanYes`false` when the credential could not list destination addresses — a scope a customer's own token may legitimately lack. Separate from an empty `addresses` list, because an empt…
rules_readablebooleanYes`false` when the credential could not list the forwarding rules. `Zone → Email Routing Rules` is a **separate** Cloudflare permission from the one that reads the zone's routing…
status_readablebooleanYes`false` when the credential could not read the zone's routing **settings** — the half that supplies `enabled`, `status`, `dns_ready` and `plan`. On Cloudflare this is a differen…
impactDomainEmailRoutingImpactYesWhat turning routing on would replace, measured against the zone's live records.

Errors this endpoint can return

401 · 403 · 404 · 422 · 429 · 503