Hoster-Kriterien für zuverlässige Zustellung von Emails

Springer

New Member
Hallo zusammen,

in unserer kleinen Firma "leben" wir sozusagen davon, dass wir mit unseren Kunden über Mail kommunizieren und haben das Problem, dass teilweise wichtige Mails nicht bei den Empfängern ankommen. Es handelt sich dabei nicht um Massen-Mails oder Newsletter, aber es können durchaus mehrere Empfänger gleichzeitig via BCC angeschrieben werden, wenn wir z.B. benötigte Dokumente oder Unterlagen versenden. Laut meinen Recherchen befindet sich unser Email-Server aktuell nicht auf einer Blacklist. Wir hatten bei unserem Email-Hoster bereits früher massive Probleme mit der gemeinsamen Benutzung von E-Mail-Konten auf zwei iPhones sowie ein paar Apple-Computern wegen angeblich zu vieler gleichzeitiger Verbindungen, die bei Mail-Konten verschiedener anderer Anbieter jedoch nicht auftraten und nach langem Hin- und Her dann irgendwann vom Hoster durch eine Anpassung der server-seitigen Limits behoben wurden. Da ich wegen zahlreicher anderer Email-Restriktionen in Betracht ziehe, die Email-Kommunikation einem anderen Hoster zu übertragen, würde mich interessieren, ob bzw. woran man im Vorfeld erkennen kann, ob ein Hoster in Punkto zuverlässige Email-Zustellung brauchbar ist?

Die Mails sollen überwiegend in finnischer Sprache an finnische Empfänger gesendet werden, wobei sich die Server der Empfänger-Domains dann aber wohl nicht zwingend geographisch in Finnland befinden, sondern bei Firmen mit .com-Domains laut IP-Geo-Location-Diensten z.B. in den Niederlanden oder ganz woanders sitzen. Zudem nutzen viele Empfänger auch Konten bei Gmail, Yahoo, etc. Wir arbeiten ausschließlich mit IMAP-Konten in Apple-Mail-Clients (Desktop und Mobil) und nutzen ausgiebig die dort verfügbaren farblichen Markierungs-Möglichkeiten(verschiedenfarbige Flaggen), falls das wegen irgendwelcher IMAP-Standards eine Rolle spielen sollte. Eventuell kann der neue Hoster auch nur für die Email-Kommunikation zuständig sein, da unser Webhosting über einen Managed-Wordpress-Drittanbieter läuft, der nicht für die E-Mails zuständig ist. Diese Situation ist sozusagen historisch gewachsen bzw. einzelnen und zeitlich versetzen Lösungs-Ansätzen geschuldet.

Mir ist klar, dass man die Zustellung nicht zu 100% garantieren kann, aber vielleicht gibt es ja bestimmte Faktoren, auf die man allgemein achten sollte, damit die Zustellung mit der größtmöglichen Wahrscheinlichkeit erfolgt...als mögliches(!) Beispiel sei z.B. die bei meiner Recherche gefundene Certified Sender Alliance genannt, bei der ich mich frage, in wie weit die Mitgliedschaft eines Hosters in Bezug auf die Zustellungs-Rate hilfreich oder sogar notwendig ist?

Mich beschäftigt z.B. auch die Frage, ob man besser auf einen potenten Cloud-Mail-Server eines großen/bekannten Anbieters setzt, anstatt auf einen eher kleinen Mail-Server eines Shared-Webhosting-Anbieters?

Der Server-Standort unseres Mail-Servers scheint aktuell London zu sein. Spielen die Standorte der sendenden und empfangenden Mail-Server eine entscheidende Rolle für die Zustell-Wahrscheinlichkeit?

Ich habe übrigens sehr interessiert einen Nachbar-Thread mit dem Titel "Nach Umzug von 1und1 zu Hetzner landen Mails teilw. im SPAM" gelesen und möchte wegen der dort abgedrifteten Diskussion in Richtung Konfiguration-Fehler und Glaskugel in diesem Thread von einer korrekten und ausreichenden Konfiguration beim Web-Hoster ausgehen bzw. dies als ein zwingend notwendiges Auswahl-Kriterium definieren. Wir benötigen einen gemanagten Email-Dienst und werden insofern auch kaum irgendwelche Konfigurationen beeinflussen können. Falls es aber Zustell-Technisch ungünstig sein sollte, dass sich unterschiedliche Dienstleister um Domain, Webhosting und Email-Kommunikation kümmern, könnten wir das zukünftig natürlich über einen einzelnen Anbieter laufen lassen.

Herzlichen Dank für eure Aufmerksamkeit und viele Grüße...
Springer
 
Warum fragst du nicht bei deinem bisherigen Email-Provider, weshalb die Emails nicht zugestellt werden? Der müsste ja im Logfile sehen, warum die der Empfänger-Server ablehnt.
 
Es ist schwierig als Hoster zu erkennen warum ein anderer Mail Hoster deine Mails in den Spam Ordner packt.
Beim ablehnen das die Mail nicht zugestellt werden kann hingengen schon, dort solltest du als Sender ebenfalls benachrichtigt werden.
Die Frage die eigentlich meiner Meinung nach wichtiger ist, werden E-Mails garnicht an den Benutzer ausgeliefert oder kommen diese im Spam Ordner an?


Ich kann dir z.b. AWS sehr empfehlen, ist leider bei der Konfiguration meistens nicht so einfach, dafür sorgt aber Amazon das die Mail Server nicht auf einer Blacklist landen.
Was aber auch Hetzner tut.

Wie @mr_brain schon geschrieben hat, am besten mal mit deinem aktuellen Hoster sprechen ob ihm dieses Problem schon bekannt ist und dran gearbeitet wird oder nicht.
 
Zuerst teste deine Emails mal gegen https://www.mail-tester.com/ um raus zu finden ob Konfigurationsprobleme beim Hoster oder nicht sogar in deiner Email die Ursache sind.

würde mich interessieren, ob bzw. woran man im Vorfeld erkennen kann, ob ein Hoster in Punkto zuverlässige Email-Zustellung brauchbar ist?
Schwer bis gar nicht. "Schwergewichte" können sich manchmal sehr schwer tun Probleme zu lösen, kleine Anbieter diese teilweise gar nicht mal erkennen. Generell sollte ein kleinerer Anbieter mit dedizierter IP für dein Konto und ohne Email-Limits aber das sein was am besten klappt.

falls das wegen irgendwelcher IMAP-Standards eine Rolle spielen sollte
Aus dem Kopf sind die Flaggenfarben custom-permanentflags von Apple. Dies bedeutet dass der Mailserver eigene Permanentflags zulassen muss welche in IMAP4 Rev1 definiert sind aber nicht zwingend aktiviert sein müssen. Die meisten Server sollten es aber unterstützen.

Beispiel sei z.B. die bei meiner Recherche gefundene Certified Sender Alliance genannt, bei der ich mich frage, in wie weit die Mitgliedschaft eines Hosters in Bezug auf die Zustellungs-Rate hilfreich oder sogar notwendig ist?
Certified Allience ist wie alle Email-made-in-Germany Ideen ein Schuss in den Ofen und mehr als Witz denn als seriöse Idee zu werten. Es gibt durchaus einige "Allianzen" wie bspw DNSWL welche aber nur begrenzt für mittlere oder kleinere ANbieter hilft. Üblicher und sehr effektiv ist mit den Industriegrössenen einen "MRA" (Mail Reporting Agreement) ab zu schliessen wo man dann Feedback zu Problemen erhält und den "Partner" über diesen Weg dann auch zwecks Lösung rückkontaktieren kann.

ob man besser auf einen potenten Cloud-Mail-Server eines großen/bekannten Anbieters setzt
Die Wahrscheinlichkeit an Zustellproblemen ist geringer. Bei Problemen kannst du aber in aller Regel nur *tagelang* abwarten weil du garantiert niemanden mit halbwegs Kompetenz erreichen _kannst_ und alle Gesprächspartner dich nur durch deren Checkliste bugsieren wollen.

Spielen die Standorte der sendenden und empfangenden Mail-Server eine entscheidende Rolle für die Zustell-Wahrscheinlichkeit?
Nein, ausser in wenigen Ausnahmen wo viele Anbieter wegen regelmässigen Problemen und weil es die Hauptquellen für Spam sind auch mal ganze Netzblöcke blacklisten, bspw Nigerien, Russland, ... Deutschland.

Falls es aber Zustell-Technisch ungünstig sein sollte, dass sich unterschiedliche Dienstleister um Domain, Webhosting und Email-Kommunikation kümmern
Wenn der Email-Anbieter korrekt im DNS vermerkt ist (bestenfalls inklusive DKIM, SPF, ...) ist das keineswegs nachteilhaft sondern entspricht der ursprünglichsten Server-Konfiguration.
 
Last edited by a moderator:
Hallo ihr Lieben,

zunächst einmal vielen Dank an euch alle für eure Antworten, die mir sehr weitergeholfen haben.

Ich melde mich spät zurück und bitte dafür um Entschuldigung, aber ich selbst konnte mich aus bestimmten Gründen erst vor kurzem weiter mit der Thematik beschäftigen. Ich habe einige Hoster angeschrieben und alle hatten mehr oder weniger unverhandelbare Einschränkungen, so dass wir uns vor ein paar Tagen entschieden haben, einen Amazon AWS Account zu erstellen und nun via Amazon SES-SMTP unsere Mails senden.

Wir haben die Email-Konfiguration unserer Domain wie von Amazon gewünscht über unseren Hoster vornehmen lassen (DKIM, SPF) und bei Amazon werden sowohl Domain als auch E-Mail-Adressen als OK angezeigt. Das Senden im Allgemeinen funktioniert auch einwandfrei. Ich habe inzwischen auch eine Überprüfung durch Mail-Tester.com durchgeführt und dort wird bemängelt, dass wir keinen DMARC-Datensatz haben. Da werde ich mich jetzt erstmal einlesen, abgesehen davon scheint aber alles OK zu sein.

Leider funktioniert das Versenden im Speziellen jedoch nicht so gut und ich wollte meine Erkentnisse und Annahmen hier mal zur Diskussion stellen:

Gemessen an den paar Mails, die wir bisher gesendet haben, hatten wir bereits mehrere Unzustellbarkeiten, die scheinbar allesamt auf durch Amazon vergebene IP-Adressen zurückzuführen sind, die sich auf Blacklisten befinden. Ein Beispiel...
Diagnostic-Code: smtp; 554 5.7.1 Service unavailable; Client host [54.240.7.18] blocked using bl.suomispam.net; 20190202 lincolnsgazebo.com www.onecasino.com
Status: 5.7.1

Teilweise sind die Einträge scheinbar mehrere Wochen alt und im Amazon AWS Support Forum gibt es wirklich viele andere AWS User, die mit verschiedensten IP-Adressen das gleiche Problem haben und Amazon drängen, doch etwas dagegen zu tun. Amazon wiederum antwortet zuverlässig auf jede Beschwerde, dass sich das Team mit Hochdruck darum kümmert, was aber nur spät und möglicherweise manchmal auch gar nicht passiert. Ich habe mich erst gewundert, warum sich so viele Kunden in einem Forum darüber ausheulen, bis ich wegen unserer Zustell-Probleme den Support von Amazon um Hilfe bitten wollte und feststellen musste, dass das für uns als AWS Kunde so gar nicht möglich ist und ich einen kostenpflichtigen Support buchen müsste. Wenn das halbwegs bezahlbar ist kann ich das gerne tun, aber ich habe große Zweifel, dass dadurch mein Problem gelöst wird, denn eigentlich sollte so etwas laut Amazon ja gar nicht passieren, da sie angeblich stets ihre Services überwachen und dafür Sorge tragen, dass die IP-Adressen auf keiner Spam-Liste landen bzw. kurzfristig davon entfernt werden. Das passt nur so gar nicht zu den Beiträgen im Forum und den Zeitstempeln, die ich selbst auf Spam-Listen sehen konnte.

Meine Idee, uns eine kostenpflichtige dedizierte IP bei AWS zu buchen, um dieser Problematik zu entgehen, habe ich bislang noch nicht umgesetzt, weil mich die folgende Aussage von Amazon in der Dokumentation verunsichert hat:
https://docs.aws.amazon.com/de_de/ses/latest/DeveloperGuide/dedicated-ips.html
Wichtig
Wenn Sie nicht vorhaben, regelmäßig und geplant große Mengen an E-Mails zu versenden, empfehlen wir Ihnen, gemeinsam genutzte IP-Adressen zu verwenden. Wenn Sie dedizierte IP-Adressen in Situationen verwenden, in denen Sie nur geringe Mengen an E-Mails versenden, oder wenn Ihre Versandmuster sehr unregelmäßig sind, bekommen Sie Probleme mit der Zustellbarkeit.
Aktuell bin ich echt ratlos, weil wir uns so wie von Amazon empfohlen verhalten und dennoch Pobleme mit der Zustellbarkeit haben. Wir hatten uns von dem Wechsel zu Amazon AWS viel versprochen, haben jetzt aber gefühlt mehr unlösbare Probleme als vorher. Ich habe die Befürchtung, dass Amazon mehr für Sender von echten Massen-Mails im Millionen-Bereich gedacht ist, wo es auf ein paar Prozent unzustellbare Mails nicht so sehr ankommt. Eventuell kann ja jemand etwas zu den auf Black-Listen befindlichen IPs oder den dedizierten IPs mit sehr geringem Sende-Aufkommen sagen.

Viele Grüße
Springer
 
Gemessen an den paar Mails, die wir bisher gesendet haben, hatten wir bereits mehrere Unzustellbarkeiten, die scheinbar allesamt auf durch Amazon vergebene IP-Adressen zurückzuführen sind, die sich auf Blacklisten befinden.

Da ich auf meinem Server auch hin und wieder Spam beobachte, die über Amazon Server kommt, halte ich das für wenig verwunderlich.

Teilweise sind die Einträge scheinbar mehrere Wochen alt und im Amazon AWS Support Forum gibt es wirklich viele andere AWS User, die mit verschiedensten IP-Adressen das gleiche Problem haben und Amazon drängen, doch etwas dagegen zu tun.

Naja, die Blacklist-Anbieter sitzen am längeren Hebel und haben ihre Regeln, um IPs wieder zu entfernen - und die gelten i.d.R. für alle (manchmal kann man sich freikaufen). Oft sind es bestimmte Fristen, bevor eine IP wieder freigegeben wird - wird sie innerhalb dieser Frist erneut auffällig, fängt die Zeit wieder bei Null an - da können dann auch mal Monate zusammenkommen.

Meine Idee, uns eine kostenpflichtige dedizierte IP bei AWS zu buchen, um dieser Problematik zu entgehen, habe ich bislang noch nicht umgesetzt, weil mich die folgende Aussage von Amazon in der Dokumentation verunsichert hat:

Da die meisten großen Hoster und Mail-Dienste bez. Spamabwehr ihr eigenes "Voodoo" einsetzen, kann man keine pauschale Aussage treffen, was hilft. Letztendlich trifft das Problem mit der Zustellbarkeit aber auch auf die gemeinsam genutzen IPs bei Amazon zu, denn auch dort lassen sich unregelmäßige Muster ausmachen, wenn man sowas prüft. Bei einer dedizierten IP hast du natürlich den Vorteil, dass du relativ alleine dafür verantwortlich bist, diese sauber zu halten (wobei es auch Blacklisten gibt, die direkt ganze IP-Bereiche quasi in Sippenhaft nehmen...)
 
Einige Antispam-Anbieter (bspw Cisco's Thalos) verwenden sogenannte Trust levels. Man ist vereinfacht gesagt "known good", "unknown" oder "known bad". Bei "unknown" wird oft (fälschlicherweise) den Nachrichten eine negative Reputation angehangen so dass sie viel schneller blacklisted werden können.

Nicht beschränkt auf Amazon kann man eigentlich davon ausgehen dass jede neue IP anfangs auf so ziemlich allen Blacklists ists die man sich nur denken kann, die meisten davon nicht öffentlich einsehbar. Nach einem Holperstart hat man dann aber damit eigentlich keine Probleme.

Anmerkung: wenn AWS euch direkt so enttäuscht hat würde ich empfehlen andere Anbieter zu versuchen. Dazu gehören
- Hornetsecurity (ehem. Antispameurope)
- Sendgrid
- einen kleineren Webhoster der dedizierte IPs (auch für Emailversand!) anbietet


Als Referenz, hier die üblichen Blacklists wo man landen kann:
=> Public list checker
http://dnsbl.info/

=> Private lists
* Cisco
https://talosintelligence.com/reputation_center/lookup?search=XXXX
* Symantec
https://ipremoval.sms.symantec.com/
* McAfee
http://mcafee.com/threat-intelligence/ip/default.aspx?ip=XXX
* WatchGuard
http://www.reputationauthority.org/
* ReturnPath
https://senderscore.org/
* Proofpoint
https://support.proofpoint.com/dnsbl-lookup.cgi?ip=XXXX
https://ipcheck.proofpoint.com/?ip=XXXX
* Barracudabar
http://barracudacentral.org/lookups
* Microsoft SNDS
https://postmaster.live.com/snds/data.aspx
*Trend Micro
https://www.ers.trendmicro.com/reputations/index?ip_address=XXXX
http://www.mail-abuse.com/cgi-bin/lookup?ip_address=XXXX
 
Hallo zusammen,

Die Frage die eigentlich meiner Meinung nach wichtiger ist, werden E-Mails garnicht an den Benutzer ausgeliefert oder kommen diese im Spam Ordner an?

Teilweise bekamen wir Bounces, manchmal landeten wir auch im Spam-Ordner und - was das Fass dann zum Überlaufen brachte - teilweise hatten wir den Verdacht, dass die Mails irgendwo versacken, also weder gebouncet werden noch beim Empfänger ankommen. Wir haben es immer wieder mal von Kunden berichtet bekommen, dass unsere Mails nirgendwo zu finden seien. Sicher waren wir uns aber erst, als genau das mit der Empfänger-Adresse eines Bekannten passiert ist, wo man sowohl persönliche Motive als auch technische Unzulänglichkeiten ausschließen konnte. Da der Bekannte jedoch in einem größeren Unternehmen arbeitet, konnten wir da auch nicht einfach die IT für uns tätig werden lassen, um die Ursachen zu ergründen. Aber diese Vorkommnisse zusammen mit den Restriktionen (z.B. ein niedriges Sendelimit pro Stunde!) haben uns dann dazu bewogen, uns nach Alternativen umzusehen.

Mehrere Empfänger per BCC kontaktieren? Das ist definitiv ein ordentliches Kriterium für den Spamfilter.

Wie löst man denn dieses Problem im Alltag, wenn man mit Kunden per E-Mail kommuniziert und denen z.B. Informationen zukommen lassen möchte? Es geht hier nicht um tausende Empfänger mit identischen Anschreiben, sondern eher um 10 verschiedene individuelle Mails mit je 20 Empfängern.

Anmerkung: wenn AWS euch direkt so enttäuscht hat würde ich empfehlen andere Anbieter zu versuchen.

Wenn ich wüsste, dass die dedizierte IP bei Amazon unsere Probleme dauerhaft löst, sofern wir selbst keinen Mist bauen, hätte ich kein Problem damit, dort zu bleiben. Ich frage mich eben nur, warum die so vehement davon abraten, als Wenig-Versender eine dedizierte IP einzusetzen? So selbstlos sind Unternehmen beim Verkaufen von Dienstleistungen im Allgemeinen dann nicht und Amazon im Speziellen schon mal gar nicht. Das mit dem bezahlten Support, um denen Probleme mit deren Services melden zu dürfen, ist ja auch ein schlechter Scherz. Ich befürchte daher, dass an der Warnung etwas dran sein könnte und wir dann mit der statischen IP noch größere Probleme bekommen. Und wenn ich von Amazon AWS schnelle Hilfe benötige, werde ich vermutlich erleben, wie träge ein Tanker dieser Größe sein kann

Die Suche ist allerdings wirklich nicht einfach. Ich habe bereits einige Anbieter angeschrieben, sowohl kleine als auch große wie z.B. Strato. Bei Strato passte es z.B. wegen der maximal gleichzeitigen IMAP-Verbinungen nicht. Bei den kleineren Hostern sind es meist Beschränkungen wie "nur 200 Mails pro Stunde", die einem den Tag versauen können. Ein Sendelimit von 2000 pro Tag würden wir hingegen so gut wie nie ausreizen. Das sind Sachen, die nirgenwo offen kommuniziert werden, sondern die man jedem Unternehmen per Support-Anfrage aus der Nase ziehen muss. Oft musste ich auch ein zweites mal nachfragen, weil die Antwort uklar war.

Aber trotzdem (oder gerade deswegen) vielen dank für die Empfehlungen, ich werde mich damit befassen.
Und vielen Dank auch nochmal für die vielen Details zum E-Mail-Versand. Das ist ja schon irgendwie krank, worauf man alles achten muss und wie wenig Einfluss man selbst auf die Zustellung hat.

Veile Grüße
Springer
 
Wie wäre es denn mit einem selbst betriebenen Mailserver auf einem Rootserver (der logischerweise eine eigene IP hat), bei dem Ihr die Parameter selbst einstellen und v.a. die Logs auslesen könnt. Dann könnt Ihr auch bei einzelnen Kunden nachforschen, wo das Problem ist. Bevor man den Mailserver einrichtet, sollte man logischerweise sicher gehen, dass sie nicht auf Banlisten steht.
 
Ein selbst betriebener Mail-Server wäre natürlich toll, aber so etwas habe ich bislang nur zu Hause in einer virtuellen Maschine eingerichtet. Da ich aber einen Webserver selbst mal eine Zeit lang auf einem Root-Server Co-Administriert habe, rechne ich mit gewissen Herausforderungen (z.B. nachts arbeiten um Updates durchzuführen, was sich mit meinen regulären Arbeitszeiten dann nicht ganz so gut verträgt) und auch mit einem gewissen Aufwand, um die Dienste sowie die BackUp-Szenarien regelmäßig zu prüfen und stabil am laufen zu halten. Ich nahm an, dass diese Vorgehensweise für einen einzelnen Server mit geringer Senderate für eine kleine Firma unwirtschaftlich ist.

Bietet jemand "Managed Virtual Mail Server" an, wo also jemand im Hintergrund den Betrieb nicht nur für uns aufrecht erhält, nachts Updates einspielt, zuverlässige BackUp-Konzepte anbietet, etc. und wir die Konfiguration (IMAP-Connections, Sende-Limits, etc.) im Rahmen der gebuchten Ressourcen nach unseren Bedürfnissen anpassen können und Zugriff auf die Logfiles haben? Ich finde auf die Schnelle überwiegend nur dedizierte managed Mail-Server und das scheint mir bei unseren Anforderungen dann doch wie mit Kanonen auf Spatzen zu schießen (die meiste Zeit haben wir bisher weit unter 1000 Mails pro Tag gesendet).

Ich hatte so etwas im letzten Jahr bei Host-Europe gesehen, wobei mir das schon extrem günstig vorkam und ich da inzwischen auch von den vielen negativen Bewertungen abgeschreckt worden bin. Meine positiven Erfahrungen mit Host-Europe im Webhosting-Bereich liegen schon eine Weile zurück und anscheinend ist da nach dem Verkauf einiges passiert.
 
Bietet jemand "Managed Virtual Mail Server" an, wo also jemand im Hintergrund den Betrieb nicht nur für uns aufrecht erhält, nachts Updates einspielt, zuverlässige BackUp-Konzepte anbietet, etc. und wir die Konfiguration (IMAP-Connections, Sende-Limits, etc.) im Rahmen der gebuchten Ressourcen nach unseren Bedürfnissen anpassen können und Zugriff auf die Logfiles haben?
Du kannst hier im Forum im Bereich "Suche" dein Interesse kundtun, dort können gewerbliche Anbieter direkt reagieren.
Alternativ kannst du auch mal bei den Anbietern nachfragen, die ich in meiner Signatur verlinkt habe. Die bieten auf jeden Fall managed Services an und ich kann die ruhigen Gewissens empfehlen.
 
OK, vielen Dank. Vielleicht kann mir ja noch jemand eine letzte Frage zu SPF beantworten....laut der Dokumentation von Amazon SES kann die SPF-Prüfung auf zwei Arten bestanden werden:

Bestehen einer SPF-Prüfung – Wenn Sie Amazon SES verwenden, gibt es zwei Einrichtungen zum Bestehen einer SPF-Prüfung. Die erste ist die Verwendung der Standard-MAIL FROM-Domäne von Amazon SES, wobei überhaupt kein SPF-Datensatz veröffentlicht wird. Diese Einstellung ermöglicht Ihnen das Bestehen einer SPF-Prüfung, da Amazon SES standardmäßig seine eigene MAIL FROM-Domäne verwendet, um Ihre E-Mails zu senden. In diesem Fall wird eine SPF-Prüfung bestanden, da die Standard-MAIL FROM-Domäne amazonses.com (oder eine Subdomäne) und der sendende Mail-Server Amazon SES ist.

Die andere Einrichtung, mit der eine SPF-Prüfung bestanden werden kann, ist, Amazon SES für die Verwendung Ihrer eigenen FROM FROM-Domäne zu konfigurieren. In diesem Fall müssen Sie einen SPF-Datensatz veröffentlichen, da die MAIL FROM-Domäne und die Domäne des sendenden Mail-Server, Amazon SES, unterschiedlich sind. Anweisungen für die Konfiguration Ihrer Domäne zum Senden von E-Mails über eine benutzerdefinierte MAIL FROM-Domäne finden Sie unter Verwenden einer benutzerdefinierten MAIL FROM-Domäne .

Hat die erste Art der Prüfung mit Amazon SES als voreingestellter MAIL FROM Domäne irgendwelche Nachteile, oder ist es hinsichtlich der Zustellbarkeit völlig egal, weil in beiden Fällen die SPF-Prüfung bestanden wird und daher der aufsummierte Spam-Score-Wert in dieser Hinsicht identisch ist?
 
Ein SPF-Record trifft eine Aussagen, welche IPs Mails für eine bestimmte Domain senden dürfen und welche nicht. Es ist entsprechend kein Mechnismus zur Spam-Vermeidung, wird aber trotzdem von vielen Spamfiltern ausgewertet (wobei auch einige Spammer mittlerweile mit gültigen SPF-Records arbeiten). Eigentlich ist SPF nur ein Regelwerk, um legitime und nicht legitime IPs bekanntzugeben.
Der SPF-Record von GMX für die gmx.de Domain z.B. sieht aktuell so aus:
Code:
v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all
Der gestattet den Versand von mehreren IPv4-Bereichen und alles, was da nicht von erfasst wird, soll vom Empfänger abgelehnt werden.
Grundsätzlich würde ich die Verwendung eine SPF-Records empfehlen. Wenn du eine dediziert IP von Amazon bekommst, nimmst du die mit auf, ansonsten müsste Amazon auch einen SPF-Record für sienen SES-Server haben, die du includen kannst.
 
Hallo danton,

vielen Dank für Deine Antwort. Mir ist jedoch noch nicht ganz klar, ob ich dich richtig verstehe - entschuldige bitte meine lange Leitung.

Du empfiehlst grundsätzlich die Verwendung eines SPF-Records - den scheinen wir jedoch bereits zu verwenden. Wenn ich mir selbst eine Test-Mail sende, kann ich im Header aktuell folgendes sehen:
Received-Spf: ⁨Pass (sender SPF authorized) identity=mailfrom; client-ip=54.240.7.18; helo=a7-18.smtp-out.eu-west-1.amazonses.com; envelope-from=...
Wir haben in den DNS-Einstellungen für unsere Domain jedoch weder die IP 54.240.7.18 noch die Domain amazonses.com includet!
Darf ich dich so verstehen, dass es - aus welchen Gründen auch immer - vorteilhaft ist, den SPF Record in den eigenen DNS-Einstellungen zu includen?

Und dann umfasst das Thema SPF zumindest laut Amazon auch noch die Möglichkeit der Hinterlegung einer eigenen MAIL FROM Domain. Wenn ich lediglich den SPF Record hinterlege, gibt es ja theoretisch immer noch zwei Konfigurations-Möglichkeiten:
1. amazonses.com bzw. dedizierte IP bei uns eintragen lassen - sonst nichts!
2. amazonses.com bzw. dedizierte IP bei uns eintragen lassen, aber zusätzlich noch unsere Domain bei Amazon als MAIL FROM Domain hinterlegen.

An der Stelle könnte ich mir mit ganz viel Phantasie vorstellen, dass bei einem empfangenden Mail-Server bei amazonses.com als MAIL FROM Domain trotz dedizierter IP möglicherweise die Alarmglocken schrillen - wenn wir unsere eigene MAIL FROM Domain eintragen jedoch nicht?

Meine Verständnis-Schwierigkeiten beziehen sich zwar auf Amazon SES, aber ich vermute mal, dass ich bei anderen Anbietern bzw. bei einem eigenen Mail-Server identische Konfigurations-Möglichkeiten habe.
 
Wir haben in den DNS-Einstellungen für unsere Domain jedoch weder die IP 54.240.7.18 noch die Domain amazonses.com includet!

Das kommt auch auf den hinterlegten Qualifikator an. Das kann sein...
  • -all: abweisen
  • ~all: "grosszügig" behandeln
  • ?all: trifft keine Aussage über positiv oder negativ
Falls Du also ein ~all oder?all hinterlegt hast, kann es gut sein, dass die Mal trotzdem durchgelassen wird.

Für mehr Details:
https://de.wikipedia.org/wiki/Sender_Policy_Framework

Das Vorgehen einen Record eines Dienstleisters einzubinden ist die gängige Methode um diesem bei Verwendung von SPF zu erlauben für die eigene Domain versenden zu dürfen. Infrastrukturen sind ja auch immer dynamisch und umfangreich. D. h. wenn Du da einzelne IP-Adressen eintragen würdest, dann müsstest Du ständig prüfen, ob sich da den IP-Adreßbereichen irgend etwas geändert hat und würdest vermutlich regelmässig in SPF-Probleme rennen.

Und ja. Man muß den eigenen DNS-Record ändern. Also den Record, für die Domain um die es geht. Denn der wird beim Empfang von jedem Mailserver, der das prüft, ausgelesen.
 
Ich kenne jetzt AmazonSES zu wenig, um zu sagen wie die arbeiten. Die Headerzeile sieht mir danach aus, dass wenn der Envelope-From aus der AmazonSES-Domain stammt und dann über die SPF-Records von Amazon abgedeckt ist.
Sinnvoller ist es IMHO, wenn der Envelope-From auch von eurer Domain stammt und dann werden nur die SPF-Records eurer Domain abgefragt. Und da kommt es dann drauf an, ob ihr eine dedizierte IP habt (dann reicht es, diese in euren SPF mit aufzunehmen) oder den Pool von AmazonSES verwendet (dann ist ein Include sinnvoll, da ihr nicht mitbekommt, wenn sich bei den IPs was ändert und Amazon seinen SPF ja anpasst - was da für ein Include verwendet wird, sollte Amazon ja irgendwo beschrieben haben).
Wenn ihr neben AmazonSES noch einen eigenen Mailserver für ausgehende Mails verwendet (z.B. als AmazonSES nur für Newsletter verwendet werden soll), dann muss dessen IP natürlich auch mit aufgenommen werden - das gleiche kann für Webserver gelten, wenn dort Scripte Mails verwenden, z.B. bei einer User-Registrierung.
 
Hallo,

vielen Dank für eure sehr guten Erklärungen. Damit kann ich die DNS Änderungen vornehmen.

Viele Grüße
Springer
 
Unabhängig von allen technischen Optimierungen auf der Versendeseite (DMARC,DKIM, feste IP und nur für E-Mails genutzt, die legitim sind etc..), kommt es zu Zustellungsblocks auf Serverebene und SPAM-Einstufung im Postfach.

Was in den letzten Jahren auffällt, ist die Reduzierung von Mailservern auf Firmenseite. Immer mehr sind bei Google oder Microsoft (Office365 hat hier durchschlagende Wirkung). Und mit dem Erfolg der Plattformen, kommen auch mehr Missbrauch. Das Feintuning der Filter war früher bei Eigenbetrieb eher der Fall, jetzt wird z.B. mit Office365 das bei Microsofts Default-Verhalten gelassen.

AmazonSES ist mir eher als Preisbrecher bekannt. Selbst mit dedizierter IP, wird es Probleme geben.
Weil einige IP-Blocks sich nach einiger Zeit über IP-Bereiche gezogen werden. Wenn man Pech hat, hat man eine IP in einer Range, wo ein SPAMMER spontan einige IPs für SPAM nutzt und schon ist die eigene IP in der Range drin und wird mitgeblockt.

Zustellung der E-Mails (Problem: Block auf IP-Ebene, Block auf Inhalt)
Zuordnung der E-Mail (Landet im SPAM-Ordner)

Für die Sicherstellung von E-Mails im B2C-Bereich gibt es noch die Möglichkeit, Mailserver mit CSA-Whitelist anzumieten. Mit entsprechenden Auflagen, was regelmäßig zu Rügen führt. https://certified-senders.org/de/teilnehmer/

Apropos nicht erhaltene E-Mail: Bei Googlemail-Nutzern ist das "clevere" Interface oftmals auch in der Lage, die E-Mail zuverlässig vor dem Nutzer zu verstecken ;-)
 
Back
Top