E-Mail Policy

WEB.DE sieht sich in der Pflicht, einen vertrauenswürdigen und sicheren Dienst zur Verfügung zu stellen. Daher genießt die sorgfältige Bewertung eingehender E-Mails sowie das Vorgehen gegen unerwünschte Nachrichten höchste Priorität.

Möchten Sie erfolgreich E-Mails an WEB.DE versenden, so müssen Sie die folgenden Richtlinien einhalten.

Richtlinien:

  • (Static IP) Der einliefernde Server muss über eine statische IP-Adresse verfügen.
  • (No Dialup) IP-Adressen, die zu einem Dialup-Bereich gehören/dynamisch vergeben werden, können keine E-Mails bei uns einliefern.
  • (rDNS) Für die IP-Adresse Ihres Mailservers muss im DNS (Domain Name System) ein gültiger Reverse-DNS-Eintrag vorhanden sein, welcher auf Ihre Domain zeigt. Dabei muss der RDNS-Eintrag auf einen individuellen, vollständigen Hostnamen (FQDN) gesetzt sein.
    Informationen zu reverse DNS Records finden Sie u. a. hier: Wikipedia.org, Spamhaus.org
  • (rDNS-Policy) Der reverse DNS Record darf nicht dem Standardeintrag Ihres Hosters/Providers entsprechen, also z. B. "123-123-123-123-static.yourprovider.tld".
    Empfohlenes Format: "mail.yourdomain.tld"
  • (DNSBL) Stellen Sie sicher, dass die IP-Adresse Ihres Mailservers, sowie Ihre Domain nicht auf einer Blocklist von Spamhaus.org eingetragen ist.
  • (HELO) Ihr Mailserver muss ein valides HELO/EHLO senden. Dieses muss ein Fully Qualified Domain Name (FQDN) sein, z. B. "host.ihredomain.tld".
    Die Konfiguration Ihres HELOs können Sie z. B. über folgenden Service prüfen: https://www.abuseat.org/helocheck.html
  • (MX, A Record) Zu Ihrer Domain müssen korrekte MX oder A Records im DNS konfiguriert sein.
    Folgender Service bietet eine Überprüfung Ihrer MX-Konfiguration an: https://mxtoolbox.com/
    Einen detaillierteren Überblick über Ihre DNS-Konfiguration bietet: https://intodns.com/
  • (Header) Beim Erstellen Ihrer E-Mails müssen Sie die in RFC 5321 und RFC 5322 geforderten Standards einhalten. Dies schließt u. a. folgende Punkte mit ein:
    • Folgende Header-Felder müssen enthalten und syntaktisch korrekt sein: Date, From, Message-ID. Dies gilt auch für das Feld Sender, sofern Sie dieses verwenden.
    • Die Felder BCC, CC, Date, From, Sender, Subject, To dürfen nicht mehr als ein Mal im Header enthalten sein
    • Stellen Sie sicher, dass die Zeit (Datum, Uhrzeit und Zeitzone) Ihres Servers und Clients richtig eingestellt ist, damit keine signifikante Abweichung zur tatsächlichen Zeit im Date-Header auftritt
  • (DKIM) Ihre Nachrichten sollten per DKIM signiert werden und somit über mindestens eine valide DKIM-Signatur verfügen. Unsere dringliche Empfehlung dabei ist, dass die DKIM signing Domain mit der From Domain (RFC 5322.From header) übereinstimmt, mindestens in relaxter Form. Nutzen Sie eine Infrastruktur, die dies per Voreinstellung nicht gewährleistet, so sollten Sie über eine weitere Signatur die Übereinstimmung von DKIM signing Domain und From Domain (RFC 5322.From header) erreichen. Das Gleiche gilt im optimalen Fall auch für die MailFrom Domain (RFC 5321.MailFrom).
  • (SPF) Neben der Unterstützung von DKIM können Sie zudem einen SPF Record im DNS veröffentlichen. Dieser gibt Auskunft darüber, wer (welche Systeme) im Namen Ihrer Domain E-Mails versenden darf (dürfen) und wie E-Mails behandelt werden sollen, die die im SPF Record angegebene Policy nicht erfüllen.
  • (DMARC) Signieren Sie Ihre E-Mails per DKIM, um so die Authentizität Ihrer E-Mails sicherzustellen und/oder haben Sie für Ihre Domain einen SPF Record festgelegt, sollten Sie im DNS eine DMARC Policy veröffentlichen. Damit geben Sie dem empfangenden System eine Empfehlung, wie mit E-Mails verfahren werden soll, die Sie nicht versandt haben und die somit gefälscht wurden. Sogenanntes "Spoofing" Ihrer Domain kann so erschwert werden. Umgekehrt sollten auch Sie keine Domain als Absendeangabe verwenden, für deren Verwendung Sie nicht autorisiert sind.

Anforderungen:

  • Beachten Sie die geltenden gesetzlichen Vorgaben. Für die USA sind dies z. B. der Can-Spam Act. Beachten Sie, dass Sie beim Versand von Massen-E-Mails verantwortlich gemacht werden können, wenn Sie kein Einverständnis von der Empfangsseite eingeholt haben.
  • Der einliefernde Server muss gegen unberechtigten Zugriff geschützt sein.
  • Der Empfang von E-Mails mit schädlichen, sittenwidrigen oder gesetzeswidrigen Inhalten wird abgelehnt. Dies sind inbesondere viren- oder trojanerinfizierte E-Mails sowie solche die auf viren- oder trojanerinfiziert Seiten verweisen. E-Mails mit Inhalten, die der Volksverhetzung dienen, zu Straftaten anleiten, Gewalt verherrlichen oder E-Mails, die auf Seiten mit dementsprechenden Inhalten referenzieren. E-Mails, die darauf abzielen, widerrechtlich an Zugangsdaten zu gelangen, werden ebenfalls abgelehnt.
  • WEB.DE behält sich das Recht vor, zum Sortieren und Abweisen von E-Mails externe Listen wie z. B. IP-Listen (DNSBL/RBL-Listen) oder Hashwert-Listen zu verwenden. Darüber hinaus behält sich WEB.DE das Recht vor, gegen Personen, die gegen diese E-Mail Policy verstoßen, rechtlich vorzugehen oder den Empfang von entsprechenden E-Mails temporär oder dauerhaft zu unterbinden.

Glossar

  1. Der E-Mail-Header beinhaltet technische Informationen zum Sendeverlauf einer E-Mail. In den meisten E-Mail-Programmen und Webmail-Oberflächen werden die Header der E-Mails ausgeblendet. Im Gegensatz dazu wird der Body einer E-Mail (der eigentliche Text) standardmäßig angezeigt. Dieser kann aus einfachem Text bestehen, oder auch aus mehreren Elementen, zum Beispiel aus Text und Anlagen.
  2. Das HELO Kommando ist Teil des SMTP Protokolls, das für die Übertragung von E-Mails verwendet wird. Mit diesem Kommando wird der E-Mailaustausch zwischen zwei Servern initiiert, indem der sendende Server seinen vollständigen Domainnamen übermittelt. Analog dazu signalisiert ein Server mittels EHLO Kommando zusätzlich, dass die erweiterte SMTP Protokollversion (ESMTP) benutzt werden soll.
  3. Reverse DNS-Eintrag (FQDN oder PTR-RR) Ein Reverse DNS-Eintrag oder auch FQDN (Fully Qualified Domain Name) ist der eindeutige Name eines Internet-Hosts. Mit Hilfe des FQDN kann die IP-Adresse des Hosts ermittelt werden. Der Reverse DNS-Eintrag sollte beim Versand von E-Mails als HELO verwendet werden. Weiterführende Informationen finden Sie im IONOS Digital Guide.
  4. SPF (Sender Policy Framework) ist eine Technik, die das Fälschen von Domainangaben beim Versandprozess erschweren soll. Hierzu wird festgelegt, von welchen IP-Adressen der Versand von E-Mails mit einer bestimmten Versanddomain erfolgen darf (respektive von welchen IP-Adressen ein Versand nicht erfolgen darf). Dazu wird in der DNS-Zone ein Ressource Record vom Typ TXT (oder falls vorhanden SPF) hinterlegt, der alle berechtigten IP-Adressen auflistet, diese Domain als Absendeadresse zu verwenden. Weiterführende Informationen zur Einrichtung eines SPF-Eintrages finden Sie auf den Seiten von Open-spf.org
    Im Falle einer Umleitung kann ein Empfangssystem, das den Empfang von E-Mails auf einen gültigen SPF-Eintrag prüft, die Echtheit der angegebenen Domain nicht mehr überprüfen. Weiterleitende Server sollten die Absendeadressen im so genannten Envelope via SRS so umschreiben, sodass eine Überprüfung auf SPF-Einträge keine falschen Ergebnisse liefert. Weitere Informationen zu SRS finden Sie auf den Seiten von Open-spf.org.
  5. In einer RBL-Liste werden IP-Adressen gesammelt. Mit Hilfe einer solchen Liste kann im Vorfeld einer Verbindungsaufnahme entschieden werden, ob bestimmte Versandsysteme E-Mails in das Empfängersystem zustellen dürfen oder mit welcher Spamwahrscheinlichkeit solche E-Mails markiert werden. Es gibt mehrere Arten solcher Listen. Einige beinhalten IP-Adressen, an die nicht versendet werden darf und von denen auch keine E-Mails angenommen werden dürfen. Andere Listen führen IP-Adressen, die für den Versand von Spam-Mails verantwortlich sind.