Resend's DKIM selector is resend._domainkey. On classic setups it is a TXT record, not a CNAME, and its value is a public key Resend generates for your domain, so you copy the exact string from the Resend dashboard rather than typing it. When you send from a subdomain the selector shifts to match (for example resend._domainkey.mail.yourdomain.com). Newly added domains get three randomized DKIM CNAMEs instead, which is covered below. This guide walks the full set of DNS records Resend asks for, how to check them from the terminal, and why domains get stuck on Pending.
The records Resend asks for.
After you add a domain in the Resend dashboard, Resend generates a small set of DNS records and watches for them. Three carry the weight: the DKIM key, an SPF record, and a return-path MX record. The exact values are unique to your domain, so treat the table below as the shape of what you publish and copy the literal strings from the dashboard.
| Host | Type | Value shape | Purpose |
|---|---|---|---|
| resend._domainkey.yourdomain.com | TXT | The DKIM public key, copied exactly from the Resend dashboard. | DKIM. Lets receiving servers verify the message was signed by you and not altered in transit. |
| send.yourdomain.com | TXT | v=spf1 include:amazonses.com ~all | SPF. Authorizes the Amazon SES infrastructure Resend sends through to send for the send subdomain. |
| send.yourdomain.com | MX | Generated per domain in the dashboard, with the priority Resend shows. | Routes bounce and complaint processing back to Resend. |
The SPF and MX records sit on a send subdomain rather than your apex. That send label is Resend's default return path and is customizable through Resend's Custom Return Path setting, so if the dashboard shows a different subdomain, publish the records where the dashboard tells you. The MX value in particular is generated per domain, so never hardcode a host or priority you saw in someone else's guide.
New domains: three DKIM CNAMEs instead of one selector.
The single resend._domainkey TXT record this post is named for is what classic setups publish, and plenty of verified domains still run on it. Domains added more recently get a different record set: three DKIM CNAME records rather than one TXT key, each on its own randomized selector subdomain.
The shape is <random>._domainkey.yourdomain.com pointing at <the same random>.dkim.amazonses.com., repeated three times with three different random strings. That is Amazon SES Easy DKIM underneath: SES holds the key pair and hosts the public keys, and your DNS only has to point at them. It is not a downgrade or a broken setup, just a different way of publishing the same signature.
Which set you get is decided when the domain is added, so the practical rule does not change: copy the exact records your own dashboard shows. The record set is unique per domain, which means a value from another guide, an older project, or a teammate's screenshot will never verify.
Why verification stalls.
A domain that will not leave Pending is a DNS problem far more often than a Resend problem. Three causes account for most of it.
Propagation. DNS changes are not instant. Resend keeps rechecking, and there is no fixed success time to promise beyond "usually shortly after the records propagate." If Resend cannot detect the records it marks the domain Temporary Failure, and after 72 hours the status becomes Failure. That is a cue to re-check the records, not to re-add the domain.
Cloudflare proxying. If your DNS is on Cloudflare, a record set to proxied (the orange cloud) is not resolvable as a plain DNS answer, so Resend cannot read it. Switch the DKIM, SPF, and MX records to DNS only (grey cloud), or use Resend's Cloudflare integration to have the records added correctly for you.
Paste errors. Some DNS editors auto-append your domain to the host field, which turns a pasted resend._domainkey.yourdomain.com into resend._domainkey.yourdomain.com.yourdomain.com. Others wrap the value in quotes you did not intend. Paste the host and value exactly as the dashboard shows them, then confirm with a lookup rather than trusting the editor.
Check your records from the terminal.
Before you wait on Resend, confirm what the public DNS actually returns. The DKIM lookup should print the public key value, the SPF lookup should print the v=spf1 string, and the MX lookup should print the host Resend assigned.
# DKIM public key (TXT) dig +short TXT resend._domainkey.yourdomain.com # SPF for the send subdomain (TXT) dig +short TXT send.yourdomain.com # Bounce-processing MX for the send subdomain dig +short MX send.yourdomain.com
If dig is not available (it ships on macOS and most Linux distributions but not by default on Windows), nslookup asks the same questions.
nslookup -type=TXT resend._domainkey.yourdomain.com nslookup -type=TXT send.yourdomain.com nslookup -type=MX send.yourdomain.com
An empty result means the record has not propagated or is not published at the name you expect, which points straight back to the three stall causes above. A result that does not match the dashboard value means a paste error.
Where Amazon SES fits in.
Resend sends through Amazon SES under the hood, which is why the SPF value it asks for is v=spf1 include:amazonses.com ~all rather than a Resend-specific include. That detail confuses people who expect a _spf.resend.com style include, but the SES include is correct. On the classic single-selector setup, what Resend does not inherit from SES is the DKIM selector: SES has its own default selectors, and Resend signs with its own resend._domainkey selector instead, so the DKIM record you publish is Resend's. On the newer three-CNAME setup that inverts, and the keys you point at are SES's.
Add DMARC once DKIM passes.
DMARC is not required to verify a Resend domain, so do not let a missing DMARC record block you: get DKIM, SPF, and the return-path MX green first. Once they pass, adding DMARC is the right next step for deliverability. Resend surfaces it as a suggestion with a monitoring-only p=none default, which reports on alignment without affecting delivery while you confirm legitimate mail passes. For the full walkthrough of how SPF, DKIM, and DMARC fit together and how to tighten the policy over time, see SPF, DKIM, and DMARC for SaaS.
The Resend DKIM selector, answered.
What is the DKIM selector for Resend?
The selector is resend._domainkey, so the full record host is resend._domainkey.yourdomain.com. When you send from a subdomain, the selector shifts to match, for example resend._domainkey.mail.yourdomain.com. It is a TXT record whose value is a public key Resend generates for your domain, so you copy the exact value shown in the Resend dashboard rather than typing it by hand.
Is the Resend DKIM record TXT or CNAME?
On classic setups it is a TXT record: Resend publishes the public key directly, so you paste the key value into a TXT record on resend._domainkey.yourdomain.com. Copy the whole value from the dashboard without adding or removing quotes. Domains added on Resend's newer DKIM flow get three CNAME records instead, covered in the section above.
Why do I see three DKIM CNAME records instead of resend._domainkey?
Because that domain was set up on Resend's newer DKIM flow, which publishes three CNAME records on randomized selector subdomains pointing at Amazon SES Easy DKIM keys rather than one resend._domainkey TXT record. Both styles are valid, so publish exactly the set your dashboard shows for that domain and do not mix records from the two.
Why is my Resend domain stuck on Pending?
Almost always DNS. The record has not propagated yet, a Cloudflare record is set to proxied (orange cloud) so Resend cannot read it, or the value was pasted with an error such as the full hostname appearing twice or stray quotes around the key. If Resend cannot detect the records it moves the domain to Temporary Failure, and after 72 hours to Failure. Confirm each record from the terminal with dig before you assume Resend is at fault.
Does Resend use Amazon SES?
Yes. Resend sends through Amazon SES under the hood, which is why its SPF record includes amazonses.com. On the classic setup it does not use SES's own DKIM keys: Resend signs with its own resend._domainkey selector, so the DKIM record you publish is Resend's. Domains on the newer three-CNAME setup point straight at SES Easy DKIM keys instead.
Do I need DMARC to send with Resend?
No. DMARC is not required for domain verification, and Resend will verify a domain with just DKIM, SPF, and the return-path MX in place. DMARC is still worth adding once DKIM passes: Resend suggests a monitoring-only policy (p=none) to start, which lets you watch alignment reports without affecting delivery.
Once the domain reads Verified, the interesting work is what happens to the mail you send. Wiring Resend into GetFluxly turns every delivery, bounce, open, and click into an event on the customer profile, and the Resend integration guide covers the connection end to end. If you want to understand what those open and click signals actually mean before you build on them, the companion piece on Resend email analytics digs into that, and Resend webhooks covers consuming the events from your own backend.