The Domain Verification Rabbit Hole: SPF, DKIM, and DMARC with Resend
I recently launched a feature in one of my applications that sent notifications via email using Resend. Everything worked in development. Emails arrived. Beautiful.
Then it went to production.
And they disappeared.
Not to spam. Disappeared completely. The client never received them. Not in spam. Nowhere. It was like they never existed.
That was my entry into the rabbit hole of domain verification.
Why Resend is Excellent (But It's Not Magic)
Resend is genuinely good. The API is clean, the documentation is clear, and emails send fast. But here's the secret nobody tells you: Resend doesn't control whether your emails reach the inbox. That's on you.
Email servers from Gmail, Outlook, and others still use standards dating back decades. And those standards require you to prove you are who you say you are.
Enter SPF, DKIM, and DMARC.
SPF: The First Guardian
SPF (Sender Policy Framework) is basically a DNS record that says: "Legitimate emails from my domain come from these servers".
When you set up Resend, they give you a specific domain or SPF record. Typically something like:
``` v=spf1 include:resend.com ~all ```
This means: "Trust Resend's servers to send emails on my behalf".
The problem: If you don't configure this correctly, Gmail and others will see your emails as suspicious. And "suspicious" in email means "spam folder" or straight up "deleted".
What I learned:
- SPF must be on your root domain or the subdomain you're sending from
- Too many includes in SPF causes issues (there's a limit on DNS lookups)
- If you change email providers, you must update SPF or new emails will fail
DKIM: The Digital Signature
DKIM (DomainKeys Identified Mail) is more sophisticated. It's a cryptographic signature that says: "This email was really sent by us and hasn't been modified".
Resend gives you a public and private key. The public key goes in your DNS (the DKIM record), and Resend signs each email with the private key.
Resend automates this pretty well, but here's where many developers get lost:
``` default._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0BCKQE..." ```
The real problem: Resend gives you multiple DKIM records (often 3). You must add ALL of them. Not just one. If you only add one and the others are pending, emails can fail authentication.
In my case, I added one, tested locally, saw it work, and left it. Then in production, with real volume, some emails authenticated and others didn't. It was a 3-hour debugging session.
DMARC: The Enforcement Policy
DMARC (Domain-based Message Authentication, Reporting and Conformance) is where it all comes together. It's your policy: "If an email doesn't pass SPF or DKIM, what do you do?".
Typically you start with:
``` v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com ```
This means: "Don't do anything if it fails, but send me reports".
Then, when you trust your configuration:
``` v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com ```
This puts suspicious emails in quarantine.
And finally, if you really want to be strict:
``` v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com ```
This directly rejects any email that doesn't pass.
My recommendation: Start with `p=none`, read the reports for a week, make sure your legitimate emails are passing, then move to `p=quarantine`.
Real Debugging: Where Everything Falls Apart
When I set all this up, I used simple tools:
1. MXToolbox - Verifies SPF, DKIM, DMARC in real time 2. Google Postmaster Tools - Shows you how Google sees your domain 3. 250ok or similar - Continuous monitoring
But the most useful tool was... sending myself emails and reviewing the headers.
In Gmail, if you click on an email and then "Show original", you see exactly what happened:
``` Authentication-Results: mx.google.com; spf=pass (google.com: domain of xxx@yourdomain.com designates xxx as permitted sender) dkim=pass header.d=yourdomain.com dmarc=pass ```
If any says `fail`, there's your problem.
DNSBL: The Guardian I Ignored
DNSBL (DNS Blacklist) is where many developers get stuck without even knowing it.
Your email servers (or in this case, Resend's) have IP addresses. If those IPs are on spam blacklists, your emails won't arrive no matter how perfect your SPF/DKIM/DMARC is.
Resend handles this well because they use respected infrastructure, but if you ever switch providers or run your own server, you need to:
1. Verify your IP isn't in DNSBL 2. Monitor regularly (some services offer alerts) 3. If you're on a list, request removal (typically requires proof you've fixed the issue)
Practical Lessons
1. Automate verification
Don't trust that "I tested and it worked". Set up alerts. Resend has webhooks. Use them to monitor bounces and complaints.
2. Start with small volume
Before sending thousands of emails, send 100 to different providers (Gmail, Outlook, etc.) and verify they all arrive.
3. Read the DMARC reports
They're boring, but they show you exactly what's failing. They're your treasure map.
4. Use subdomains for testing
Create a `testing.yourdomain.com` with its own SPF/DKIM/DMARC. That way you don't break your main domain while experimenting.
The Real Code
In your application, the Resend integration is simple:
```javascript import { Resend } from 'resend';
const resend = new Resend(process.env.RESEND_API_KEY);
await resend.emails.send({ from: 'noreply@yourdomain.com', to: 'user@example.com', subject: 'Test', html: '<p>Hello</p>', }); ```
But 90% of the work is in DNS, not code.
The Takeaway
Domain verification isn't sexy. It's not the kind of problem you want to solve at 3 AM. But it's the kind of problem that, if you don't solve it well, makes your application look broken.
Resend handles the technical side of sending. Your job is to make sure the world trusts your domain.
SPF, DKIM, DMARC, and DNSBL. Four standards that together create an ecosystem of trust.
And once you understand it, you never lose emails in the void again.
---
Dealing with deliverability issues? Most of the time it's in DNS, not code.
