Beim Betrieb eines E‑Mail‑Servers ist vieles zu beachten. Am wichtigsten ist, dass man nicht als Spam‑Quelle gilt und dadurch eine schlechte Reputation im Internet bekommt. Entsprechend muss sichergestellt werden, dass der verwendete Server kein „Open Relay“ ist und E‑Mails nicht ungeprüft und ohne Authentifizierung weiterleitet. Ebenso gehört dazu, zu prüfen, ob die verwendete IP‑Adresse auf einer Blockliste geführt wird. Das ist bei älteren IPv4‑Adressen, die zuvor einem anderen Nutzer zugeordnet waren, wahrscheinlicher als bei IPv6‑Adressen.
Bei meiner IPv4‑Adresse war tatsächlich der Fall, dass sie auf einer Blockliste stand. Das Problem ließ sich jedoch durch eine Nachricht über das Kontaktformular des Anbieters klären. Seitdem erfüllt mein E‑Mail‑Server die wichtigsten und grundlegendsten Anforderungen auch SPF, DKIM und DMARC habe ich von Anfang an gepflegt und normgerecht eingerichtet.
Trotzdem besteht bei großen Anbietern oft Skepsis gegenüber kleinen oder neuen E‑Mail‑Servern. Auch wenn meine Domain zuvor über den Apple‑E‑Mail‑Dienst verwaltet wurde, muss ich meine Reputation neu aufbauen.
Kurz eingeschoben: Im iCloud‑Abo sind viele Funktionen enthalten, die für ein Homelab oder technisch interessierte Heim‑Anwender nützlich sind. Wenn man aus Interesse oder Datenschutzgründen keinen eigenen E‑Mail‑Server betreiben möchte, kann man Apples Angebot nutzen. Für 0,99 € im Monat erhält man eine eigene Domain inklusive 5 Aliase und einige nützliche Funktionen — für den Einstieg in Ordnung.
Ziel ist, dass versendete E‑Mails beim vorgesehenen Empfänger im Posteingang ankommen und nicht im Spam landen oder gar zurückgeworfen (bounced) werden. Neben einer sauberen Reputation — also kein Spamversand oder massenhafte Newsletter von Anfang an — hilft ein hoher technischer Standard. Eine hundertprozentige Einsicht, wie einzelne Anbieter E‑Mails bewerten, gibt es nicht, aber es gibt Hinweise und Standards, an denen sich die Bewertung orientiert.
Eine hilfreiche Prüfmöglichkeit bietet die Webseite Internet.nl (eine Initiative der Internet‑Community und der niederländischen Regierung). Dort lassen sich eigene Dienste auf die Implementierung moderner Internet‑Standards testen. Die geprüften Standards sind unter anderem:
- IPv6: Erreichbarkeit über den modernen IP‑Standard.
- DNSSEC: Ist die DNS‑Zone signiert?
- DMARC, DKIM und SPF: Authentifizierungsmechanismen zum Schutz vor E‑Mail‑Phishing.
- STARTTLS und DANE: Ist eine sichere Verbindung zum E‑Mail‑Server möglich?
- RPKI: Route‑Autorisierung (RPKI schützt vor falschen Routing‑Ankündigungen).
Wenn alle diese Standards erfüllt sind, landet man in der „Hall of Fame“ und darf das entsprechende Badge verwenden. Seit dem 21.03.2026 erfüllt mein E‑Mail‑Server alle diese Kriterien, und ich darf das Badge verwenden.
Notwendig für den Abschluss war der Umzug meiner Domain vom Hoster Strato zu Netcup, um DNSSEC schnell und unkompliziert umzusetzen. Bei Netcup hatte ich bereits eine Domain, sodass dort bereits ein Nutzerkonto bestand. Die Kündigung bei Strato war über das Webinterface möglich; nach wenigen Stunden erhielt ich den Auth‑Code zur Domainübertragung. Bei Netcup konnte ich die Domain einrichten und die Nameserver von desec.io hinterlegen. Den DNSSEC‑Key habe ich anhand der klaren Anleitung von desec.io eingefügt. Der Wechsel verlief daher ohne Ausfall und mit geringem Aufwand.
Hier eine Möglichkeit euren E-Mail Server zu Testen:
PS: Auch große Anbieter erreichen nicht immer 100 %. Am Beispiel web.de (abgerufen am 22.03.2026, 13:43 Uhr) liegt die Bewertung bei nur 90 %, weil das E‑Mail‑System nicht ausreichend über IPv6 erreichbar ist. Außerdem werden dort ältere, weniger sichere TLS‑Versionen unterstützt, was die Kompatibilität zu älteren Clients erhöht, aber aus Sicherheitssicht problematisch ist.
Für mich stellt sich die Frage, weshalb veraltete TLS‑Versionen (1.0/1.1) im Jahr 2026 immer noch unterstützt werden, während zeitgemäß konfigurierte und sichere E‑Mail‑Server oft schlechter bewertet oder fälschlich als Spam markiert werden. Jeder aktuell gepflegte Server kann höhere Standards nutzen. Beispiele für Exchange:
- Exchange Server 2016: TLS 1.2 nativ ab CU3; empfohlen CU8 oder neuer für volle Kompatibilität.
- Exchange Server 2013: TLS 1.2 wird ab CU13 unterstützt (vollständige Empfehlungen ab CU19/CB).
- Exchange Server 2010: TLS 1.2 ist nach Updates (SP3 + bestimmte Hotfixes) möglich, aber nicht so umfassend getestet wie bei neueren Versionen.
- Exchange Online (Microsoft 365): TLS 1.2 ist Standard.
Bei On‑Prem‑Installationen in Firmen oder Behörden sollten nicht mehr unterstützte Server grundsätzlich ersetzt werden, da Microsoft den Support eingestellt hat. Für die neueste Exchange‑Version (Subscription Edition) ist inzwischen TLS 1.3 möglich, vorausgesetzt, das zugrundeliegende Betriebssystem ist Windows Server 2022 oder 2025.
Es gibt mittlerweile hinreichend technische Möglichkeiten, neue und korrekt konfigurierte Server automatisch zu erkennen und innerhalb eines Provider‑Konzerns (z. B. web.de / gmx.de) zu bewerten. So könnten Spam‑ und Phishing‑Quellen effizienter von vertrauenswürdigen Servern unterschieden werden. Ein frisch aufgesetzter E‑Mail‑Server wird in den meisten Fällen nicht sofort massenhaft Newsletter an Hunderte Empfänger versenden.
Sich hingegen darauf zu verlassen, dass alte, potenziell unsichere Systeme einfach ausreichen, ist keine gute Strategie, um Kunden hohen Spam‑Schutz zu bieten. Provider sollten moderne Sicherheitsstandards stärker gewichten und Mechanismen einführen, die korrekt konfigurierte neue Server bevorzugen, statt sie wegen Kompatibilitätsbestrebungen mit veralteten Protokollen zu benachteiligen.
]]>
