E-Mail Probleme beheben

Siehe auch

All-inkl - Newsletter Anbieter einrichten
TYPO3 - E-Mail
https://it-stack.de/30/05/2018/anti-spam-basics-fuer-versender-spf-dkim-dmarc-mehr/

Testtools

https://mxtoolbox.com/SuperTool.aspx

Spam Codes

https://www.futurequest.net/docs/SA/ (Spam Assasin Liste mit Scorewerten)

Codes die den Spam Level verändern können

FREEMAIL_FORGED_REPLYTO -> Freemail in Reply-To, aber nicht in From
HEADER_FROM_DIFFERENT_DOMAINS
HTML_MESSAGE
RCVD_IN_DNSWL_NONE
RDNS_NONE - hoher Score: Delivered to internal network by a host with no rDNS
SPF_HELO_NONE - kein spf eintrag nicht so schlimm

Diverses

Make sure you have SPF, DMARC, DKIM, and sign up for their JMRP and SDNS they will tell you.

SPF

https://all-inkl.com/wichtig/anleitungen/kas/tools/dns-werkzeuge/spf_482.html
SPF (Sender Policy Framework)

SPF, Sender Policy Framework, ist ein Standard zur Überprüfung des Absenders einer E-Mail und vermutlich der wichtigste Anti-Spam-Indikator. SPF ist ein TXT-Eintrag im DNS der Absender-Domain und leicht zu setzen.

Etwas mehr Wissen erfordert unter Umständen das Generieren des TXT Eintrags. Hier muss beachtet werden, welche Mailserver und Maildienste für das Versenden der Mails benutzt werden. Wenn ich den Mailserver meines Webhosters nutze, jedoch Mails über die Googlemail Weboberfläche schicke (E-Mail über SMTP eingebunden), muss ich das im SPF-Eintrag beachten. Hierzu gibt es von fast allen Anbietern entsprechende Infos/Hilfeseiten, etwas googeln hilft hier schnell.

Ein beispielhafter SPF-Eintrag, der Google als Relay inkludiert, könnte so aussehen:

v=spf1 a mx include:_spf.google.com ~all

• Kein ptr im SPF eintragen, wenn MX gesetzt ist, auch wenn das viele Generatoren immernoch machen.
• Überprüfung mit SPF Check der MXToolBox. Weitere Infos findet ihr bestimmt in der Hilfe eures Maildienstleisters/Hosters mit der Suche nach „SPF“.

Syntax

Erklärungen zur Syntax von SPF:

Am Anfang des SPF Records wird mit v= die SPF-Version festgelegt. Bislang gibt es nur spf1. Danach werden üblicherweise Direktiven angegeben. Diese bestehen aus einem optionalen Qualifikator und einem Mechanismus.

Qualifikatoren:

+ Pass - autorisierte Sender, daher Annahme der E-Mail; Standard, wenn kein Qualifikator explizit angegeben wird
- Fail - nicht autorisierte Sender, daher Abweisung der E-Mail
~ SoftFail - nicht autorisierte Sender, E-Mail wird trotzdem angenommen, kann jedoch z.b. als Spam markiert werden
? Neutral - Sender, über deren Gültigkeit nichts gesagt werden kann und die akzeptiert werden müssen, daher Annahme der E-Mail

gängige Mechanismen (=Befehle):

a               A-/AAAA-Record der abgefragten oder explizit angegebenen Domain
mx              MX-Record der abgefragten oder explizit angegebenen Domain
ptr             PTR-Record der abgefragten oder explizit angegebenen Domain
ip4             IPv4-Adresse oder IPv4-Subnetz
ip6             IPv6-Adresse oder IPv6-Subnetz
include         SPF-Abfrage der angegebenen Domain, diese sollte einen gültigen SPF-Record besitzen
all             immer

Sofern für einen Mechanismus ein Argument übergeben werden soll, dann trennen Sie dies mit einem Doppelpunkt.

Beispiele

Beispiel für einen sehr gängigen Eintrag

v=spf1 mx a -all

Dieser bedeutet, dass für alle E-Mails, die von Sendern kommen, die sich nicht aus dem A- bzw. MX-Record des DNS ergeben, ein negatives Ergebnis zurückgegeben wird.

v=spf1 a:mail.example.org -all

Mails erlaubt, wenn sie aus den DNS Einträgen der Hauptdomain hervorgehen (-all) oder wenn es vom Server mit dem A-Record zu mail.example.org gehört.

v=spf1 ip4:85.13.164.115 include:spf.protection.outlook.com -all

Mehrere Server im SPF Eintrag

Möchten Sie die IP eines E-Mail-Server in einen SPF-Eintrag aufnehmen, geben Sie vor dem Argument ~all die IP-Adresse des Servers ein. Verwenden Sie das Format ip4:Adresse oder ip6:Adresse, wie in diesem Beispiel:

v=spf1 ip4:172.16.254.1 include:_spf.google.com ~all

Soll die Domain eines E-Mail-Servers hinzugefügt werden, verwenden Sie für jede Domain eine "include"-Anweisung. Beispiel:

v=spf1 include:serverdomain.com include:_spf.google.com ~all

SPF-Beispiele

https://stackoverflow.com/questions/14261214/too-many-dns-lookups-in-an-spf-record?rq=1

Amazon SES

Here are the TXT records we currently use successfully for Amazon SES as per Authenticating Your Email Address and (it's indeed unfortunate that their documentation doesn't address the quoting needs):

"v=spf1 include:amazonses.com ~all"
"spf2.0/pra include:amazonses.com ~all"

DKIM

DKIM Signiert die Mails, so kann der Empfänger kontrollieren, ob der Inhalt unverändert ankommt. Also erstmal kein Spam Tool.

DKIM, DomainKeys Identified Mail (Standard, Wikipedia), ist wie SPF ebenfalls ein Protokoll zur Überprüfung von eingehenden Mails und deren unverändertem Inhalt. DKIM nutzt zur Überprüfung eine asymmetrische Verschlüsselungstechnik mit zwei Schlüsseln – einem privaten Schlüssel, der Mails unsichtbar angehängt wird und einem öffentlichen Schlüssel, abgelegt im DNS des Absenders.

Somit kann der Empfänger-Mailserver die Schlüssel aus dem Absender DNS und der Mail-Signatur gegeneinander prüfen und validieren. Das Hinzufügen des privaten Schlüssels in den Mailserver, damit dieser unsichtbar alle ausgehenden Mails damit signiert, erfordert eine fortgeschrittene Anpassung des Mailservers bzw. Konfiguration des Mailers und übersteigt den Rahmen dieses Artikels. Für GMail-Nutzer hilft die Google DKIM Step-by-Step-Anleitung, ansonsten wieder beim Anbieter/Hoster in der Hilfe schauen bzw. Support fragen.

Der zweite Teil besteht aus einem TXT DNS Record, der zuvor generiert werden muss. Benötigt wird dafür die Domain und ein „Selektor“; eine beliebige Zeichenkette, z.B. „meindkim1“. Der Record sollte immer mit v=DKIM1;k=rsa;p= anfangen! Selbst wenn die Generatoren gerne einen der Parameter v oder k weglassen, oder diese als optional angeben, sollten beide gesetzt sein. Info: Beide Überprüfungs-Tools (MxToolBox und GSuite MX-Check) bestätigen einen validen DKIM übrigens nur mit Parametern v UND k, Warnungen falls einer fehlt. Die Überprüfung von DKIM erfordert dann ebenfalls Domain und Selektor und sollte anschließend positiv ausfallen.

Aber Achtung: Ausschließlich den DKIM DNS Eintrag zu setzen, ohne die Mails zu signieren, hat keine weiteren positiven Auswirkungen (meistens aber auch keine negativen) und ist daher nicht zu empfehlen.

DKIM bei all-inkl aktivieren

https://all-inkl.com/wichtig/anleitungen/providerwechsel/einrichtung/dns/dkim-bei-versand-ueber-unsere-mailserver_541.html

• In den Domaineinstellungen DKIM aktivieren.
• Der passende DNS Eintrag wird automatisch ergänzt und sieht ungefähr so aus:

Name: kas202005201235._domainkey.meineDomain.de
Typ: TXT
Eintrag: v=DKIM1; k=rsa; p=MIIB[MEHR SCHLÜSSELINHALT]QAB

DMARC

https://elasticemail.com/dmarc (Generator für DMARC Einträge)

DMARC, Domain-based Message Authentication, Reporting, and Conformance (Standard, Wikipedia)

Technologie zur Erweiterung von SPF und DKIM. Geliefert werden zusätzliche Informationen, wie der Empfängerserver mit geprüften Mails umgehen soll sowie die Möglichkeit von Reports der Überprüfungen.

Auch hier ein DNS TXT Eintrag, der die Infos liefert. Zwei grundlegende Fragen müsst ihr euch stellen:

1. Wie sollen Mails behandelt werden, deren SPF/DKIM-Überprüfung fehlschlägt? Ignorieren / Spam / Abweisen.
2. Sollen Daten und fehlgeschlagene Überprüfungen als Reports verschickt werden und an welche Mail-Adresse?

Solltet ihr mit „Ignorieren“ dem Empfangsserver kein Verhalten vorschreiben wollen und auch keinerlei Reporting wünschen (v=DMARC1;p=none;), erfüllt DMARC keinen Zweck und hat auch keine weiteren Effekte auf den Mailempfang, kann also ausgelassen werden.

Restriktiveres Verhalten oder Reporting gewünscht? Dann wird einer der vielen existierenden Generatoren aus den gewählten Optionen einen einfachen bis recht komplexen TXT Record erstellen:

v=DMARC1; p=none; rua=mailto:admin@it-stack.de; ruf=mailto:admin@it-stack.de; fo=1;

Dieser Eintrag schickt Reportings an mich, wenn SPF oder DKIM fehlschlägt sowie generelle Reports, der Mailserver soll die Fehlschläge jedoch wie gewohnt behandeln, ich gebe kein strikteres Vorgehen vor.

Blacklists

Es gibt eine Vielzahl von professionell betriebenen Anti-Spam-Listen, also Blacklists, die von Mailservern zur weiteren Überprüfung abgefragt werden können. Ob mein Mailserver auf einer Blacklist steht, kann ich beispielsweise mit der MxToolBox Blacklist Suche herausfinden. Gebt hier eure Domain ein und eine Auswertung von über 100 Blackslists wird eventuelle Funde aufzeigen. Solltet euer Mailserver nicht die IP eurer Domain teilen oder weitere in das Mailing involvierten MX-Server-IPs bekannt sein, diese am besten auch noch testen. Eure Domain/IP ist in einer Blacklist gefunden worden? Das ist unpraktisch, kann aber mal passieren. Geblacklistet werden für gewöhnlich ganze Server. Auf einem Shared Server, wie das bei Webhosting fast immer der Fall ist, sind, je nach Vertrag, 20 bis 100 weitere Kunden untergebracht. Die Chance, dass ein anderer Kunde für das Blacklisting verantwortlich ist, ist hoch. Was tun? Auf der Betreiberseite der Blacklist gibt es meistens Suchen/Informationsportale, in denen Blacklist-Kandidaten, teilweise mit mehr Details und Begründung, gesucht werden können. Ich empfehle zwei Recherchen: Suche nach der Domain und nach der/den IPs. So kann es sein, dass die IP-Adresse des Servers in mehreren Einträgen gefunden wird (Reportfunde bei Spamhaus ZEN: Link1, Link2, in welchen wiederum eure Domain nicht erwähnt wird), für die Domain jedoch kein Eintrag vorhanden ist. Das sind weitere Hinweise darauf, dass nicht ihr, sondern ein anderer Kunde des Servers Schuld hat. Unabhängig von diesen Recherchen könnt ihr vermutlich wenig gegen das Blacklisting tun. Manche Betreiber bieten Unblock Formulare an, andere nicht. Informiert auf jeden Fall euren Webhoster/Mailing-Anbieter mit allen herausgefundenen Informationen über das Blacklisting – dieser hat für gewöhnlich andere Optionen und kann direkt selbst in die Behandlung der Problemursache, also gegen entsprechende Kunden, vorgehen.

User Trust

Desweiteren hilft es, sich zusätzlich Trust über den User/Empfänger zu holen – beispielsweise durch das Hinzufügen eurer Absenderadresse zu den Kontakten, das Markieren der Nachrichten als „Wichtig“ oder Versehen mit Sternchen/Markern (je nach Client heißt das anders), den Absender „Nie als Spam markieren“ (ebenfalls je Client anders) und mehr. Alles, was man mit einer Mail oder einem Absender bei dem jeweiligen Anbieter des Empfängers tun kann, dass letztlich einen positiven Effekt hat. Die Anbieter speichern solche Informationen (wie oft wurde eine Mail mit Inhalt X positiv behandelt, wie oft der Absender usw.) und behandeln Mails dieses Absenders zukünftig besser. Diese Maßnahme kann man bis zu einer gewissen Anzahl mit den eigenen Mitarbeitern starten – Mails an ihre private Mailadresse schicken, bestenfalls bei unterschiedlichen Anbietern, und die Mails von ihnen „positiv behandeln“ lassen.