You send the email through Resend, the API returns 200, and the dashboard says "delivered." But the recipient never sees it. It is in spam, or it is not there at all. Resend is a modern, developer-friendly sender, but when deliverability drops, the cause is almost always on your side: the sending domain, the authentication records, the IP reputation, or the list you are sending to. Here are the five reasons Resend deliverability drops, in order of likelihood, and the exact fix for each one.
This is the number one cause. When you send through Resend, the mail leaves from a Resend IP, not your own server. The receiving mail server checks your SPF record to see if that IP is allowed to send as your domain. If your SPF record does not include resend.com, the receiving server sees an unauthorized sender and flags the mail.
The fix: add include:resend.com to your SPF record. If you are also sending from your own server, add both: v=spf1 include:resend.com ip4:YOUR_SERVER_IP -all. Then verify the record is actually live: run the SPF checker on your domain and confirm the include resolves.
DKIM is the second layer. Resend signs your mail with a DKIM key, and the receiving server verifies that signature against the DNS record for your domain. If the DKIM record is missing, expired, or the selector does not match, the signature fails and the mail is flagged.
The fix: go to Resend's settings, copy the DKIM host record and value, and add it to your DNS. Then verify it: run the DKIM checker on your domain and confirm the signature verifies. If you recently changed your DKIM key in Resend, the old selector may still be in your DNS and the new one may not be. Check both.
DMARC is the policy layer. It tells the receiving server what to do when SPF or DKIM fails. If you do not have a DMARC record, the receiving server has no policy to follow and may treat the mail as suspicious. If your DMARC record is misconfigured (wrong selector, wrong policy, missing reporting address), it can cause the same problem.
The fix: add a DMARC record that references your SPF and DKIM selectors. Start with p=none and a reporting address, then tighten it to p=quarantine or p=reject as your domain proves itself. Run the DMARC checker on your domain and confirm the record is live and correctly configured.
Resend uses shared IPs by default. If another sender on that IP has been flagged for spam, your mail can be affected too. Even on a dedicated IP, a blocklist hit will not announce itself: the mail is still "delivered" by Resend, but the receiving server rejects it at the SMTP level.
The fix: check your sending IP against the major blocklists. Run the IP blocklist checker on your sending IP. If it is listed, request delisting from the blocklist operator. If you are on a shared IP and your deliverability is inconsistent, consider moving to a dedicated IP in Resend.
The last two causes are on your side, not Resend's. A list full of hard bounces and cold recipients poisons your reputation. A sudden 10x spike in send volume trips spam filters. Both of these show up as a sudden drop in deliverability with no obvious cause in your infrastructure.
The fix: prune your list. Remove hard bounces, honor unsubscribes the same day, and keep your complaint rate under 0.1%. Ramp your volume in steps over days instead of all at once. If you are sending cold email, warm up the domain before you scale.
Do not guess. Run the checks in order. Start with the authentication layer (SPF, DKIM, DMARC), because it is the most common and the cheapest to verify. Then check the IP reputation. Then look at the list and the volume. The free audit runs the DNS and reputation checks in one pass, scores the domain, and points at the exact record to fix first. That is the fastest way to stop guessing and start fixing.
Want this checked automatically every day? Inboxproof Pro monitors your domain around the clock and alerts you the moment a record breaks or an IP gets listed. See pricing →