Send Laravel mail with Lettermint, set up for you

Brewless makes the project, the sending token, the domain and the DNS records for a Laravel app that sends through Lettermint, in your own Lettermint team.

In this post
  1. What does Brewless do at Lettermint?
  2. Why a project per application?
  3. How do I set it up?
  4. Which DNS records does it need?
  5. What do I see afterwards?
  6. Which mailer should I pick?

Transactional mail is the part of a Laravel application that quietly leaves your infrastructure: a password reset, an invoice, a notification. Where it is sent from decides whose law applies to the addresses in it. Lettermint is a Dutch email service that keeps that traffic inside Europe, and since this week Brewless sets an application up there for you: the project, the sending token, the domain and its DNS records.

What does Brewless do at Lettermint?

With a Lettermint Team API token connected that may write, a deploy of an environment with mail: lettermint gives the application a project of its own at Lettermint, makes a sending token for that one environment and puts it in your own Secret Manager, makes the domain when your team has none of that name, and sets the domain to send from that project. The DNS records Lettermint asks for are named on the plan of the deploy and written after your yes.

Without a connected token nothing is made: the mailer is set and the token stays yours to push. The same application, the same file, one step more by hand.

Why a project per application?

Lettermint organises sending in projects, each with its own tokens, routes and suppressions. Brewless gives every application a project of its own there, the same way it gives every application a Scaleway project of its own: one application's mail cannot be sent with another's token, and revoking a token stops exactly one environment.

At Lettermint What Brewless makes Named after
Project One per application The application
Sending token One per environment Brewless · <application>-<environment>
Domain One, when your team has none of that name The domain the environment sends from

Note

A project you already have, of the same name, is used as it stands. Brewless does not change its routes, its settings or its other tokens, and the only token it ever revokes is the one it made for that environment, when it puts a new one in its place.

How do I set it up?

Three steps: the package in your application, the token on the Providers page, and one line in brewless.yml.

Install the Laravel package Lettermint publishes, which registers the lettermint mailer:

composer require lettermint/lettermint-laravel

Create a Team API token in your Lettermint team with read:domains, read:messages, read:suppressions and read:projects, and add write:projects and write:domains to have Brewless set environments up. Paste it on the Providers page of your organisation in Brewless.

Then name the mailer for the environment:

brewless.yml
environments:
  production:
    kind: production
    domains:
      - shop.example.eu
    mail: lettermint

A deploy shows what it will do before it does it:

brewless plan
brewless deploy

Which DNS records does it need?

Lettermint asks for four: two DKIM names and a return path, each a CNAME, and a DMARC policy as a TXT record. Brewless reads them from Lettermint, compares them with your zone, and names the ones that are missing.

Record Type What it is for
lm1._domainkey CNAME The first DKIM key, which Lettermint rotates itself
lm2._domainkey CNAME The second DKIM key, for that rotation
lm-bounces CNAME The return path, so bounces come back to Lettermint
_dmarc TXT A DMARC policy, only when your domain has none

In a DNS zone Brewless manages, writing them is one yes: brewless deploy --mail-records, or the button on the Mail page of the domain. Every change goes into the audit trail, and right after writing Brewless asks Lettermint to look at the records again, so the domain starts sending sooner.

Warning

A DMARC policy you chose yourself is never replaced, and the MX records of a domain that receives mail are never touched. A domain that already receives mail keeps receiving it.

What do I see afterwards?

The Mail page of the environment shows the domain with the state of each record, what Lettermint counted over the last 30 days, the newest messages with every delivery attempt, and the addresses Lettermint suppresses. A message keeps its content at Lettermint for 28 days, so Brewless needs no copy of its own to show it; nothing of it is stored here.

The variables of the environment show MAIL_MAILER, MAIL_FROM_ADDRESS and LETTERMINT_PROJECT_TOKEN, the last one pointing at the secret in your own Secret Manager. See Mail and Connecting providers for the details, and Scaleway Transactional Email for Laravel, compared for the other mailer Brewless sets up.

Which mailer should I pick?

Both keep your mail in Europe, and both are billed to you by the provider. Transactional Email runs in the Scaleway project your application already has; Lettermint is a second account, with a dashboard of its own and a message log that keeps content for 28 days.

Scaleway Transactional Email Lettermint
Account The Scaleway project of the application Your Lettermint team
Set up by Brewless Offer, domain, a sending identity, copies in your own bucket Project, sending token, domain
DNS records SPF, DKIM, DMARC Two DKIM CNAMEs, a return path, DMARC
Content of a sent mail From the copies Brewless keeps in your bucket, for as long as you say Kept by Lettermint for 28 days
In brewless.yml mail: scaleway, or nothing at all in production mail: lettermint

Pick the one whose dashboard you want to be in when a mail does not arrive. Brewless sets up either, and never replaces a MAIL_MAILER you set yourself.

Frequently asked questions

Do I need a Lettermint account of my own?

Yes. Lettermint bills you directly, the way Scaleway and bunny.net do. Brewless works in your team with a Team API token you paste on the Providers page, and it does not resell mail.

What can Brewless do in my Lettermint team?

With a Team API token that may write projects and domains, it makes a project named after your application, a sending token for one environment, and the domain when your team has none of that name. It never sends mail through your token, never changes a project you already have, and the only token it revokes is one it made for that same environment.

Where does the sending token end up?

In your own Secret Manager at Scaleway, as LETTERMINT_PROJECT_TOKEN for that environment. Brewless keeps the name of the secret and the name of the token at Lettermint, never the token itself, and Lettermint shows a token only once.

What if my DNS is not with a provider Brewless manages?

Then the four records are listed on the Mail page and on the plan of your deploy, with their names and values, and adding them stays yours. Lettermint checks them whenever you ask it to.

Can I use Lettermint without connecting a token?

Yes. mail: lettermint then only sets MAIL_MAILER and MAIL_FROM_ADDRESS, and names LETTERMINT_PROJECT_TOKEN as a variable for you to push with brewless env:push.

All posts Read this post as markdown

Try it on your own app

Brewless deploys your Laravel app to Scaleway and bunny.net, in your own accounts. Start free with one application, production included.