Setting Up Resend: The DNS Mistakes We Actually See

Adding a domain to Resend means publishing a handful of DNS records, and Resend's dashboard tells you, record by record, whether each one verified. When one doesn't, the cause is almost always one of a few repeat mistakes. We scan a lot of domains that send through Resend, and the same ones keep turning up.

This post goes through them: what each mistake looks like in DNS, whether it actually breaks your mail, and how to check for it yourself. Then come the records that look wrong and aren't, because a few of Resend's records surprise people who are used to other providers.

Every name below is relative to the domain you added in Resend. We use example.com. If you added updates.example.com, as Resend recommends ("We recommend sending your emails from one or more subdomains"), everything moves under it: the return path becomes send.updates.example.com, and so on.

What a Resend domain publishes

The return path is where the variety is. Depending on when your domain was created, Resend's verification guide shows one of two shapes. Older domains get an MX record and an SPF TXT record at send.example.com. Domains created after August 2026 "may show CNAME records instead": two of them, one at your return-path name and one at an r-prefixed sibling, rsend.example.com. Domains that activated Resend Forge later keep their old records and add one CNAME at a new name. Always go by your domain's Records tab, not by a guide.

Why the return path matters so much: SPF doesn't check the address in the From line. It checks the envelope sender, the bounce address (RFC 7208 §2.4). For Resend mail, that's an address at send.example.com. So that's the name whose SPF record counts, and the record at your root plays no part in it.

1. The return-path SPF record went on the root

This one applies to domains whose Records tab shows an MX and an SPF TXT record for send. Resend's verification guide lists it among its checks: verify "that the records are added at the correct location (the send subdomain, not the root domain)". It's an easy slip, because the value, v=spf1 include:amazonses.com ~all, looks exactly like a root SPF record.

At the root, the include does nothing for Resend mail. Resend's return path is send.example.com, so a receiver checking SPF for a Resend message never reads your root record. Amazon's own documentation for its email service, which Resend's MX values point at, says the same thing from the other side: a custom bounce domain "has to be a subdomain of the parent domain of a verified identity" (AWS SES, custom MAIL FROM domain). Your root is never that subdomain.

And send.example.com is still missing its SPF record, so Resend's SPF check won't verify.

What it does to your other mail depends on how the record landed:

• Merged into your existing root SPF record. Mostly harmless. SPF allows ten DNS-querying terms per evaluation (RFC 7208 §4.6.4), and an evaluation that reaches the include spends at least one of them on it. On a record already close to the limit, that can be the one that tips it into permerror. If something else sends with your root domain as its return path through Amazon's servers, that's the one case where the include does work, so check before removing it.
• Added as a second record beside your existing one. Two v=spf1 records at one name is a permerror for every message checked there (RFC 7208 §4.5). If your mailbox provider, Google Workspace say, uses your root as its return path, its SPF result is now an error.
• Replaced your existing record. Now the root authorizes only the servers include:amazonses.com covers. Mail your mailbox provider sends with your root return path no longer passes SPF. With the ~all shown above it gets softfail rather than fail, but DMARC only counts a pass, so for DMARC the two are the same.

How to check:

dig +short TXT send.example.com
dig +short TXT example.com

The first should show the SPF TXT value from your Records tab. The second, if you have a root SPF record at all, should show exactly one v=spf1 record, listing only the services that use your root as their return path. Resend doesn't need anything there.

2. The return path is half built

On older domains the return path is two records at one name, and Resend's guide is explicit: "both must be correct for SPF to verify at all." The three half-built versions we see:

• The MX without the SPF TXT. Often the TXT went to the root (mistake 1).
• The SPF TXT without the MX. The MX is the one people skip, because "MX" sounds like incoming mail and they don't want to touch their mailbox. This MX is only for bounces: Resend's MX guide uses it "to establish a return-path for bounce/complaint reports from Inbox Providers," and Amazon's requires it "so that your domain can receive the bounce and complaint notifications that email providers send you."
• The MX value entered as a TXT record. The record exists at the right name with the right text, so it looks done, but it's the wrong type. A receiver asking for an MX gets nothing.

On CNAME-shaped domains the pair is send and rsend, and Resend verifies each on its own. Miss one and your domain shows as partially_verified. You can still send, Resend explains, "but without a fallback sending server."

How to check:

dig +short MX send.example.com
dig +short TXT send.example.com

For CNAME-shaped domains:

dig +short CNAME send.example.com
dig +short CNAME rsend.example.com

Each should return exactly the value in your Records tab. If one comes back empty, run it again without +short and look at the status: line. NOERROR or NXDOMAIN with no answer means the record isn't there as that type. SERVFAIL or REFUSED means the lookup itself failed, which says nothing about the record.

3. Your DNS host appended your domain

Many DNS panels treat any value that doesn't end in a dot as relative to your zone and quietly add your domain to the end. That's standard zone-file behavior: a name without a trailing dot is "relative," and "the actual domain name is the concatenation of the relative part with an origin" (RFC 1035 §5.1). So the MX you typed as

feedback-smtp.us-east-1.amazonses.com

gets published as

feedback-smtp.us-east-1.amazonses.com.example.com

which names a server inside your own domain instead of Amazon's. Resend's guide covers it, and the fix is to add a trailing dot to the value: feedback-smtp.us-east-1.amazonses.com. The same applies to the CNAME values on newer domains.

The name field has the same trap in reverse. Many panels add your domain to the name you type, which is why Resend's Cloudflare guide says to paste only send, not send.example.com. Whatever your panel does, check that the saved record's full name is send.example.com, not send.example.com.example.com.

How to check: look at what dig +short MX send.example.com returns. If the value ends in your own domain name, it was appended.

4. The receiving MX is fighting your mailbox

This one only matters if you use Resend to receive mail. When a domain has more than one MX record, senders try the lowest preference number first, and move on to higher numbers only when delivery there doesn't succeed (RFC 5321 §5.1). Records with equal preference are tried in random order. So an MX set that names both your mailbox provider and Resend's receiving endpoint never delivers a message to both. With different numbers, the lower one normally gets all of the mail and the other gets none. With the same number, each message lands on one or the other, unpredictably.

Resend's receiving guide says so plainly: "you will not receive emails at Resend if the required MX record is not the lowest priority value for the domain." Put Resend's MX at the lowest number instead and your mailbox stops receiving. Its recommendation is to receive at a subdomain, inbound.example.com say, and leave your root MX alone. If you need both on one name, the guide describes forwarding from your mailbox provider to an address on a Resend-verified receiving domain.

This is separate from the return-path MX in mistake 2. That one lives at send.example.com, and "MX records only impact the subdomain they are associated to," so it can't affect your mailbox.

How to check: dig +short MX example.com lists each MX with its preference number. If your mailbox provider and Resend both appear at one name, decide which one should receive there, or move Resend to a subdomain.

5. Looking for the return path in the wrong place

Most guides, checklists and support answers assume send.example.com. Yours may not be there, and that's fine:

• You picked a custom label. Resend lets you choose the return-path name when you add the domain, bounce or outbound say. The records then live at bounce.example.com, and on CNAME-shaped domains at rbounce.example.com too.
• You verified a subdomain. Verify updates.example.com and the return path is send.updates.example.com, not send.example.com.
• You activated Forge. Forge "uses a new subdomain as the Return-Path (e.g. mail.yourdomain.com)," with one CNAME there. Your old send records stay: "Your existing DNS records stay untouched. Don't remove them."

So before concluding the return path is missing, find your actual label in the Records tab and check that name. The label is fixed when the domain is created. Resend's docs say changing it means deleting the domain and adding it again (activating Forge is the exception, since it sets up its own new name). If the domain has a tracking subdomain, read Resend's tracking guide before deleting it: removing the domain removes the tracking proxy too, which breaks the links in mail you've already sent.

6. Cloudflare's proxy is on

If your Resend records include CNAMEs, they must be DNS only on Cloudflare: the gray cloud, not the orange one. Resend warns about this on several pages: "Proxied records don't resolve as CNAMEs, so verification will fail." Cloudflare's proxy is built for websites. It answers with its own addresses instead of the CNAME, and Resend's verification looks for the CNAME.

How to check: dig +short CNAME send.example.com (or your label) should print the host from your Records tab. If it prints nothing, open the record in Cloudflare and confirm that it's a CNAME, that its target matches, and that it's set to DNS only.

7. An SPF include Resend doesn't publish

Some root SPF records carry include:_spf.resend.com or include:spf.resend.com. The shape is familiar, since other providers do publish includes like it (Google's is include:_spf.google.com), but Resend doesn't give one. Neither name publishes an SPF record; both return NXDOMAIN (checked November 5, 2026).

That makes the include an error, not a no-op. An include whose target has no SPF record is a permerror for any evaluation that reaches it (RFC 7208 §5.2). Evaluation runs left to right and stops at the first mechanism that matches, returning that mechanism's result (§4.6.2). So mail authorized by an earlier mechanism still passes, and any evaluation that reaches the broken include gets permerror instead of continuing to your all. Where the made-up include is the record's only term, every SPF check at your root ends that way.

It wouldn't help Resend's mail even if the name existed, for the reason in mistake 1: Resend's SPF is checked at your return path, not your root.

How to check: look for resend.com in dig +short TXT example.com. If it's there, remove that include from your root SPF record and keep its other terms. Then make sure every return-path record in your Records tab is published: an MX and an SPF TXT record, or CNAMEs, depending on your domain.

8. A CNAME on a name that already has records

Newer domains and Forge put a CNAME at the return-path name. A CNAME can't share its name with other records: "If a CNAME RR is present at a node, no other data should be present" (RFC 1034 §3.6.2). Resend's verification guide puts it the same way: "A CNAME record can't co-exist with any other record on the same subdomain."

Most DNS hosts refuse to save the CNAME then. Some accept it, and the name ends up answering with its old TXT and MX records for some lookups and the CNAME for others. An SPF check asks for TXT, so it can get the old record instead of the one behind the CNAME.

Resend's guide gives two fixes: remove the existing records from that name, or use a different return-path name. Remove records only once you've confirmed nothing still uses them; an A record may serve a website and an MX may receive mail. If the CNAME is Forge's, use a different name. Resend still sends part of your mail the old way while it moves you onto Forge, so the old records need to stay where they are. Forge's troubleshooting shows where to change its return path: Configuration, then Finish Forge setup, then Change. Outside Forge, a different return-path name means deleting and re-adding the domain, so read mistake 5 first, especially if you use click tracking.

How to check: run dig CNAME send.example.com and dig TXT send.example.com (or your label), without +short. If the first returns a CNAME, the second should too: a resolver asked for TXT at an alias answers with the CNAME, followed by the target's TXT records. If the CNAME query returns a CNAME but the TXT query returns a TXT record owned by your name itself, with no CNAME line, the name holds both.

One DMARC setting to watch

Resend's mail can pass DMARC two ways: through its DKIM signature, which is signed for your domain, and through SPF on the return path, which is a subdomain of your domain. That second path relies on relaxed alignment, the default. If your DMARC record sets aspf=s, an SPF pass on send.example.com no longer counts for mail from example.com, and DKIM carries the message alone. We covered why that matters, and when strict alignment is worth it, in Your SaaS Sends Email From Five Places.

Records that look wrong and aren't

An MX record that isn't your mail server. The MX at send.example.com points at Amazon's feedback servers. It handles bounces for that one name and doesn't touch mail to your mailbox.

include:dc-<letters and numbers>._spfm.send.example.com. If you set Resend up through Domain Connect, the one-click setup (on Cloudflare it's the "Sign in to Cloudflare" button), Resend's template asks your DNS host to merge include:amazonses.com into the SPF record at send rather than overwrite it. Some DNS hosts implement that merge by publishing the rules at a separate _spfm name and including it. Follow it one step and you'll find include:amazonses.com. It's the same record, wrapped.

Two CNAMEs, send and rsend. That's the newer domain shape from mistake 2, and both halves are needed.

Old send records plus one more CNAME somewhere else. That's a domain that activated Forge. Resend moves sending onto Forge gradually and falls back to its older engine when Forge can't deliver, so keep both.

A 1024-bit DKIM key. Resend signs with 1024-bit keys, and "You can't change the key length." The DKIM standard says signers "MUST use RSA keys of at least 1024 bits" and "SHOULD use RSA keys of at least 2048 bits" (RFC 8301 §3.2), so a 1024-bit key meets the protocol minimum. The key length is Resend's setting, so editing the DNS record won't change it.

A CNAME pointing at resend-dns.com. That's open and click tracking: tracked links in your mail use that name. It doesn't send mail, so it needs no SPF, MX or DKIM of its own. Resend may also ask for a CAA record so a certificate can be issued for the tracking name; add it at exactly the name Resend shows. If you changed your tracking subdomain, you may see two tracking CNAMEs, one shown dimmed. Keep both: Resend keeps the old one "to avoid breaking links in emails that were already sent using the previous subdomain."

A receive-only domain with no SPF records. If you turn off sending for a domain, Resend's receiving FAQ says "You no longer need Resend's SPF records." The DKIM record stays.

Checking your setup

Resend's dashboard is the first place to look: it validates each record live and puts a red underline on the one that's wrong. Beyond that:

• Check your domain on dmarc.quest. The report flags a DNS host appending your domain to an MX or CNAME value, a receiving MX that one side of the mix will lose, a Resend DKIM key whose return path isn't complete (including when the missing SPF record looks like it went to your root), an SPF include Resend doesn't publish, a return-path CNAME whose SPF or MX answers differ from its target's, and return-path MX records in more than one region, which Resend's dashboard reports as a "multiple-regions" error. It finds return paths under the common labels, finds Resend domains verified at a subdomain, and recognizes the Forge, CNAME and Domain Connect shapes above. And it shows your other senders beside Resend, since your DMARC policy covers all of them.
• Send a test email from your app, through Resend, to the address that page gives you. You'll see the return path the message actually used, so a custom label or a Forge name stops being guesswork, along with the SPF, DKIM and DMARC verdicts a real receiver gave it.