Dies ist die archivierte Version des Blogs vom 05.01.2017. Aktuelle Beiträge findest du unter thomas-leister.de
 

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:<Hostname> 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.

(Microsoft-Maildienste sind übrigens die einzigen, bei denen ich mit meinen E-Mails im Spam lande. Alle andere Mailprovider, mit denen sich mein Server bisher ausgetauscht hat, haben meine E-Mails ohne Zicken akzeptiert!)

 


Post published on 20. April 2016 | Last updated on 20. April 2016
Tags:                     

Diesen Blog unterstützen

Wenn Dir der Beitrag gefallen hat, freue ich mich über einen kleinen Obolus :-) Bitcoin QR Code

PayPal-Seite: https://www.paypal.me/ThomasLeister
Meine Bitcoin-Adresse: 15z8 QkNi dHsx q9WW d8nx W9XU hsdf Qe5B 4s

Siehe auch: Unterstützung

Informationen zum Autor

Thomas Leister

Geb. 1995, Kurzhaar-Metaller, Geek und Blogger. Nutzt seit Anfang 2013 ausschließlich Linux auf Desktop und Servern. Student der Automobilinformatik an der Hochschule für angewandte Wissenschaften in Landshut.

9 thoughts on “Voraussetzungen für den E-Mail Versand zu großen Providern

  • Hi Thomas,
    du hast ja selbst schon auf Peer Heinleins Meinung verwiesen, was SPF angeht. Allerdings empfiehlt er auch, auf keinen Fall einen „-all“-Record zu setzen. Mehr Sinn macht da ein „?all“, also keine Aussage über andere Mailserver zu treffen. Ansonsten gibts schon Probleme mit einfachen Forwardings.
    Vielleicht ein Verbesserungsvorschlag für deine Anleitung zu SPF…
    Gruß Martin

    • Wow Martin, du bist ja schnell ;-) Gerade erst veröffentlicht, und schon ein Kommentar dazu.

      Ja, du hast Recht. Ich nutze selber gerne -all für meine Server (weil mir das bisher noch keine Probleme bereitet hat) aber ein ?all ist im Allgemeinen eher zu empfehlen. ich habe die Zeile angepasst. Danke für die Anregung!

      LG Thomas

    • Um Weiterleitungen trotz hartem SPF -all zu ermöglichen, kann man SRS einsetzen. Dabei wird der Absender vor der Weiterleitung automatisch nach Schema F zu einer Adresse mit zugelassener IP umgeschrieben.
      Hat auch wieder gewisse Nachteile, funktioniert aber bei mir seit einer ganzen Weile hervorragend.

  • Hallo Thomas,
    der Link zu „Abschnitt zu Amavis in meiner Mailserver-Anleitung für Ubuntu Server 16.04 LTS“ öffnet sich bei mir leider nicht. Kannst du evtl. noch einmal den richtigen Link posten? Das Thema interessiert mich auf jeden Fall :)
    Danke schön!
    Gruß
    Sebastian

  • Moin Thomas,

    einen gibt es noch der kein E-Mail kann. Schau dir mal AOL an.
    Ich weiß es sollte tot seid ist es aber leider nicht.

  • Servus Thomas,
    super Beitrag auf den ich zufällig gestoßen bin weil ich von meinem Mailserver keine Mails an Outlook Accounts versenden kann. Alle anderen großen Provider funktionieren wunderbar und die Mails werden auch nicht als SPAM aussortiert. Ich habe das jetzt so gelöst das Mails die an Outlook Accounts versendet werden sollen über einen SMTP Relay bei meinem Domain Provider versendet werden. Schade das man das so lösen muss… Ich kann dem Empfänger ja schlecht erklären das er da beim falschen Mail Provider ist.
    Gruß aus München
    Jan

  • Hallo Thomas,
    ich habe meinen Mailserver (IP & Domain) vor 10 Tagen bei Microsoft registrieren lassen, seit heute kommen meine Mails ganz normal in meinem Posteingang bei Outlook.de an.
    Gruß,
    Jan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.