A customer messaged me: “Hey, just wanted to let you know your confirmation email went to my junk folder.”
I said thanks, made a mental note, and moved on. A week later, two more customers said the same thing. I started wondering how many just never confirmed at all.
I had no idea what was causing it. I’m not a developer. I built my app with Claude and Cursor. It sends emails through Resend because someone in a Discord server said that’s what you use. I didn’t know anything else about email.
Here’s what I learned.
The problem had a name I didn’t recognize
Email providers like Gmail and Outlook run a background check on every email they receive, trying to answer one question: is this email really from who it claims to be from, or is it a fake?
To do that, they check three things, each with a technical name:
- SPF (Sender Policy Framework): is the service sending this email actually allowed to send on behalf of this domain?
- DKIM (DomainKeys Identified Mail): is there a digital signature proving the email wasn’t tampered with?
- DMARC (Domain-based Message Authentication, Reporting & Conformance): what should the receiver do if those checks fail?
These aren’t optional extras. They’re standard infrastructure that every serious email setup has. I had none of them properly configured.
What “not properly configured” looked like for me
My app was sending emails through Resend. That part worked; emails were going out. But Resend wasn’t listed as an authorized sender for my domain. So Gmail saw an email claiming to be from hello@example.com, arriving from a Resend server, with no proof Resend was allowed to do that.
Suspicious. Into the spam folder it went.
It’s the email equivalent of a package arriving with no return address and no tracking number. The recipient is right to be cautious.
How I fixed it, step by step
I want to share the actual steps, because every guide I found while researching this assumed I already knew things I didn’t.
Step 1: I logged into my DNS provider. DNS is the address book for the internet. For most small apps, this is wherever you bought your domain: Namecheap, Cloudflare, Google Domains, GoDaddy.
Step 2: I added an SPF record. This is a line of text that says “Resend is allowed to send email for my domain.” Resend’s own documentation had the exact text to copy. It took two minutes: I pasted it as a new TXT record at the root of my domain.
Step 3: I set up DKIM in the Resend dashboard. DKIM is a digital signature system. In the Resend dashboard there’s a section called “Domains.” I added my domain, and it gave me two DNS records to publish. I copied them into my DNS provider, clicked “Verify,” and both went green.
Step 4: I added a DMARC record.
This one confused me most. DMARC is a policy that tells email providers what to do if SPF or DKIM fail. The policy lives in a tag called p. The standard says a record that leaves p out (but does have a reporting address) is read as p=none, but I wrote it out on purpose so there was no doubt. I started with the gentlest setting: monitoring only, no blocking. I signed up for DMARC Guardian, which gave me a ready-made reporting address for my domain, and pointed my DMARC record at it so I could see the reports without touching XML myself. (When you’re ready to move beyond monitoring, this guide covers the full journey to p=reject.)
The record I added was:
v=DMARC1; p=none; rua=mailto:dmarc-xxxxxxxx@dmarc-guardian.comp=none means “don’t do anything harsh yet.” The rua= address is what asks for the reports, and it’s the one DMARC Guardian generated for my domain when I added it.
Step 5: I waited. DNS changes can take up to 48 hours to spread. I waited a day, sent myself a test email, and checked the headers. Everything passed.
What I see now
DMARC Guardian shows me a dashboard for exactly what’s happening with my email. Every day, Google and Microsoft send small reports about mail that claimed to come from my domain. DMARC Guardian turns those reports from technical XML into something I can actually read.
I can see how many emails passed authentication, whether any failed and why, and whether someone else is sending mail that pretends to be from my domain.
Since fixing the configuration, my delivery got noticeably better. More importantly, I can see it’s working. I don’t have to guess anymore.
The thing I wish I’d known earlier
Email authentication doesn’t fix a spam problem if you’re actually sending spam. But if you’re sending legitimate mail (onboarding, password resets, invoices) and it’s hitting spam, authentication is usually the first thing to check and fix.
It’s not complicated. It’s just unfamiliar. Once you’ve done it for one domain, you can do it for the next in 15 minutes. For the technical breakdown of what to check and fix, see why transactional emails land in spam.
If you build anything that sends email to customers, set this up before you launch, not after your first support message about a spam folder.