Email Deliverability for Developers: Why Your Transactional Emails Land in Spam

Your password reset email landing in spam is worse than it not sending at all. The user thinks the feature is broken. They try again. Multiple emails pile up in spam. They contact support. Trust erodes.

Email deliverability is an infrastructure concern that most developers ignore until it becomes a customer-facing problem. Here is how it works and how to fix it.

Why Emails Go to Spam

Email providers (Gmail, Outlook, Yahoo) use signals to classify incoming email: is this legitimate or spam? The signals include:

Authentication signals: does the sending server have permission to send from this domain? (SPF, DKIM, DMARC records.)

Reputation signals: has this sending IP/domain sent spam before? What percentage of its emails are opened vs marked as spam?

Content signals: does the email body contain spammy patterns? (All caps, excessive links, known spam phrases.)

Engagement signals: do recipients open emails from this sender? Do they click links? Do they mark it as spam?

If any of these signals are negative, your email risks spam classification. Let me walk through each one.

Authentication: SPF, DKIM, DMARC

These three DNS records prove that your email is legitimate:

SPF (Sender Policy Framework): a TXT record listing which IP addresses are authorized to send email from your domain. When Gmail receives an email from @yourdomain.com, it checks: is the sending server's IP in the SPF record? If no: the email might be spoofed.

Configuration: add a TXT record to your domain's DNS. The value lists your sending services: v=spf1 include:sendgrid.net include:_spf.google.com -all. This says: SendGrid and Google are authorized senders. Hard fail (-all) anything else.

DKIM (DomainKeys Identified Mail): your sending service signs every email with a private key. A corresponding public key is published in your DNS. Recipients verify the signature, confirming: the email was sent by an authorized server and was not modified in transit.

Configuration: your email service (SendGrid, Resend, Postmark) provides a DKIM public key. Add it as a TXT record in your DNS. The service handles signing automatically.

DMARC (Domain-based Message Authentication, Reporting, and Conformance): tells receiving servers what to do with emails that fail SPF and DKIM. Options: none (just report failures), quarantine (send to spam), or reject (bounce entirely).

Start with: v=DMARC1; p=none; rua=mailto:[email protected]. This monitors without affecting delivery. Once you confirm legitimate emails pass, tighten to p=quarantine or p=reject.

Sender Reputation

Email services maintain reputation scores for sending IPs and domains. New domains and IPs have no reputation — they start in a neutral state. Reputation builds over time based on: how many recipients mark your email as spam (spam complaint rate), how many emails bounce (invalid addresses), and engagement rates (opens, clicks).

Maintaining good reputation: keep spam complaint rate below 0.1% (1 in 1000 recipients marking as spam), remove bounced addresses immediately (do not retry invalid emails), send only to people who opted in (no purchased lists, no scraped addresses), and maintain consistent sending volume (sudden spikes from zero trigger spam filters).

Content Best Practices

Email content affects deliverability. Avoid: ALL CAPS IN SUBJECT LINES, excessive exclamation marks (!!!), spam trigger words ("free," "urgent," "act now"), image-only emails (no text content), and misleading subject lines.

For transactional emails (password resets, order confirmations): keep content simple, relevant, and expected. The recipient knows they requested this email. Clean design, clear purpose, minimal links.

For marketing emails: include a visible unsubscribe link (legally required), use a recognizable sender name, set expectations about email frequency during signup, and honor unsubscribe requests immediately.

Choosing an Email Service

For transactional emails (password reset, verification, notifications): use a dedicated transactional service: Resend (developer-friendly, great API), Postmark (best deliverability reputation), SendGrid (most features, complex pricing), or Amazon SES (cheapest at scale, most configuration required).

Do NOT use: your web server's built-in mail function, a shared hosting email server, or a marketing email service for transactional emails.

Why dedicated services matter: they maintain high-reputation sending IPs, handle authentication automatically, provide delivery analytics, and separate your transactional emails from marketing (different reputation pools).

We use Resend at AIDToolStack. The API is clean, TypeScript-native, and deliverability is excellent for our transactional emails (account verification, password reset, weekly digest).

Testing Deliverability

Before going live with a new email setup: send test emails to Gmail, Outlook, and Yahoo accounts. Check if they arrive in inbox or spam. Check email headers for SPF, DKIM, and DMARC pass/fail.

Use mail-tester.com: send an email to their test address and receive a score (1-10) with specific issues identified.

Check Google Postmaster Tools: if you send to Gmail users, Postmaster Tools shows your domain's reputation, spam rate, and authentication status.

Common Deliverability Mistakes

Mistake 1: not setting up authentication records. Without SPF, DKIM, and DMARC, your emails look suspicious to every email provider. This is the most common cause of deliverability problems.

Mistake 2: sending from a new domain without warming up. A brand new domain sending 10,000 emails on day one looks like spam. Warm up: start with 50 emails/day, gradually increase over 2-4 weeks.

Mistake 3: mixing transactional and marketing email. If your marketing emails get spam complaints (normal at 0.1-0.3%), that reputation affects your transactional emails if they share the same sending domain/IP. Use separate subdomains: mail.yourdomain.com for transactional, marketing.yourdomain.com for newsletters.

Mistake 4: not handling bounces. Repeatedly sending to invalid addresses damages your sender reputation. Remove hard bounces immediately. Suppress soft bounces after 3 attempts.

Mistake 5: no unsubscribe mechanism. For any non-transactional email, missing unsubscribe links violate CAN-SPAM/GDPR and cause recipients to mark as spam instead (which hurts your reputation far more than an unsubscribe).

The Minimal Setup Checklist

For any web application sending email:

Choose a dedicated transactional email service (Resend, Postmark, SendGrid)

Add SPF record to your DNS (authorizing the service's IPs)

Add DKIM record to your DNS (public key from the service)

Add DMARC record starting with p=none

Send test emails to major providers and verify inbox delivery

Monitor bounce rates and spam complaints

Use a separate subdomain for marketing vs transactional email

This takes about an hour to set up. The return: your password reset emails reach your users' inboxes, your verification emails work reliably, and your users trust that your application functions correctly.