Your signup confirmation and password reset emails are landing in spam for one reason: your sending domain is unauthenticated. Gmail, Outlook, and Yahoo have no cryptographic proof that mail claiming to be from you@yourdomain.com actually came from you — so they treat it like any other unverified sender, which increasingly means the spam folder or a silent drop. The fix is not a clever subject line. It's three DNS records (SPF, DKIM, DMARC), a real sending provider instead of your app server's raw SMTP, and a gradual volume ramp on a dedicated subdomain. None of this is optional in 2026 — it's table stakes for every mailbox provider that matters.

Stop sending from your app server#

If your Node/Rails/Django app is calling smtplib or a raw SMTP library directly from your production server, stop. Your app server's IP has no sending history, no reverse DNS reputation, and nothing stopping it from being reused by a spammer on the same host or cloud range. Route transactional mail through Resend, Postmark, SES, or Mailgun instead — they maintain dedicated sending infrastructure, IP reputation, feedback loops with mailbox providers, and the exact DNS records covered below, generated for you. See our comparison of Resend vs Postmark vs Amazon SES if you haven't picked one yet, and the Resend email API tool highlight if you want the fastest path to a working setup.

SPF: authorize your provider's servers#

SPF (RFC 7208) is a TXT record on your domain listing which servers are allowed to send mail as you. Your provider gives you an include value; add it to a single TXT record:

yourdomain.com.  IN  TXT  "v=spf1 include:_spf.provider.com ~all"

~all softfails unauthorized senders (marks them suspicious); -all hardfails them. Start with ~all while you confirm nothing legitimate breaks, then consider -all once stable. Watch the 10-DNS-lookup limit — RFC 7208 caps SPF evaluation at 10 lookups (each include, a, mx, redirect counts), and exceeding it produces a PermError that fails SPF for everyone, silently. Stacking a CRM, a helpdesk, and a marketing tool's SPF includes on top of your transactional provider is the most common way solo founders blow this limit. Verify it:

dig TXT yourdomain.com +short

DKIM: sign every message cryptographically#

DKIM (RFC 6376) has your provider sign each outgoing message with a private key, while the matching public key sits in DNS as a CNAME or TXT record at selector._domainkey.yourdomain.com. Receivers fetch the public key, verify the signature, and know the message wasn't altered in transit — that's the entire trust model.

selector1._domainkey.yourdomain.com.  IN  CNAME  selector1-yourdomain-com._domainkey.provider.com.

Your provider's dashboard gives you the exact selector and target — never invent one. Verify with:

dig CNAME selector1._domainkey.yourdomain.com +short

DMARC: the policy and the feedback loop#

DMARC (RFC 7489) is a TXT record at _dmarc.yourdomain.com that does two things: tells receivers what to do when a message fails SPF and DKIM alignment, and tells them where to send aggregate reports about your domain's mail.

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Start at p=none — pure monitoring, no enforcement — and read the reports for a few weeks before moving to p=quarantine and eventually p=reject. Alignment is the part founders miss: DMARC only passes if the domain in your visible From: header matches (or is a parent of) the domain that SPF or DKIM authenticated. If your provider sends on your behalf using their own domain in DKIM's d= tag without aligning it to yours, DMARC fails even though DKIM itself passed.

Authentication is table stakes; reputation is the currency receivers actually spend on you.

Warm up, isolate, and verify#

Send transactional mail from a dedicated subdomain — mail.yourdomain.com or notify.yourdomain.com — not your root domain, and never share it with newsletter or promotional sends. A single subdomain gets one reputation; if your marketing blast spikes complaints, a shared subdomain drags your password resets down with it. On a new domain or IP, ramp volume gradually over one to a few weeks rather than firing your entire waitlist on day one — mailbox providers treat sudden volume from an unknown sender as a spam signal.

Verify continuously, not just once:

dig TXT yourdomain.com +short
dig TXT _dmarc.yourdomain.com +short
dig CNAME selector1._domainkey.yourdomain.com +short

Send a test message to mail-tester.com for a full authentication + content score, and check Google Postmaster Tools for reputation data. Most importantly, read your DMARC aggregate reports — they're the only place you see every server sending mail as your domain, whether you authorized it or not. That visibility is the real payoff of DMARC, more than the enforcement policy itself.

Since February 2024, Google and Yahoo require bulk senders to have SPF and DKIM configured, a DMARC record with aligned domains, one-click unsubscribe (RFC 8058) on any bulk or marketing mail, and a spam complaint rate under 0.3% — and enforcement has only tightened through 2025 and 2026. Transactional mail (password resets, receipts, confirmations) isn't "bulk" in the marketing sense, but it rides on the same domain reputation, so the same hygiene applies.

Go-live checklist#