My emails kept landing in spam — here’s what I found out

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. They’re trying to answer: “Is this email from who it claims to be from, or is it a fake?”

To do that, they check three things, which have technical names:

  • 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 we do if those checks fail?

These aren’t optional features. 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 was not listed as an authorized sender for my domain. So Gmail saw an email claiming to be from hello@myapp.com, coming from a Resend server, with no proof that 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 when I was researching this, every guide assumed I knew things I didn’t.

Step 1: I logged into my DNS provider. DNS is like 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 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. Then I clicked “Verify” and both went green.

Step 4: I added a DMARC record. This one I was most confused about. DMARC is a policy that tells email providers what to do if SPF or DKIM fail. I started with the gentlest setting — monitoring only, no blocking — and pointed it at DMARC Guardian so I could actually see the reports.

The record I added was:

v=DMARC1; p=none; rua=mailto:dmarc-reports@myapp.com

p=none means “just send me reports, don’t do anything harsh yet.” I connected that email address to DMARC Guardian which parses the reports automatically.

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 where I can see exactly what’s happening with my email. Every day, Google and Microsoft send little reports about emails that claimed to be from my domain. DMARC Guardian translates those reports from technical XML into something I can actually read.

I can see:

  • How many emails passed authentication
  • If any failed (and why)
  • Whether someone is trying to send fake emails pretending to be from my domain

Since fixing the configuration, my delivery rates improved noticeably. 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 your spam problem if you’re actually sending spam. But if you’re sending legitimate emails — onboarding, password resets, invoices — and they’re hitting spam, authentication is usually the first thing to check and fix.

It’s not complicated. It’s just unfamiliar. Once you do it once for one domain, you can do it in 15 minutes for the next one.

And if you build anything that sends email to customers, set this up before you launch. Not after your first support message about spam folders.

Start a free trial of DMARC Guardian — it reads the reports for you, so you don’t have to learn XML.