Email Setup

Overview

Mail is configured once for the whole install, in your .env file. Every schedule on the instance sends through that one mail transport. Without a working mail configuration these features do nothing:

What happens with no mail transport

While MAIL_MAILER is log or array, an email goes one of two ways:

What differs from the hosted service

• No plan gate. A selfhosted install resolves to the Enterprise feature set, so no email feature here is held back by a plan.
• No per-schedule sender. The Email Settings row, on the Integrations tab of the schedule form, is drawn only in hosted mode. Every schedule on your install sends through the transport you configure below. See Sender Configuration.
• No newsletter allowance. The monthly allowance of the hosted service, which counts individual recipients rather than newsletters, does not apply. Your schedules send unlimited newsletters to unlimited recipients.
• No platform mail. Onboarding and activation nudges, the weekly owner digest, plan renewal reminders and referral credit notices belong to the hosted service. Their scheduled tasks do nothing while IS_HOSTED=false.

What Is Sent Automatically

Most mail answers something a person just did, such as a purchase, a booking or a password reset. The emails below go out on a timer or on someone else's action instead, so they are the ones an operator gets asked about. Every one of them needs a real mail transport; the table says what else each needs.

Every row that is checked on the hour or once a day is a scheduled task, so it needs the schedule:run cron entry from the installation guide even when QUEUE_CONNECTION=sync. Six optional variables change the timing and the size of the digest and the interest list's emails:

SMTP Setup

SMTP is the recommended setup for a selfhosted install: it works with every provider and needs no extra packages. You can point it at your hosting provider's mail server, a mailbox at Gmail or Microsoft 365, or a transactional email service such as Amazon SES, Mailgun or Postmark.

Configure it in four steps

1. Get SMTP credentials from your provider. A host name, a port, a username and a password. Transactional services issue SMTP credentials that are separate from their API keys.
2. Add the variables to .env. Use the block below as a starting point and replace every value.
3. Clear the config cache. Run php artisan config:clear, otherwise the old values keep being used.
4. Send yourself a test message. See Testing below.

Environment Variables

Add these to your .env file:

MAIL_MAILER=smtp
MAIL_HOST=smtp.example.com
MAIL_PORT=587
MAIL_USERNAME=[email protected]
MAIL_PASSWORD=your-password
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=[email protected]
MAIL_FROM_NAME="${APP_NAME}"

Variable Reference

Popular SMTP Providers

Here are the settings for commonly used SMTP services:

Other Mail Drivers

Besides SMTP, Event Schedule ships with the mailers listed below. Set the one you want as MAIL_MAILER. Anything not in this table has to be added to config/mail.php yourself, and the app will fail with "Mailer is not defined" until it is.

For a production install we recommend SMTP pointed at a transactional email service such as Mailgun, Amazon SES or Postmark. These services are built for application-generated email, they let you authenticate your sending domain, and they deliver far better than a personal mailbox.

Sender Configuration

The MAIL_FROM_ADDRESS and MAIL_FROM_NAME determine who emails appear to come from. A fresh install ships with MAIL_FROM_ADDRESS="[email protected]", a reserved example domain that no receiving server will trust, so change it to an address on a domain you control before you send anything.

MAIL_FROM_ADDRESS=[email protected]
MAIL_FROM_NAME="My Event Schedule"

One sender for every schedule

On a selfhosted install this is the From address for all outgoing mail, whichever schedule triggered it. There is no per-schedule sender to configure: the Email Settings row of the schedule form's Integrations tab, where an owner supplies their own SMTP credentials, is part of the hosted service and is not rendered when the app runs selfhosted, so mail that a hosted schedule may only send from its own address, such as change and cancellation notices to ticket buyers, goes out from this one (see What Is Sent Automatically). Pick an address that reads sensibly for every schedule on the instance, and one you can actually receive replies at.

Three emails also name the schedule. The sign-up confirmation, the new-event digest and the interest list's emails keep your address but put the schedule in the sender name, for example "The Blue Note via My Event Schedule" with the settings above, and send replies to the schedule's own email address when it has one.

Testing

After configuring your email settings, verify that mail is really being sent. The Send Test Email button for SMTP settings belongs to the hosted-only Email Settings row, so on a selfhosted install you test the transport from the command line.

1. Clear the config cache

   Laravel caches .env values, so do this first or you will be testing the old configuration:

   bash Copy

   php artisan config:clear

2. Send a test message

   Use Laravel's built-in Artisan command to send a test email:

   bash Copy

   php artisan tinker --execute="Mail::raw('Test email from Event Schedule', function(\$m) { \$m->to('[email protected]')->subject('Test'); });"

   Send it to a real mailbox you can open. Addresses on the reserved test domains (example.com, example.org, example.net, test.com, test.org, test.net) and anything at @localhost are deliberately never emailed by the app's own notifications.

3. Confirm queued mail is being processed

   Ticket confirmations, sale alerts and newsletter batches are dispatched as background jobs rather than sent inline. Which means:

   • With the default QUEUE_CONNECTION=sync they run immediately, in the same request. Nothing extra is needed.
   • With database or redis they wait for a worker. Event Schedule's scheduler runs queue:work --stop-when-empty every minute and retries failed jobs every five minutes, so the schedule:run cron job from the installation guide is what actually drains the mail queue. No cron, no email.
   • Scheduled newsletters are also released by that same cron, once a minute.
   • The hourly and daily emails listed under What Is Sent Automatically are sent by tasks on that same cron, whatever the queue connection.

4. Run one through the app

   A real end-to-end check is a free RSVP or a test ticket purchase on one of your own schedules: it exercises the queue, the mailable and the sender address together.

   Two buttons inside the app also send through your transport once their feature is set up: Send test feedback email, in the Feedback row of the schedule form's Engagement tab while Post-event feedback is on, and Send Test Email in a schedule's graphic email settings. With MAIL_MAILER still on log or array, the feedback test answers "Email settings are not configured" instead of sending.

Troubleshooting