Websites
Verify Sending Domain
Run a fresh SPF, DKIM, and MAIL FROM verification
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 inwebsite.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.