SPF, DKIM, and DMARC for Resend: complete setup guide
A complete walkthrough for authenticating Resend. Resend uses a per-domain MX + SPF TXT + DKIM TXT pattern under a sending subdomain (default: send.yourdomain). Both SPF and DKIM are set up together so DMARC aligns cleanly.
TL;DR
- 1 SPF: publish the SPF TXT record Resend gives you on the sending subdomain (send.yourdomain), plus the MX record. Do not add a Resend include to your apex.
- 2 DKIM: publish the resend._domainkey TXT record Resend shows on the sending subdomain, or mail does not align.
- 3 DMARC: start at p=none with rua, watch reports, then ramp to p=quarantine and p=reject.
What it does
This guide authenticates Resend against your domain. Resend's domain setup walks you through records on your chosen sending subdomain (default: send.yourdomain): an MX record for bounce handling (Resend runs on AWS SES under the hood), an SPF TXT record, and a DKIM TXT record (resend._domainkey.send.yourdomain). After all of them resolve and Resend verifies them, outbound mail signs with d=send.yourdomain and the envelope-from also aligns under that subdomain.
Because everything is scoped to the sending subdomain, your From: address must use that subdomain (for example hello@send.yourdomain). Sending from the apex finds no DKIM key and fails DMARC.
Step 1: Set up SPF for Resend
Resend publishes SPF on the sending subdomain, not your apex. The wizard gives you an SPF TXT record (and an MX record for bounces) to put on send.yourdomain, so SPF aligns through the subdomain your From uses.
-
1
Add the sending subdomain (send.yourdomain by default) in Resend's Domains page and let it generate the records.
-
2
Publish the SPF TXT record Resend shows on the sending subdomain, plus the MX record (priority 10 by default) for bounce handling.
-
3
Do not add include:_spf.resend.com to your apex SPF. Resend handles SPF on the sending subdomain, and an apex include is redundant and consumes a lookup.
The exact SPF value and MX host (region) are shown by Resend's wizard; copy them exactly. The sending subdomain's MX must be the only MX on that subdomain, so remove any leftover receiver MX.
Step 2: Set up DKIM for Resend
Resend uses a single DKIM record at resend._domainkey on the sending subdomain. Resend generates the key and shows you the value to publish as a TXT record, so you paste the value rather than a CNAME.
Selector: resend._domainkey, under the sending subdomain (send.yourdomain)
-
1
In Resend, go to Domains -> your domain. (Confirm the current menu path in your Resend dashboard.)
-
2
Resend shows the DKIM record value (begins with p=) for resend._domainkey.send.yourdomain.
-
3
Publish it as a TXT record at resend._domainkey.send.yourdomain with the value Resend provides.
-
4
Click Verify. Resend re-checks DNS and flips the status to verified, usually within 5 to 10 minutes.
-
5
Send a test message via the API with a From: on the sending subdomain, and verify with the DKIM checker against resend._domainkey.send.yourdomain.
Resend's DKIM is a TXT record per Resend's docs; paste the key value Resend shows. The selector and value are account-specific to your sending subdomain.
Step 3: Publish DMARC
-
1
With the MX, SPF, and DKIM records verified on the sending subdomain, publish your DMARC record at _dmarc.yourdomain. Start at p=none so receivers report but take no action.
-
2
Add a rua address to collect daily aggregate reports.
-
3
Watch the reports for a couple of weeks. Confirm Resend mail passes and aligns under the sending subdomain.
-
4
Move to p=quarantine, then p=reject once the only remaining failures are unknown or spoofed sources. See the DMARC rollout playbook for the full ramp.
Example record
Common pitfalls
-
Trying to send from the apex (hello@yourdomain) when DKIM is only set up at send.yourdomain. DKIM lookup at _domainkey at the apex finds nothing, so DMARC fails.
-
Having another MX on send.yourdomain (e.g. leftover Google Workspace MX). Resend's verification will fail until the conflict is removed.
-
Adding include:_spf.resend.com to your APEX SPF when Resend already provides SPF on the sending subdomain. Redundant and consumes a lookup.
-
Custom sending subdomain (e.g., notifications.yourdomain instead of send) requires re-running the setup wizard with the new value. Resend doesn't let you rename after verification.
FAQ
What DNS records does Resend need?▾
Records on your sending subdomain (send.yourdomain by default): an MX record for bounces, an SPF TXT record, and a DKIM TXT record at resend._domainkey. Publish all of them and click Verify; your From: must then use the sending subdomain.
Can I send from my apex domain with Resend?▾
Not without extra setup. Resend scopes DKIM and SPF to the sending subdomain, so a From: at the apex finds no DKIM key and fails DMARC. Send from send.yourdomain (or whatever sending subdomain you configured).
Do I need to add Resend to my apex SPF?▾
No. Resend publishes SPF on the sending subdomain. Adding include:_spf.resend.com to your apex is redundant and burns a DNS lookup.
Why is Resend's verification failing?▾
The usual cause is a conflicting MX on the sending subdomain (for example a leftover Google Workspace MX), or the records were published at the apex instead of under send.yourdomain. Resend's MX must be the only one on that subdomain.