Blog-Leser Alexander J. hat mich kürzlich über eine Neuerung bei Google Mail (GMail) informiert. Der Mail-Dienst von Google werden wohl nicht mehr angenommen, wenn kein SPF-Record existiert. Das scheint im Februar 2023 scharf geschaltet worden zu sein.
Anzeige
Alexander hatte mich bereits im Februar 2023 per Mail kontaktiert, um mich auf ein Problem mit Google Mail (GMail) hinzuweisen (danke dafür). Er schrieb, dass ihm der Fehler "erst heute aufgefallen ist" als ein Kunde von ihm sich beschwert hat, dass seine E-Mails von Google nicht mehr angenommen werden.
Der Schluss den Alexander zog, ist, dass Google offenbarstill und schweigend das so scharf geschaltet hat, dass ohne SPF-Record überhaupt keine E-Mails mehr angenommen werden.
Alexander hat mir dazu den Link auf den Google-Supportbeitrag Vermeiden, dass E-Mails an Gmail-Nutzer blockiert werden oder im Spamordner landen mitgeschickt, wo das Ganze diskutiert wird. Im Artikel wird den Nutzern geraten, die Richtlinien von Google zu beachten. Nur dann können E‑Mails erfolgreich an private Gmail-Konten gesendet und zugestellt werden.
Google schreibt, dass ab 2024 E‑Mail-Absender die im Artikel beschriebenen Anforderungen erfüllen müssen, wenn sie E‑Mails an private Gmail-Konten senden wollen. Private Gmail-Konten enden auf @gmail.com oder @googlemail.com, gibt Google an.
Anzeige
Im Artikel gibt Google in den Richtlinien an, dass die Verwendung einer TLS-Verbindung zum Übertragen von E‑Mails seit Dezember 2023 gefordert wird – das ist also eine alte Anforderung. Neu ist, dass alle Absender einen SPF- oder DKIM-Eintrag für die Domain einrichten bzw. konfigurieren müssen. Für die Absender von Massen-E‐Mails gilt sogar, dass die drei Einträge SPF, DKIM und DMARC für die Domain zu konfigurieren sind. Das ist wohl eine Maßnahme zur Spamerkennung und -abwehr.
Anzeige
Meiner Erfahrung nach, müssen SPF-Record und DMARC-Record vorhanden sein.
Es reicht, wenn ein SPF-Record vorhanden ist
Ist DMARC wirklich Voraussetzung? Wir haben nur einen SPF-Eintrag und ich konnte eine Mail eben ohne Probleme an eine Google-Adresse zustellen.
Also bei uns war der SPF-Record vorhanden und die Mail ging nicht durch, erst als ich noch einen DMARC-Record gesetzt habe, ging die Mail durch.
Kann ich bestätigen.
Wir bekommen seit ein paar Tagen NDRs wegen fehlendem DMARC von GMail… *tja*
Finde es aber grundsätzlich gut, dass "die Großen" es jetzt langsam mal durchziehen…
google mal wieder. meinen der nabel der welt zu sein was security betrifft. in der realität eine der lausigsten buden überhaupt. so dermaßen kaputt wie google ist nicht mal microsoft unterwegs.
selbst wenn du bei denen mal kunde warst und alles gemäß ihren formularen gekündigt wurde, die accounts gelöscht wurden etc, wirst du jahre später noch immer damit belästigt, dass dein account irgendwo in ein neues cloud service migriert wird oder, dass alte kreditkarten daten nun abgelaufen sind und aktualisiert werden sollen.
und selbst da kann man google nicht kontaktieren, weil google lebt nur von formularen, die der eingeloggte kunde ausfüllen kann. und auch da heisst es dann ping pong mit abteilungen bei google spielen.
drum nie wieder google dienste und schon gar kein android. von den grossen dreien ist google was support und so betrifft, die mieseste bude. bestens bedient wird man noch bei apple, dann kommt microsoft. und dekaden später am ende google
eine ordentlich kontaktmöglichkeit von google wäre schon echt toll
Die Verweigerung kann ich bestätigen. Eine unserer GmbHs hatte nach einem Domainumzug keinen SPF und das fiel nicht auf, bis jetzt.
Wir haben sofort SPF und DMARC nachgezogen, aber werden immernoch geblockt. Selbst nach 72-stündigem Selbst-Exil mit komplettem SMTP-Block in Richtung Google. Ich weiß langsam nicht mehr, wie ich das wieder hingebogen bekomme… Bleibt mir wohl nur Auseinandersetzen mit dem Google-Support…
LG
Frank W.
versuche es mal mit einem "~all" [tilde] statt einem "-all" [minus] am Ende vom SPF Record, ist zwar nicht ideal, aber vor allem bei kleineren Hostern hilfreich, da die in Ihrer Dokumentation oft nicht alle Mailserver stehen haben und der SPF Record dann ggf. unvollständig ist.
-all hat bei uns dann auch geholfen!
Nimm eine andere IP für die Email Auslieferung (mit SPF)
Den ganzen AS wird Google nicht sperren.
und Stelle sicher, das ihr Emails die ihr nicht zustellen könnt, schon beim Eingang rejektet und nicht etwa annehmt und dann einen Bounce macht (Back scsttering)
Meine E-Mails per PHPMailer enthalten keine SPF-Records. Wie ich das ändern kann, weiß ich momentan nicht. Stellt sich für mich derzeit nicht als Problem dar, weil ich per PHPMailer keine Mails an Google Konten versende. Ich hatte aber einmal ein Problem, wie ich Mails per PHPMailer an yahoo Konten versendete. Dies habe ich abgestellt. Es wird jedenfalls immer aufwendiger sich mit den Thematiken zu beschäftigen, wenn man kein finanziell potenter Großkonzern ist.
Ich glaube du hast nicht verstanden was SPF ist, dass wird im DNS einmal eingerichetet, im Idealfall für alle Server die Mails für die Domain versenden und damit ist das Thema erledigt. Ob man Outlook (EWS), IMAP, SMTP oder was auch immer zum versenden von Mails verwendet ist egal.
Der SPF record kommt in den DNS, nicht in die Email.
Du musst den SPF mit Deiner Server IP in den DNS Deiner Domain eintragen.
Das wird via DNS geregelt, da hat Dein Mailer nix mit zu tun.
Kann ich so bestätigen. Habe mich die letzten Wochen schon gefragt, warum Mails von meinem privaten Mailserver zu Gmail Adressen abgewiesen werden. Letzte Woche dann unabhängig davon mal ein wenig Pflege und Hardening des eigenen Mailservers betrieben und beim Testen festgestellt, dass Gmail weiterhin nicht funktioniert. Nach ein wenig Recherche und Log-Überprüfung dann auf den Fehler gestoßen. Habe dann einen SPF-Record erstellt und dann lief es sofort. Kann man gut mit einem SPF-Lookup-Checker überprüfen.
Eigentlich schreib Google eine klare Umfangreiche Fehlermeldung beim rejekt.
Richtig. Hab es erst ignoriert, weil ich mich noch nicht intensiv genug damit auseinandergesetzt hatte. War ehrlich gesagt auch nicht sonderlich traurig, dass Google meine Daten nicht möchte. Beim Warten des Servers hatte ich dann aber ausreichend Zeit, mir mal anzuschauen, was so ein SPF-Record eigentlich macht. Das lernt man ja auch nicht in der Schule.
Gerade Mal ausprobiert. Gesendet über Strato mit SPF=Keine SPF-Regel an mein Google-Konto. E-Mail kam erfolgreich an.
Über eine Webseite den Record angesehen: Gibt keinen.
Google macht das Stück für Stück. Kann sein das du morgen dran bist, kann sein das du in einem Jahr dran bist…
https://support.google.com/mail/answer/81126#authentication
Danke für den Link.
Da steht: "Ab November 2022 müssen neue Absender, die E-Mails an private Gmail-Konten senden, entweder SPF oder DKIM einrichten."
Aus dem Header einer E-Mail von der Firma an mich:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=nnnnnnnn;
s=strato-dkim-0002; d=nnnnnnnn.de;
Damit gibt sich Google dann auch zufrieden.
Uralter Hut und wurde schon vor Monaten angekündigt. Wer Mailserver betreibt, sollte es kennen – oder dem offenen Netz fernbleiben.
Auch andere Dienste setzen gewisse Voraussetzungen, bevor sie Mails annehmen (Geylisting, anyone?)
SPF und DKIM sollten eigentlich heutzutage Standard sein. DMARC ist nicht notwendig, aber hilfreich.
Gerade in der heuten Zeit, wo es nur so von Spam und Phisishing wimmelt, wundert es mich doch sehr, dass man solche Maßnahmen nicht schon lange nutzt, wenn man eine eigene Domain hat. Schon alleine als Selbstschutz.
Weil es Bullshit ist!
Wie viele Mail Anwender haben ihre Mail-Domain wohl bei 1und1/IONOS/Strato/Host Europe/DF/Microsoft 365 usw. usf. ???
Die meisten werden dann auch einen Smarthost bei ihrem Provider verwenden selbst wenn sie noch eigene Server haben.
Bedeutet bei IONOS z.B.: ALLES geht über mout.kundenserver.de raus. Das bedeutet alle IONOS Kunden haben diesen Eintrag im SPF – RICHTIG – jeder IONOS Kunde kann also seelenruhig Mails im Namen Fremder IONOS-Domains versenden, weil die trotzdem vom "richtigen" Server stammen. Damit kann man es auch sein lassen, wenn Millionen Anwender sich auf eine Handvoll Provider stützen ist die Chance gut, dass der SPAM gerade so weiter rausgeht wie bislang…
Korrekte Reaktion wäre dem Empfänger zu sagen: Hey dein Provider (Google) baut Schei*e such dir mal einen anständigen Provider!
Das gilt für SPF,
bei DKIM / DMARC geht es um die Absendende Domain
ja, das ist ein Problem des SPF.
Da stehen manchmal Millionen Addresse als erlaubt drin, Cloud
..
Darum gibt es ja auch DKIM und DMARC
dann dürfte alles von @t-online.de nach gmail jetzt geblockt werden?
Denn @t-online.de hat es seit Jahren nicht nötig SPF zu nutzen.
Ja das wird dann genau so sein. Dann muss sich der T-Online Support damit rumschlagen.
Gerade eben getestet mittels @t-online.de und @magenta.de Absenderadressen. Beide Testmails an GMail kamen an.
Habe es auch getestet: @t-online an @gmail kommt an. (@magenta hat sowieso SPF). Bei aller Aufregung und t-online-bashing, man darf ja auch nicht vergessen, dass es auch Kritik an SPF gibt ;-) (und damit will ich nicht gleich die Telekom "verteidigen").
Wer eine eigene Domäne hat und seinen SPF-Eintrag immer noch nicht gesetzt (wir haben 2023, hallo?), der gehört nicht wirklich auf die Allgemeinheit losgelassen.
Das passiert auch nur, wenn Script Kiddies sich ihre E-Mail-Server ohne Verstand selbst aufsetzen, denn die anderen müssen darunter leiden durch unnötiges Spamaufkommen, das so einfach zu 100% verweigert werden könnte.
Für eine Domäne mit ganz simpel im DNS gesetzten SPF wird von keinem professionellen Mail-System mehr E-Mail(Spam) angenommen. Ohne SPF kann jeder x-beliebige im Namen der Domäne E-Mails versenden und nur andere Verfahren können mutmaßen, ob es sich um Spam handelt.
Ich habe für unsere Domäne sogar schon seit Jahren konfiguriert (im Mailsystem), dass keine SMTP-Verbindungen bidirektional mehr aufgebaut werden, die kein bis zu einer Zertifizierungsstelle gültiges TLS-Zertifikat aufweisen, d. h. sämtliche E-Mails werden sicher auch zwischen den Servern nur verschlüsselt oder gar nicht übertragen.
Seine eigene Konfiguration kann man sehr einfach z. B. über https://checktls.com prüfen: links in der Mitte nur die Domäne eintragen und auf Check It. Danach auf Show Detail und schauen, dass unter Cert alles grün ist.
Das Google hier Tabula Rasa macht, finde ich absolut super! Man erhält vermutlich eine für Profis aussagekräftige Rückmeldung. Wer damit nicht umzugehen weiß, soll einfach einen guten Standard-E-Mail-Anbieter nutzen oder seine Hausaufgaben machen.
Ich hatte schon 2018 damit Probleme, als Mail meiner privaten Domain an eine Google-Adresse plötzlich im Spam landeten, nachdem sie zuvor immer durchgingen. Damals mußte ich eine Weile forschen, woran es lag. Die Adressatin wolte mich dann einfach in die Liste der vertrauenswürdigen Absender aufnehmen. Aber ich wollte eine Lösung, die für alle Google-Konten greift. Da mußte ich erst mal nach suchen.
ich hatte dieses Problem bereits Mitte letzten Jahres bei mehreren Kunden, die nicht mehr an gmail-Adressen mailen konnten.
Überall musste nur der SPF gesetzt werden und dann war gut.
Beim SPF gab es "neulich" eine Änderung.
Bisher machte dies nichts, weil die Email trotzdem angenommen wurde, aber heute ja.
Ich glaube man darf nur noch IPs angeben und keine Domains.
Es ist einfach zu viel Arbeit für die Server.
Auch die Include Tiefe ist begrenzt
Begrenzte Include Tiefe ist natürlich schon wieder schei***
Nicht umsonst gibt ein empfohlenes max. (10) für die dns-lookups. Wer wirklich so viele (warum? weniger ist mehr) sendende Mailserver hat sollte sich mit spf-flattening auseinanersetzen: https://www.autospf.com
Bitte seid direkt vorbildlich, setzt einen spf, kümmert euch um dkim und setzt dann direkt dmarc mit reject. Dann solltet ihr die nächste Zeit Ruhe haben.
Die Include Tiefe zu begrenzen macht Sinn
Denn ein Mail Server muss den Record bis zum Ende abklappern.
Das kostet Zeit. Besonders wenn die Includes von anderen DNS geholt werden müssen. Das belastet auch die DNS.
Bei jeder E-Mail, denn Spammer nutzen nur Server die SPF haben…
Es war mal als Spam Abwehr gedacht, ja, als jeder Zombie Dialup PC noch Emails erfolgreich ohne den Provider versenden könnte und zu der es zum guten Ton gehörte jeden über seinen SMTP Server das relayen zu erlauben.
(damals wählte man sich noch mit einem Modem ein. Wenn aber der direkte MX down war, war es schon nett, wenn man seine E-Mails bei einem offenen Relay abgegeben konnte. Heute unvorstellbar)
Nein, nicht nur IPs. Hier z. B. unserer für Exchange Online und einen eigenen V-Server:
"v=spf1 include:spf.protection.outlook.com a:[unsere Domäne].de -all"
@Fred
Deine Zeilen sagen viel über deine "Expertise" als verantwortungsbewusster IT-Betreuer aus…
Weil das mit dem fehlenden SPF hier nun mehrfach für Überraschung sorgte:
Wenn ihr eine Domain (neu) einrichtet, kippt ihr die Domain nicht in einen der zahlreichen Domain-Tester, weil die Test-Email an die heimische Adresse geht ja?
Ich glaub's nicht.
SPF macht Sinn, aber alles was mit Zertifikaten in Verbindung steht ist grundsätzlich erstmal abzulehnen. Oftmals fehlt dafür die Infrastruktur und das Personal zur Pflege. Letztendlich gewinnen dann nur wieder die Großen, die sowas automatisieren können.
SPF alleine reicht ja aus, bei signiertem DNS spricht dann auch nichts mehr für eine andere Lösung.
Viel sinnvoller wäre es jedoch, wenn lästige Blacklists endlich mal verschwinden. Wer shared-hoster oder freemailer benutzt, landet dadurch ständig im Spam.
Ein Trauerspiel!
signieren mit s/mime bzw. openpgp würde ich jetzt auch nicht. Aber der geringe einmalige Mehraufwand für spf+dkim+dmarc ist zu vernachlässigen da es auch bereits jeder Hoster implementiert hat.
Empfehle aus eigener Erfahrung dieses Tool: https://www.learndmarc.com
Ich habe über 1&1 in meinem DSL Vertrag eine Domain kostenlos dabei über die ich mir verschiedene Mailkonten eingerichtet habe. Leider ist 1&1 hier nicht in der Lage oder willens einen SPF oder DKIM Eintrag zu setzen. Wenn weitere Anbieter dem Beispiel von Google folgen wird die Anzahl möglicher Adressaten immer kleiner…
hier ist das genau so, betrifft aber imho Altverträge