Questions · Updated 2026-09-28

How long does domain verification take?

Domain verification takes as long as your DNS provider takes to publish the records, because each check is a DNS read. The server keeps checking on its own inside the window the catalogue names, POST /domains/{id}/verify re-checks now, and GET /domains/{id}/wait long-polls until the status settles.

Domain verification takes as long as your DNS provider takes to publish the records, and no longer. Each check is a DNS read, so Domains and DNS says it "is only as fast as your registrar's propagation — minutes usually, longer if your TTLs are long." You do not have to ask twice: the catalogue fix for domain_not_verified says "checks continue for 72 hours." POST /domains/{id}/verify re-checks now, and GET /domains/{id}/wait long-polls until the status is verified or failed.

What sets the clock

Your provider's publish time comes first. Providers publish on their own schedule; the Namecheap page quotes that provider's own article on how long a new host record normally takes, and the GoDaddy, Google Domains, Hostinger and Route 53 pages quote theirs.

TTL comes second. Every row on GET /domains/{id}/setup carries ttl, the TTL the zone file uses for that record. A resolver that already looked a name up and found nothing keeps that empty answer until the TTL it was given runs out, so a record published after a failed lookup can appear later from where we check than from your own machine.

Our cadence comes last. After POST /domains or POST /domains/{id}/verify, the server checks on a schedule of its own and the wait reply says when. The MCP tool wait_for_domain describes the same reply: "Returns: status, next_poll_seconds (when the server will check again), deadline (when the 72-hour window closes), reason, and progress (required_verified of required_total)." A verify call restarts that schedule from the top, which is the right move the moment a record is published, and the wrong one before.

curl -sS -X GET https://api.agentisend.com/domains/9c8f8f0e-3d1a-4d3f-9a1e-2b7c1a0f5e42/wait \
  -H "Authorization: Bearer $AGENTISEND_API_KEY"
200
{
  "deadline": "string",
  "id": "9c8f8f0e-3d1a-4d3f-9a1e-2b7c1a0f5e42",
  "name": "yourdomain.com",
  "next_poll_seconds": 1,
  "progress": {},
  "reason": "ok",
  "status": "pending"
}
Response

Reading where it is

checked_at on each row of GET /domains/{id} is when we last looked at that record; it is null before the first check. status per row says what that look found. recent_events on the same response, and the full list on GET /domains/{id}/events, carry one sentence per step: "DNS checked for the first time.", "The DKIM record was found.", "The return-path MX record was found.", "Domain verified." A required row that answers with the wrong value shows observed, and Why did my domain verification fail? reads that row.

Once the domain is verified, checking does not stop. The notification that opens then says "Checks continue every 6 hours in case a record is removed." A record that later disappears demotes the domain, and How do I get notified when domain verification breaks? is how you hear.

Once the domain is failed, checking does stop until you call POST /domains/{id}/verify. The catalogue fix says that reopens the window.

Sending before it is done

Two sends work while you wait. An address ending in @simulator.agentisend.com is accepted from any well-formed From, costs nothing and reaches nobody. And the POST /emails summary says "Before a domain is verified, from onboarding@agentisend.com delivers only to this account's member sign-in addresses (20 per UTC day, no cc/bcc/attachments/tracking/extra headers)." Any other From on an unverified domain answers domain_not_verified.

Next