Sending Email from a Website, Done Properly
How contact forms, receipts and password resets get delivered from a website, using an authenticated mail service rather than the web server's default mail function.
Marcus Adeyemi
Where most projects go wrong
The usual mistakes:
- Relying on the server's default mail function
- Sending from domains you have not authenticated
- Contact forms that send from the visitor's address
- No record of failed deliveries
What good looks like instead
- Send through an authenticated transactional provider
- Set up SPF, DKIM and DMARC
- Queue emails instead of sending during the request
- Log delivery status and bounces
- Use a real reply-to address
Why it matters
Email sent without authentication from a web server often lands in spam or is rejected, so customers miss orders and password resets.
The specs that matter
| Measure | Figure |
|---|---|
| Authentication | SPF, DKIM and DMARC on the sending domain |
| Transactional services | dedicated providers improve deliverability and logging |
| Queues | sending email in background jobs keeps pages fast |
| Bulk sender rules | major mailbox providers require authentication for high-volume senders |
Knowing when to hand it over
Tip: Bring in help when order or password emails go missing, or when moving hosting providers.
Where this comes from
- Laravel Documentation — Mail
- RFC Editor — RFC 7489 Domain-based Message Authentication, Reporting, and Conformance
The figures and practices above come from the sources listed.
Working on something like this?
We take on Web Design & Development work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
