Veröffentlicht am
In den letzten Monaten geht GoogleMail dazu über, bei ihrer Spam-Filterung immer "strengere Türsteher" einzusetzen und auf diese Weise "SPF" zu erzwingen.
Mit diesem Hilfe-Artikel (der Ihr DRKCMS, aber auch und vor allen Dingen Ihre normale Mail-Konfiguration betrifft) wollen wir Ihnen Details erklären.
Fehlerbild 1
In der ersten Runde im Sommer waren überwiegend Absender betroffen, die eine Subdomain unterhalb von drk.de benutzen (also z.B. Emails im Format irgendwas@kv-musterstadt.drk.de). Google hat diese mit folgender Fehlermeldung abgelehnt:
<irgendwer@gmail.com>: host gmail-smtp-in.l.google.com[142.251.5.27] said: > 550-5.7.26 This message does not pass authentication checks (SPF and DKIM > both 550-5.7.26 do not pass). SPF check for [kv-musterstadt.drk.de] does not > pass with 550-5.7.26 ip: [80.237.197.11].To best protect our users from > spam, the message 550-5.7.26 has been blocked. Please visit 550-5.7.26 > support.google.com/mail/answer/81126 for more 550 > 5.7.26 information. da6-20020a93802408600b0021bbace5486si3610969wrb.262 - > gsmtp (in reply to end of DATA command)</irgendwer@gmail.com>
Hier ist die Fehlersuche noch relativ einfach: Google teilt uns direkt mit, dass sie gerne SPF und/oder DKIM nutzen möchten.
Fehlerbild 2
Neu ist seit dem Spätsommer ein anderes Fehlerbild, die Mails kommen mit folgender Fehlermeldung zurück:
<irgend.ein.empfaenger@gmail.com>: host gmail-smtp-in.l.google.com[74.125.133.27] said: 550-5.7.1 [80.237.197.11] Messages missing a valid messageId header are not 550 5.7.1 accepted. </irgend.ein.empfaenger@gmail.com>
Hier ist die Fehlersuche etwas auffälliger, denn laut der Fehlermeldung läge die Ursache (angeblich) woanders: Man würde Mails ohne den üblichen "Message-ID"-Header mit senden, und GoogleMail lässt keine solchen Mails rein.
Ohne zu technisch werden zu wollen: Das entsprechende RFC (sozusagen die technische Norm) definiert ein derartiger Header nicht als Pflichtfeld, aber als "dringend empfohlen" (RFC 2822, 3.6.4 "Though optional, every message SHOULD have"). Es darf also durchaus als Fehler verstanden werden, wenn Ihr Mail-Programm einen derartigen Header nicht setzen würde.
Für uns als Provider legt das entsprechende RFC fest, dass wir, wenn für uns nötig, einen solchen Header nachträglich hinzufügen dürfen (RFC 5321, 6.4. Compensating for Irregularities: [..] The following changes to a message being processed MAY be applied when necessary by an originating SMTP server [..] Addition of a message-id field when none appears), damit einher geht aber keine Verpflichtung (im Gegenteil, "MAY"), es gibt auch durchaus Gründe, warum wir die Header von Kundenmails möglichst nicht anpassen.
Wenn Google nun Mails von Ihnen ablehnt, weil Ihr Mail-Programm wirklich keinen Message-ID-Header setzt, dann ist das zunächst mal ein Fehler Ihres Mail-Programms (es ist zwar zulässig, aber nicht schön, solche Mails zu versenden) und der Google-Türsteher lässt Sie nicht rein.
In den letzten Wochen gab es aber solche Fehler auch bei Mails, die nachweislich einen korrekten Message-ID-Header hatten. Und angeblich (ungetestet) kann man auch das umgehen, wenn man einen SPF-Record setzt (obwohl es da gar keinen Zusammenhang gibt). Hier scheint Google einfach mal Mist zu bauen und die falsche Fehlermeldung auszuliefern, wie auch hier diskutiert wird.
Und was ist nun ein SPF-Record?
In beiden Fällen dürfte die Abhilfe sein, für Ihre Domain einen SPF ("Sender policy framework")-Record zu setzen. Damit machen Sie bei Ihrer Domain Angaben dazu, wer in Ihrem Namen Mails versenden darf.
Die Idee dahinter ist einfach: Wenn Sie nur bestimmte Mailserver autorisieren, für Sie Mails zu versenden, dann können alle übrigen (die nicht auf dieser Liste stehen) besser als Adressfälschung und damit Spam erkannt werden.
Also: Sie tragen im SPF-Record Ihrer Domain an, dass alle Server von uns Mails in Ihrem Namen verschicken dürfen. Außerdem die von Microsoft/Office 365, weil Sie das nutzen. Und alle anderen dürfen es nicht. Und wenn z.B. Google jetzt eine Mail mit Ihrer Domain als Absender bekommt, kann es nachgucken, ob der Absender-Server auf dieser Liste steht und die im Zweifelsfall als Spam aussortieren.
Das ist im Prinzip eine gute Technik, sie hat nur einen Haken: Wenn Sie Fehler im SPF-Record machen, dann ist das schlecht. Stellen Sie sich vor, Sie haben die o.g. Liste (wir + MS365) im SPF-Record gesetzt. Sie nutzen aber noch ein Kursanmelde-System von Anbieter XYZ, ein Bewerber-Management von Anbieter ABC oder ein Newsletter-Tool 123. Und die schicken ebenfalls Mails in Ihrem Namen raus, deren Server stehen aber nicht auf der Liste.
Dann werden diese Mails fälschlicherweise als Spam aussortiert (weil die Server von XYZ, ABC oder 123 eben als Adressfälscher eingestuft werden). Das gemeine daran ist,
- dass Sie das möglicherweise gar nicht selbst bemerken (denn Ihre Mails, die Sie aus MS365 heraus verschicken, kommen ja an)
- dass auch andere das möglicherweise gar nicht bemerken. Denn ob der Empfänger SPF auswertet (und wie er damit umgeht - Mail löschen/abweisen/...) entscheidet er selbst. Es kann also durchaus sein, dass Kursteilnehmer mit einer T-Online-Adresse Ihre Mails bekommen, während Kursteilnehmer mit einer GoogleMail-Adresse sie nicht bekommen
- dass das DNS-Änderungen sind, und die reagieren generell nur teilweise mit mehreren Tagen Verzögerung
Aus diesem Grund setzen wir nicht ungefragt irgendwelche SPF-Records.
Wenn Sie SPF nutzen wollen (oder "müssen", damit die Kommunikation zu Google wieder funktioniert), gehen Sie bitte wie folgt vor:
- Gehen Sie ins Kundenmenü in den Bereich "Produkte" - "Domains und DNS" - "Nameserver-Zonenverwaltung" und bearbeiten Sie das Zonenfile Ihrer Mail-Domain
- Legen Sie einen neuen Subdomain-Eintrag an (oder bearbeiten Sie ggf. andere v=spf1-Einträge, wenn schon einer existiert)
- Das erste Feld ("Subdomain") bleibt leer. Der Typ lautet: IN TXT
- Im hinteren Feld bauen Sie jetzt die entsprechende SPF-Syntax ein, die Sie benötigen. Beispielsweise:
"v=spf1 include:ihr-webspace.de ~all"
Die grundsätzliche Syntax ist immer gleich: Der ganze Eintrag ist von Anführungszeichen ("") umschlossen, und er beginnt mit v=spf1
Danach kommen die Server, die versenden dürfen. Da gibt es verschiedene Möglichkeiten, die teilt Ihnen der Server-Betreiber (also z.B. Microsoft oder die o.g. Anbieter XYZ, ABC oder 123 mit). Unsere D&T-Server verbergen sich hinter dem Eintrag include:ihr-webspace.de (das klingt wie ein Platzhalter für Ihre Domain, ist es aber nicht, sondern muss genau so da drin stehen).
Und am Ende wird noch festgelegt, wie mit den restlichen Servern dieser Welt umzugehen ist ("all"). Ein von manchen Anbietern empfohlenes Minuszeichen (also -all) führt eben zu o.g. Problematik, dass vergessene Mailserver unnötigerweise ausgeschlossen werden. Wenn Sie auf Nummer sicher gehen wollen, folgen Sie unserer Empfehlung ~all, die Tilde heißt soviel wie "keine Aussage zum Rest" (oder mit anderen Worten: Wenn irgend ein anderer Server dieser Welt Mails in Ihrem Namen verschickt, dann würden Sie weder bestätigen noch verneinen, dass er das darf, sondern dann sollen die Spam-Filter des Empfängers selbständig beurteilen, ob das echt sein könnte.
Wichtig: Wenn Sie unsicher sind, helfen wir Ihnen gerne beim Setzen des SPF-Records. Aber aus o.g. Gründen müssten Sie uns schon genau mitteilen, welche Server wir da eintragen sollen, wir haben als externer keine Chance, das alles zu erraten/ermitteln!