Fix Resend emails going to spam

Resend will not deliver to a real recipient until you verify a domain, so the shared-sending-domain trap that catches Klaviyo and Mailchimp users does not exist here. What breaks instead is narrower and easier to miss: the records Resend puts on the send subdomain, a DMARC policy nobody creates for you, a DKIM key you cannot upgrade, and a domain whose entire sending history starts the day you ship. This guide covers the DNS Resend actually issues, the resend.dev sandbox trap, dedicated versus shared IPs, and how to test a real send with Unspam.

Run a free spam test How to test your sends

Why Resend emails land in spam.

Nothing published a DMARC record, because Resend does not

Verifying a domain writes SPF and DKIM for you and stops there. Resend's own spam troubleshooting page says DMARC is not automatically set up but is strongly recommended, and Deliverability Insights carries a separate check for a valid DMARC record that quietly fails on every message. Since the Google and Yahoo bulk sender rules, a From domain with no DMARC policy is a filtering signal on its own. Publish v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; at _dmarc.yourdomain.com before you look at anything else.

Your first production send is your domain's first send ever

Every message you sent while building went out from resend.dev, which carries Resend's reputation and not yours. The day you swap the from address to your own domain, Gmail sees a brand new sender at whatever volume your launch produces. Resend's warm-up plan starts at up to 150 emails on day one and reaches up to 2,000 by day seven, and their calculator stretches the ramp to 42 days for larger targets. A launch that fires several thousand signup confirmations from a domain verified that morning is exactly the pattern the plan exists to prevent.

DKIM is 1024-bit and you cannot change it

Resend signs outbound mail with 1024-bit DKIM keys and states plainly that it does not support 2048-bit keys. That is the floor receivers are still required to validate, so signatures verify normally, but it leaves you no headroom and no way to rotate to a stronger key inside the product. It also means DKIM is not a lever you can pull when a corporate filter such as Mimecast or Proofpoint scores you down. Spend your effort where you do have control: a published DMARC policy, a subdomain with its own history, and content that does not need excusing.

Broadcasts and password resets leave from the same verified domain

Resend splits sending into the Emails API for transactional mail and Broadcasts for marketing, but both go out from whatever domain you verified. One newsletter that collects complaints then drags your password resets down with it, because to a filter they are the same sender. Resend's own guidance is to send from a subdomain so inbox providers get a clear indication of where to place your mail. Verify two, for example notifications.yourdomain.com for the API and updates.yourdomain.com for Broadcasts, and keep them apart from day one.

Your complaint count reads near zero and means nothing

Resend's suppression documentation states that not all inbox providers return a complained event, most notably Gmail and Google Workspace. The number you are watching in the dashboard therefore omits the provider that decides most of your placement. Suppressions are also team-wide: an address suppressed after a marketing bounce is skipped across every domain and subdomain you own, transactional included, so a password reset can silently never send. Read your real Gmail spam rate in Google Postmaster Tools and treat Resend's figure as a floor.

The template links somewhere other than your sending domain, or is too big

Resend's Deliverability Insights checks that the links in a message point at the same domain the message is sent from, and a template whose buttons all resolve to a marketing site, a link shortener or a third-party tracker fails it on every send. Use a subdomain of your sending domain for click tracking rather than a shortener, and keep at least the primary call to action on your own domain. Size matters too: Resend notes that Gmail limits each message to 102 KB, and past that the rest of the content is clipped and hidden behind a link to view the entire message, which puts your unsubscribe link behind an extra click.

How Resend authenticates your mail.

Resend is unusual among sending platforms: it will not send to anyone but your own account address until a domain is verified, and verification itself writes SPF and DKIM. That removes the shared-domain misalignment other platforms suffer from and leaves exactly two things to get right, the send subdomain and DMARC.

record	default	the problem	the fix
SPF	Domain verification issues a TXT record on the send subdomain of the domain you added, with the value v=spf1 include:amazonses.com ~all. The include and the bounce host both point at amazonses.com, so SPF authenticates Amazon's sending infrastructure.	Because the record lives on send.yourdomain.com, SPF authenticates the subdomain and not your From domain. Relaxed alignment, the DMARC default, still counts that as aligned. People who do not know this add a Resend include to their root SPF record, which does nothing at all, or set aspf=s and leave DMARC resting on DKIM alone.	Publish the record exactly as generated, with the host set to send only, since your DNS provider appends the domain. Leave your root SPF record untouched, including your Google Workspace or Microsoft 365 include, and do not set aspf=s.
DKIM	Verification issues one TXT record at resend._domainkey on the domain you added, holding a 1024-bit public key. Resend signs with 1024-bit keys and does not support 2048-bit.	The value is long enough that DNS panels truncate it, split it into multiple quoted strings, or add quotes of their own. When that happens the domain never leaves the pending state and you cannot send from it at all, which developers usually misread as a Resend outage. There is no path to a stronger key inside the product.	Copy and paste the value rather than retyping it, use resend._domainkey as the host with no domain appended, and set Cloudflare records to DNS only rather than proxied. Confirm it publicly with dns.email or nslookup, then check the d= value on a real message: it should be your own domain.
DMARC	Resend creates no DMARC record. Your domain verifies, sends, and reports healthy with no policy published anywhere.	Resend's troubleshooting checklist puts authentication first and names DMARC as the one record it does not create, and Deliverability Insights flags a missing or invalid record on every message. Jumping straight to an enforcement policy is its own failure: quarantine or reject before every legitimate sender is aligned and you filter your own invoices and helpdesk mail.	Start at v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; on _dmarc.yourdomain.com. Read the reports, Resend maintains a free open-source DMARC analyzer at checkdmarc.email, confirm every legitimate sender is aligned, then move to p=quarantine and p=reject.
Return-Path subdomain	Resend uses the send subdomain of your verified domain for the Return-Path, which is why both the SPF TXT record and the bounce MX record sit on send.yourdomain.com. The MX value is region specific, feedback-smtp.us-east-1.amazonses.com for a domain created in North Virginia and a different host for Ireland, São Paulo or Tokyo, so copy the exact value from the domain's Records tab.	Some mail clients expose the Return-Path to recipients, so an invented value is a credibility problem, and Resend warns specifically against values like testing. Publishing that MX record on the root domain instead of the subdomain is far worse: it takes over inbound mail for the entire domain.	Keep the default. If you must change it, pass custom_return_path when you create or update the domain: maximum 63 characters, letters, numbers and hyphens only, starting with a letter and ending with a letter or number.

Once you have updated these records, confirm they pass with Unspam's free SPF checker, DKIM checker, and DMARC checker.

How to test a Resend campaign with Unspam.

Resend's dashboard tells you what left the API and stops at Delivered, which by their own definition only means the receiving server answered 250 OK. After that the message can go to the inbox, the spam folder, a corporate quarantine or nowhere, and Resend never sees which. The only way to know is to send a real message through your own code path to seed mailboxes.

01
Get your Unspam seed address and Test ID

Start a free spam test or an inbox placement test in Unspam and copy the seed address it generates. An inbox placement test also issues a Test ID. Paste it into the subject line or the body before you send, or the message reaches the seed mailboxes and is never matched back to your test. Placement tests deliver to seed mailboxes at Gmail, Outlook, Yahoo and five other providers and report where each copy landed.
02
Send from your verified domain, not resend.dev

Set from to an address on the domain you verified, for example notifications@notifications.yourdomain.com. Leaving the quickstart value in place returns a 403 telling you that you can only send testing emails to your own email address, and a from domain that does not match the verified one exactly, subdomain included, returns a 403 domain mismatch. The mailbox itself does not need to exist, though Resend recommends addresses that can receive replies.
03
Fire it through the real code path

Call the same API route, Broadcast or Automation your customers get, with the same template, the same links and the same custom headers. A hand-typed one-off skips your List-Unsubscribe headers, your rendered React Email markup and the link rewriting if you have click tracking enabled, so it does not test what you actually ship.
04
Hand Unspam SMTP credentials for repeat runs

For scheduled inbox placement tests, give Unspam Resend's SMTP details: host smtp.resend.com, port 587, username resend, password a Resend API key. Create a dedicated key with sending_access permission and a domain_id restriction so it can do nothing but send from that one domain, and copy the value immediately because Resend never shows a key again. Unspam uses those credentials only to send its own test messages; it does not read your Resend contacts, logs or dashboard.
05
Read the report and fix what it flags

Unspam reports the spam score, the SPF, DKIM and DMARC results on the live message, which folder each seed provider chose, client previews and a heatmap. Confirm the DKIM d= value is your own domain and that DMARC passes rather than simply being absent. Fix what is flagged, then rerun the identical send to confirm the change moved placement.

The same test renders your campaign in 50+ real email clients, Gmail, Outlook, Apple Mail, iPhone, and Android among them, each in light and dark mode, via email client previews, so you confirm placement and rendering in one pass.

Resend features that quietly affect delivery.

Resend's MX record on the root domain hijacks your inbound mail

Resend's sending records belong on the send subdomain, and Resend points out that an MX record only affects the subdomain it sits on, so the record on send.yourdomain.com leaves your Google Workspace or Microsoft 365 inbox alone. Move that value to the root and you repoint mail for anything@yourdomain.com at Resend's bounce host instead of your mail provider. Resend publishes the same warning about its inbound feature: adding a receiving MX record at the apex routes every message for the domain to Resend rather than your previous provider, which is why it tells you to put inbound on its own subdomain (for example subdomain.yourdomain.com). Keep every Resend record on the exact host shown in the domain's Records tab and change nothing at the apex.

The bounce host is region-specific, and DNS panels break it

A domain is created in North Virginia (us-east-1), Ireland (eu-west-1), São Paulo (sa-east-1) or Tokyo (ap-northeast-1), and the MX value has to match that region. Two failures dominate: a record pointing at a different region than the domain was created in, and a DNS provider appending your domain so the value becomes feedback-smtp.eu-west-1.amazonses.com.example.com. Add a trailing period to mark the value fully qualified. Changing region is not an edit, it means deleting the domain, adding it again and republishing every record.

Delivered does not mean the inbox

Resend marks an email Delivered once the recipient server accepts it with a 250 OK response. Everything after that, inbox, spam folder, corporate quarantine, silent discard, happens outside Resend's visibility. A dashboard full of green Delivered rows is entirely compatible with every one of those messages sitting in junk, which is why teams chase this for weeks before they test placement.

The Emails API adds no List-Unsubscribe header for you

Broadcasts and Automations handle the unsubscribe flow automatically when you include an unsubscribe link. Transactional sends through the Emails API do not, because Resend does not manage contact lists for them, so you pass the headers yourself: List-Unsubscribe with your URL in angle brackets and List-Unsubscribe-Post set to List-Unsubscribe=One-Click. Your endpoint has to answer both GET and POST, and act on the request within 48 hours.

What real Resend senders run into.

The deliverability problems Resend senders hit most often, each with the fix that resolves it.

Domain says Verified in Resend, SPF and DKIM both pass, and Gmail still puts everything in the spam folder.

Verification only produces SPF and DKIM. It does not publish DMARC, and Resend states that DMARC is not set up automatically. Passing SPF and DKIM with no DMARC policy on the From domain is exactly what the Google and Yahoo bulk sender requirements target, and Resend's own Deliverability Insights flags it on every message you look at.

The fix Publish v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; at _dmarc.yourdomain.com, then open the Insights panel on a real send and clear every remaining check, especially the link URL match and the no-reply sender.

I keep getting 403 domain is not verified when sending from localhost, even to my own address.

Two different rules collide here. The from domain has to match the verified domain exactly, so a domain verified as sending.example.com rejects a request that says example.com. Separately, if from is still onboarding@resend.dev, the only recipient allowed is the address on your Resend account, so a typo in your own address produces what looks like the same error.

The fix Open the Domains page and copy the verified domain string character for character into from, then check the API key is not restricted to a different domain by domain_id. While developing, send to delivered@resend.dev, bounced@resend.dev, complained@resend.dev or suppressed@resend.dev instead of your own inbox.

Added every record to Cloudflare two days ago and the domain is still pending. Nothing changes when I click verify.

Three causes account for almost all of these. The DNS provider appended your domain to the MX value, producing feedback-smtp.us-east-1.amazonses.com.example.com. The records went to the registrar while the nameservers point somewhere else, so nothing you published is live. Or the MX region does not match the region the domain was created in, sometimes with two regions published at once.

The fix Look the records up publicly with dns.email or nslookup rather than trusting the DNS panel. Add a trailing period to the MX value to mark it fully qualified, delete any duplicate region rows, set the records to DNS only rather than proxied, then use Restart verification.

After I pointed the MX record at Resend, our Google Workspace inbox stopped receiving anything.

The MX record Resend generates belongs on the send subdomain. Published on the root, it becomes the mail exchanger for the whole domain, so every message addressed to anyone@yourdomain.com routes to Resend and away from Google Workspace or Microsoft 365. Resend documents this exact failure and recommends a subdomain to avoid it.

The fix Delete the MX record from the root, restore your Google Workspace or Microsoft 365 MX records exactly as they were, and republish Resend's MX with the host set to send. If send is already taken, Resend suggests send.sub.yourdomain.com.

We launched, sent about four thousand signup confirmations in a day from a domain we verified that morning, and most of them landed in junk.

Everything before launch went out from resend.dev, so your own domain had no sending history at all. Resend puts the responsibility for warming a domain on you, unlike dedicated IPs, which it warms automatically. Their plan starts at up to 150 emails on day one and reaches up to 2,000 by day seven, with the calculator extending the ramp to 42 days for larger targets.

The fix Verify the sending subdomain weeks before launch and start real low-volume traffic on it. Follow the warm-up plan, keep bounce rate under 4% and spam rate under 0.08%, and limit non-transactional sends to people who opened or clicked in the last six months, as Resend's audience hygiene guidance recommends.

Resend deliverability, answered.

Why do I get a 403 when I send to a customer from onboarding@resend.dev?

resend.dev is a test-only sender. It can only deliver to the email address on your Resend account, and anything else returns a 403 saying you can only send testing emails to your own email address. The quickstart and most framework scaffolds ship with that value in the code, so it survives into staging more often than anyone admits. Verify a domain, then change from to an address on it.

Does Resend set up SPF and DKIM for me?

Yes. Domain verification generates the DKIM TXT record at resend._domainkey and the SPF TXT record on the send subdomain, plus the MX record for the Return-Path, and you publish all three at your DNS provider. DMARC is the exception: Resend does not create it and says so. Verification usually completes within 15 minutes of the records going live, though DNS changes can take up to 72 hours to propagate globally.

Do I need a dedicated IP with Resend?

Only above real volume. Resend's stated criteria are an active Transactional Scale or Marketing Pro subscription and sending volume above 3,000 emails a day, and they warn that under 90,000 emails a month may not be enough to keep the IPs warm. Below that, shared IPs are the better choice because they arrive already warmed by other senders. Resend also does not expose the addresses in a pool, so a dedicated IP cannot be used for allowlisting.

Should I verify my root domain or a subdomain?

A subdomain. Resend recommends it for two reasons: it isolates sending reputation so a compromised subdomain can be quarantined without touching your primary domain, and it gives inbox providers a clear signal about what kind of mail this is. Their example is notifications.acme.com rather than acme.com. What they warn against is a lookalike domain such as acme-alerts.com, which reads as phishing to filters.

Resend shows almost no spam complaints, so why is my mail in junk?

Because the largest mailbox provider never tells Resend. Resend's suppression documentation states that not all inbox providers return a complained event, most notably Gmail and Google Workspace. Your dashboard undercounts by whatever share of your list is on Gmail. Sign up for Google Postmaster Tools to see the real spam rate, and run inbox placement tests to see the folder rather than inferring it from engagement.

Can I use a 2048-bit DKIM key with Resend?

No. Resend signs outbound mail with 1024-bit DKIM keys and does not support 2048-bit. If a security review or an internal policy requires 2048-bit signing, that is a hard blocker rather than a setting, and the answer is a different sending path for that mail. For ordinary deliverability it is not the problem to solve: 1024-bit signatures still verify at every major provider.

Resend platform details were verified against publicly available documentation in August 2026 and may have changed since. Resend is a trademark of its respective owner. Unspam is not affiliated with or endorsed by Resend.

Test your next Resend campaign before your subscribers do.

Start a free spam test Inbox placement test