Google Spamschutz 2024
Zwei große Consumer-Postfachhoster haben angekündigt, dass Sie ab Februar 2024 neue Prüfungen für eingehende Mails schrittweise aktivieren, um ihre Kunden besser gegen Spam/Missbrauch zu schützen. Im Grund aktivieren Google endlich die Einstellungen, die ich schon lange habe. Entsprechend finden Sie mehrere Blog-Artikel bei Dienstleistern zum Versand von Massenmails. Diese Thema ist nur relevant, wenn Sie Mails an Empfänger der folgenden Domains senden.
gmail.com googlemail.com
Zudem unterscheidet Google Versender mit weniger als 5000 Mails/Tag pro Absenderdomain und Absenderdomains mit mehr als 5000 Mails/Tag.
Follow these guidelines to help ensure messages are
delivered to Gmail accounts as expected, and to help prevent Gmail from limiting
sending rates, blocking messages, or marking messages as spam.
Email sender guidelines
https://support.google.com/mail/answer/81126?hl=en
Die Anforderungen gelten auch für Mails an "Yahoo". Microsoft
hat einen eigenen Weg um die eigenen Server besser zu qualifizieren. Siehe dazu
Smart Network Data Service
https://sendersupport.olc.protection.outlook.com/snds/
Getting started with Microsoft SNDS: Sender reputation
https://www.mailgun.com/blog/deliverability/microsoft-snds-understanding-sender-reputation/
Allgemeine Anforderungen
Für alle Systeme, die Mail an Google einliefern, gelten folgende Grundvorgaben, die aber nicht schwer zu erfüllen sind.
Auch die 100% Erfüllung dieser Bedingungen garantiert nicht, dass ihre Mails angenommen, den Spamfilter passieren und in den Posteingang zugestellt werden.
Prüfung | Erfüllt |
---|---|
DNS AuflösungIhr einliefernder SMTP-Server meldet sich bei Google mit einem "HELO <fqdn des Servers>". Dieser Namen muss per DNS aus dem Internet auflösbar sein. Google sieht zudem die IP-Adresse des Servers. Auch die IP-Adresse muss per DNS auf den Server (Reverse DNS) auflösbar sein. Das ist kein Problem, wenn ihr Mailserver eine öffentliche statische IP-Adresse hat und sie ihren Server korrekt konfiguriert haben. Wenn aber ihr eigener Exchange Server direkt versendet, nutzt er per Default den Server-FQDN und der ist bei vielen Firmen nicht öffentliche auflösbar. Hier müssen Sie dann einen Send-Connector anlegen oder anpassen, damit der Parameter "FQDN" einen gültigen liefert. Set-Send-Connector ` -Identity <Identity> ` -FQDN <öffentlicher DNS-Name> Wer noch gar keinen Send-Connector hat, muss erst einen anlegen. Wer vorgelagert ein SMTP-Gateway verwendet, muss dies dort prüfen.
|
|
SPF und/oder DKIMSPF und DKIM sind unterschiedliche Verfahren, die sicherstellen sollen, dass die Absenderdomain nicht missbraucht werden kann, indem eine Allow-Liste der Versendesysteme per DNS-Eintrag veröffentlicht oder der Inhalt der Mail signiert wird. Auch die Signatur stützt sich auf DNS-Informationen. Eigentlich gehört die Einrichtung von SPF schon lange zu einer Pflicht aber DKIM können z.B. lokale Exchange Server nur mittels 3rd Party AddOn oder eine vorgeschaltete Verarbeitung durch Gateways wie NoSpamProxy - eine Idee ist Realität geworden. Beide Verfahren schützen zwar vor Fälschung aber nicht gegen Phishing/Spam, denn Spammer können eigene Domains/ähnliche Domains anmelden und problemlos SPF/DKIM einrichten und erfüllen. Hinweis: Google erwartet bei DKIM mindestens eine 1024bit-Signatur Leider schreibt Google nicht, ob sie ein "-all" einfordern. Insofern ist auch ein "weicher" SPF-Eintrag mit +all oder ?all möglich |
|
TLS verwendenIch habe keine Zahlen, welcher Anteil im Internet immer noch SMTP ohne TLS macht. Zumindest "Opportunistic TLS" mit einem eigenen Zertifikat ist immer noch besser als eine Klartextmail. Vermutlich sind es nur einfache Versendetools, die kein TLS machen. Diese Hürde sollten Sie problemlos nehmen können. Nutzen Sie die Change vielleicht auf ihrem Server ein offizielles Zertifikat einzurichten oder zumindest überhaupt ein gültiges Zertifikat zu nutzen, damit eingehende Mails ebenfalls per TLS abgesichert sein können.
|
|
Spamrate < 0,1%, aber auf jeden Fall <0,3%Google wird weiterhin eingehende Mails auf Spam bewerten und als Massenversenden sollten Sie einen Blick auf die Google Postmaster Tools (https://gmail.com/postmaster/) haben, über die Google ihnen für ihre Domain die entsprechende Information liefert.
|
|
RFC5322-FormatGoogle schreibt war nicht genau, was Sie wie prüfen aber falsch formatierte Mails haben ja den ein oder anderen Server schon einmal zu unerwarteten Reaktionen veranlasst. Eine "Input-Validierung" ist daher immer eine gute Idee um Fehler, Lücken, Missbrauch zu erschweren. |
|
Die allgemeinen Regeln gehören eigentlich schon lange zu einem guten Setup und dürften weitgehend schon erfüllt sein. Dennoch lohnt sich ein Blick auf die eigenen Versender, insbesondere für spezielle Domains wie "<user>@helpdesk.<firmendomain>" o.ä., die vielleicht nicht mit SPF korrekt konfiguriert sind. Damit haben ja auch schon namhafte Versender (z.B. Google blockt Domain ct.de wegen Microsoft?) ihre Erfahrungen gemacht.
Zusätzlich >5000 Mails/Tag
Für Versender höherer Mailvolumen gelten erst einmal die gleichen Vorgaben wie für Versender weniger Mails. Aber wenn Google bei der täglichen Zählung auf mehr als 5000 Mails pro Absenderdomain kommt, dann gelten weitere Regeln.
Leider schreibt Google nicht, ob eine Mail an mehrere Empfänger als eine Mail gewertet wird oder die einzelnen Empfänger zählen.
Prüfung | Erfüllt |
---|---|
DMARCSobald sie mehr als 5000 Mails pro Absenderdomain senden, müssen Sie auch einen DMARC-Record veröffentlichen. Dies ist ein TXT-Record im DNS ihrer Domain. Ein DMARC Record steuert mehrere Dinge:
Dennoch würde ich heute auch immer einen DMARC-Record setzen und die Rückmeldungen auswerten. Google akzeptiert im Feb2024 auch ein "None" als Richtlinie. Also kann der Eintrag mit Ausnahme bei Alignment-Fehlern recht gefahrlos gesetzt werden.
|
|
Kein Versand mit einer Google-DomainIch finde es interessant, dass G/Y überhaupt Mails von ihren eigenen Domains aus dem Internet angenommen hatten. Das ist doch die erste Blockade, um Fälschungen zu verhindern. Google wird ihre eigene Domain mit "DMARC: Quarantäne" konfigurieren, so dass solche Mails immer in de Quarantäne landen. Das hat nichts damit zu tun, wenn Sie ein Postfach bei Google haben sie sich über Port 587 anmelden um eine Mail über den Provider zu versenden. |
|
ARC für WeiterleitungenAuf den Seiten Google blockt Domain ct.de wegen Microsoft? und DDMARC bricht SPF mit SRS habe ich schon die Probleme von Umleitungen beschrieben. Dies betrifft durch DMARC auch den Versand von Mails eines AbsenderA an ein PostfachB, wenn PostfachB die Mails an an ein Google-Postfach umleitet. Ein häufiger Fall ist der Betrieb einer Mailingliste, in der auch Google-Postfächer eingetragen sind. Exchange Online addiert ARC-Header aber Exchange OnPremises kann dies nicht
|
|
Unsubscribe-LinkFür "Marketing-Mails" fordert Google einen einfachen Unsubscribe-Link in der Mail als auch im Header, damit Empfänger einfach einen Verteiler wieder verlassen können. Dabei bleibt offen, wie genau Google eine "Marketing-Mail" definiert.
|
Fehlersuche
Ich erwarte, dass mit der Umsetzung der neuen Vorgaben ab Februar 2024 die meisten Firmen beim regulären Mailverkehr nicht viel davon mitbekommen dürften. Zumindest meine Kunden haben relativ wenige B2C-Geschäftsmails und zumindest einen SPF-Eintrag und senden kaum mehr als die 500 Mails/Tag. Es könnte aber Mails des Marketings erwischen, wenn Sie eigene Strukturen nutzen. Sobald Sie über die bekannten großen Mailversanddienstleister (Sendgrid, Mailgun, etc.) senden, addieren diese Dienstleister in der Regel nicht nur den Unsubscribe-Link sondern auch DKIM- und ARC-Einträge und fordern den Kunden schon bei der Einrichtung auf, die entsprechenden Einträge bei SPF, DKIM und DMARC zu machen.
Es dürfte also eher die Firmen erwischen, die auch den Massenmailversand selbst betreiben und nicht auf der Höher der Zeit bezüglich SPF, DKIM, ARC, DMARC sind. Es gibt aber mehrere Ansätze, bei Problemen die Ursache zu ergründen.
- NDR-Kontrolle
Wenn Google und auch andere Server eine Mail nicht zustellen werden, dann lehnen diese immer häufiger bei SMTP-Empfang schon mit einer Fehlermeldung ab. Es gibt leider auch immer noch Systeme, die Mails erst annehmen und nachträglich selbst eine Unzustellbarkeitsmeldung senden. In beiden Fällen können Sie aber die Rückmeldung analysieren, wenn es zur Absenderadresse auch ein Postfach gibt, welches Sie auswerten können. Wer natürlich Mails mit "noreply@<firmendomain>" sendet und kein Postfach vorhält, kann maximal aus dem Messagetracking oder Performance Countern erkennen, dass die Zustellungsrate abnimmt. - Google Postmaster Tools
Da es hier um den Versand an Google-Postfächer geht, sollten Sie ihre Domain bei den Google Postmaster Tools (https://gmail.com/postmaster/) anmelden und über den Weg Zugriff auf die Zustelldaten erhalten und diese kontrollieren. Auch den Troubleshooter auf https://support.google.com/mail/troubleshooter/2696779 können Sie nutzen - Versand verifizieren
Ob ihr eigener Server alles korrekt macht, können Sie z.B. mit Dienste wie https://www.learndmarc.com prüfen. Sie senden eine Mail an die temporäre Adresse und sehen genau die Auswertung.
Wer Massenmails versendet oder als Firma so groß ist, dass viele Mails/Tag an Google gehen, sollte immer auf dem aktuellen Stand beim Spamfilter (eingehende aber auch ausgehend) sein und Rückläufer und Fehler gewissenhaft abarbeiten.
Weiter Links
- Spam und UCE - Filter: SPF, SenderID
- Spam und UCE - Filter: DKIM
- DMARC
- DMARC bricht SPF mit SRS
- NoSpamProxy - eine Idee ist Realität geworden
- Google blockt Domain ct.de wegen Microsoft?
- ARC - Authenticated Received Chain
- Email sender guidelines
https://support.google.com/ail/answer/81126?hl=en
https://support.google.com/mail/answer/81126?hl=en#troubleshooting - Google Postmaster Tools
https://gmail.com/postmaster/ - Neue Richtlinien für E-Mail-Absender bei Google: Was Sie tun
müssen
https://www.nospamproxy.de/de/neue-richtlinien-fuer-e-mail-absender-bei-google/ - NoSpamProxy Serie zu "Absenderreputation und E-Mail-Sicherheit"
Teil 1: Authenticated Received Chain (ARC)
https://www.nospamproxy.de/de/authenticated-received-chain-arc/
Teil 2: Sender Policy Framework (SPF)
https://www.nospamproxy.de/de/sender-policy-framework-spf/
Teil 3: DomainKeys Identified Mail (DKIM)
https://www.nospamproxy.de/de/domainkeys-identified-mail-dkim/
Teil 4: Domain-based Message Authentication, Reporting and Conformance (DMARC)
https://www.nospamproxy.de/de/domain-based-message-authentication-reporting-conformance-dmarc/
Teil 5: DNS-based Authentication of Named Entities (DANE)
https://www.nospamproxy.de/de/dns-based-authentication-of-named-entities-dane/ - February 2024 Gmail and Yahoo Authentication Requirements
https://help.actionnetwork.org/c/en-us/articles/22453842139028-February-2024-Gmail-and-Yahoo-Authentication-Requirements - What Are Google’s February 2024 Gmail Guidelines and How to
Deal with the New Email Sender Rules?
https://woodpecker.co/blog/gmail-rules-changes-february-2024/ - Prevent spam, spoofing & phishing with Gmail authentication
https://support.google.com/a/answer/10583557 - Google and Yahoo are upping their game in 2024!
https://blog.mxtoolbox.com/2023/10/20/google-and-yahoo-are-upping-their-game-in-2024/ - Google and Yahoo Updated Email Authentication Requirements
for 2024
https://www.youtube.com/watch?v=qxuCKEMC5S8 - Your 2024 guide to Google & Yahoo’s new requirements for
email senders
https://postmarkapp.com/blog/2024-gmail-yahoo-email-requirements - Linkedin: New requirements from Gmail and Yahoo Mail
effective February 2024
https://www.linkedin.com/posts/alitajran_spf-dkim-dmarc-activity-7149042205570056192-I4fE - Smart Network Data Service
https://sendersupport.olc.protection.outlook.com/snds/ - Getting started with Microsoft SNDS: Sender reputation
https://www.mailgun.com/blog/deliverability/microsoft-snds-understanding-sender-reputation/ - What Is Microsoft Smart Network Data Services (SNDS) and Do
I Need It?
https://sendgrid.com/en-us/blog/what-is-microsoft-smart-network-data-services