SMTP 550 5.7.26 und 5.7.23: Mail nicht authentifiziert

So sieht die Meldung aus

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

Häufige Ursachen

• Die versendende IP (Newsletter-Tool, CRM, Webshop) fehlt im SPF-Record.
• SPF überschreitet das Limit von 10 DNS-Lookups und liefert permerror.
• DKIM signiert nicht, oder der Selector im DNS passt nicht zum Schlüssel.
• Kein Alignment: SPF/DKIM bestehen für eine andere Domain als die im From:.
• Weiterleitung über fremde Server bricht SPF, und DKIM fehlt als Absicherung.

Prüfen

1. SPF-Record der Absenderdomain abfragen
   dig +short TXT beispiel.de | grep spf1Kopieren
2. DMARC-Policy abfragen
   dig +short TXT _dmarc.beispiel.deKopieren
3. DKIM-Schlüssel für den Selector prüfen
   dig +short TXT default._domainkey.beispiel.deKopieren
4. DKIM-Schlüssel gegen DNS testen (OpenDKIM)
   opendkim-testkey -d beispiel.de -s default -vvvKopieren
5. Im Header einer zugestellten Testmail die Zeile Authentication-Results auf spf=, dkim= und dmarc= prüfen

Lösung

• Alle Versandquellen per ip4:/include: in den SPF-Record aufnehmen und mit ~all oder -all abschließen.
• SPF unter 10 Lookups halten: unnötige includes entfernen oder durch IP-Bereiche ersetzen.
• DKIM-Signierung am Mailserver bzw. im Versanddienst aktivieren und den öffentlichen Schlüssel unter selector._domainkey veröffentlichen.
• Bei externen Diensten eine eigene Return-Path- bzw. DKIM-Domain einrichten, damit das Alignment passt.
• DMARC zunächst mit p=none und rua=-Reports betreiben, auswerten und dann verschärfen.

Häufige Fragen

Was ist der Unterschied zwischen 5.7.26 und 5.7.23?

5.7.26 bedeutet: DMARC ist fehlgeschlagen bzw. die Mail ist gar nicht authentifiziert. 5.7.23 bedeutet: Der SPF-Check selbst ist hart fehlgeschlagen, typischerweise bei -all.

Reicht SPF allein für Gmail?

Für Massenversender nicht – Google verlangt SPF und DKIM plus DMARC. Auch bei kleinem Volumen ist DKIM die robustere Basis, weil es Weiterleitungen übersteht.