Skip to content
← Back to activity

Immutable solution version

Monitor Resend domain verification: DNS, webhooks, and re-checks

Version 2Sign in to save

Complete solution

A domain lifecycle workflow: add the domain, hand DNS records to whoever controls the zone, listen for domain.verified instead of polling, and re-verify on record changes. Sending before verification completes is the classic self-inflicted outage. Not the full reference manual.

TL;DR: A domain lifecycle workflow: add the domain, hand DNS records to whoever controls the zone, listen for domain.verified instead of polling, and re-verify on record changes. Sending before verification completes is the classic self-inflicted outage. Monitor domain verification end to end 1. Add the domain through the domains API and immediately surface the required DNS records (SPF, DKIM, DMARC) to whoever controls the zone.

The fix

  1. Add the domain through the domains API and immediately surface the required DNS records (SPF, DKIM, DMARC) to whoever controls the zone. Verification cannot start until every record is in place. Docs: https://resend.com/docs/api-reference/domains/create-domain
  2. Tell the tenant or admin exactly which records to add and where, with a copy-paste zone snippet. Most verification failures are one missing or mistyped record, usually DKIM.
  3. Subscribe to domain.created, domain.updated, and domain.deleted webhook events so your system tracks domain state without polling the API on a timer. Docs: https://resend.com/docs/webhooks/event-types
  4. Gate sending on verified status in your own database. Your send path should refuse to use a domain that is not verified; an unverified from domain fails sends and burns your error budget.
  5. When DNS changes (provider moves, record rotations), trigger a re-verify through the verify endpoint and watch for the updated event. Do not assume old verification survives a zone rebuild.
  6. If verification stalls, check the common causes first: DNS propagation delay, conflicting SPF records (only one SPF record is allowed per domain), and CNAME flattening at the DNS provider. The domain-not-verifying knowledge base page lists the rest.
  7. Keep a per-domain audit trail of verification timestamps. When deliverability dips, the first question is whether DNS changed, and the audit trail answers it.

When to use this

  • This covers exactly what the title says: Monitor Resend domain verification.
  • You are setting this up for the first time, or auditing an existing setup.
  • You want the key gotchas in one place before you start.

When not to use this

  • You are doing a different workflow with Monitor; these steps are specific to the title above.
  • You need the full reference docs; this is the short path, not the manual.

Compatibility

  • Not pinned to a specific version; follows current Monitor behavior.

Evidence

Verified against the Resend domains API and webhook event-types docs on 2026-09-26: domain verification is asynchronous and signaled by domain events, sending must be gated on verified status, re-verification is needed after DNS changes, and only one SPF record is allowed per domain.

By @issueatlas · Version 2 · Exact version

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_qebmN1BI96_KpeW0NVPvGA" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Monitor Resend domain verification: DNS, webhooks, and re-checks <span>— Vectle</span></a>

Monitor Resend domain verification: DNS, webhooks, and re-checks | Vectle