Magento 2 SMTP: come liberarsi dal mail() di PHP e raddoppiare la deliverability

Magento 2 è una delle piattaforme e-commerce più potenti per il mercato italiano, ma in installazione standard ha lo stesso problema della maggior parte dei CMS PHP: invia email tramite la funzione mail() di sistema, senza autenticazione né tracciamento. In un negozio reale questo si traduce in tassi di consegna sotto il 60%: le conferme ordine finiscono in spam, i recuperi password vengono ignorati, le notifiche admin di nuovi ordini non arrivano, e il cliente chiama infuriato pensando che il pagamento sia fallito. La buona notizia è che la migrazione a un SMTP autenticato è relativamente semplice in Magento 2 e i benefici sono immediati: in casi reali documentati la deliverability può raddoppiare o quasi nei primi 30 giorni. In questo articolo vediamo configurazione admin, modulo Mageplaza SMTP, alternative open source, e come misurare il miglioramento.

Cosa Magento 2 invia di default

Magento 2 in installazione standard genera circa 15-25 tipi di email transactional:

• Account: registrazione, conferma email, recupero password, change email
• Order: conferma ordine, aggiornamento status, fatturazione, spedizione, tracking
• Newsletter: subscribe, unsubscribe
• Cart: cart abandonment (con modulo dedicato)
• Reviews: nuova recensione, moderazione
• Admin: nuovo ordine, low stock, contact form
• RMA: richiesta reso, status reso

Tutte vanno dallo stesso sender configurato in Stores > Configuration > General > Store Email Addresses, attraverso PHP mail() per default. Se l'hosting è condiviso e/o l'IP è in blacklist, l'intero flusso commerciale è compromesso.

Configurazione admin: i quattro mittenti

Magento 2 espone quattro identità sender separate:

Per ognuno: Name + Email Address. Importante: tutti gli indirizzi devono essere sullo stesso dominio del sito, e quel dominio deve avere SPF, DKIM, DMARC configurati. Email cross-domain (sender noreply@altrodominio.it per sito su tuodominio.it) falliscono DMARC alignment.

Setup SMTP via modulo Mageplaza

Magento 2 NON ha settings SMTP nativi: la configurazione richiede un modulo esterno. Il più diffuso è Mageplaza SMTP, gratuito e mantenuto:

Installazione

cd /var/www/magento
composer require mageplaza/module-smtp
php bin/magento module:enable Mageplaza_Smtp
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f
php bin/magento cache:flush

Configurazione

1. Admin > Stores > Configuration > Mageplaza Extensions > SMTP
2. Section "General Configuration": Enable = Yes, Sender = General Contact
3. Section "SMTP Configuration for [scope]":

4. Test Connection: deve restituire "Success"
5. Send Test Email: invia mail a indirizzo specifico per validare end-to-end
6. Save Config + php bin/magento cache:flush

⚠️ Attenzione: configurazione SMTP "scope" è importante. Su installazioni multi-store puoi avere SMTP diverso per store/website. Default scope = "Default Config" applica a tutti. Override esplicito per uno store sovrascrive il default. Verifica sempre nel quale scope stai salvando.

Modulo nativo Magento 2.5+

Da Magento 2.5 (2023) è stata introdotta una sezione SMTP nativa, sotto Stores > Configuration > Advanced > System > Mail Sending Settings. Limitata rispetto a Mageplaza ma sufficiente per setup base:

• Transport: SMTP / Sendmail (default Sendmail = PHP mail())
• Host, Port, SSL, Username, Password
• Niente log, niente queue, niente backup mailer

Per piccoli store la nativa è ok. Sopra le 5.000 mail/mese conviene Mageplaza o alternativi (Magefan SMTP, Amasty SMTP).

Queue per evitare blocchi checkout

Default Magento 2 invia le email in linea con il checkout: il customer clicca "Place Order", e Magento aspetta che la SMTP rispondi prima di ritornare il "Thank You". Se SMTP è lento (1-3 secondi), il checkout sembra freezato. Soluzione: abilitare asynchronous emails.

php bin/magento config:set sales_email/general/async_sending 1
php bin/magento cache:flush

Ora le sales email vengono accodate in sales_email_log e processate dal cron job sales_send_order_emails (default ogni 5 minuti). Trade-off: il customer riceve la conferma ordine con 5 min di ritardo nominal. Per accelerare, riduci la cron frequency in crontab.xml a 1 min.

Log invii e debugging

Mageplaza SMTP include una sezione Email Logs (Admin > Stores > Mageplaza SMTP > Email Logs) con:

• Lista ultimi N invii con timestamp, recipient, subject, status
• Preview HTML del messaggio
• Pulsante "Resend" per invio manuale
• Filtro per status (sent/failed) e per data

Mantieni retention 30-60 giorni: il database Magento è già "pesante", non aggiungere milioni di righe email_log. Cron di pulizia notturna:

DELETE FROM mageplaza_smtp_email_log WHERE created_at < DATE_SUB(NOW(), INTERVAL 60 DAY);

Header transactional consigliati

Magento 2 di default non include header List-Unsubscribe e Feedback-ID. Vanno aggiunti via plugin Magento per template marketing (newsletter, abandoned cart). Esempio plugin:

// app/code/YourVendor/EmailHeaders/Plugin/MessagePlugin.php
namespace YourVendorEmailHeadersPlugin;

use MagentoFrameworkMailMessageInterface;

class MessagePlugin
{
    public function afterSetBody(MessageInterface $subject, $result)
    {
        $message = $subject->getMessage();
        $message->getHeaders()->addHeaderLine(
            'List-Unsubscribe',
            '<mailto:unsubscribe@tuodominio.it>, <https://tuodominio.it/unsubscribe>'
        );
        $message->getHeaders()->addHeaderLine('List-Unsubscribe-Post', 'List-Unsubscribe=One-Click');
        return $result;
    }
}

Benchmark deliverability

Test su negozio reale (settore moda, 8.000 ordini/mese, traffico Italia + DACH) in tre fasi:

Risultati tipici. La sola migrazione SMTP+auth porta a +20-25% di inbox rate. La combinazione con IP gestito e suppression list aggiunge altri 10-15%.

💡 Suggerimento: prima di valutare ROI di SMTP, fai un audit basic con tool gratuiti come MXToolbox Email Deliverability: verifica SPF, DKIM, DMARC, blacklist, MTA-STS, BIMI. Spesso il problema è già visibile prima di inviare.

Multi-store: SMTP separato per store

Per merchant con multiple store views (es. brand-it.it, brand-de.de, brand-fr.fr sullo stesso Magento), conviene SMTP separato per ogni store:

1. Mageplaza SMTP supporta scope a livello Website e Store View
2. Per Italia: smtp.targetsmtp.it con DKIM brand-it.it
3. Per Germania: stesso server SMTP, ma DKIM brand-de.de
4. SPF, DKIM, DMARC vanno pubblicati su ogni dominio usato come sender

Cart abandonment: il pattern critico

I template di cart abandonment sono i più filtrati: contengono link, CTA "compra ora", spesso pattern di promo. Best practice:

• Inviare dopo 4-6 ore dall'abbandono (non immediato)
• Massimo 2-3 reminder, poi stop
• Soggetti personalizzati con nome + prodotto, no "Hai dimenticato qualcosa?"
• Tracking link short via redirect dominio sito, non short URL pubblici (bit.ly, t.co)
• Test A/B su click rate, non open rate (vedi MPP)

Errori frequenti in Magento 2

1. Salvare SMTP password in chiaro nel core_config_data: usa env config php bin/magento config:sensitive:set smtp/configuration_option/password XYZ
2. Cron non attivo: senza cron le async sales email non partono. Verifica cron:run e crontab utente magento
3. Cache non flushata dopo config change: le modifiche SMTP non hanno effetto finché non fai cache:flush
4. Mageplaza SMTP attivo ma override non funzionante: il modulo a volte richiede priority più alta. Controlla che email_template non sia overridden da un altro modulo terzo
5. Magento Cloud + custom SMTP: su Magento Cloud serve whitelist outbound dei IP SMTP. Apri ticket support Adobe

Riferimenti

• Mageplaza SMTP docs
• Magento Commerce email docs
• Magento 2 Developer Docs
• RFC 7208 — SPF

Migrare Magento 2 da PHP mail() a SMTP autenticato è una delle iterazioni a più alto ROI per qualunque e-commerce: poche ore di lavoro, risultati misurabili in giorni, impatto diretto su conversion (i clienti che non ricevono la conferma ordine spesso disputano il pagamento). Target SMTP fornisce modulo Magento 2 dedicato che imposta automaticamente DKIM rotation, header List-Unsubscribe sui template marketing e Send-Time Firewall che blocca cart abandonment verso indirizzi in soft bounce ricorrente, preservando reputation IP nei momenti di volume alto come saldi e Black Friday.