{"id":370,"date":"2026-09-10T11:41:16","date_gmt":"2026-09-10T17:11:16","guid":{"rendered":"https:\/\/photonconsole.com\/blog\/?p=370"},"modified":"2026-09-10T11:41:17","modified_gmt":"2026-09-10T17:11:17","slug":"laravel-mail-configuration-for-production-delivery","status":"publish","type":"post","link":"https:\/\/photonconsole.com\/blog\/laravel-mail-configuration-for-production-delivery\/","title":{"rendered":"Laravel Mail Configuration for Production Delivery"},"content":{"rendered":"\n

Your Laravel app sends mail perfectly in local development. You push to production, and the emails stop arriving. No exception is thrown, no error appears in the logs, and Mail::send()<\/code> returns without complaint. Users report that password resets never arrive and order confirmations never show up.<\/p>\n\n\n\n

In most cases the application code is correct. What changed is the mail configuration, the queue, or the SMTP host your app is now talking to. This guide covers the full production setup: the .env<\/code> values that actually matter, mailable classes, queued sending, and the specific Laravel failures that let mail disappear without a trace.<\/p>\n\n\n\n

Quick Answer: How Do You Configure Mail in Laravel?<\/h2>\n\n\n\n

Set the SMTP mailer in your .env<\/code> file, then send through a mailable class:<\/p>\n\n\n\n

# .env\nMAIL_MAILER=smtp\nMAIL_HOST=smtp.photonconsole.com\nMAIL_PORT=587\nMAIL_USERNAME=your_project_api_user\nMAIL_PASSWORD=your_secret_api_key\nMAIL_ENCRYPTION=tls\nMAIL_FROM_ADDRESS=\"noreply@yourdomain.com\"\nMAIL_FROM_NAME=\"${APP_NAME}\"<\/code><\/pre>\n\n\n\n
use Illuminate\\Support\\Facades\\Mail;\nuse App\\Mail\\OrderShipped;\n\nMail::to($user->email)->send(new OrderShipped($order));<\/code><\/pre>\n\n\n\n
Laravel reads these values through config\/mail.php<\/code>. The application code rarely causes delivery failures. The host you authenticate against, and whether your domain is authorised to send, is what decides if the message reaches an inbox. An authenticated relay such as PhotonConsole<\/a> on port 587 removes most of the failure modes described below.<\/p>\n\n\n\n
How Laravel Actually Sends Mail<\/h2>\n\n\n\n
Since Laravel 9, the framework uses Symfony Mailer<\/a> underneath (earlier versions used SwiftMailer). Your app builds a message through a mailable class, Laravel hands it to the configured transport, and the transport opens an SMTP connection to whatever host you named in .env<\/code>.<\/p>\n\n\n\n
Laravel does not deliver the email itself. It is a client, not a mail server. That distinction explains most production failures: the Laravel side works exactly as written, but the transport it was pointed at cannot deliver.<\/p>\n\n\n\n
Note<\/p>\n\n\n\n
Configuration key names have shifted between Laravel versions. Laravel 11 and later accept MAIL_SCHEME<\/code> alongside MAIL_ENCRYPTION<\/code>, and Laravel 9 changed mailable classes from the older build()<\/code> method to envelope()<\/code> and content()<\/code>. Check the official Laravel mail documentation<\/a> for your specific version before copying configuration from an older tutorial.<\/p>\n\n\n\n
Why Laravel Mail Fails in Production<\/h2>\n\n\n\n
\"\"
Four points where a Laravel application reports success but no email is delivered.<\/figcaption><\/figure>\n\n\n\n
Most SMTP errors occur due to misconfiguration or authentication issues rather than faults in application code. These are the causes that account for the majority of Laravel delivery failures.<\/p>\n\n\n\n
1. MAIL_MAILER Is Still Set to log<\/h3>\n\n\n\n
Recent Laravel releases ship with MAIL_MAILER=log<\/code> as the default in .env<\/code>. This writes the entire email into storage\/logs\/laravel.log<\/code> instead of sending it. Everything appears to work \u2014 no error, no exception, and the mailable is rendered correctly. The message simply never leaves the server.<\/p>\n\n\n\n
This is the single most common reason a Laravel app “sends” mail that nobody receives.<\/p>\n\n\n\n
2. Configuration Is Cached<\/h3>\n\n\n\n
If php artisan config:cache<\/code> has been run, Laravel reads from the cached config file and ignores .env<\/code> entirely. You can correct every mail value in .env<\/code>, deploy, and see no change at all, because the cached configuration still holds the old credentials.<\/p>\n\n\n\n
3. The Queue Worker Is Not Running<\/h3>\n\n\n\n
If your mailable implements ShouldQueue<\/code>, Laravel pushes the message onto a queue instead of sending it. With no worker process running, jobs accumulate in the jobs<\/code> table and nothing is ever delivered. The application reports success because queueing the job succeeded.<\/p>\n\n\n\n
4. MAIL_FROM_ADDRESS Does Not Match an Authorised Domain<\/h3>\n\n\n\n
If your from address is noreply@yourdomain.com<\/code> but your domain has no SPF record covering the sending server, mailbox providers cannot verify the message and filter or reject it. This is covered fully in our guide to SPF, DKIM and DMARC<\/a>.<\/p>\n\n\n\n
5. Your Host Blocks Outbound SMTP<\/h3>\n\n\n\n
AWS, Google Cloud, DigitalOcean and Azure restrict outbound port 25 by default \u2014 AWS documents its port 25 throttle removal process<\/a> \u2014 and many shared hosts throttle SMTP entirely. The connection stalls and eventually times out with no useful message. Our breakdown of SMTP connection timeouts<\/a> covers the diagnosis.<\/p>\n\n\n\n
Quick Fix<\/p>\n\n\n\n
Laravel Sends Locally but Not in Production<\/p>\n\n\n\n