Making Sure Your Application's Email Arrives
Last updated:
The default silently fails
PHP's basic mail function hands the message to the local mail system, which typically sends it without proper authentication. Recipient providers discard such messages without a bounce.
The application logs a success, the user is told the message was sent, and nothing arrives. It is the most expensive silent failure in web applications.
What to do instead
- Authenticated SMTP through your mail provider, or a transactional email service
- Send from a domain you control, with correct authentication records
- Put the user's address in reply-to, never in from
- Log every send with its outcome
- Handle bounces, rather than ignoring them
Domain authentication
- SPF, listing whatever sends on your behalf
- DKIM signing, configured with your provider
- DMARC, starting in monitoring mode
- All three checked after any change to your sending setup
Those three records are what let receiving providers verify your mail is genuinely yours. Without them, deliverability is a matter of luck.
Separate transactional from marketing
Marketing email affects sender reputation. Sending both from the same domain means a poorly-received campaign can affect delivery of password resets and order confirmations.
A subdomain for marketing keeps the reputations separate, which protects the mail that genuinely matters.
Monitor it
| Watch | Why |
|---|---|
| Send failures | Configuration has broken |
| Bounce rate | Invalid addresses accumulating |
| Complaint rate | Reputation damage |
| A test send weekly | Silent failures are caught in days |
| Queue depth | Sending has stopped |
Frequently asked questions
Which service should we use?
How do we know if email is arriving?
Why does our mail go to spam?
Should we queue email?
Not certain your application's email arrives?
Send yourself one from the live system and check the headers. It is usually revealing.
Related services
What we build for problems like this one