Tiefgehende Analyse der E-Mail-Zustellbarkeit
- Im Oktober 1971 sendete der MIT-Absolvent Ray Tomlinson die erste E-Mail über ein Netzwerk.
- Im vergangenen Jahr wurden rund 121 Billionen E-Mails zwischen etwa 4,3 Milliarden Menschen versendet.
- E-Mail ist die wichtigste Form schriftlicher Kommunikation auf der Erde und wird das auch in naher Zukunft bleiben.
Überblick
- Am 3. Oktober 2023 kündigten Google und Yahoo neue E-Mail-Sicherheitsstandards an, um Spam-, Phishing- und Malware-Versuche zu verhindern.
- Da E-Mail-Dienstanbieter diese Richtlinien durchsetzen, ist die Einhaltung der Vorgaben zur E-Mail-Zustellbarkeit unverzichtbar.
- Die größte Veränderung ist die Implementierung von E-Mail-Authentifizierungsstandards wie SPF, DKIM und DMARC.
- Bei Gmail werden nicht authentifizierte E-Mails blockiert.
Wer betroffen ist
- Vor allem Massenversender sind betroffen und müssen SPF, DMARC und DKIM für ihre Domains aktivieren.
- Auch wer kein Massenversender ist, kann betroffen sein, wenn die Richtlinien nicht eingehalten werden.
Zeitplan
- Google verlangt ab Februar 2024 von Massenversendern die Authentifizierung ihrer E-Mails.
- Yahoo führt dieselben Anforderungen ebenfalls ab dem 1. Quartal 2024 ein.
Richtlinien
- Absenderauthentifizierung: Implementierung von E-Mail-Authentifizierungsprotokollen wie SPF, DKIM und DMARC.
- Anforderungen für Massenversender: Unnötige Massenmails vermeiden, um Spam-Filterung und Reputationsschäden zu verhindern.
- Einfaches Abbestellen: Eine leicht nutzbare Abmeldeoption bereitstellen.
- Interaktion: Irreführende Betreffzeilen, übermäßige Personalisierung und werbliche Inhalte vermeiden, die Spam-Filter auslösen.
Absenderauthentifizierung
- SPF, DKIM und DMARC sind drei Authentifizierungsstandards, die helfen, die E-Mails einer Organisation zu schützen.
- Eine korrekte Konfiguration dieser Standards schützt vor Angriffen und verbessert die Zustellbarkeit, sodass E-Mails im Posteingang statt im Spam-Ordner landen.
Auswirkungen
- Google aktualisiert kontinuierlich Algorithmen und nutzergemeldete Daten, um E-Mail-Filterung und Nutzererfahrung zu verbessern.
- Die neuen Sicherheitsrichtlinien zeigen, welche Auswirkungen auf E-Mail-Zustellbarkeit und Interaktion zu erwarten sind.
Tools
- Es wird eine Liste kostenloser Online-Ressourcen bereitgestellt, die bei Einrichtung, Prüfung und Pflege der E-Mail-Hygiene helfen.
Implementierung
- Die Umsetzung dieser Richtlinien kann für kleine Organisationen mit begrenzten Ressourcen eine Herausforderung sein.
- Für die Implementierung der E-Mail-Authentifizierung sollte auf Ressourcen oder Support der Dienstanbieter zurückgegriffen werden.
Bonus
- Es werden einige Methoden vorgestellt, mit denen Hacker Schwachstellen in der E-Mail-Sicherheit ausnutzen.
Meinung von GN⁺
- Dieser Artikel betont, wie wichtig es ist, die neuesten Standards im Bereich E-Mail-Sicherheit einzuhalten. Das erhöht die Zuverlässigkeit der Kommunikation per E-Mail und trägt dazu bei, Nutzer vor Bedrohungen wie Spam oder Phishing zu schützen.
- Da E-Mail-Dienstanbieter neue Sicherheitsstandards durchsetzen, müssen Organisationen Anstrengungen unternehmen, um sich an diese Veränderungen anzupassen und die Vorgaben einzuhalten. Das ist in einer Zeit, in der Datenschutz und Datensicherheit besonders sensibel sind, umso wichtiger.
- Für Unternehmen, die ein Geschäft rund um E-Mail-Marketing betreiben, kann dieser Artikel besonders nützlich sein. Da E-Mail-Marketing für viele Unternehmen weiterhin ein wichtiger Marketingkanal ist, ist die Aufrechterhaltung der E-Mail-Zustellbarkeit entscheidend für erfolgreiche Kampagnen.
- Die Implementierung von E-Mail-Authentifizierungsstandards kann eine technische Herausforderung sein, insbesondere für Organisationen, die erstmals mit Protokollen wie SPF, DKIM und DMARC arbeiten. Für die Einführung dieser Standards können technischer Support und zusätzliche Ressourcen erforderlich sein, was Zeit und Kosten verursacht.
- Indem dieser Artikel hilfreiche Richtlinien und Tools für Organisationen bereitstellt, die ihre E-Mail-Sicherheit stärken möchten, kann er dazu beitragen, Schwachstellen in E-Mail-Systemen zu beheben und die Nutzererfahrung zu verbessern.
1 Kommentare
Kommentare auf Hacker News
Angesichts des Einflusses von E-Mail-Anbietern wie „Gmail“, „Outlook“ und „Yahoo“ habe ich mich immer gefragt, ob als Angriff auf Unternehmen nicht auch gezieltes Zustellungsversagen möglich wäre.
Man bringt das Opfer, insbesondere ein Unternehmen, eine Mailingliste oder eine NGO, dazu, massenhaft E-Mails an Adressen zu schicken, die dem Angreifer gehören, und der Angreifer markiert diese E-Mails bei Gmail/Yahoo/Outlook als Spam.
Dann könnten KI-Spamfilter daraus neue Spam-Aktivität lernen und später sogar E-Mails an echte Kunden als Spam behandeln oder vor der Zustellung löschen.
Nach etwa einem Jahr verliert das Unternehmen vielleicht Quartal für Quartal Geld, die Werbeabteilung wundert sich über sinkende E-Mail-Engagement-Raten, und die Technikabteilung gerät ins Chaos.
Große Unternehmen könnten das überstehen oder E-Mail ganz aufgeben, aber kleine Unternehmen oder NGOs und politische Mailinglisten könnten durch sinkende Spenden tatsächlich getroffen werden.
Ehrlich gesagt ist das als Angriffsweg wohl eher unwahrscheinlich, aber der Gedanke ist mir im Kopf geblieben.
Die Spammer bauten das legitime Template unsichtbar in die E-Mail ein und zeigten nur ein paar Zeilen des eigentlichen Betrugstexts an.
Die Idee war, dass der Filter den Großteil der E-Mail als normal einstuft und sie passieren lässt; wenn dann genug Nutzer Spam melden, löst am Ende das Template selbst Blockierungen aus.
Dann wechseln die Spammer zum E-Mail-Template des nächsten Opfers, das noch durch die Filter kommt, und das erste Opfer bleibt mit dem Aufräumen zurück, weil seine eigenen Mails nirgends mehr ankommen.
Nach einer wirklich schlechten Erfahrung mit einem großen Unternehmen, das sich die Maximierung des Shareholder Value auf die Fahnen schreibt, habe ich alte E-Mail-Verläufe durchsucht und sämtliche Kommunikation dieser Firma als Spam markiert.
Vielleicht ist das nur ein Tropfen auf den heißen Stein, aber in der Spam-Welt braucht es womöglich gar nicht so viele Stimmen.
E-Mail-Zustellung wird sich wohl zu einem noch unverhohleneren Pay-to-Pass-Modell entwickeln, und vielleicht gibt es hinter den Kulissen schon entsprechende Absprachen.
Selbst wenn diese Domain gemeldet wird, können transaktionale E-Mails weiter über die Hauptdomain verschickt werden.
Natürlich setzt das voraus, dass die beiden Mailserver auf unterschiedlichen IPs liegen.
Man kann sich auf der Website abmelden, aber man soll sie eben nicht im E-Mail-Client als Spam behandeln.
Für kleine Organisationen kann das ein ziemlich reales Risiko sein.
Wie große Organisationen das abfedern, weiß ich nicht genau.
Wenn die vom Angreifer gesendete E-Mail bei SPF/DKIM durchfällt, kann man eine DMARC-Policy setzen, damit Gmail diese gefälschte Mail gar nicht erst zustellt.
Dann funktioniert so ein Angriff nicht.
Diese Änderung war nötig und kommt viel zu spät.
Wenn man Domaininhaber, die große Mengen E-Mails verschicken, ordentlich dazu verpflichtet, Nachrichten zu signieren, können Empfänger gute und schlechte Mails klarer anhand der Domain-Reputation statt der Reputation der IP-Adresse unterscheiden.
Da immer mehr Domains E-Mails über gemeinsam genutzte IP-Bereiche von transaktionalen und Marketing-Diensten versenden, ist die Fähigkeit, Reputation stabil an die absendende Domain zu knüpfen, sehr nützlich, um Missbrauch zu reduzieren.
Google sagt zwar, die neuen Anforderungen seien nur verpflichtend, wenn man mehr als 5.000 Nachrichten pro Tag verschickt, aber das ist falsch.
Ich habe höchstens ein paar Mails pro Tag verschickt, über gewöhnliche Gmail-Konten meist nicht einmal eine pro Tag, und obwohl ich nur einen Teil der Anforderungen umgesetzt hatte, begann Google, meine Nachrichten abzulehnen.
Am Ende musste ich Zeit damit verschwenden, alle Anforderungen umzusetzen, einschließlich einiger ziemlich redundanter.
Insgesamt stimme ich zu, dass das eine positive Änderung ist, aber es ist wirklich frustrierend, wenn E-Mails wegen einer Fehlkonfiguration auf Empfängerseite im Spamordner landen.
Zum Beispiel kann SPF beim Weiterleiten kaputtgehen.
Wenn ein böswilliger Absender jede E-Mail von einer anderen IPv6-Adresse verschicken kann, müsste man neu auftauchenden IPv6-Adressen vielleicht grundsätzlich allen misstrauen.
Es ist unbequem, aber ich hoffe, diese Änderung bringt das E-Mail-Ökosystem in Ordnung.
Spam ist von bösartigen Inhalten nicht zu unterscheiden.
Du hast dich nie für diesen „Newsletter“ angemeldet; deine E-Mail-Adresse wurde gesammelt und an böswillige Akteure weitergegeben, die dich belästigen wollen.
Wenn du irgendetwas anklickst, landest du auf einer Website eines Unternehmens, das deine Daten hat und deine Interessen in keiner Weise berücksichtigt.
Im besten Fall entfernst du damit nur eine Quelle von Müll in deinem Posteingang; im schlimmsten Fall klickst du auf etwas, das Malware auf deinem Computer installiert.
Deshalb: Klicke nicht auf Abmeldelinks, drücke den Spam-melden-Button und höre auf, große E-Mail-Dienste zu nutzen, die Spam-Meldungen ignorieren.
Gmail lässt andere Großunternehmen dir Spam schicken und gibt dir nicht einmal die Möglichkeit, ganze Domains direkt zu blockieren.
Solange du nicht zu einem E-Mail-Anbieter wechselst, der Datenschutz und Sicherheit ernst nimmt, werden bösartige Inhalte weiter in deinem Posteingang landen.
Ich bin neugierig, welchen E-Mail-Anbieter du nutzt.
One-Click-Abmeldung: Es überrascht, dass so viele Großunternehmen diesen Test nicht bestehen
Entweder blockieren Cloudflare oder Akamai die Verbindung, die Seite braucht mehr als 5 Sekunden zum Laden, oder es wird verlangt, sich einzuloggen bzw. die E-Mail-Adresse erneut einzugeben
Danach sollte man sich nicht wundern, wenn Kunden auf den Spam-melden-Button klicken
Deshalb klicke ich auf Spam melden
Am nervigsten ist, dass E-Mail-Absender Click-Tracking über Domains machen, die von Werbeblocker-Listen blockiert werden
Ich habe zwar eine separate Browser-Instanz, um solche Links hineinzukopieren, aber dann muss ich mich wieder anmelden
Ich schicke lieber eine Abmelde-E-Mail, als auf den Link zu klicken, und Gmail kann das automatisieren
Wenn in ein paar Tagen wieder eine E-Mail kommt, markiere ich sie als Spam
Wenn TripAdvisor KI-generierte Reisepläne erstellen kann, sollte es auch herausfinden können, wie man sie nicht per E-Mail verschickt
Kunden wählen den bequemeren Weg, egal ob Abmeldung oder Spam-Meldung
Eine Sache, die durch die Änderungen im April kaputtgeht, ist die Weiterleitung zwischen E-Mail-Diensten
Wenn man zum Beispiel von der alten Uni-Adresse foo@school.edu auf ein privates Gmail-Konto bar@gmail.com weiterleitet, wird das nicht mehr funktionieren
Nach dem Vorgehen der großen Anbieter zu urteilen ist das wohl ein relativ seltener Anwendungsfall, aber für Betroffene ist es eine ziemlich lästige Änderung
Solange der Weiterleiter den Nachrichteninhalt nicht verändert, passt er weiterhin zur DKIM-Signatur und sollte durchkommen
SPF hat Weiterleiter, die die Absenderadresse im Envelope nicht anfassen, schon immer kaputtgemacht, und das ist richtig und angemessen
Mail-Weiterleitung ist weiterhin möglich, aber der Weiterleiter muss den Return-Path umschreiben
Es überrascht mich, dass überhaupt jemand Mails durchgelassen hat, obwohl SPF, DKIM und DMARC nicht perfekt eingerichtet waren
Ich habe jahrelang einen gut konfigurierten selbst gehosteten privaten E-Mail-Server betrieben und hatte trotzdem gelegentlich Schwierigkeiten, durchzukommen; immerhin scheint es nach und nach besser zu werden
Besonders Microsoft-Server lassen völlig unproblematische DKIM-Konfigurationen oft ohne ersichtlichen Grund zufällig fehlschlagen
Bei geringem Versandvolumen besteht schon allein deshalb die Gefahr, verworfen zu werden, weil man kein bekannter Absender ist
Da die großen drei solche Richtlinien veröffentlicht und transparent gemacht haben, hoffe ich auf konsistenteres Verhalten
Spammer können das genauso machen, weil die Einstiegshürde niedrig ist
Wichtig ist es zwar, aber mit realer Zustellbarkeit hat es nur sehr wenig zu tun
Das Schwierigste an DMARC ist, dass es besonders bei Microsoft häufig fehlschlägt
Außerdem gibt es Probleme bei allen Anwendungsfällen, in denen Empfänger Mails weiterleiten; dabei bricht die SPF-Ausrichtung
Weil ich Best Practices folgen wollte, habe ich kürzlich p=quarantine auf p=none geändert
Ich hatte Angst, dass legitime E-Mails DMARC nicht bestehen, obwohl DKIM und SPF korrekt eingerichtet sind
Ich würde wirklich gern p=reject nutzen, kann es aber nicht, bis die Empfänger ihre eingehenden Mailserver so reparieren, dass sie solche Ausnahmefälle behandeln, in denen E-Mail-Weiterleitung DMARC bricht
Das Weiterleiten einer DKIM-signierten Nachricht bricht DMARC überhaupt nicht
Am schlimmsten ist, wenn Mails angenommen, stillschweigend als Spam markiert und an einen Ort verschoben werden, an dem der beabsichtigte Empfänger sie nie sieht
Googles Gmail macht das am schlimmsten
Unternehmens-E-Mail ist keine E-Mail mehr, sondern ein Walled Garden und ein Silo wie Facebook
Sonst würden wir in Cold-E-Mail-Spam ertrinken
Im Ernst: Ich habe den Betrieb und die Verwaltung eigener Server aufgegeben und nutze für alle Firmen Gmail
Dass das so schwierig geworden ist, ist tragisch
Wenn man nicht auf einem gut konfigurierten Gmail Workspace sitzt, fühlt es sich so an, als hätten selbst legitime Mails keine Chance durchzukommen
Soweit ich es verstehe, will man Spammern offenbar kein Signal geben, ob eine Nachricht als normale Mail oder als Spam eingestuft wurde
Ich würde gern wissen, wie intelligent Spammer solche Informationen tatsächlich nutzen
Der meiste Spam wirkt wie ein stumpfes Draufhauen, ohne Fehler-Feedback zu berücksichtigen
Auf meinem Mailserver lasse ich als Junk eingestufte Nachrichten mit einer normalen Fehlermeldung weiterhin temporär ablehnen
Zumindest falsch klassifizierte legitime Absender bekommen so eine verzögerte DSN und am Ende Feedback, dass die Nachricht nicht zugestellt wurde
Viele Mailserver und Dienste scheinen es wichtiger zu finden, Spammern kein Signal zu geben, als falsch klassifizierten legitimen Nutzern ein nützliches Signal zu liefern
Vielleicht glauben sie auch, ihre Klassifizierung sei so hervorragend, dass sie keine Fehlklassifizierungen produziert
Gmails Spamfilter und Promotions-Filter sind aus Nutzersicht zu über 99 % verlässlich, und False Positives sind wirklich selten
Im B2B-Bereich hat im Grunde jeder Marketer, der deine E-Mail-Adresse herausfinden kann, das Recht, dir so viele Nachrichten zu schicken, wie er will
Ohne diese Mauer wäre es völlig unbenutzbar
Meine persönliche VM ist auf einer RBL gelandet, weil der gesamte /24-Adressraum auf die Blacklist gesetzt wurde.
Offenbar hat jemand Spam verschickt, und jetzt wird auch meine Maschine blockiert, die etwa drei E-Mails pro Woche versendet.
Der Spammer könnte eine beliebige Adresse in diesem Bereich genutzt haben, oder jemand könnte einen falsch konfigurierten SMTP-Server betrieben haben, der Relaying erlaubt.
Einen ausgehenden SMTP-Server in einem Kunden-IP-Bereich zu betreiben, ist ohnehin anfällig für Probleme.
Solche Bereiche kann man insgesamt als verdächtig betrachten, weil Spammer sie nutzen, ohne sich um Reputation zu kümmern.
Es scheint, als würden Betreiber von Blocklisten Missbrauchsmeldungen schlecht prüfen oder Kollateralschäden verursachen, um Netzwerkbetreiber zum Handeln zu bewegen.
Ich möchte nicht auf einer Blockliste landen, aber für das offene Internet könnte es vielleicht einen Nettoeffekt geben.
Meiner Ansicht nach verwenden Mailserver und Dienste IP-basierte Blocklisten falsch.
Man kann sie als eines von mehreren Signalen nutzen und bei erstmals gesehenen Absendern stärker gewichten.
Wenn aber eine per SPF/DKIM/DMARC authentifizierte Nachricht von einer IP kommt, mit der man schon länger Nachrichten und Transaktionen austauscht, und diese IP plötzlich auf einer Blockliste steht, sollte die frühere positive Reputation stärker wiegen als diese Blockierung.
Mit bekannten Gegenstellen sollte man weiter kommunizieren können, und erst nachdem sie etwas als Spam markiert haben, sollte man spätere Zustellungen ablehnen oder als Junk behandeln.
Derzeit scheinen viele Mailserver und Dienste IP-Blocklisten sehr früh im SMTP-Prozess anzuwenden, um die Systemlast zu senken.
Das ist gut für die Systemlast, aber schlecht für die Analysequalität.
Insgesamt wirken selbst große kostenlose Maildienste nicht besonders gut darin, vorhandene Reputation für die Unterscheidung zwischen legitimer Mail und Spam zu nutzen.
Kürzlich habe ich einen von mir gebauten Online-Webservice auf eine E-Mail-basierte Registrierung umgestellt, ähnlich wie bei Mailinglisten: Man meldet sich an, indem man eine E-Mail an eine bestimmte Adresse schickt.
Die Idee ist, dass ich in die Liste bekannter Kontakte des Nutzers aufgenommen werde, wenn der Nutzer meinem Dienst eine E-Mail sendet.
Dann sollte die SPF/DKIM/DMARC-konforme Bestätigungsantwort meines Mailservers natürlich akzeptiert werden.
Wie viel klareres Opt-in braucht man denn noch?
Als ich das bei einigen großen kostenlosen Maildiensten getestet habe, hat Yahoo sogar die Bestätigungsantwort, die auf die ursprüngliche Nachricht verwies, in den Junk-Ordner gelegt.
Für alle, die glauben, man könne mit großen Maildiensten nicht konkurrieren: Die Messlatte liegt nicht so hoch, wie man denkt.
Reputation wiederherzustellen, ist selbst im besten Fall fast ein Albtraum.
Ich habe auch den Vorschlag gesehen, zum Schutz der Hauptdomain eine andere Domain zu kaufen und E-Mails darüber zu versenden, aber das möchte ich eigentlich nicht.
Im Artikel scheinen Envelope (RFC5321) und Header (RFC5322) vermischt worden zu sein.
Dort heißt es, „der Domainname im From:-Feld des E-Mail-Envelope-Headers wird geprüft und mit anderen per SPF oder DKIM authentifizierten Domains abgeglichen“, aber ein Envelope hat keine Header; Header befinden sich im E-Mail-Inhalt/-Body.
Auch der Screenshot „Beispiel für einen E-Mail-Envelope einer Organisation, der alle E-Mail-Sicherheitsrichtlinien besteht“ zeigt keine Envelope-Informationen, sondern Mail-Header.
Zu diesem Thema gibt es eine gute Präsentation von dmarc.org.
https://dmarc.org/presentations/Email-Authentication-Basics-...