Salta al contenuto principale
Sistemi Attivi
WP Planet — WordPress Cloud & Managed Services
Torna al MagazineInfrastruttura

Email deliverability WordPress: perché le email di WooCommerce finiscono nello spam

01 Nov 2026 — 15:20 9 min di lettura
Email deliverability WordPress: perché le email di WooCommerce finiscono nello spam

Le email di conferma ordine che non arrivano sono il problema silenzioso che costa recensioni negative e chargeback. wp_mail su hosting shared è quasi sempre in spam. Come configurare SMTP dedicato, SPF, DKIM e DMARC, e perché i servizi transazionali battono wp_mail.

Il problema arriva così: un cliente chiama perché non ha ricevuto la conferma ordine. Tu guardi l'ordine in admin, è lì, pagato, processato. Ma l'email non è arrivata. Non è nello spam del cliente — non è partita, o è partita ed è stata bloccata dal server di destinazione. È il problema più silenzioso di WooCommerce: le email ci sono, gli ordini ci sono, ma le conferme non arrivano. E ogni email non arrivata è un cliente che pensa che il suo ordine sia andato perso — o peggio, che il tuo negozio non sia affidabile.

La causa quasi sempre è wp_mail. WordPress usa wp_mail per inviare le email, e wp_mail usa la funzione mail() di PHP, che usa il server di posta del sistema operativo. Su hosting shared, quel server di posta è condiviso tra centinaia di siti — e gli IP dei server shared sono quasi sempre in blacklist per via della spam che altri siti sullo stesso server inviano. Risultato: le tue email di conferma ordine partono dallo stesso IP da cui parte la spam di un altro sito — e finiscono nello spam o vengono rifiutate.

Il SMTP dedicato: il primo passo (non opzionale)

La soluzione è non usare il server di posta del hosting. Configura wp_mail per usare un SMTP dedicato — un server di posta professionale con IP pulito e reputazione gestita. Le opzioni: un servizio SMTP (SendGrid, Mailgun, Postmark, Brevo) o un server di posta dedicato. Per WooCommerce, un servizio transazionale è la scelta migliore: gestiscono la reputazione dell'IP, il monitoraggio delle consegne, e il feedback dei loop di feedback (quando Gmail o Outlook segnalano spam).

La configurazione con WP Mail SMTP (il plugin più usato) e un servizio SMTP generico:

wp-config.php
// Configurazione SMTP via wp-config.php (più sicuro di nel database)
// Definisci le credenziali nel wp-config.php, non nel plugin

define( 'WPMS_SMTP_HOST', 'smtp.example.com' );
define( 'WPMS_SMTP_PORT', 587 );           // STARTTLS
// define( 'WPMS_SMTP_PORT', 465 );          // SSL (alternativa)
define( 'WPMS_SMTP_ENCRYPTION', 'tls' );    // o 'ssl' per la porta 465
define( 'WPMS_SMTP_USER', 'noreply@example.com' );
define( 'WPMS_SMTP_PASS', 'password-app-generata' ); // usa una password app, non la principale

// From header coerente: usa lo stesso dominio del sito
define( 'WPMS_MAIL_FROM', 'noreply@example.com' );
define( 'WPMS_MAIL_FROM_NAME', 'WP Planet' );

// Nei servizi transazionali (SendGrid, Mailgun),
// l'autenticazione può essere via API key invece di SMTP:
// define( 'WPMS_SMTP_USER', 'apikey' );
// define( 'WPMS_SMTP_PASS', 'SG.xxxxx...' );
Nota: Le credenziali SMTP nel wp-config.php sono più sicure del database perché wp-config.php non è accessibile dal browser. Usa una password app dedicata, non la password principale dell'account email. Per SendGrid/Mailgun, usa l'API key come password con 'apikey' come username.

SPF, DKIM e DMARC: i tre record DNS che fanno arrivare le email

Configurare l'SMTP non basta — se il dominio del mittente non ha SPF, DKIM e DMARC nei DNS, le email vengono comunque marcate come sospette. SPF dice quali server sono autorizzati a inviare email per il dominio. DKIM firma le email con una chiave crittografica. DMARC dice al server di destinazione cosa fare se SPF o DKIM falliscono. Senza questi tre record, anche l'SMTP migliore non garantisce la consegna.

Terminale
# Record DNS per la deliverability delle email
# (aggiungi nel pannello DNS del tuo dominio)

# SPF: autorizza il server SMTP a inviare per example.com
# TXT @  v=spf1 include:_spf.sendgrid.net ~all
# (sostituisci _spf.sendgrid.net con il SPF del tuo provider)
# ~all = soft fail (consiglia ma non blocca), -all = hard fail (blocca)

# DKIM: aggiungi la chiave pubblica fornita dal provider SMTP
# TXT s1._domainkey  k=rsa; p=MIGfMA0GCSqGSIb3...
# (la chiave pubblica è generata dal provider e va copiata letteralmente)

# DMARC: policy di gestione per email che falliscono SPF/DKIM
# TXT _dmarc  v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=s
# p=quarantine: metti in spam le email che falliscono (più sicuro di p=none)
# p=reject: blocca le email che falliscono (più aggressivo, usa dopo test)
# rua=mailto: ricevi report aggregati per monitorare

# Verifica i record DNS
dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT s1._domainkey.example.com +short
Nota: Inizia con p=quarantine per DMARC — non rifiuta le email ma le marca. Dopo un mese di monitoraggio dei report (rua), se non ci sono falsi positivi, passa a p=reject. Il passaggio diretto a reject senza test può bloccare email legittime se SPF o DKIM sono mal configurati.

Perché i servizi transazionali battono wp_mail

wp_mail è una funzione semplice: invia un'email e basta. Non traccia la consegna, non gestisce i bounce, non fornisce analytics. Un servizio transazionale (SendGrid, Mailgun, Postmark, Brevo) fa tutto questo: traccia ogni email, ti dice se è stata consegnata, aperta, o se è stata rifiutata. Per un e-commerce, questo è essenziale — se il 5% delle email di conferma ordine viene rifiutata, stai perdendo il 5% dei clienti che non ricevono conferma e pensano che il negozio non sia affidabile.

La differenza è misurabile. Con wp_mail su hosting shared, il tasso di consegna è tipicamente del 70-85% — il 15-30% finisce in spam o viene rifiutato. Con un servizio transazionale e SPF/DKIM/DMARC configurati, il tasso di consegna è del 95-99%. Su mille ordini al mese, la differenza è tra 150-300 clienti che non ricevono la conferma e 10-50. Il costo del servizio transazionale (5-20€/mese per volumi piccoli) si paga da solo in recensioni positive e chargeback evitati.

Il test: verifica la deliverability prima di andare in produzione

Prima di lanciare un e-commerce o dopo aver cambiato SMTP, testa la deliverability con strumenti dedicati. Mail-Tester.com ti dice se la tua email passa i filtri anti-spam:

Terminale
# Test di deliverability con mail-tester.com
# 1. Vai su https://www.mail-tester.com/
# 2. Copia l'indirizzo email generato (es. test-abc123@mail-tester.com)
# 3. Invia un'email di test dal tuo WordPress:

wp eval 'wp_mail("test-abc123@mail-tester.com", "Test deliverability", "Email di test da WooCommerce");'

# 4. Aggiorna la pagina di mail-tester.com per vedere il punteggio
# Punteggio target: 9/10 o 10/10
# Se hai meno di 7/10, il report ti dice cosa manca (SPF, DKIM, DMARC)

# Test alternativo: invia a un tuo indirizzo Gmail e controlla i dettagli
# In Gmail: mostra originale → Authentication Results
# Deve mostrare: spf=pass, dkim=pass, dmarc=pass
Nota: Se il punteggio è sotto 7/10, il problema è quasi sempre uno dei tre record DNS (SPF, DKIM, DMARC) o l'IP del server SMTP in blacklist. Verifica i record DNS con dig e l'IP con mxtoolbox.com/blacklists. Un IP in blacklist richiede delisting dal provider della blacklist — può richiedere giorni.

Le email di WooCommerce sono infrastruttura silenziosa — non ci pensi finché non si rompono. E quando si rompono, il danno è invisibile ma reale: clienti che non ricevono conferme, recensioni negative, chargeback da ordini che il cliente pensa non siano andati a buon fine. La configurazione SMTP + SPF + DKIM + DMARC è il lavoro di un'ora che previene mesi di problemi silenziosi. Non è opzionale — è la base di un e-commerce professionale.

Check-up WordPress

Verifica lo stato del tuo WordPress con un check-up gratuito.

Analisi di sicurezza, prestazioni e configurazione tecnica senza impegno commerciale.

Check-up WordPress
Condividi