Laravel Mailables vs. Mail Notifications

When Laravel code sends email, a mailable describes the email itself. A notification carries an update to a recipient through one or more delivery routes, called channels. A channel can send email, store the update in a database, or broadcast it.

Choose a mailable when the code mainly needs to compose and send an email. Choose a mail notification when the code needs to deliver an update through more than one channel, such as sending it by email and storing it for the recipient. A notification can also use a mailable to create its email, so you can combine the two. The Laravel mail documentation and notification documentation describe these roles.

Mailables define the email

A mailable is a class that defines an email’s sender, subject, content, and attachments. It can use a Blade view, Laravel’s system for creating page and email content, to build the email body. Code sends the mailable through Laravel’s Mail facade. The sending code specifies the recipients and chooses whether Laravel sends the email now or queues it for later.

Use a mailable when the code needs control over how it builds or sends an email. An order confirmation with a custom layout and an attached document is a good fit. The sending code can set recipients directly through the mail facade, including carbon-copy and blind-carbon-copy recipients.

Mail notifications choose delivery channels

A notification class describes an event or update to send, such as an account alert. Its via method selects how Laravel delivers the update to a recipient. When email is one of the selected channels, Laravel calls toMail. By default, toMail returns a MailMessage, Laravel’s helper for building an email with text, links, and other common elements.

Laravel calls the object receiving a notification a notifiable. It is commonly a user model. For email, Laravel normally gets the recipient’s address from an email property. A notifiable can change how Laravel finds that address with routeNotificationForMail. Laravel also supports sending a notification directly to an email address when no stored user model is available.

Use a notification when delivery depends on the recipient’s routing or needs more than one channel. For example, a notification can send an account alert by email and store it in the database. Its via method can choose channels based on the recipient.

Choose based on what the code needs to represent

These are starting points, not strict limits. Notifications support custom views, Markdown formatting, and attachments, so they can produce detailed emails. Start with a mailable when the email itself is the main concern. Start with a notification when the code needs to handle an update based on its recipient.

Combine a notification with a mailable

A notification’s toMail method can return a full mailable. The notification still selects channels and routes the update, while the mailable defines the specialized email.

When a notification returns a mailable, the code must set the recipient on that mailable explicitly. The notification’s normal email routing does not set the mailable’s recipient as it does for a MailMessage.

Queueing does not decide the choice

Both options support queued delivery. Code can queue a mailable directly or configure it to queue by implementing Laravel’s ShouldQueue interface. A notification can also implement ShouldQueue. Laravel then creates a queued job for each recipient-and-channel combination.

This difference affects how many jobs Laravel schedules, not which option produces a better email. Choose based on whether the code mainly represents an email or an update delivered through selected channels.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com