Why your email went to spam

The failure nobody reports

A user requests a password reset. The email goes to spam, or is dropped by the receiving server without a bounce. They do not tell you. They tell nobody. They leave.

Email is infrastructure with no error message, which is why it deserves a lesson of its own in a course about shipping.

You cannot send it from your own server

Two facts settle this.

Outbound port 25 is blocked by essentially every cloud provider by default: AWS, Google Cloud, Azure, DigitalOcean, Hetzner. That is deliberate, because compromised virtual machines are the internet’s main source of spam.

And even with it open, a brand-new IP address has no reputation, which means the large mailbox providers treat it with suspicion for weeks. Building sending reputation is a months-long process that a relay has already done for you.

So use a relay. Do not run your own mail server for transactional email. Running one for your own inbox is a defensible hobby; putting your password resets behind it is not.

The three records

SPF: a TXT record on your domain listing who may send on your behalf.

v=spf1 include:_spf.example-provider.com -all

There is a hard limit of 10 DNS lookups when evaluating SPF, and each include: may cost several. Add four providers and SPF silently fails with a permerror, which is a common cause of “it worked until we added the newsletter tool”.

DKIM: a cryptographic signature on each message, with the public key published in DNS at a selector your provider gives you. This is what proves the message was not forged or altered, and it survives forwarding, which SPF does not.

DMARC: a policy saying what to do when SPF and DKIM fail, plus an address to send reports to.

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Start at p=none, which changes nothing and only collects reports. Read them for two weeks: they will show you every system sending as your domain, including the two you forgot. Then move to p=quarantine and later p=reject. Going straight to p=reject is how people stop their own invoicing system from delivering.

Since February 2024, Google and Yahoo require all three from bulk senders, plus one-click unsubscribe on marketing mail and a spam complaint rate kept under 0.3%. That is not a guideline; mail that fails it is rejected.

Check any domain from a terminal:

dig +short TXT example.com | grep spf
dig +short TXT _dmarc.example.com

Authentication is necessary and not sufficient

The rest is behaviour, and it is where most deliverability is actually won or lost:

• Send from a subdomain. mail.example.com for transactional, a different one for marketing. Then a badly received campaign cannot damage the reputation carrying your password resets. Keep them separate from the first day; separating them later is much harder.
• Warm up gradually. A new sending domain going from zero to 50,000 messages in a day looks exactly like a compromised account.
• Never buy a list. Spam traps are seeded addresses that exist only on purchased lists, and hitting one gets you blocked outright.
• Honour unsubscribes immediately, and make the link obvious. A complaint is far more damaging than an unsubscribe: a user who cannot find the unsubscribe link presses the spam button, and that is the metric that gets you blocked.
• Set a real Reply-To. no-reply@ addresses depress engagement, and engagement is a ranking signal.

Process bounces and complaints

Your provider sends webhooks for delivery, bounce and complaint events. Handle them, and store the result.

A hard bounce means the address does not exist. Continuing to send to it is one of the strongest negative signals there is. Mark it dead and stop. A soft bounce is temporary (a full mailbox) and can be retried a few times. A complaint means somebody pressed spam; suppress that address permanently, whatever your records say about consent.

Testing it

Send to a real Gmail account and open “Show original”. You want to see SPF: PASS, DKIM: PASS and DMARC: PASS. mail-tester.com is free, gives you a score out of 10 and names what is wrong. Do this before launch, not after the first support ticket.

In development, do not send at all. Mailpit or MailHog (one binary each, free) capture everything and show it in a web UI.

The free path

Brevo has a free tier of a few hundred messages a day; Resend and Mailgun have small free tiers; Amazon SES is the cheap option at large volume and gives you almost no hand-holding; Postmark costs more and is the most reliable for transactional mail specifically. Free tiers move constantly, so check before you build against one, and keep the sending code behind a small interface so switching provider is an afternoon rather than a project.