Eine Kundin nutzt Office365 in Verbindung mit dem Hoster all-inkl.com. Nun kamen allerdings keine Mails von irgendeinem Formular von der Website bei der Kundin an. Und wie immer bei solchen vertrackten Situationen habe ich viel gelernt. In diesem Fall über SPF-Records.

Die Einrichtung von Office365 erfolgte nach dieser Anleitung. Die endet mit folgendem Ergebnis:

Wie im Bild zu sehen ist der SPF-Record ausschließlich auf outlook.com gesetzt.

v=spf1 include:spf.protection.outlook.com -all

Die Erklärung was dieser Code genau macht, liefert all-inkl.com auf einer eigenen Seite zum Thema SPF-Records:

Erklärungen zur Syntax von SPF:

Am Anfang des SPF Records wird mit v= die SPF-Version festgelegt. Bislang gibt es nur spf1. Danach werden üblicherweise Direktiven angegeben. Diese bestehen aus einem optionalen Qualifikator und einem Mechanismus.

Qualifikatoren:

+ Pass – autorisierte Sender, daher Annahme der E-Mail; Standard, wenn kein Qualifikator explizit angegeben wird

– Fail – nicht autorisierte Sender, daher Abweisung der E-Mail

~ SoftFail – nicht autorisierte Sender, E-Mail wird trotzdem angenommen, kann jedoch z.b. als Spam markiert werden

? Neutral – Sender, über deren Gültigkeit nichts gesagt werden kann und die akzeptiert werden müssen, daher Annahme der E-Mail

gängige Mechanismen:

a A-/AAAA-Record der abgefragten oder explizit angegebenen Domain

mx MX-Record der abgefragten oder explizit angegebenen Domain

ptr PTR-Record der abgefragten oder explizit angegebenen Domain

ip4 IPv4-Adresse oder IPv4-Subnetz

ip6 IPv6-Adresse oder IPv6-Subnetz

include SPF-Abfrage der angegebenen Domain, diese sollte einen gültigen SPF-Record besitzen

all immer

Das bedeutet für unseren Block also folgendes:
v=spf1 => Version 1 von SPF wird benutzt

include:spf.protection.outlook.com => spf.protection.outlook.com ist als Domain erlaubt von der Kunden-Domain zu senden

-all => Mail soll abgewiesen (hard fail), wenn die sendende Domain nicht mit der tatsächlich Domain übereinstimmt

Warum kommen die Mails vom Formular jetzt nicht durch?

Schrägerweise ist eine Mail doch angekommen und ein Blick in den Quelltext der Mail offenbart das Problem:

X-ACL-Warn: 85.13.157.161 is not allowed to send mail from example.de. Help at/Hilfe unter www.mfaq.info
X-Received-SPF: fail ( mx14.ispgateway.de: domain of example.de does not designate 85.13.157.161 as permitted sender )

85.13.157.161 ist die IP-Adresse vom all-inkl.com-Server. Das Formular wird ja standardmäßig vom Webserver versendet (sofern kein SMTP-Plugin genutzt wird). Diese IP-Adresse ist aber gar nicht als erlaubter Sender im SPF-Record hinterlegt, also ein Fehler, der laut Konfiguration zum Abweisen der Mail führen soll und auch tat. Wäre es kein „hard fail“, sondern ein „soft fail“ gewesen (~all), dann wäre die Mail zumindest im Spamordner gelandet …

Was ist die Lösung?

Ganz einfach, wenn das Problem erst einmal bekannt ist. Wir müssen einfach den all-inkl.com-Server als erlaubten Sender hinzufügen. Das geht auf verschiedene Arten:

ip4:85.13.157.161 wäre eine Variante, die aber den Nachteil hat, dass sich die IP-Adresse bei einem Serverwechsel ändern könnte.

Einfacher und verlässlicher ist somit include:kasserver.com, denn das ist der sendende Webserver bei all-inkl.com.

Falls wir jemals wieder umstellen, erlauben wir auch schon mal dem MX- und A-Record zu senden. Zusätzlich habe ich von Hardfail auf Softfail gewechselt. Was uns zu diesem neuen SF-Record bringt:

v=spf1 mx a include:kasserver.com include:spf.protection.outlook.com ~all

Testen könnt ihr das mit dem Online-Tool von mxtoolbox.com. Dort einfach im Dropdown auf „SPF-Record-Lookup“ auswählen.

Ein Blick in den Quelltext zeigt den Erfolg:

X-Received-SPF: pass ( mx08.ispgateway.de: domain of example.de designates 85.13.157.161 as permitted sender )

Der SPF-Check ist erfolgreich, der all-inkl.com Server darf jetzt auch unter dieser Domain mailen.

Sind SPF jetzt Pflicht?

Jein. Das Problem taucht definitiv auch generell auf, nicht nur in Bezug auf Office365. Gmail nimmt seit November 2022 keine Mails mehr an, wenn kein SPF-Record und kein DKIM gesetzt ist.

Wichtig: Ab November 2022 müssen neue Absender, die E-Mails an private Gmail-Konten senden, entweder SPF oder DKIM einrichten.

Diese Fehlermeldung kommt im besten Fall zurück, um den Absender darüber zu informieren:

SMTP error from remote server for TEXT command, host: gmail-smtp-in.l.google.com (142.251.31.27) reason:
550-5.7.26 This mail is unauthenticated, which poses a security risk to the
550-5.7.26 sender and Gmail users, and has been blocked. The sender must
550-5.7.26 authenticate with at least one of SPF or DKIM. For this message,
550-5.7.26 DKIM checks did not pass and SPF check for [example.de] did
550-5.7.26 not pass with ip: [x.x.x.x]. The sender should visit
550-5.7.26 https://support.google.com/mail/answer/81126#authentication for
550 5.7.26 instructions on setting up authentication.

Sofern keine anderen Tools genutzt werden, die über andere Server Mails versenden, aber die Domain als Absender benutzen (z.B. CRM-Systeme, Helpdesk-Software, etc.), dann bieten die Hoster oft eine schnelle einfache Möglichkeit einen SPF-Record anzulegen.

Bei Ionos gibt es einen eigenen Menüpunkt, um einen Standard-SPF für die Ionos-Server zu setzen:

Bei DomainFactory ist es unter dem Menüpunkt „Nameserver-Einstellungen“ zu finden und bietet ein schönes Interface, mit dem der SPF zusammengeklickt werden kann:

Und bei all-inkl.com wird ein Standardeintrag schon mal in das Inputfeld eingesetzt, sofern ein SPF-Eintrag gesetzt wird.

Fazit

Was GMail hier vormacht, wird sicher weitere Nachahmer finden. Ähnlich wie bei SSL wird diese Änderung meines Erachtens dazu führen, dass in Zukunft ein SPF-Eintrag immer erforderlich sein wird, wenn weiterhin E-Mails verschickt werden wollen. Immer mehr Mailserver nehmen sonst einfach keine Mails mehr an. Checkt daher mal eure (Kunden-)Websites und setzt den Eintrag, damit eure Mails in Zukunft auch weiterhin ankommen.