Your newsletter leaves through the mail provider you choose, under your own name. Your install's own mail, such as sign-in codes, goes its own way.
Paste this into your agent
Connect my Mailpiece newsletter to my mail provider and send me a test. Read mailpiece.dev/llms.txt first.
System mail
Sign-in codes and email changes go over SMTP_* and come from MAILER_FROM_ADDRESS. Any SMTP server works; port 587 unless set.
SMTP_ADDRESS=smtp.example.com
SMTP_USERNAME=apikey
SMTP_PASSWORD=...
# Optional: SMTP_PORT, SMTP_TLS=true for 465, SMTP_AUTHENTICATION, SMTP_DOMAINNewsletter mail
Issues, tests, welcome emails and confirmations never use SMTP_*. They leave through the relay or SMTP server each newsletter sets on Settings › Outgoing mail; without one, the newsletter mails nothing.
Nothing is checked when you set it: a wrong setting shows as a message that fails when sent.
Newsletter mail over SMTP
On Settings › Outgoing mail, set up an SMTP server with its Server, Port (587 unless changed), Username and Password. TLS follows the port: 465 is TLS from the first byte, and any other port must offer STARTTLS. Leave the username out for a server with no sign-in. Provider settings are on the integrations pages.
The password is never shown again. The server, port and username can be edited; to change the password, delete the SMTP server and set it up again. A newsletter has one way out, so setting up a relay replaces it.
A delivery that can't be confirmed is never sent twice: it shows on the post as unverified.
Only production sends through the newsletter's relay or SMTP server; in development, mail goes the environment's own way.
mailpiece settings sending smtp update --address smtp.example.com --port 587 \
--username ... --password ...
mailpiece settings sending smtp removeNewsletter mail through a relay
Mailpiece POSTs each message as JSON to a small relay you run, which calls any provider's API. A message with no answer Mailpiece can trust is posted again under the same Idempotency-Key, so the relay must send each key once. See Send through a relay.
Set it up on Settings › Outgoing mail with its Relay address and Token. The token is never shown again; to change it, delete the relay and set it up again.
mailpiece settings sending relay update --url https://relay.example.com --token ...
mailpiece settings sending relay removeSender
Each newsletter sets its from name, from address and reply-to on Settings › Sending. The from address must be one your provider lets you send from.
Bounces
Mailpiece does not hear from your provider. When it stops delivering to an address, an admin presses Mark as bounced on the subscriber's page, or your agent does it through the JSON API. No more posts go there, and only the person can undo it by subscribing again.
Sending speed
MAIL_DELIVERIES_PER_MINUTE, 30 with the shipped deploy file and 20 otherwise; match your provider's limit. Every 15 minutes a sweep requeues deliveries whose turn passed two hours ago.
When mail doesn't go out
Check Settings › Sending and Settings › Outgoing mail first: until the sender and a way out are both set, nothing goes out. A mailed post shows how far it got, and how many were refused or unverified. A subscriber's page lists each email sent to them and what became of it.
Then open the job queue at /admin/jobs, as the person who made the first account. Each issue and welcome email to a subscriber is a job of its own: Scheduled jobs holds those waiting their turn or a retry, and Failed jobs lists those that stopped, each with its error. Fix the cause, then retry them there. Mailpiece never mails anyone twice: a delivery already sent, refused or unverified is skipped.
Still need help? Ask on GitHub.