E-Mail-Weiterleitungen & SPF

Warum E-Mail-Weiterleitungen wegen SPF manchmal scheitern
 
Wenn eine E-Mail weitergeleitet wird, entsteht ein grundlegendes Problem mit dem SPF-Mechanismus (Sender Policy Framework): SPF prüft, ob der sendende Mailserver berechtigt ist, E-Mails für die Absender-Domain zu verschicken. Bei einer direkten Zustellung ist das kein Problem – der Mailserver der Absender-Domain sendet direkt an den Empfänger, und SPF kann das einwandfrei verifizieren.
Bei einer Weiterleitung ändert sich jedoch die Situation grundlegend: Die weitergeleitete E-Mail behält in der Regel die originale Absenderadresse (z. B. absender@beispiel.de) bei, wird aber nun vom Weiterleitungsserver (z. B. dem Mailserver von senseLAN) an den eigentlichen Empfänger zugestellt. Der empfangende Mailserver prüft nun per SPF, ob dieser Weiterleitungsserver berechtigt ist, E-Mails im Namen von beispiel.de zu versenden – und das ist er naturgemäss nicht, denn er taucht im SPF-Record der Ursprungsdomain nicht auf. Das Ergebnis ist ein SPF-Fail.
 
Ob das zu Problemen führt, hängt vom Empfänger ab
Hier kommt die Konfiguration des empfangenden Mailservers ins Spiel. Es gibt verschiedene Reaktionsmöglichkeiten auf einen SPF-Fail:
 
Keine Prüfung / SPF wird ignoriert: Die E-Mail wird problemlos zugestellt. Weiterleitungen funktionieren ohne Einschränkungen.
SPF als Hinweis (Softfail ~all): Der Mailserver wertet das Ergebnis als schwaches Signal. Die E-Mail wird zwar zugestellt, aber möglicherweise mit einem höheren Spam-Score versehen, was zu einer Einstufung im Junk-Ordner führen kann.
SPF-Fail führt zur Ablehnung (-all + strikte Policy): Der Mailserver lehnt die E-Mail direkt ab oder verwirft sie stillschweigend. Gerade in Kombination mit DMARC kann das problematisch werden: Wenn die Ursprungsdomain eine DMARC-Policy mit p=reject oder p=quarantine hat und SPF fehlschlägt (und DKIM nicht passt), wird die E-Mail abgelehnt oder in Quarantäne verschoben – unabhängig davon, ob die Weiterleitung legitim ist.
 
Die Lösung: SRS oder DKIM
Um das Problem zu umgehen, gibt es zwei gängige Ansätze:
SRS (Sender Rewriting Scheme): Der Weiterleitungsserver schreibt die Absenderadresse im Envelope (MAIL FROM) so um, dass sie zur eigenen Domain gehört. SPF-Prüfungen schlagen dann nicht mehr fehl, da nun der eigene Server für die eigene Domain sendet. Der ursprüngliche Absender bleibt im From:-Header sichtbar.
DKIM: Ist die Original-E-Mail mit einer gültigen DKIM-Signatur versehen und wird beim Weiterleiten nicht verändert (kein Rewriting des Body, keine Footer-Anhänge), bleibt die DKIM-Signatur gültig. Ein empfangender Server, der DMARC-Alignment über DKIM (statt SPF) prüft, akzeptiert die E-Mail dann trotzdem.
 
Kurz zusammengefasst: Eine Weiterleitung bricht das SPF-Modell technisch gesehen, weil der Weiterleitungsserver nicht im SPF-Record der Ursprungsdomain eingetragen ist. Ob das zu einem Problem wird, hängt davon ab, wie streng der empfangende Server konfiguriert ist – und ob DKIM als Fallback greift.

E-Mail-Weiterleitungen & SPF

Warum E-Mail-Weiterleitungen wegen SPF manchmal scheitern
 
Wenn eine E-Mail weitergeleitet wird, entsteht ein grundlegendes Problem mit dem SPF-Mechanismus (Sender Policy Framework): SPF prüft, ob der sendende Mailserver berechtigt ist, E-Mails für die Absender-Domain zu verschicken. Bei einer direkten Zustellung ist das kein Problem – der Mailserver der Absender-Domain sendet direkt an den Empfänger, und SPF kann das einwandfrei verifizieren.
Bei einer Weiterleitung ändert sich jedoch die Situation grundlegend: Die weitergeleitete E-Mail behält in der Regel die originale Absenderadresse (z. B. absender@beispiel.de) bei, wird aber nun vom Weiterleitungsserver (z. B. dem Mailserver von senseLAN) an den eigentlichen Empfänger zugestellt. Der empfangende Mailserver prüft nun per SPF, ob dieser Weiterleitungsserver berechtigt ist, E-Mails im Namen von beispiel.de zu versenden – und das ist er naturgemäss nicht, denn er taucht im SPF-Record der Ursprungsdomain nicht auf. Das Ergebnis ist ein SPF-Fail.
 
Ob das zu Problemen führt, hängt vom Empfänger ab
Hier kommt die Konfiguration des empfangenden Mailservers ins Spiel. Es gibt verschiedene Reaktionsmöglichkeiten auf einen SPF-Fail:
 
Keine Prüfung / SPF wird ignoriert: Die E-Mail wird problemlos zugestellt. Weiterleitungen funktionieren ohne Einschränkungen.
SPF als Hinweis (Softfail ~all): Der Mailserver wertet das Ergebnis als schwaches Signal. Die E-Mail wird zwar zugestellt, aber möglicherweise mit einem höheren Spam-Score versehen, was zu einer Einstufung im Junk-Ordner führen kann.
SPF-Fail führt zur Ablehnung (-all + strikte Policy): Der Mailserver lehnt die E-Mail direkt ab oder verwirft sie stillschweigend. Gerade in Kombination mit DMARC kann das problematisch werden: Wenn die Ursprungsdomain eine DMARC-Policy mit p=reject oder p=quarantine hat und SPF fehlschlägt (und DKIM nicht passt), wird die E-Mail abgelehnt oder in Quarantäne verschoben – unabhängig davon, ob die Weiterleitung legitim ist.
 
Die Lösung: SRS oder DKIM
Um das Problem zu umgehen, gibt es zwei gängige Ansätze:
SRS (Sender Rewriting Scheme): Der Weiterleitungsserver schreibt die Absenderadresse im Envelope (MAIL FROM) so um, dass sie zur eigenen Domain gehört. SPF-Prüfungen schlagen dann nicht mehr fehl, da nun der eigene Server für die eigene Domain sendet. Der ursprüngliche Absender bleibt im From:-Header sichtbar.
DKIM: Ist die Original-E-Mail mit einer gültigen DKIM-Signatur versehen und wird beim Weiterleiten nicht verändert (kein Rewriting des Body, keine Footer-Anhänge), bleibt die DKIM-Signatur gültig. Ein empfangender Server, der DMARC-Alignment über DKIM (statt SPF) prüft, akzeptiert die E-Mail dann trotzdem.
 
Kurz zusammengefasst: Eine Weiterleitung bricht das SPF-Modell technisch gesehen, weil der Weiterleitungsserver nicht im SPF-Record der Ursprungsdomain eingetragen ist. Ob das zu einem Problem wird, hängt davon ab, wie streng der empfangende Server konfiguriert ist – und ob DKIM als Fallback greift.