Skip to main content
POST
Verify Sending Domain
Run the sending-domain DNS verification pipeline immediately and return DNS status separately from sending readiness. verified is the fresh DNS verdict. The company tracking domain is never part of it; this check also rechecks the tracking domain without letting it affect the domain. readyToSend additionally requires the domain to finish activating for sending. message reports both: when DNS is verified but activation is still running, it says so instead of claiming the domain can send. This endpoint uses the same verification process as the dashboard and updates the stored status.

Custom reply DNS recovery

Reply routing is separate from sending readiness. Once a legacy reply domain’s MX verifies, this endpoint prepares any additional ownership TXT record in website.dnsRecords.inboundVerificationRecord (name and value). The value is a public DNS token, not an API credential. Publish it at the returned fully qualified name and call this endpoint again after DNS propagation. A pending verification returns HTTP 200 with inboundRoutingStatus: "failed" and a retry instruction in inboundRoutingError; it does not make a verified sending domain unable to send. inboundVerificationStatus reports ownership only. Use inboundRoutingStatus: "active" to confirm the stored routing checks passed. Missing MX leaves routing pending. Provider lookup/preparation errors can be retried with this same endpoint. An inconclusive ownership lookup preserves an existing active route and records an error rather than discarding accepted replies. Previously confirmed ownership remains verified; an unchecked legacy SES route still displays pending until its first successful ownership check. discarded: true means a concurrent update superseded this check; read the current website or retry before acting on stale results. Repeated checks reuse a pending token. Expired verification is restarted and the current returned token is authoritative. Already-sent reply addresses and their MX remain unchanged. A required TXT stays available after verification; an unnecessary pending TXT instruction disappears when a parent verifies. These generated fields are read-only: no request parameter sets, clears, or replaces them. A missing record alone does not prove routing is ready; its preparation may not have run or may have failed. CLI: sequenzy websites verify mail.example.com --company comp_123. MCP: verify_sending_domain. Both return the same records and retry status.

Request

string
required
Configured sending domain.

Responses