1,201 26/03/2026 07/04/2026 3 min

Quando le mail iniziano a finire in spam o restano in coda, il problema spesso non è “il provider”, ma una verifica che non viene fatta con regolarità: SPF, DKIM, DMARC, code di invio e header reali delle email spedite.

Un modo semplice per evitare controlli manuali è automatizzare una verifica giornaliera con cron o systemd timer, salvando un report e inviando un alert solo se qualcosa non torna. L’idea è controllare tre cose: la configurazione DNS, la firma delle mail e il comportamento della coda SMTP.

Diagnosi probabile

Se la deliverability peggiora all’improvviso, le cause più comuni sono:

  • record SPF troppo permissivo o non allineato al server che invia;
  • DKIM attivo ma firma non valida dopo un cambio di chiave o di selector;
  • DMARC presente ma in modalità monitoraggio, quindi i problemi restano invisibili;
  • coda mail bloccata o rallentata da limiti del relay, rifiuti temporanei o retry troppo aggressivi.

Verifiche immediate

Prima di automatizzare, controlla manualmente un invio di test verso una sandbox o un mailbox di prova che mostri gli header completi.

  1. Invia una mail di test e apri gli header completi: cerca SPF=pass, DKIM=pass e DMARC=pass.
  2. Controlla la coda locale con il comando del tuo MTA: per esempio, su Postfix, mailq o postqueue -p. L’esito atteso è una coda vuota o in diminuzione.
  3. Verifica i DNS pubblici con un tool affidabile, ad esempio MXToolbox o un resolver interno, per confermare che i record SPF, DKIM e DMARC pubblicati siano quelli attesi.

Soluzione consigliata passo-passo

Usa un piccolo script che esegua controlli in sequenza e generi un report leggibile. Esempio di flusso:

  1. Salva un backup dei file coinvolti, se il controllo legge configurazioni locali, prima di modificarli.
  2. Prepara uno script che faccia almeno questi controlli: lookup DNS di SPF/DMARC, verifica del selector DKIM, lettura della coda mail e ricerca di errori ricorrenti nei log.
  3. Programma l’esecuzione con cron o systemd timer una volta al giorno, in orario di bassa attività.
  4. Fai inviare l’output solo in caso di anomalia, ad esempio se la coda supera una soglia o se manca un pass negli header del messaggio di test.

Un esempio minimale con systemd timer è spesso più robusto di cron perché registra meglio gli esiti:

[Unit]
Description=Controllo deliverability email

[Service]
Type=oneshot
ExecStart=/usr/local/bin/check-mail-delivery.sh

Poi aggiungi il timer giornaliero e verifica che parta davvero con systemctl list-timers. Se preferisci cron, usa un job che scriva il report in un file e invii una mail solo quando trova errori.

Controlli finali / rollback

  1. Esegui un test in sandbox e conserva il messaggio con gli header completi come prova di riferimento; l’esito atteso è una catena SPF/DKIM/DMARC coerente.
  2. Controlla il report automatico per 2-3 cicli consecutivi: se segnala falsi positivi, abbassa la sensibilità della soglia o correggi il selector DKIM.
  3. Se una modifica ai record DNS peggiora la deliverability, ripristina il valore precedente dal backup e ripeti il test in sandbox prima di rimettere in produzione.
La regola pratica: non limitarti a “spedire una mail di prova”. Verifica anche gli header, la coda e un alert automatico, così i problemi emergono prima che lo facciano gli utenti.