Email Deliverability for Developers: Why Your App's Emails Go to Spam

Building LaravelSMTP.com — a service that gives Laravel apps one-line email setup across SES, Mailgun, Postmark, SendGrid, and raw SMTP — forced me to learn deliverability at a depth most developers never need. The summary: inbox placement is earned infrastructure, not luck.

The three DNS records that are not optional

• SPF: lists which servers may send for your domain — one record, include your provider
• DKIM: cryptographically signs each message; without it you are presumed forged
• DMARC: tells receivers what to do when SPF/DKIM fail, and sends you reports — start with p=none, monitor, then move to quarantine

Gmail and Yahoo now require this stack outright for bulk senders. No SPF+DKIM+DMARC means no inbox — the conversation ends there.

Separate transactional from marketing

Password resets and invoices must never share a sending domain with newsletters. Marketing complaints poison the reputation that your critical mail depends on. Use subdomains (mail.example.com for transactional, news.example.com for campaigns) so reputations stay independent.

Choosing a provider honestly

SES is by far the cheapest and rock-solid once you leave sandbox, but you build your own monitoring. Postmark has the best transactional deliverability and tooling out of the box. Mailgun and SendGrid sit between, with stronger marketing features. The pattern I implemented in LaravelSMTP: route through one abstraction so you can switch providers without touching application code.

Watch the feedback loops

Process bounce and complaint webhooks and suppress those addresses immediately. Hard-bouncing the same address repeatedly is the fastest way to a blocklist. Track delivery, open, bounce, and complaint rates per domain — when a number moves, you want to know that day, not when a customer says 'we stopped receiving signups'.