SMTP 550 5.7.26 e 5.7.23: email non autenticata

Come appare il messaggio

550-5.7.26 Unauthenticated email from beispiel.de is not accepted due to domain's DMARC policy.

Cause frequenti

• L'IP che invia (newsletter, CRM, e-commerce) manca nel record SPF.
• SPF supera il limite di 10 lookup DNS e restituisce permerror.
• DKIM non firma, oppure il selector nel DNS non corrisponde alla chiave.
• Manca l'allineamento: SPF/DKIM passano per un dominio diverso da quello nel From:.
• Un inoltro tramite server terzi rompe SPF e non c'è DKIM a coprire.

Verifica

1. Interroga il record SPF del dominio mittente
   dig +short TXT example.com | grep spf1Copia
2. Interroga la policy DMARC
   dig +short TXT _dmarc.example.comCopia
3. Controlla la chiave DKIM del selector
   dig +short TXT default._domainkey.example.comCopia
4. Testa la chiave DKIM contro il DNS (OpenDKIM)
   opendkim-testkey -d example.com -s default -vvvCopia
5. In una mail di test consegnata, controlla l'header Authentication-Results: spf=, dkim= e dmarc=

Soluzione

• Inserisci tutte le sorgenti di invio con ip4:/include: nel record SPF e chiudilo con ~all o -all.
• Resta sotto i 10 lookup: togli gli include inutili o sostituiscili con range IP.
• Attiva la firma DKIM sul server o nel servizio di invio e pubblica la chiave pubblica in selector._domainkey.
• Per i servizi esterni configura un return-path o un dominio DKIM personalizzato, così l'allineamento torna.
• Parti con DMARC p=none e report rua=, analizzali e poi stringi la policy.

Domande frequenti

Che differenza c'è tra 5.7.26 e 5.7.23?

5.7.26 indica che DMARC è fallito o che la mail non è autenticata affatto. 5.7.23 indica che è fallito proprio il controllo SPF, di solito con -all.

Basta SPF per Gmail?

Per chi invia in volume no: Google chiede SPF e DKIM più DMARC. Anche con pochi invii DKIM è la base più solida, perché sopravvive agli inoltri.