Voraussetzungen für den E-Mail-Versand zu großen Mailprovidern (GMX, Web.de, Microsoft)

Wer erst seit kurzem einen eigenen Mailserver betreibt, wird vielleicht schon festgestellt haben, dass die eigenen E-Mails von anderen Server nicht immer akzeptiert werden und schnell im Spamverdachts-Ordner landen. Tatsächlich gibt es einige Dinge zu beachten, wenn man in die Liga der seriösen Mailprovider aufgenommen werden will. Um bei fremden System einen guten Ruf zu erreichen, sollten die folgenden Merkmale erfüllt sein:

Statische IP-Adresse - möglichst nicht aus einem Netz für Privathaushalte
Hostnamen im DNS (z.B. mail.mysystems.tld)
PTR (Reverse DNS) -Record von IP-Adresse auf Hostnamen
SPF-Eintrag im DNS
DKIM-Signierung für ausgehende E-Mails

Nicht alle großen Mailprovider verlangen alle Merkmale - allerdings werden von den meisten Providern mindestens eine statische IP, ein gültiger Hostname und ein PTR Record verlangt. SPF und DKIM erhöhen die Chancen, dass der eigene Mailserver als seriöser Sender eingestuft wird. Versendete Mails landen dann weniger oft im Spam-Ordner bzw. werden nicht mehr komplett abgelehnt. Aber wieso überhaupt der ganze Aufwand? Der Grund ist folgender:

Jeder Mailserver kann prinzipiell E-Mails im Namen von fremden Mailservern verschicken. Es ist ohne weiteres möglich, mit meinem eigenen Mailserver eine E-Mail im Namen von bestellungen@amazon.de zu versenden, und so den Eindruck zu erwecken, meine E-Mail komme tatsächlich von Amazon (genau das wird auch für Phishing-Mails ausgenutzt!). Woher soll der Empfänger-Server wissen, dass die E-Mail tatsächlich vom angegebenen Absender stammt und keine Fälschung ist? Um diese Frage drehen sich die genannten Techniken. Mit ihrer Hilfe kann (mal mehr, mal weniger zuverlässig) bestimmt werden, ob ein Server zum Senden unter einem bestimmten Namen / einer bestimmten Domain überhaupt berechtigt ist. Um die Frage zu beantworten, wird vor allem das DNS befragt.

Wenn wir E-Mails zu einem populären, großen Anbieter senden wollen, sollten wir sicherstellen, dass wir Techniken wie PTR, SPF und DKIM beherrschen bzw. unterstützen. Andernfalls wird unser Server häufig als Spamserver eingestuft und E-Mails werden blockiert.

PTR Record

Ein PTR Record kann als das Gegenteil zu einem herkömmlichen DNS-Record beschrieben werden. Während ein normaler DNS-Record einem Namen (einer Domain / Subdomain) eine oder mehrere IP-Adressen zuordnet, ordnet ein PTR Record einer IP einen Namen zu. Und so funktioniert’s:

Beim Erhalt einer E-Mail von einem fremden Server kennt der empfangende Server nur ein sicheres Attribut: Die IP-Adresse des sendenden Servers, der sich zu ihm verbunden hat. Alles weitere (und das sind die Mail-Daten an sich) könnten gefälscht sein. Wenn der sendende Server sagt “Ich bin Host mail.domain.tld” und sende im Namen von “benutzer@domain.tld”, dann muss das nicht zwangsläufig stimmen. Und wie schlägt man nach, ob der genannte Hostname stimmt? Man versucht, den Hostnamen zu der IP herauszufinden und vergleicht, ob die Angabe stimmt! - Und genau das tut ein Server, wenn er via Reverse DNS auf einen PTR Record prüft. Stimmt der in den E-Mail-Daten angegebene Hostname des Mailservers mit dem ermittelnden Hostnamen überein, wird die Mail angenommen - andernfalls handelt es sich vermutlich um eine gefälschte E-Mail.

Einen PTR Record könnt ihr bei eurem Server-Hoster beantragen. Ihr braucht ihm nur mitzuteilen, auf welchen Hostname der PTR Record angelegt werden soll, z.B. 123.123.123.456 <=> mail.domain.tld. Vergesst dabei auch eine evtl. vorhandene IPv6-Adresse nicht. Der Hostname wiederum muss in eurem DNS Zonefile mit der Server-IP verknüpft sein.

SPF (Sender Policy Framework)

Beim SPF handelt es sich um eine Technik, anhand derer festgestellt werden kann, ob ein Server zum Verschicken einer E-Mail unter der angegebenen Absenderdomain berechtigt ist. Nachdem anhand des geprüften PTR-Records nun schon festgestellt ist, dass der Hostname des sendenden Servers stimmt, wird nun nachgesehen, ob dieser Server auch berechtigt ist, E-Mails für die jeweilige Absenderdomain zu versenden. Ein Mailserver, der unter dem Namen “mail.domain.tld” läuft, kann nämlich nicht nur für “domain.tld”-Benutzer E-Mails verschicken, sondern auch für andere Domains wie z.B. “meinehomepage.tld”. So kann man mehrere Domains mit nur einem Mailserver betreuen (Multi-Domain-Betrieb). Angenommen, den Empfängerserver erreicht eine E-Mail, die von einem Absender “user@meinehomepage.tld” stammt - wie kann er feststellen, ob Host mail.domain.tld überhaupt zum Senden unter dieser Mailadresse ist?

An dieser Stelle hilft der SPF-Record: Der Empfängerserver extrahiert den Domainnamen aus der Absenderadresse (hier “meinehomepage.tld”) und lädt sich einen evtl. vorhandenen SPF-Record aus der DNS-Zone von “meinehomepage.tld”. In dem heruntergeladenen SPF-Record ist aufgelistet, welche Mailserver mit welchem Hostname oder welcher IP für diese Domain senden dürfen. Ist der Hostname des Senderservers in diesem Record genannt, wird die E-Mail als legitimiert angesehen. Ist der Hostname nicht genannt, ist der absendende Mailserver offenbar nicht dazu legitimiert, E-Mails für diese Domain zu verschicken. Die Mail wird abgelehnt.

Einen SPF Eintrag könnt ihr selbstständig in eurem DNS Zonefile anlegen. Unter http://www.spf-record.de gibt es einen sehr praktischen und leicht verständlichen SPF-Generator. Wählt aus, welche Server unter welchen Hostnames und IP-Adressen für eine Domain senden dürfen, und lasst euch den Code generieren. Der Code wir dann in einen TXT-Record eingefügt, z.B. so:

domain.tld.    86400    IN    TXT    v=spf1 a mx a:mail.domain1.tld a:mail.domain2.tld ip4:123.123.123.42 ?all

In diesem Fall wird folgendes festgelegt:

a: Hosts, die bereits in einem A oder AAAA Record zu der Domain erwähnt wurden, dürfen senden (z.B. user1@domain.tld)
mx: Hosts, die bereits in einem MX Record zu der Domain erwähnt wurden, dürfen senden (Bedeutet: Empfangende Hosts dürfen auch senden)
a: Außerdem dürfen Hosts senden, die den genannten A-/AAAA-Record haben.
ipv4: Der Host mit der IP-Adresse 123.123.123.42 darf ebenfalls senden
?all: Vermutlich sind andere Mailserver nicht dazu berechtigt, E-Mails unter dieser Domain zu senden.

Das ist auch schon alles.

DKIM

Leider hat sich SPF vor allem im Zusammenspiel mit Mail-Relays und Mailinglisten als untauglich erwiesen. Mehr Details dazu könnt ihr in diesem Vortrag von Peer Heinlein erfahren: https://www.heinlein-support.de/vortrag/spf-dkim-greylisting-der-neue-spamschutz

Aus diesem Grund wurde DKIM geschaffen, welches auf der Prüfung kryptographischer Signaturen basiert. Jede ausgehende E-Mail wird vom Mailserver automatisch mit einem geheimen Schlüssel signiert, bevor sie den eigenen Mailserver verlässt. Der Empfängerserver holt sich anhand der Absenderdomain den DKIM Record mit dem Public Key aus dem DNS ab und kann damit prüfen, ob eine E-Mail tatsächlich von dem Server stammt, dessen Public Key im DNS veröffentlicht wurde. Ein Server, der nicht den passenden Private Key hat, kann E-Mails nicht korrekt signieren und der Schwindel fliegt auf. Das Verfahren behebt einige Schwächen von SPF, ist aber etwas komplizierter einzurichten. Das E-Mail Filterframework Amavis unterstützt beispielsweise die DKIM-Signierung. Alternativ kann auch auf OpenDKIM zurückgegriffen werden.

Ein DKIM-Eintrag kann beispielsweise wie folgt aussehen:

dkim._domainkey.mysystems.tld. 3600 IN TXT v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCobe5aaqYeaUxLG3lTV3rcUP8OnB1KfGAOUU4/yYj/Fy0uOJNWajyGeAS9s3IEOhb5Zl8t0q4CB20ani3WfxhWQUGLCd3tkmira4nD8k5HMeCzUD5XbB1pmd3xTfdD03ahAm11Ii6skHYvZxJ+HOLdDaogDK8nkQw9cnydCZOTJwIDAQA

Wenn euch interessiert, wir ihr DKIM für euren Mailserver einrichtet, könnt ihr euch den Abschnitt zu Amavis in meiner Mailserver-Anleitung für Ubuntu Server 16.04 LTS oder den Beitrag von sys4.de zur DKIM-Signierung mit Amavis ansehen.

Probleme mit Microsoft Hotmail und Outlook

All die bisher genannten Maßnahmen reichen Microsoft leider nicht aus, um euren Mailserver als “seriös” einzustufen. Microsoft führt ein eigenes Mailserver-Register, in dem die Vertrauenswürdigkeit eures Mailservers aufgezeichnet wird. Dabei spielt unter anderem das Mailvolumen eine Rolle, welches Microsoft’s Server erreicht. Als kleiner Serverbetreiber hat man schlechte Chancen, dem “Junk” Ordner in Outlook oder Hotmail jemals zu entkommen. Zu dem Thema gibt es endlose Beschwerde-Threads in den Microsoft-Foren. Leider kommt erschwerend hinzu, dass Microsoft immer noch nicht in der Lage ist, SPF-Einträge in einigen Fällen korrekt zu verifizieren. Angeblich soll es helfen, seinen Mailserver bei Microsoft über dieses Formular zu registrieren. Habe ich gemacht - geholfen hat es nichts.

Mit statischer, bei Microsoft registrierter Mailserver-IP, korrektem Hostnamen, PTR-Record, SPF-Record, DKIM und sogar DMARC schaffe ich es nur in den Junk-Ordner meines outlook.com-Testaccounts - und das, obwohl ich die entsprechenden E-Mails mehrmals als harmlos markiert habe.

Um es kurz zusammen zu fassen: Wenn eure E-Mails eine MS-Mailbox nicht erreichen, hat der Empfänger sich den falschen Mailprovider ausgesucht. Euch trifft da keine Schuld (und ihr seid mit dem Problem auch bei weitem nicht die einzigen). Dass Microsoft kein E-Mail kann, ist bekannt und wird sich so schnell auch nicht ändern.

Nachtrag vom 07.12.2017: Über das Portal https://sender.office.com kann man die Freischaltung der eigenen Mailserver-IP-Adresse für Outlook.com beantragen.