How to Set Up DKIM and DMARC for Resend
To authenticate email from Resend, add three DNS records: the DKIM TXT record from your Resend dashboard (published at resend._domainkey.yourdomain.com), an SPF TXT record including amazonses.com, and a DMARC TXT record at _dmarc.yourdomain.com. Resend's domain verification flow checks DKIM once you publish its records; SPF and DMARC require manual entries. If you're configuring email from scratch, our email setup guide for new SaaS frames where each of these pieces fits.
Domain verification in Resend
Log into your Resend dashboard and go to Domains. Add a new domain and enter the one you'll send from (e.g., mail.myapp.com or your main domain myapp.com). Resend will show you the DNS records to add:
- A DKIM TXT record at
resend._domainkey.yourdomain.comcontaining your public key - A Return-Path record (MX or CNAME) for bounce handling and SPF alignment
Copy each record exactly as your dashboard shows it and add it to your DNS provider (Route53, Cloudflare, Namecheap, etc.). If you want to understand what the DKIM record actually does, see our explainer on what DKIM is. Wait for DNS propagation (usually <5 minutes), then click Verify in Resend. The dashboard will check the records and confirm the domain is live. The full record set is documented in our Resend vendor setup guide.
Add your SPF record
Resend uses Amazon SES infrastructure, so your SPF record includes amazonses.com. Add this to your domain's DNS:
v=spf1 include:amazonses.com ~all
If you have other mail services on the same domain (e.g., transactional from Resend, team email from Google Workspace), combine them:
v=spf1 include:amazonses.com include:_spf.google.com ~all
The ~all at the end is a soft fail: messages fail SPF but still deliver. Once you're confident all authorized senders are listed, change it to -all (hard fail).
Wait 5–15 minutes for the record to propagate. Use the SPF Record Checker to verify it's live and parseable.
The resend selector, and why amazonses.com is all over your DNS
Two things about a Resend setup confuse almost everyone the first time.
First, the selector. Resend signs with the selector resend, so your DKIM record lives at resend._domainkey.yourdomain.com. When a receiver verifies a signature, it looks up exactly that name. If you published the record under a different name, or your DNS provider silently appended your domain to a name that already included it, verification fails even though the key itself is correct.
Second, amazonses.com. It appears in your SPF include and in your Return-Path record because Resend runs on Amazon SES infrastructure. Seeing Amazon's domain in your DNS makes people worry their mail will authenticate as Amazon's instead of their own. It won't. Those records describe where the mail physically comes from; the DKIM signature carries your domain. Check any delivered Resend message and you'll find:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=yourdomain.com; s=resend;
h=from:to:subject:date:message-id; bh=...; b=...
d=yourdomain.com is what DMARC aligns against, and s=resend is the selector pointing at your published key. The amazonses.com entries never enter the alignment check.
To confirm yours looks like this, check the Authentication-Results header of a test message for dkim=pass header.d=yourdomain.com header.s=resend. That combination means signing and alignment are both yours.
If you instead see d=amazonses.com in the signature, the message was signed with Amazon's key rather than your domain's key. That happens when the sending domain isn't verified in Resend, so SES falls back to signing as itself. The message may still show dkim=pass, but DMARC fails because amazonses.com doesn't align with your From domain. The fix is to finish domain verification: publish the resend._domainkey record and wait for the dashboard to confirm it.
Create a DMARC record
DMARC is the policy layer on top of SPF and DKIM. You don't have to set a policy to benefit from reports. Start with p=none to monitor alignment without rejecting anything.
Add a TXT record at _dmarc.mail.myapp.com (or _dmarc.myapp.com if you're not using a subdomain). Use the DMARC Record Generator if you want to build the record interactively:
v=DMARC1; p=none; rua=mailto:reports@yourdomain.com
The three parts:
v=DMARC1: DMARC version (always this)p=none: monitor only; don't reject failing messagesrua=mailto:: where to send aggregate reports (optional, but see the next section)
If you're not ready to set up report collection yet, use:
v=DMARC1; p=none
Verify the record with the DMARC Record Checker.
Point reports to DMARCdrift
To get a digest email of your alignment and spoofing signals, change your rua= address:
v=DMARC1; p=none; rua=mailto:d-[your-domain-id]@in.dmarcdrift.com
You'll find your domain ID in your DMARCdrift dashboard under Domain Settings. Once the record is live, aggregate reports from mailbox providers (Gmail, Yahoo, etc.) will route to dmarcdrift. The first batch of reports arrives within 24–48 hours; timing depends on when providers generate and send them.
Verify alignment
After SPF and DKIM are live, send a test email to yourself and check the headers. Open the email in a mail client that shows raw headers (Gmail: More actions → View message source).
Look for the Authentication-Results header. You should see:
Authentication-Results: mx.google.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) ...
dkim=pass ...
spf=pass ...
If you see dmarc=fail, check:
- Does the
From:domain match your DMARC domain? (If you're sending fromnoreply@mail.myapp.com, your DMARC record must be at_dmarc.mail.myapp.com.) - Is SPF passing? Check that the sending IP is listed in your SPF record (it will be if you've added
include:amazonses.com). - Is DKIM signing? Resend adds a
DKIM-Signatureheader. If it's missing, theresend._domainkeyrecord might not have propagated yet.
Use the Email Header Analyzer to decode the full header and spot any misalignment.
Next steps
Once your domain passes authentication, change your DMARC policy to p=quarantine or p=reject when you're confident no legitimate mail is failing. But start with p=none and monitor reports first. That's what most developers do, and what DMARCdrift is built for.
Once your DMARC record is live, aggregate reports will start arriving within 24–48 hours. DMARCdrift turns the XML into a readable digest, free for one domain.