DMARC for Resend: subdomain-based DKIM with mandatory SPF
Resend uses a per-domain MX + TXT + DKIM CNAME pattern under a sending subdomain (default: send.yourdomain). Both SPF and DKIM must be set up for DMARC to align cleanly.
TL;DR
- 1 Three records: MX on the sending subdomain, SPF TXT, DKIM CNAME.
- 2 Default sending subdomain is send.yourdomain — you can change it.
- 3 Resend's MX has to be the only MX on the subdomain (no co-existing receiver).
What it does
Resend's domain setup walks you through three records on your chosen sending subdomain (default: send.yourdomain): an MX record pointing to feedback-smtp.us-east-1.amazonses.com (Resend runs on AWS SES under the hood), an SPF TXT record listing Amazon's SES IPs, and a DKIM CNAME (resend._domainkey.send.yourdomain → resend._domainkey.resend.com). After all three resolve and Resend verifies them, outbound mail signs with d=send.yourdomain and the envelope-from also aligns under that subdomain.
How it works
-
1
In Resend: Domains → Add Domain → enter yourdomain.com.
-
2
Resend displays the three DNS records to publish on send.yourdomain (the default sending subdomain).
-
3
Publish all three. Note the MX has priority 10 by default.
-
4
Click Verify. Resend re-checks DNS; status flips to Verified usually within 5-10 min.
-
5
Send a test message via the API. From: must use the sending subdomain (e.g., hello@send.yourdomain).
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 — 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.