BLOG · 27. AUGUST 2026

E-Mails, die ankommen: alle Prüfungen von internet.nl und ihre Gründe

Ein sendender Mailserver ist einfach. Damit seine Nachrichten angenommen werden und nicht gefälscht werden können, müssen ein Dutzend Einträge zusammenpassen. Hier stehen alle, auf unseren eigenen Domains, mit ihrem tatsächlichen Zweck.

DIE BEWERTUNG

So prüfen Sie die Konfiguration

internet.nl ist ein kostenloser Test der niederländischen Regierung und einer Gruppe von Internetorganisationen. Hier zählen zwei Bereiche: Website und Maildomain. Beide liefern für jede Prüfung ein öffentliches Bestanden- oder Nicht-bestanden-Ergebnis.

Sie können die Tests gegen ave17.com selbst ausführen; die Roadmap beschreibt die geplante Veröffentlichung datierter Ergebnisse.

Die Bewertung misst Konfiguration, nicht Verhalten. Ein perfektes Ergebnis belegt, dass eine Domain nicht leicht gefälscht werden kann und ihre E-Mails verschlüsselt übertragen werden. Es sagt nichts darüber aus, ob die Betreiber auf E-Mails antworten.

WER SIE GESENDET HAT

SPF, DKIM und DMARC in der entscheidenden Reihenfolge

Diese drei beantworten gemeinsam, ob eine Nachricht tatsächlich von dieser Domain kommt. Oft werden sie in der falschen Reihenfolge eingeführt. Deshalb haben viele Domains alle drei und bleiben trotzdem fälschbar.

SPF
Listet die für die Domain sendeberechtigten Maschinen. Einfach, aber allein schwach: Bei Weiterleitung scheitert die Prüfung, weil der weiterleitende Server nicht auf der Liste steht.
DKIM
Signiert die Nachricht selbst und übersteht deshalb Weiterleitung. Wir signieren mit zwei Schlüsseln, RSA und Ed25519, weil manche Empfänger den zweiten noch nicht verstehen und wir nicht zwischen beiden wählen möchten.
DMARC
Sagt dem Empfänger, was beim Scheitern der ersten beiden zu tun ist, und fordert dann einen Bericht an. Bei uns gilt p=reject: verwerfen. Jede weichere Einstellung ist eine höfliche Bitte, die die meisten Absender ignorieren.

Die funktionierende Reihenfolge ist DKIM, dann SPF, dann DMARC im Beobachtungsmodus, bis die Berichte unauffällig sind, und erst dann reject. Wer sofort reject setzt, entdeckt öffentlich, welche bislang unbekannten Systeme seiner Organisation E-Mails senden.

WIE SIE ÜBERTRAGEN WURDE

Verschlüsselung, die nicht entfernt werden kann

Mailserver bieten seit zwanzig Jahren opportunistische Verschlüsselung. Ein Angreifer dazwischen kann das Angebot entfernen, sodass beide Server unbemerkt auf Klartext zurückfallen. Zwei Mechanismen verhindern das, und sie fehlen den meisten Domains.

MTA-STS
Eine per HTTPS bereitgestellte Richtlinie: "Für diese Hostnamen immer TLS nutzen; andernfalls nicht zustellen." Wir veröffentlichen sie im Modus enforce, dem einzigen wirksamen Modus.
DANE
Das erwartete Empfängerzertifikat wird in DNS veröffentlicht und durch DNSSEC signiert. Der Absender kann es so gegen die Domain statt gegen eine Liste von Zertifizierungsstellen prüfen. Wir veröffentlichen TLSA-Einträge für submission, submissions, IMAPS und den Mail Exchanger selbst.
DNSSEC
Signaturen über die DNS-Antworten selbst. Ohne sie kann ein Angreifer alle obigen Einträge unterwegs ändern. Deshalb verlangt DANE sie, und deshalb signieren wir jede unserer Zonen.

MTA-STS und DANE überschneiden sich bewusst. Das erste ist einfach einzurichten und vertraut Webzertifikaten; das zweite ist schwieriger und vertraut DNSSEC. Mit beiden bleibt eine Domain geschützt, unabhängig davon, welches System der Angreifer erreicht.

DIE WEBSEITE

Was der Websitetest verlangt

Der Webbereich desselben Tests folgt hauptsächlich derselben Idee: Verbindungen dürfen nicht herabgestuft und Zertifikate nicht ausgetauscht werden können.

  • IPv6 für Website und Nameserver, erreichbar und mit denselben Inhalten wie IPv4
  • DNSSEC für die Zone, damit die Adresse selbst nicht umgeschrieben werden kann
  • HTTPS mit modernen Verschlüsselungsverfahren, HSTS und ohne Herabstufungsmöglichkeit
  • DANE auch für das Webzertifikat, was fast niemand umsetzt
  • CAA eingeschränkt, sodass nur die benannte Zertifizierungsstelle für die Domain ausstellen darf
  • Sicherheitsheader gegen Einbettung in Frames und falsche Interpretation des Seiteninhalts

DIE ZWEI WICHTIGEN EINSCHRÄNKUNGEN

Wo die Bewertung täuschen kann

Erstens: DMARC mit p=reject ist auf einer nie sendenden Domain trivial. Eine Domain mit echtem Verkehr erreicht das erst nach wochenlangem Lesen der Berichte. Gleiche Bewertung, völlig andere Arbeit. Fragen Sie bei einem Anbietervergleich, welche der beiden Arbeiten durchgeführt wurde.

Zweitens: DANE muss vom Empfänger geprüft werden, was viele nicht tun. Seine Veröffentlichung schützt bei prüfenden Empfängern und kostet bei anderen nichts. Sie garantiert aber nicht, dass eine bestimmte Nachricht verschlüsselt übertragen wurde. Diese Garantie kann niemand geben.

Eine unbequeme Grenze: Nichts davon verhindert eine überzeugende Nachricht von einer ähnlich aussehenden Domain. Das ist ein anderes Problem, das Menschen statt Einträge lösen.

WAS ES GEKOSTET HAT

Ehrlich gesagt

Ein Tag für die korrekten Einträge der ersten Domain, etwa zwanzig Minuten je weitere, weil es dann eine Vorlage gab. Die Konfiguration ist nicht der zeitintensive Teil. Die zwei Wochen DMARC-Berichte vor einem sicheren Wechsel zu reject lassen sich weder kaufen noch beschleunigen.

Wir betreiben das selbst statt über einen Mailanbieter; deshalb können wir es beschreiben. Möchten Sie dies nicht selbst tun, ist das vernünftig. Fragen Sie Ihren Anbieter dennoch nach den genannten Einträgen.