Email transazionali di Laravel che finiscono in spam o non arrivano: diagnosi e fix su VPS unmanaged
Un e-commerce Laravel su Hetzner inviava 800 email transazionali al giorno tramite Postfix locale. Il 40% finiva in spam su Gmail, il 15% non arrivava affatto su Outlook. Il titolare non lo sapeva perché nessuno monitorava i bounce. Diagnosi: niente SPF, niente DKIM, niente DMARC, IP del VPS in due blacklist. La soluzione non era "aggiustare Postfix" - era ripensare come un'applicazione Laravel in produzione deve gestire le email transazionali nel 2025. Continua a leggere
Ultima modifica:
Un VPS OVH con Debian 11 e Laravel 10 non vedeva un apt upgrade da 14 mesi. 247 pacchetti arretrati, 38 security patch mancanti, OpenSSH con regreSSHion non patchato. Il proprietario non lo sapeva - l'app funzionava. Il protocollo per aggiornare un server di produzione senza downtime: snapshot, dry run, upgrade in due fasi, needrestart, verifica applicativa e setup unattended-upgrades. 
Dopo aver recuperato server e credenziali, resta il problema vero: 85.000 righe di codice Laravel senza documentazione, zero test, business logic nei Blade template, e un titolare che deve sapere entro venerdì cosa può rompere e cosa si può toccare. Il metodo in 48 ore: scansione automatica con PHPStan, mappatura rotte, analisi schema, tracciamento flusso di business e consegna di una mappa di rischio prioritizzata.