Spam? Gut oder Böse?
Spam-Mails gehören mittlerweile zum Alltag eines jeden Nutzers und Empfängers und in den meisten Fällen wird der Spam-Ordner nicht einmal mehr eines Blickes gewürdigt. Dabei kann es passieren, dass wichtige und legitime Mails aus Versehen als Spam eingestuft werden. Im weiteren Verlauf des Artikels wird sicher deutlicher, dass dies keinesfalls „Versehen“ oder „Zufall“ ist, sondern aus einer Menge an Gründen und Faktoren durch Algorithmen kalkuliert wird. So kann es passieren, dass Reservierungsbestätigungen oder die legitime Lotto-Gewinnbenachrichtigung nicht im Posteingang eintrifft – Millionengewinn verpasst, schade.
Falsch eingestufter Spam ist also nicht nur ärgerlich für Empfänger, sondern vor allem auch ein Problem für Absender. Der Kunde wird nicht erreicht, wichtige Nachrichten nicht übermittelt, Umsatz geht verloren, Vertrauen und Image wird beschädigt. Die direkten und undirekten Kosten für ein Unternehmen mit Spam-Problemen können enorm sein.
Im Folgenden schreibe ich über ein paar Basics im Bereich Anti-Spam-Maßnahmen für Versender. Ziel ist es, dass versandte Mails seltener fälschlicherweise als Spam erkannt werden.
Wie funktioniert Anti-Spam für Versender?
Wenn E-Mails beim Mailserver des Empfängers eintreffen, versucht dieser Server einzuschätzen, ob die Mail tatsächlich vom angegebenen Absender stammt und der Inhalt legitim und relevant für den Empfänger ist. Ein Großteil der technischen Anti-Spam-Maßnahmen betreffen die Validierung des Absenders im Schritt 1, hier gibt es viel Potential für Optimierung. Bei Schritt 2, dem Inhalt, gibt es eher ein paar formale und syntaktische Richtlinien.
Ich schreibe das How-To aus meiner Sicht als Webhosting-Kunde von All-Inkl. Bei anderen Webhostern sowie bei eigenen Root Servern können die nötigen Schritte abweichen. Schaut bitte in die FAQ/Hilfe eures Anbieters oder fragt hier in den Kommentaren, wenn ihr nicht weiter kommt. Für Root Server gibt es hier eine Anleitung, die recht ausführlich Hilfestellung gibt.
Überprüfung der Maßnahmen
Es ist unbedingt empfehlenswert wenn nicht sogar kritisch erforderlich, vor UND nach den folgenden Maßnahmen die Einstellungen zu überprüfen. Wie ist der aktuelle Zustand, wie sieht es danach aus? DNS-Änderungen sind für gewöhnlich innerhalb von Sekunden aktiv und extern sichtbar, kein Warten nötig.
Zum Testen eignen sich besonders die Online Tools MxToolBox und die GSuite Toolbox MX-Check. Prüft damit direkt nach jeder DNS Änderung nach – für gewöhnlich werden diese innerhalb von Sekunden übernommen und sind von extern sichtbar, ebenso die Resultate.
Nun aber zu den Maßnahmen:
#1 – SPF
SPF, Sender Policy Framework (Wikipedia, Standard), ist ein Standard zur Überprüfung des Absenders einer E-Mail und vermutlich der wichtigste Anti-Spam-Indikator. SPF ist eine TXT-Einstellung im DNS der Absender-Domain und leicht zu setzen. Etwas mehr Wissen erfordert unter Umständen das Generieren des TXT Eintrags. Hier muss beachtet werden, welche Mailserver und Maildienste für das Versenden der Mails benutzt werden. Wenn ich den Mailserver meines Webhosters nutze, jedoch Mails über die Googlemail Weboberfläche schicke (E-Mail über SMTP eingebunden), muss ich das im SPF-Eintrag beachten. Hierzu gibt es von fast allen Anbietern entsprechende Infos/Hilfeseiten, etwas googeln hilft hier schnell.
Ein beispielhafter SPF-Eintrag, der Google als Relay inkludiert, könnte so aussehen:
v=spf1 a mx include:_spf.google.com ~all
Kein ptr im SPF, wenn MX gesetzt ist, auch wenn das viele Generatoren immernoch machen. Überprüfung mit SPF Check der MXToolBox. Weitere Infos findet ihr bestimmt in der Hilfe eures Maildienstleisters/Hosters mit der Suche nach „SPF“.
#2 – DKIM
DKIM, DomainKeys Identified Mail (Standard, Wikipedia, DeBounce), ist wie SPF ebenfalls ein Protokoll zur Überprüfung von eingehenden Mails und deren unverändertem Inhalt.
DKIM nutzt zur Überprüfung eine asymmetrische Verschlüsselungstechnik mit zwei Schlüsseln – einem privaten Schlüssel, der Mails unsichtbar angehängt wird und einem öffentlichen Schlüssel, abgelegt im DNS des Absenders. Somit kann der Empfänger-Mailserver die Schlüssel aus dem Absender DNS und der Mail-Signatur gegeneinander prüfen und validieren. Das Hinzufügen des privaten Schlüssels in den Mailserver, damit dieser unsichtbar alle ausgehenden Mails damit signiert, erfordert eine fortgeschrittene Anpassung des Mailservers bzw. Konfiguration des Mailers und übersteigt den Rahmen dieses Artikels. Für GMail-Nutzer hilft die Google DKIM Step-by-Step-Anleitung, ansonsten wieder beim Anbieter/Hoster in der Hilfe schauen bzw. Support fragen.
Der zweite Teil besteht aus einem TXT DNS Record, der zuvor generiert werden muss. Benötigt wird dafür die Domain und ein „Selektor“; eine beliebige Zeichenkette, z.B. „meindkim1“. Der Record sollte immer mit v=DKIM1;k=rsa;p= anfangen! Selbst wenn die Generatoren gerne einen der Parameter v oder k weglassen, oder diese als optional angeben, sollten beide gesetzt sein. Info: Beide Überprüfungs-Tools (MxToolBox und GSuite MX-Check) bestätigen einen validen DKIM übrigens nur mit Parametern v UND k, Warnungen falls einer fehlt. Die Überprüfung von DKIM erfordert dann ebenfalls Domain und Selektor und sollte anschließend positiv ausfallen:
Aber Achtung: Ausschließlich den DKIM DNS Eintrag zu setzen, ohne die Mails zu signieren, hat keine weiteren positiven Auswirkungen (meistens aber auch keine negativen) und ist daher nicht zu empfehlen.
#3 – DMARC
DMARC, Domain-based Message Authentication, Reporting, and Conformance (Standard, Wikipedia):Was wie die deutsche alte Währung klingt, ist eine Technologie zur Erweiterung von SPF und DKIM. Geliefert werden zusätzliche Informationen, wie der Empfängerserver mit geprüften Mails umgehen soll sowie die Möglichkeit von Reports der Überprüfungen. Auch hier ein DNS TXT Eintrag, der die Infos liefert. Zwei grundlegende Fragen müsst ihr euch stellen:
1. Wie sollen Mails behandelt werden, deren SPF/DKIM-Überprüfung fehlschlägt? Ignorieren / Spam / Abweisen.
2. Sollen Daten und fehlgeschlagene Überprüfungen als Reports verschickt werden und an welche Mail-Adresse?
Solltet ihr mit „Ignorieren“ dem Empfangsserver kein Verhalten vorschreiben wollen und auch keinerlei Reporting wünschen (v=DMARC1;p=none;), erfüllt DMARC keinen Zweck und hat auch keine weiteren Effekte auf den Mailempfang, kann also ausgelassen werden.
Restriktiveres Verhalten oder Reporting gewünscht? Dann wird einer der vielen existierenden Generatoren aus den gewählten Optionen einen einfachen bis recht komplexen TXT Record erstellen:
v=DMARC1; p=none; rua=mailto:admin@it-stack.de; ruf=mailto:admin@it-stack.de; fo=1;
Dieser Eintrag schickt Reportings an mich, wenn SPF oder DKIM fehlschlägt sowie generelle Reports, der Mailserver soll die Fehlschläge jedoch wie gewohnt behandeln, ich gebe kein strikteres Vorgehen vor.
#4 – Blacklists
Es gibt eine Vielzahl von professionell betriebenen Anti-Spam-Listen, also Blacklists, die von Mailservern zur weiteren Überprüfung abgefragt werden können. Ob mein Mailserver auf einer Blacklist steht, kann ich beispielsweise mit der MxToolBox Blacklist Suche herausfinden. Gebt hier eure Domain ein und eine Auswertung von über 100 Blackslists wird eventuelle Funde aufzeigen. Solltet euer Mailserver nicht die IP eurer Domain teilen oder weitere in das Mailing involvierten MX-Server-IPs bekannt sein, diese am besten auch noch testen.
Eure Domain/IP ist in einer Blacklist gefunden worden? Das ist unpraktisch, kann aber mal passieren. Geblacklistet werden für gewöhnlich ganze Server. Auf einem Shared Server, wie das bei Webhosting fast immer der Fall ist, sind, je nach Vertrag, 20 bis 100 weitere Kunden untergebracht. Die Chance, dass ein anderer Kunde für das Blacklisting verantwortlich ist, ist hoch.
Was tun? Auf der Betreiberseite der Blacklist gibt es meistens Suchen/Informationsportale, in denen Blacklist-Kandidaten, teilweise mit mehr Details und Begründung, gesucht werden können. Ich empfehle zwei Recherchen: Suche nach der Domain und nach der/den IPs.
So kann es sein, dass die IP-Adresse des Servers in mehreren Einträgen gefunden wird (Reportfunde bei Spamhaus ZEN: Link1, Link2, in welchen wiederum eure Domain nicht erwähnt wird), für die Domain jedoch kein Eintrag vorhanden ist. Das sind weitere Hinweise darauf, dass nicht ihr, sondern ein anderer Kunde des Servers Schuld hat.
Unabhängig von diesen Recherchen könnt ihr vermutlich wenig gegen das Blacklisting tun. Manche Betreiber bieten Unblock Formulare an, andere nicht. Informiert auf jeden Fall euren Webhoster/Mailing-Anbieter mit allen herausgefundenen Informationen über das Blacklisting – dieser hat für gewöhnlich andere Optionen und kann direkt selbst in die Behandlung der Problemursache, also gegen entsprechende Kunden, vorgehen.
#5 – User Trust
Desweiteren hilft es, sich zusätzlich Trust über den User/Empfänger zu holen – beispielsweise durch das Hinzufügen eurer Absenderadresse zu den Kontakten, das Markieren der Nachrichten als „Wichtig“ oder Versehen mit Sternchen/Markern (je nach Client heißt das anders), den Absender „Nie als Spam markieren“ (ebenfalls je Client anders) und mehr. Alles, was man mit einer Mail oder einem Absender bei dem jeweiligen Anbieter des Empfängers tun kann, dass letztlich einen positiven Effekt hat. Die Anbieter speichern solche Informationen (wie oft wurde eine Mail mit Inhalt X positiv behandelt, wie oft der Absender usw.) und behandeln Mails dieses Absenders zukünftig besser. Diese Maßnahme kann man bis zu einer gewissen Anzahl mit den eigenen Mitarbeitern starten – Mails an ihre private Mailadresse schicken, bestenfalls bei unterschiedlichen Anbietern, und die Mails von ihnen „positiv behandeln“ lassen.
