Nachdem ich einen E-Mail-Verteiler angeschrieben habe, erhielt ich von einem der Teilnehmer (empfaenger@googlemail.com) eine so genannte Bounce-E-Mail:
<empfaenger@googlemail.com> (expanded from <diesen.verteiler@hab-ich-angeschrieben.de>): host gmail-smtp-in.l.google.com[2a00:1450:4025:c01::1a] said: This message does not pass authentication checks (SPF and DKIM both do not pass). SPF check for [altmetaller.de] does not pass with ip [n.n.n.n]. To best protect our users from spam, the message has been blocked. Please visit https://support.google.com/mail/answer/81126#authentication for more information.n reply to end of DATA command)n.n.n.n entspricht der IPv4-Adresse von dem virtuellen Server, auf dem der E-Mail-Verteiler betrieben wird.
Diese E-Mail stammt von dem Server, auf dem der von uns angeschriebene Verteiler betrieben wird und informiert uns über eine Nichtzustellung. Die Annahme wurde verweigert, da Google unsere Nachricht als SPAM erachtet.
Ursächlich hierfür sind weder die Gestaltung, noch der Inhalt unserer Nachricht. Letztendlich handelt es um eine Meinungsverschiedenheit zwischen drei Servern:
- Unserem (absendenden) E-Mail-Server
- Dem E-Mail-Server, auf dem der Verteiler betrieben wird
- Dem (empfangenden) E-Mail-Server (Google Mail)
Und was passiert hier genau? Warum wird die E-Mail als SPAM bewertet?
Der Ablauf beim Versand der E-Mail sieht in dem Fall, wie folgt aus:
- Unser E-Mail-Programm übergibt die E-Mail an den dort hinterlegen E-Mail-Server
- Dieser leitet die E-Mail an den Server für den Verteiler weiter
- Der Server mit dem Verteiler nimmt die Nachricht an, interpretiert den Inhalt und generiert eigene E-Mails: Nämlich eine E-Mail für jeden Empfänger, der auf der Verteilerliste steht
- Der Server mit dem Verteiler verschickt die jeweiligen E-Mails. Als Absenderadresse benutzt er dabei natürlich nicht den Verteiler, sondern die Adresse von der Person, die den Verteiler angeschrieben hat
- Der von Google bekommt die E-Mail und stellt in unserem Beispiel folgendes fest:
„Ich habe eine E-Mail vom E-Mail-Server für die Domain @hab-ich-angeschrieben.de bekommen. Aber Moment – der E-Mail-Absender lautet doch auf @altmetaller.de – für diese Domain ist der doch gar nicht zuständig…“
Und jetzt? Erst einmal die Strategie…
Eigentlich ist es ganz einfach. Man delegiert das Problem an den Betreiber des eigenen E-Mail-Servers und bittet diesen um Abhilfe.
Dumm nur, wenn man selber der Betreiber ist 🙂
Ich persönlich habe mich deshalb entschieden, den Server, auf dem der Verteiler läuft, für meine Domain altmetaller.de freizuschalten.
Eine weitere Freischaltung erfolgt für die E-Mail-Server meines Webhosters (also dem Anbieter, bei dem ich die Domain altmetaller.de reserviert habe).
Eine dritte Freischaltung erfolgt für mailbox.org – einem externen E-Mail-Anbieter, über den ich meine E-Mails letztendlich handhabe.
Zusammengefasst: Ich hinterlege in den DNS-Daten meiner Domain Informationen, wer meiner Ansicht nach alles E-Mails mit der Domain altmetaller.de verschicken darf.
Diese Angaben kann man in dem in der Bounce-E-Mail erwähnten SPF (=Sender policy framework) hinterlegen.
Vorbereitung
Zuallererst sollten wir Informationen zu den Servern zusammentragen, welche die E-Mails verschicken dürfen. SPF kann z.B. mit folgenden Mechanismen umgehen:
all – trifft auf alle Server weltweit zu (also im Grunde genommen eine Abschaltung von SPF)
a – ein A- oder ein AAAA-Record im DNS (also ein Hostname, der zu einer IPv4- oder IPv6-Adresse auflöst)
mx – ein MX-Record (also ein Verweis auf den E-Mail-Server, der für eine Domain zuständig ist)
ip4 – eine IPv4-Adresse
ip6 – eine IPv6-Adresse
include – Angabe einer externen Quelle, die Hinweise auf weitere Serverangaben enthält
Grundsätzlich sollen folgende Server E-Mails über meine Domain verschicken können:
- Die Server meines Domainhosters (EWE)
- Die Server meines E-Mail-Anbieters (mailbox.org)
- Die Server, auf denen der Verteiler läuft
Die Reihenfolge, wie man die Daten ermittelt, ist diese:
- Den Anbieter fragen
- Die Daten selber ermitteln
- In die Headerdaten bereits verschickter Daten schauen
Das tue ich und erhalte folgende Ergebnisse:
Bei der EWE findet man via Google und Co. keine Informationen. Was auch nicht weiter wundert – das Ziel sind eher Privatkunden und „die Domaingeschichten laufen so nebenbei mit“. Unter https://www.spf-record.de/ gibt es ein Tool, mit denen man die Records bestehender Domains abfragen kann. Ich frage deren Hauptdomain (ewe.net) ab und bekomme den Record angezeigt:
v=spf1 ip4:212.6.122.0/24 ~all
Die EWE schaltet das gesamte Subnet 212.6.122.0 frei. Offenbar residieren hier deren E-Mail-Server und es bietet sich an, genau diese Freischaltung auch für unsere Domain zu übernehmen.
Der Anbieter mailbox.org macht es uns deutlich leichter. Man hat sich auf den Betrieb von E-Mail-Dienstleistungen spezialisiert und weiß, was die Kunden wissen möchten 🙂
Unter https://kb.mailbox.org/de/privat/e-mail-mit-eigener-domain/spf-dkim-und-dmarc-spam-reputation-verbessern-und-bounces-vermeiden findet sich der entscheidende Hinweis. Der passende Record lautet:
v=spf1 include:mailbox.org ~all
Man pflegt also eigene SPF-Records und bietet an, diese per include zu übernehmen. Anzumerken ist, dass die Übernahme eines include letztendlich dazu führt, dass Informationen in Bezug auf die SPAM-Reputation an Dritte übertragen werden. Auf der anderen Seite: Wer seinem E-Mail-Anbieter nicht traut sollte vielleicht mal überlegen, ob er dort wirklich „gut aufgehoben“ ist.
Achja: So einen „include“ könnte man auch bei der EWE fahren. Allerdings findet sich in deren Dokumentation keine Aufforderung, das zu tun. Es würde funktionieren, allerdings besteht in dem Fall immer das Risiko, dass die EWE die SPF-Records außer Betrieb setzt. Wenn das passiert und unser include „ins Leere zeigt“, würde das in einen permanenten Fehler münden.
Bezüglich des Verteilers, bei dem das Problem auftritt, schauen wir in die Headerdaten einer über diesen Verteiler verschickten E-Mail. Oder halt in die oben erwähnte Fehlermeldung.
In den Headerdaten sieht die älteste Received-Zeile so aus:
Received: from server (server.betreiber.net [n.n.n.n]) (Authenticated sender:
irgendjemand@hab-ich-angeschrieben.de) by nocheinserver.betreiber.net (Postfix) with ESMTPA
id 3E6031CE0A2A for verteiler@hab-ich-angeschrieben.de; Mon, 5 Feb 2024
12:44:35 +0100 (CET)
Das deckt sich mit den Daten aus der o.g. Fehlermeldung. Zur Erinnerung:
SPF check for [altmetaller.de] does not pass with ip [n.n.n.n].
Kurzum: Die IP-Adresse, die wir freischalten möchten, lautet n.n.n.n
Die Liste all derer, die wir freischalten möchten, sieht also so aus:
- Der Adressbereich meines Anbieters EWE: 212.6.122.0/24
- Die von meinem E-Mail-Anbieter gepflegte Liste für mailbox.org
- Die IP-Adresse n.n.n.n
Der SFP-Record
Die gewünschten Informationen fassen wir in einem SPF-Record zusammen.
v=spf1 a mx ip4:n.n.n.n ip4:212.6.122.0/24 include:mailbox.org ~all
Zur Erläuterung der Parameter:
v=spf1 leitet den SPF-Record ein.
a bedeutet, dass nicht nur die Server in dieser Liste autorisiert werden. Zusätzlich werden auch IP-Adressen autorisiert, für die DNS-Einträge (ipv4 und ipv6) bestehen. D.h., wenn ich in der Domaine z.B. den Hostnamen www.altmetaller.de auf eine IP-Adresse verweise, ist diese IP-Adresse ebenfalls zum Versand berechtigt. Falls nicht gewünscht: Bitte weglassen 🙂
mx bedeutet, dass weiterhin IP-Adressen autorisiert sind, die als MX (Mail Exchanger) im DNS eingetragen sind.
ip4:n.n.n.n ist die oben ermittelte IP-Adresse von dem Server, auf dem der E-Mail-Verteiler läuft.
ip4:212.6.122.0/24 ist das oben ermittelte Netz mit den Servern meines Domainanbieters EWE.
~all regelt letztendlich den Umgang. Die Tilde ~ steht für eine „großzügige Behandlung“ und bedeutet in etwa: „Lehne die die E-Mail nicht grundsätzlich ab, sondern führe weitere Tests durch, ob es sich um eine SPAM-E-Mail handelt“.
Wer etwas sicherheitsaffiner ist, kann den Record natürlich auch etwas restriktiver setzen.
v=spf1 ip4:n.n.n.n ip4:212.6.122.0/24 include:mailbox.org -all
In diesem Fall habe ich auf den a und den mx Eintrag verzichtet. Als Mechanismus gebe ich –all (also mit einem Minuszeichen) an. Das Minuszeichen steht für eine strenge Handhabung: „Lehne E-Mails von nicht autorisierten IP-Adressen grundsätzlich ab“.
Und was machen wir mit dem Eintrag?
Das hängt letztendlich von unserem Webhoster ab. Der Record wird als TXT-Eintrag im DNS unserer Domain hinterlegt.
Die meisten Anbieter bieten hierfür ein Webportal, über das die entsprechenden Einträge vorgenommen werden können. Bei meinem Anbieter EWE sieht das exemplarisch so aus:
Viel Erfolg – lasst mir gerne einen Kommentar da, ob es geklappt hat!