Per usare Mailgun attraverso il mailer di Laravel conviene configurare il trasporto previsto dal framework. L’SDK Mailgun diretto è un’altra possibilità, utile quando servono API specifiche: non è un prerequisito per inviare una Mailable con Laravel.
Qui considero un’applicazione Laravel 12 e un dominio Mailgun già disponibile. L’obiettivo è un’integrazione verificabile per email applicative, prima di ragionare su volumi e automazioni.
Installare il trasporto corretto
La documentazione Laravel del driver Mailgun indica queste dipendenze:
composer require symfony/mailgun-mailer symfony/http-clientIl progetto deve avere un mailer con transport impostato a mailgun in config/mail.php e il relativo servizio in config/services.php. Controlla i file effettivi dell’applicazione: progetti creati in momenti diversi possono avere configurazioni iniziali differenti.
Collegare dominio, credenziale e regione
Dominio di invio e chiave devono provenire dall’ambiente. Non inserirli nel repository o nel frontend. L’endpoint deve corrispondere alla regione dell’account o del dominio utilizzato.
Una configurazione europea può usare api.eu.mailgun.net dove previsto dal servizio; non va scelta soltanto perché il destinatario si trova in Europa. La guida iniziale Mailgun è il riferimento per preparare e verificare il dominio.
Dopo una modifica alla configurazione, considera la cache Laravel e i processi persistenti: un worker già avviato può continuare a usare i valori precedenti finché non viene riavviato con la procedura di rilascio.
Provare prima il messaggio, poi il trasporto
Separerei la verifica di destinatario, oggetto e contenuto dalla prova di rete. Un test con il mailer simulato può confermare che l’applicazione chieda l’invio corretto; non dimostra che Mailgun accetti il messaggio.
Per la prova del trasporto userei un destinatario di test controllato. Gli eventuali limiti del dominio sandbox devono essere rispettati prima di interpretare un rifiuto come un errore del codice.
Gestire code e risultati
Accodare un invio evita di trattenere la richiesta web, ma richiede worker attivi e monitoraggio dei fallimenti. Un retry dopo un timeout può produrre un duplicato se il provider aveva già accettato il messaggio.
Registrerei un riferimento applicativo e l’identificatore del provider quando disponibile. Accettazione, consegna e lettura non sono lo stesso evento; bounce e segnalazioni devono influire sui tentativi successivi.
Se usi webhook, verifica l’autenticità secondo le istruzioni del provider e gestisci notifiche ripetute. Il risultato da cercare è una catena osservabile tra richiesta applicativa e stato dell’invio, senza considerare una chiamata riuscita come garanzia di recapito in posta in arrivo.