E-Mail Probleme beheben: Unterschied zwischen den Versionen

Aus Wikizone
Wechseln zu: Navigation, Suche
 
(9 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
== Siehe auch ==
 
== Siehe auch ==
 +
All-inkl - Newsletter Anbieter einrichten
 
  [[TYPO3 - E-Mail]]
 
  [[TYPO3 - E-Mail]]
 
  https://it-stack.de/30/05/2018/anti-spam-basics-fuer-versender-spf-dkim-dmarc-mehr/
 
  https://it-stack.de/30/05/2018/anti-spam-basics-fuer-versender-spf-dkim-dmarc-mehr/
 +
 
== Testtools ==
 
== Testtools ==
 
  https://mxtoolbox.com/SuperTool.aspx
 
  https://mxtoolbox.com/SuperTool.aspx
Zeile 20: Zeile 22:
 
== SPF ==
 
== SPF ==
 
  https://all-inkl.com/wichtig/anleitungen/kas/tools/dns-werkzeuge/spf_482.html
 
  https://all-inkl.com/wichtig/anleitungen/kas/tools/dns-werkzeuge/spf_482.html
SPF, Sender Policy Framework (Wikipedia, Standard), ist ein Standard zur Überprüfung des Absenders einer E-Mail und vermutlich der wichtigste Anti-Spam-Indikator. SPF ist eine TXT-Einstellung 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.
+
[[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:
 
Ein beispielhafter SPF-Eintrag, der Google als Relay inkludiert, könnte so aussehen:
 
  v=spf1 a mx include:_spf.google.com ~all
 
  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.  
 
* 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“.
 
* Ü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
 +
E-Mails von Servern aus dem mx oder a Record sind erlaubt. Für alle anderen wird ein negatives Ergebnis zurückgegeben (-all).
 +
 +
 +
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 include:spf.protection.outlook.com -all
 +
Dieser Eintrag wird von Microsoft vorgeschlagen. Problem: Mails vom Webserver werden oft als Spam identifiziert, da hier nur Server aus dem spf Eintrag von Microsoft erlaubt sind.
 +
 +
v=spf1 ip4:85.13.164.115 include:spf.protection.outlook.com -all
 +
Lösung eins: IP des Servers hinzufügen. Ist allerdings unpraktisch wenn sich die IP ändern kann.
 +
 +
v=spf1 a mx include:spf.protection.outlook.com -all
 +
Lösung zwei: Hier werden die Server aus den A und MX Records des DNS Eintrags explizit erlaubt. Der Eintrag bleibt gültig, auch wenn sich die IP Adresse des Webservers (A Record) ändert.
 +
 +
== 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 ===
 
=== SPF-Beispiele ===
Zeile 70: Zeile 127:
 
  v=DMARC1; p=none; rua=mailto:admin@it-stack.de; ruf=mailto:admin@it-stack.de; fo=1;
 
  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.
 
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.

Aktuelle Version vom 31. Mai 2023, 08:27 Uhr

Siehe auch[Bearbeiten]

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[Bearbeiten]

https://mxtoolbox.com/SuperTool.aspx

Spam Codes[Bearbeiten]

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[Bearbeiten]

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

SPF[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

Beispiel für einen sehr gängigen Eintrag

v=spf1 mx a -all

E-Mails von Servern aus dem mx oder a Record sind erlaubt. Für alle anderen wird ein negatives Ergebnis zurückgegeben (-all).


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 include:spf.protection.outlook.com -all

Dieser Eintrag wird von Microsoft vorgeschlagen. Problem: Mails vom Webserver werden oft als Spam identifiziert, da hier nur Server aus dem spf Eintrag von Microsoft erlaubt sind.

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

Lösung eins: IP des Servers hinzufügen. Ist allerdings unpraktisch wenn sich die IP ändern kann.

v=spf1 a mx include:spf.protection.outlook.com -all

Lösung zwei: Hier werden die Server aus den A und MX Records des DNS Eintrags explizit erlaubt. Der Eintrag bleibt gültig, auch wenn sich die IP Adresse des Webservers (A Record) ändert.

Mehrere Server im SPF Eintrag[Bearbeiten]

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[Bearbeiten]

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

Amazon SES[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

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.