Resend "domain is not verified": fix DNS records and 403 errors

What it means

Resend only sends from domains you own and have verified with DNS records. If you send from a domain that is not verified, or not verified exactly as written in your From address, the API answers with a 403 error. The message usually says that the domain is not verified and asks you to add and verify it on the Resend Domains page.

A related 403 appears when you send from the test domain resend.dev to anyone other than your own account address: the test domain only delivers to you.

On the Domains page, each domain has a status. The main ones are:

• not_started: the domain was added but you have not clicked "Verify DNS Records".
• pending: Resend is still looking for the records.
• verified: you can send.
• failed: Resend could not find the records within 72 hours.
• temporary_failure: the domain was verified, but a record has disappeared. Resend rechecks for 72 hours, then marks it failed.

Why it happens

• Records not added, or added at the wrong name. Resend's records live on names such as resend._domainkey and a sending subdomain (by default send). If your DNS panel appends your domain, entering the full name doubles it; see DNS record added at the wrong name.
• From domain mismatch. You verified updates.yourdomain.com but send from yourdomain.com, or the reverse. Each domain and subdomain is verified separately.
• The DKIM value was cut or changed when pasting (missing characters, extra quotes, line breaks).
• Records deleted later, for example during a DNS migration, which leads to temporary_failure. See email records lost after moving your DNS host.
• Not visible yet. The records were added recently.

How to check

1. In Resend, open the domain and its Records tab. Note each record's type, name and value; this is the only source of truth, because the record set can differ between domains (newer domains may get CNAME records instead of TXT and MX for SPF).
2. Check what the internet sees. For a typical setup:

   dig +short TXT resend._domainkey.yourdomain.com
   dig +short MX send.yourdomain.com
   dig +short TXT send.yourdomain.com

   Compare each answer with the Records tab.
3. Run the Delivmail domain scanner on your domain to see the published SPF, DKIM and DMARC records.
4. Compare the From domain in your code, character by character, with the verified domain name.

How to fix it

1. Add every record from the Records tab. A typical set looks like this (your values will differ, copy them from Resend):

   resend._domainkey.yourdomain.com  TXT  "p=MIGfMA0GCSqGSIb3DQEB..."
   send.yourdomain.com               MX   10 feedback-smtp.<region>.amazonses.com
   send.yourdomain.com               TXT  "v=spf1 include:amazonses.com ~all"

2. Put the MX on the send subdomain, never on the root. Adding it to yourdomain.com would send your incoming mail to Resend's bounce handler. Your existing MX records for your mailbox stay unchanged.
3. Do not merge this SPF into your root SPF. It belongs to the send subdomain, which is the Return-Path domain Resend uses. Your root SPF record is not touched.
4. On Cloudflare, keep any CNAME records as "DNS only".
5. Click Verify DNS Records in Resend. If the status is failed, fix the records and start verification again.
6. Match the From address to the verified domain, or verify the domain you actually use. Using a subdomain for a type of mail is a good practice; see email authentication for subdomains.
7. Add DMARC if your domain has none, starting with p=none; see no DMARC record on your domain.

Check that it is fixed

Wait until dig returns the expected values (from minutes to a few hours, depending on your DNS host and TTL) and the domain shows verified. Then send an email through Resend to the unique address on the Delivmail home page. The report should show DKIM passing for your domain, SPF passing on the send subdomain, and DMARC passing. Then send again to the original recipient. Keep the records in place: removing one later puts the domain in temporary_failure.