Es kann gehäuft vorkommen, dass E-Mails, die man über die eigene Domain oder über einen eigenen Mail-Server verschickt, bei einem Empfänger mit einem Gmail-Konto (E-Mail Konto von Google) im Spam-Ordner landen. Dies kommt auch durchaus bei Webpaket-Anbietern, wie Hosteurope vor. Das ist nicht nur unschön, sondern auch ärgerlich bis finanziell schädlich, wenn man geschäftliche Korrespondenz darüber abwickelt.
Was Google genau veranlasst, mal eine Mail als Spam einzuordnen und mal nicht, ist schwer nachvollziehbar, da man die Spam-Algorithmen nicht kennt. Trotzdem gibt es ein paar Kriterien, die zur Vermeidung dieses Problems beitragen können. Ein entscheidendes Kriterium davon ist die Verwendung von SPF, was weiter unten in diesem Artikel beschrieben ist.
Als “kein Spam” markieren
Sollte man mal von einem E-Mail Empfänger mit Gmail-Konto im persönlichen Kontakt die Rückinformation erhalten, dass die E-Mail im Spam gelandet ist, so sollte der E-Mail Empfänger im Google-Konto die E-Mail als “Kein Spam” markieren.
Das ist erstmal kein technisches Allheilmittel, sollte aber dafür sorgen, dass zukünftig zumindest bei diesem Empfänger die E-Mails im Posteingang und nicht im Spam-Ordner landen. Ferner, aber das ist nur eine Mutmaßung, kann man vielleicht davon ausgehen, dass die Spam-Filterkriterien von Google dazu lernen. Dass heißt, dass ggf. die Reputation einer Absender-Domain oder einer Mail-Server-IP-Adresse steigt, wenn mehrere Empfänger die Mails als “Kein Spam” einsortieren. Dass es so etwas wie Domain-Reputation und IP-Reputation in den Google-Auswertungen gibt, erkennt man in den Google Postmaster Tools.
Google Postmaster Tools einrichten
Die Google Postmaster Tools sind eine weitere Empfehlung, wenn man über die eigene Domain sehr viele E-Mail, u.a. an Gmail-Konten, verschickt. Sie helfen zwar nicht direkt die Einsortierung im Spam-Ordner zu vermeiden, erlauben aber einen Einblick u.a. zu:
- Spamraten
- Domain-Reputation
- IP-Remutation
- Authentifizierung
- Übermittlungsfehler
- Verschlüsselung
Da man sich dort mit seiner Domain authentifizieren muss, z.B. über einen DNS TXT-Record, liegt die Vermutung nahe, dass allein dieser Schritt für einen besseren Bekanntheitsgrad der Domain bei Google sorgt mit kleinen positiven Effekten für die Reputation (…ist aber nur Vermutung!).
SPF einstellen
Wie funktioniert SPF?
Bei SPF (Sender Policy Framework) wird der TXT Resource Record im DNS genutzt. Das ist ein mehr oder weniger frei definierbarer Text, der bei einer DNS-Abfrage mitgesendet werden kann. Bei SPF schreibt dort die Server-IP-Adressen rein, welche offizielle E-Mails im Namen der Domain verschicken dürfen. Ein anderer E-Mail-Server, wie Gmail, der E-Mails empfängt, kann aus der empfangenen E-Mail aus dem Header auslesen, von welcher E-Mail-Adresse es gesendet wurde und von welchem Mail-Server mit welcher IP-Adresse es gesendet wurde. Nun wird der Domainname aus der E-Mail-Adresse extrahiert und eine DNS-Anfrage gestellt. Liefert diese einen SPF-Eintrag mit den gültigen Mailserver-IP-Adressen im TXT-Record zurück, kann ein Abgleich zwischen den beiden Adressen erfolgen. Nur wenn die Mailserver-IP der empfangenen E-Mail zu den IP-Adressen im SPF-TXT-Record passen, kann man davon ausgehen, dass hier nicht im “falschen Namen” gehandelt wurde.
SPF bei Hosteurpe einstellen als Beispiel
Wie man einen DNS TXT-Record vornehmen kann, kann von Anbieter zur Anbieter unterschiedlich sein. Aus diesem Grund soll hier mal Hosteurope mit einem seiner Webpakete und dem KIS-Center als Beispiel her halten. Bei anderen Anbietern kann man aber in ähnlicher Weise vorgehen. Nachdem man sich im KIS-Center eingeloggt hat, geht man auf Produktverwaltung => Domainservices => Nameserver-/DNS-Einträge bearbeiten.
Danach klickt man auf den Editieren-Button hinter der Domain für welche man SPF konfigurieren möchte. Es öffnet sich dann die Seite mit den zugehörigen DNS-Einstellungen. Man scrollt bis nach unten zu der Stelle, an der ein neuer DNS-Eintrag möglich ist. In der Kombobox wählt man den TXT-Eintrag aus. Möchte man den Eintrag für eine Subdomain vornehmen, stellt man diese im Textfeld voran.
In das rechte Textfeld schreibt man folgenden Eintrag:
v=spf1 a mx ip4:80.237.138.0/24 ip6:2a01:488:42::/48 -all
- v…hier steht die verwendete spf-version
- a…es ist die aktuelle Domain zu verwenden
- mx…erlaubt, dass die mx-Server der Domain E-Mails verschicken dürfen
- ip4…eine IPv4-Maske für alle IPv4-Adressen, die E-Mails verschicken dürfen. In diesem Fall ein Adressraum von Hosteurope. Hier kann auch eine einzelne IP-Adresse stehen.
- ip6…eine IPv6-Maske für alle IPv6-Adressen, die E-Mails verschicken dürfen. In diesem Fall ein Adressraum von Hosteurope. Hier kann auch eine einzelne IP-Adresse stehen.
- -all…bedeutet, dass alle anderen Server/IPs vom Versand der E-Mails ausgeschlossen sind
Es gibt bei Hosteurope noch eine Kurzvariante über eine include-Anweisung:
v=spf1 include:spf.server-he.de -all
Wird also eine E-Mail mit dem Domainnamen von einem anderen Server mit einer anderen IP-Adresse versendet, wird beim Empfänger über eine DNS-Abfrage zur Domain erkannt, dass es sich um keine gültige/erlaubte IP-Adresse handelt. Also ein klares Indiz für Spam oder umgekehrt, bei erfolgreichem Abgleich der IP-Adresse mit dem DNS-Eintrag, kann sich der Absender authentifizieren und es ist ein relativ eindeutiges Indiz, dass die E-Mail nicht aus einer unlauteren Quelle stammt.
Nachdem man auf “Neu anlegen” geklickt hat, kann es eine paar Minuten bis Stunden dauern, bis der DNS-Eintrag bekannt gemacht worden ist.
Etwas Obacht muss man geben, wenn mit der Domain per A-Record auf einen externen Server verweist, außerhalb von Hosteurope. Dann muss diese IP-Adresse in den oben angeführten TXT-Record ergänzt werden.
Unterschied mit und ohne SPF im Google E-Mail Header
In meinem Fall führten die Eintragungen zum Erfolg und meine E-Mails landeten bei den Gmail-Empfängern nicht mehr im Spam. Schaut man sich den E-Mail-Header der bei Google empfangenen E-Mail an, so erkennt man auch einen deutlichen Unterschied in der Authentifizierung.
ARC-Authentication-Results: i=1; mx.google.com;
spf=neutral (google.com: 87.230.xx.xxx is neither permitted nor denied by best guess record for domain of vorname.nachname@meinedomain.com) smtp.mailfrom=vorname.nachname@meinedomain.com
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: domain of vorname.nachname@meinedomain.com designates 2a01:488:42:1000:::: as permitted sender) smtp.mailfrom=vorname.nachname@meinedomain.com
Wo Google vorher nicht wusste, ob die E-Mail vom richtigen Server, zu dem auch die Domain gehört, kommt, so kann Google mit SPF nun eine klare Zuordnung treffen. Es ist davon auszugehen, dass neben Google auch viele andere Mailserver die SPF-Eintragungen nutzen, um über Spam oder Nicht-Spam zu entscheiden.
Danke für diesen Beitrag!
Ich hatte genau dieses Problem mit einer Domain die bei Hosteurope und war schon ziemlich ratlos. Dank deines Beitrages habe ich meine Konfiguration nochmal ganz genau geprüft und abgeglichen und nun scheint’s zu funktionieren.
Danke!!! 🙂
Danke!
Warum kann Hosteurope das nicht automatsich eintragen…
Die Kurzvariante von Hosteurope sieht inzwischen so aus und funktioniert:
“v=spf1 a mx include:spf.server-he.de -all”
Mit obigem Eintrag konnte ich vermeiden, dass Google Mails von mir in den Spam schiebt:
Vorher:
spf=neutral (google.com: 2a01:488:42:1000:50ed:822c:: is neither permitted nor denied by best guess record for domain of XXX@XXX.de)
Nachher:
spf=pass (google.com: domain of XXX@XXX.de designates 2a01:488:42:1000:50ed:822c:: as permitted sender) smtp.mailfrom=XXX@XXX.de
Sehr gut! Freut mich, dass es geklappt hat.
Tja, warum Hosteurope das nicht standardmäßig konfiguriert, ist eine gute Frage. Genauso wie die Frage, warum es Hosteurope nicht schafft HTTP2 anzubieten, was ja mittlerweile etabliert ist und viele Vorteile bringt.