Do I need to add an SPF include to my root domain for Resend?

No. Resend's SPF (v=spf1 include:amazonses.com ~all) goes on the send subdomain that acts as the SES envelope/return path — not your root. Because that subdomain shares your organizational domain, SPF still aligns for DMARC in relaxed mode. Adding include:amazonses.com to your root does nothing for Resend and needlessly burns one of your 10 root SPF lookups.

Resend runs on Amazon SES — do I set up SES Easy-DKIM CNAMEs?

No. Resend generates its own DKIM key and gives you a single TXT record at resend._domainkey with the public key. You never touch SES directly and you don't add SES's three CNAME selectors. Publishing that one TXT (paste it exactly) is what makes Resend sign as d=yourdomain.com.

Why is DKIM on my root but SPF and MX on the send subdomain?

They authenticate two different things. The resend DKIM selector signs with d=yourdomain.com so it strict-aligns for DMARC and survives forwarding. SPF and the feedback-smtp MX sit on send.yourdomain.com — the SES MAIL FROM/return path — and align in relaxed mode. Together you get both mechanisms aligned, which is stronger than most ESPs manage.

Should I verify my root domain or a subdomain?

Either works, but Resend recommends a dedicated sending subdomain (e.g. updates.yourdomain.com or mail.yourdomain.com) so your transactional/broadcast reputation stays off your primary domain. The records then nest under it — send.updates.yourdomain.com for SPF/MX and resend._domainkey.updates.yourdomain.com for DKIM.

My domain won't verify in Resend — what's usually wrong?

Almost always one of four things: a doubled host (your registrar appended the domain), an MX pointing at the wrong AWS region, a missing trailing dot on the MX value, or a partially pasted/re-quoted DKIM key. Confirm each record resolves with dig and matches Resend's Records tab exactly, then click Verify again — propagation can take up to 72 hours.

Does Resend create my DMARC record?

No. Resend surfaces a recommended DMARC policy but you publish it yourself at _dmarc.yourdomain.com. Keep exactly one _dmarc record per domain, start at p=none to monitor, and — because Resend gives you both aligned DKIM and aligned SPF — tighten to p=quarantine and then p=reject once the reports look clean.

Can I change my domain's AWS region later?

No — the region is fixed when you add the domain because it's baked into the feedback-smtp MX host. To move regions you delete the domain in Resend, re-add it in the new region, and update the MX (and re-verify all the records) to match. There's no in-place region switch, so pick the region closest to your recipients the first time — us-east-1 (N. Virginia), eu-west-1 (Ireland), sa-east-1 (São Paulo), or ap-northeast-1 (Tokyo).

SPF setup guide

SPF, DKIM & DMARC for Resend.

Resend is a developer-first email API, and it authenticates your domain with a small set of DNS records generated per domain — not a shared SPF line you paste. When you add a domain, Resend shows three records: a DKIM TXT at resend._domainkey (a signing key it generates for you), plus an SPF TXT and an MX record that both live on a send. subdomain acting as your return path. Under the hood Resend runs on Amazon SES, but it hides SES's Easy-DKIM CNAMEs behind its own single DKIM key. Once those three records resolve, Resend signs mail as your own domain — DKIM strict-aligns to d=yourdomain.com, SPF relax-aligns via the send subdomain, and DMARC passes on both.

Per-account authentication

Your DNSAdd the CNAME / TXT records

ResendSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Resend?

Authenticating your Resend domain is the difference between the inbox and the spam folder — and until you do it, you can only send from Resend's shared onboarding@resend.dev test domain, which isn't yours at all. Since February 2024, Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft began enforcing the same on high-volume mail into Outlook/Hotmail in 2025. Resend is typically wired into the exact mail those rules judge most harshly — password resets, receipts, verification codes, and increasingly marketing broadcasts — where a single trip to spam breaks a signup flow. Resend makes this unusually clean: because it puts the SPF/return path on a send. subdomain of YOUR domain (rather than owning a bounce domain the way Mailchimp or SendGrid's legacy setup does), SPF actually aligns in relaxed mode, and the resend DKIM selector signs as your own domain so DKIM aligns strictly. Publish the records and a Resend domain passes DMARC on both mechanisms — the resilient setup that survives forwarding. Skip them and mail either goes out as resend.dev or is unauthenticated, with reputation pooled on shared infrastructure.

The SPF reality for Resend

Resend is a per-account provider built on Amazon SES, so there is NO shared include for your root domain — and that's by design. When you add a domain, Resend provisions a send. subdomain (the SES custom MAIL FROM / envelope domain) and puts the SPF record there: send.yourdomain.com gets v=spf1 include:amazonses.com ~all, and the matching MX (feedback-smtp.{region}.amazonses.com) catches bounces and complaints. Your root domain's SPF is never touched — Resend adds ZERO DNS lookups to it. Two things make this better than most ESPs. First, because the return path is a subdomain of your own domain rather than a Resend-owned bounce domain, SPF aligns for DMARC in relaxed mode (send.yourdomain.com shares the organizational domain yourdomain.com). Second, Resend does not use SES's three CNAME Easy-DKIM selectors — it generates its own DKIM key and publishes a single TXT at resend._domainkey.yourdomain.com, signing with d=yourdomain.com, so DKIM aligns strictly. So the reality is: nothing goes on your root SPF, the include:amazonses.com you see belongs only on the send subdomain, and DKIM (not a root include) is what carries the strongest alignment. If an old tutorial tells you to add include:amazonses.com to your root, ignore it — it does nothing for Resend, burns one of your root's 10 SPF lookups, and needlessly authorizes all of SES to send as your apex.

Step by step

In Resend

1
Add your domain (and pick a region)
Log in at resend.com, open Domains in the left nav, and click Add Domain. Enter your sending domain — either your apex (yourdomain.com) or, better, a dedicated sending subdomain like updates.yourdomain.com — then choose the AWS region closest to your users (N. Virginia us-east-1, Ireland eu-west-1, São Paulo sa-east-1, or Tokyo ap-northeast-1). The region is baked into the MX host and can't be changed later without deleting and re-adding the domain, so pick deliberately.
2
Open the Records tab
Resend generates the DNS records for you and lists them under the domain's Records/DNS tab: one DKIM TXT (resend._domainkey), one SPF TXT on the send subdomain, and one MX on the send subdomain. If you already run a service on send.yourdomain.com, use the Custom Return Path option to choose a different subdomain before you copy the records.

In your DNS

3
Add the DKIM TXT record
At your DNS host create a TXT record with host resend._domainkey and the long public-key value Resend shows (starting with p=). This is the record that strict-aligns your mail to d=yourdomain.com, so paste the value exactly — a partially pasted or re-quoted key is the single most common reason a correct-looking domain still fails DKIM. Note it sits at the selector on your root (or sending subdomain), not under send.
4
Add the SPF TXT on the send subdomain
Create a TXT record with host send (i.e. send.yourdomain.com) and value v=spf1 include:amazonses.com ~all. This authorizes the SES envelope for the return path — leave your root SPF alone and do NOT add include:amazonses.com to it. If your registrar auto-appends the domain, enter just send, not send.yourdomain.com.
5
Add the MX record on the send subdomain
Create an MX record with host send, priority 10, and value feedback-smtp.{region}.amazonses.com matching the region you chose (e.g. feedback-smtp.us-east-1.amazonses.com). Add a trailing dot to the value so your registrar doesn't append your domain to it. This MX only receives SES bounce/complaint feedback — it does not change where your normal inbound mail is delivered.
6
Publish a DMARC record
Resend recommends a DMARC policy but doesn't create it for you. Add a TXT record at host _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so nothing about delivery changes while you confirm alignment. Keep exactly one _dmarc record per domain.

Verify

7
Click Verify DNS Records
Back in Resend, click Verify DNS Records. Propagation is usually minutes but can take up to 72 hours; the status flips to Verified once all three records resolve. If it stalls, re-check for a doubled host, a region-mismatched MX, or a missing trailing dot, then verify again.
8
Send a real test and read the headers
Verified in the dashboard isn't proof mail is aligned. Send a message from an address on your verified domain (not @resend.dev) to a Gmail account, open it, and choose ⋮ → Show original. You want SPF: PASS (mailed-by a send.yourdomain.com host), DKIM: PASS with signed-by: yourdomain.com and selector resend, and DMARC: PASS — all pointing at your domain, not resend.dev or amazonses.com.

Records to add

Resend generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
TXT	resend._domainkey	p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…(long public key from Resend)DKIM public key, selector resend, on your root/sending domain — this strict-aligns mail to d=yourdomain.com. Illustrative; the real 1024-bit key is generated per domain and displayed as a single p=… string (no v=DKIM1 prefix) — paste it exactly as shown.
TXT	send	v=spf1 include:amazonses.com ~allSPF for the send subdomain (the SES envelope / MAIL FROM). Lives on send.yourdomain.com, NOT your root — don't add include:amazonses.com to your apex SPF.
MX	send	feedback-smtp.us-east-1.amazonses.comReturn path for SES bounces/complaints — priority 10, on the send subdomain, with a trailing dot. Region-specific: the region matches the one you picked when adding the domain (us-east-1 / eu-west-1 / sa-east-1 / ap-northeast-1).
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYou add this yourself — Resend surfaces a recommended policy but never writes it to DNS. One per domain; start at p=none, then tighten.

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Resend's setup costs against that budget.

SPF 10-lookup budget0 used · 10 free

Resend's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.

DKIM

DKIM is the most important record in a Resend setup, and it's where Resend quietly diverges from raw Amazon SES. Even though Resend runs on SES, it does NOT hand you SES's three Easy-DKIM CNAME selectors. Instead Resend generates its own DKIM key pair per domain and gives you a single TXT record: host resend._domainkey.yourdomain.com, value the public key (a p=… string it displays in the Records tab), selector resend. Resend holds the matching private key and signs every message with d=yourdomain.com; s=resend. Because that d= is your own domain — not amazonses.com and not a Resend-owned domain — DKIM aligns strictly for DMARC, and it keeps passing even when a message is forwarded (which is exactly when SPF tends to break). Two practical notes. First, this is a TXT record you publish, not a CNAME delegation, so Resend can't silently rotate the key the way CNAME providers do — if you ever rotate, you re-publish the new value. Second, paste the value exactly as Resend shows it. Because Resend signs with a 1024-bit key, the p= value is a single ~216-character string that fits under DNS's 255-character-per-string TXT limit — so, unlike the longer 2048-bit keys some providers hand you, it is NOT split across multiple quoted strings; paste it as one unbroken value. A partial copy, an inserted space, or an extra pair of quotes your DNS panel wraps around the string is the number-one cause of a domain that looks configured but still fails a DKIM check. The DKIM record sits at the selector on your root (or on your sending subdomain) — not under the send subdomain where SPF and the MX live.

DMARC

DMARC is a separate policy record that Resend recommends but does not create for you — you add it at your DNS host. Publish a TXT record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only: it changes nothing about delivery but tells receivers to email you aggregate (rua) reports so you can confirm Resend mail is passing SPF and DKIM aligned to your domain. Resend is well-behaved here — you get relaxed SPF alignment via the send subdomain AND strict DKIM alignment via the resend selector — so you should see clean DMARC passes almost immediately, and you can safely add adkim=s (strict DKIM alignment) if you want, since d=yourdomain.com matches your From domain exactly. Watch the reports for a week or two, make sure every legitimate sender (Resend plus any mailbox host or other tools) is authenticating, then ramp the policy from p=none to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole organizational domain no matter how many senders you run — never add a second DMARC record just for Resend.

Check it actually worked

Don't trust Resend's green Verified badge alone — it only means the three records resolved, not that a real message aligns. Send a test from an address on your verified domain (for example no-reply@yourdomain.com, NOT anything @resend.dev) to a Gmail account, open it, and choose ⋮ → Show original. You want SPF: PASS with mailed-by showing a send.yourdomain.com host, DKIM: PASS with signed-by: yourdomain.com and selector resend, and DMARC: PASS — all attributed to your domain rather than resend.dev or amazonses.com. If DKIM shows as your domain but SPF shows amazonses.com without aligning, check that the send subdomain records are in place. You can spot-check the raw records with dig TXT resend._domainkey.yourdomain.com, dig TXT send.yourdomain.com, and dig MX send.yourdomain.com. Finally, run the domain through Qualisend's domain health check to confirm every record resolves and your root SPF stays under the 10-lookup limit, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — Resend/Amazon SES should show up as an aligned, passing source.

Domain health check DMARC report analyzer

Common gotchas

Coverage
Resend's records live on the send subdomain, not your root. Registrars that auto-append the domain turn send into send.yourdomain.com.yourdomain.com and resend._domainkey into a doubled host — enter just the labels (send, resend._domainkey) and let the panel add the domain.
Coverage
The MX value is region-specific and must match the region you picked when adding the domain. An eu-west-1 domain with a us-east-1 feedback-smtp MX won't verify — and you can't change a domain's region after creating it; delete and re-add it in the new region, then update the MX.
Coverage
Add a trailing dot to the MX value (feedback-smtp.{region}.amazonses.com.) so your registrar doesn't append your domain and produce feedback-smtp.us-east-1.amazonses.com.yourdomain.com.
Breaks auth
Don't add include:amazonses.com to your ROOT SPF. Resend's SPF belongs on the send subdomain; a root include does nothing for Resend, wastes one of your 10 root SPF lookups, and authorizes all of Amazon SES to send as your apex.
DNS setup
Resend is built on SES but does NOT use SES's three Easy-DKIM CNAMEs — it publishes one DKIM TXT (selector resend) that it generates. Don't hunt for CNAME selectors; paste the single TXT key exactly, since a partially pasted or re-quoted key is the top reason DKIM still fails on a 'configured' domain. It's a 1024-bit key, so the value fits in one string — don't split it.
Coverage
The shared @resend.dev addresses (onboarding@resend.dev, delivered@resend.dev, etc.) are for trying the API only — they are not your domain and give you zero SPF/DKIM alignment. You must add and verify your own domain to send as yourself.
DNS setup
These are TXT and MX records, not CNAMEs, so there's no Cloudflare orange-cloud proxy trap — but if Cloudflare already auto-created an SPF on your root, leave it alone; Resend's SPF is separate and lives on the send subdomain.
Coverage
If you already run mail or a service on send.yourdomain.com (an existing SPF, MX, or subdomain), use Resend's Custom Return Path feature to pick a different return-path subdomain instead of colliding with what's there.

Build your SPF record

Resend doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.

Sending sources

Search for each platform you send email through and tick it.

Search for your email platform above, or .

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list