Mail-Server & DKIM überwachen: Erreichbarkeit, die kein Browser-Check sieht

Die Website des Kunden läuft grün, das Monitoring meldet 100 % Uptime, und trotzdem ruft der Kunde an: „Wir bekommen seit heute Morgen keine E-Mails mehr." Wie kann das sein, wenn doch alles „online" ist? Die Antwort liegt in einem verbreiteten blinden Fleck: Eine erreichbare Website bedeutet nicht, dass die Mail funktioniert. Website und Mailserver sind getrennte Dienste, und ein gewöhnlicher Browser-Check sieht vom Mail-Teil schlicht nichts. Dieser Artikel erklärt, warum das so ist, wie SMTP- und IMAP-Monitore diesen blinden Fleck schließen und warum auch die Authentifizierungs-Records wie DKIM zur Überwachung gehören.

Warum ein Website-Check die Mail nicht sieht

Der Denkfehler beginnt mit einer verständlichen Vereinfachung: „Die Domain ist online, also läuft alles." Tatsächlich aber verbergen sich hinter einer Domain mehrere unabhängige Dienste, die technisch nichts miteinander zu tun haben müssen. Der Webserver, der deinkunde.de im Browser ausliefert, ist ein anderer Dienst als der SMTP-Server, der die E-Mails dieser Domain verschickt, und wieder ein anderer als der IMAP-Server, über den die Postfächer abgerufen werden. Häufig laufen sie auf unterschiedlichen Systemen, manchmal sogar bei unterschiedlichen Anbietern.

Ein Website-Monitoring fragt genau eine Sache: Antwortet der Webserver mit einer gültigen Seite? Das ist eine wertvolle Frage, aber es ist eine Frage über den Web-Dienst, und nur über ihn. Der Mailserver kann in diesem Moment abgestürzt, überlastet oder falsch konfiguriert sein, ohne dass der Website-Check auch nur zuckt. Er schaut schlicht nicht dorthin. Für den gesamten Mail-Teil einer Domain ist ein reines Web-Monitoring blind.

Und dieser blinde Fleck ist gefährlich, weil er unsichtbar ist. Ein Website-Ausfall meldet sich von selbst: Besucher beschweren sich, das Monitoring schlägt an. Ein toter Mailversand meldet sich oft tagelang nicht, weil niemand aktiv „testet", ob gerade E-Mails rausgehen. Man merkt es erst, wenn eine erwartete Mail ausbleibt oder ein Kunde sich wundert, dass er keine Antwort bekommen hat. Bis dahin ist der Schaden längst da.

Die Erreichbarkeit prüfen: SMTP- und IMAP-Monitore

Die Lösung ist, den Mailserver genauso direkt zu prüfen wie den Webserver, nur eben mit dem passenden Protokoll. Statt eine Webseite aufzurufen, verbindet sich ein Protokoll-Monitor mit dem Mailserver selbst und prüft, ob er wie erwartet antwortet. Zwei Monitor-Typen decken die beiden Richtungen der Mail ab.

Der SMTP-Monitor prüft den ausgehenden Weg. SMTP (Simple Mail Transfer Protocol) ist das Protokoll, über das Mails verschickt werden. Ein SMTP-Monitor baut in kurzen Abständen eine Verbindung zum SMTP-Port des Servers auf, typischerweise Port 587 für den authentifizierten Versand, und prüft, ob der Server die Verbindung annimmt und korrekt antwortet. Gelingt das nicht, ist der ausgehende Mailversand gestört, und du wirst alarmiert. Genau dieser Check hätte im Eingangsbeispiel den toten Versand sofort erkannt, statt dass der Kunde es Stunden später bemerkt.

Der IMAP/POP-Monitor prüft den eingehenden Weg, genauer: den Zugriff auf die Postfächer. IMAP und POP sind die Protokolle, über die Mail-Programme Postfächer abrufen. Ein IMAP/POP-Monitor verbindet sich mit dem entsprechenden Dienst und prüft dessen Erreichbarkeit. Fällt er aus, können die Nutzer des Kunden ihre Mails nicht mehr abrufen, ein ebenso geschäftskritischer Zustand wie ein toter Versand.

Der entscheidende Punkt: Diese Monitore sehen genau das, was ein Browser-Check nicht sieht. Sie sprechen die Sprache des Mailservers und prüfen die Erreichbarkeit auf der Ebene, auf der Mail tatsächlich stattfindet. Bei Uptimeify wird auch hier jeder Ausfall von mehreren EU-Standorten bestätigt, bevor ein Alarm ausgelöst wird. Ein kurzer Netzwerk-Schluckauf an einem Knoten erzeugt also keinen Fehlalarm.

Die zweite Ebene: Authentifizierungs-Records wie DKIM

Ein erreichbarer Mailserver ist notwendig, aber nicht hinreichend. Selbst wenn der SMTP-Server tadellos läuft und Mails verschickt, kann etwas anderes still versagen: die Authentifizierung, die dafür sorgt, dass die verschickten Mails vom Empfänger auch akzeptiert werden. Diese Authentifizierung lebt nicht auf dem Mailserver, sondern im DNS, in Form mehrerer TXT-basierter Einträge.

DKIM (DomainKeys Identified Mail) ist der wichtigste davon. Es ist ein DNS-Eintrag, der einen kryptografischen Schlüssel veröffentlicht, mit dem ausgehende Mails signiert werden. Der Empfänger-Server prüft anhand dieses Eintrags, ob eine Mail wirklich unverändert von der angegebenen Domain stammt. SPF (Sender Policy Framework) ist ein verwandter TXT-Eintrag, der festlegt, welche Server überhaupt im Namen der Domain senden dürfen. DMARC baut auf beiden auf und sagt Empfänger-Servern, wie sie mit Mails umgehen sollen, die SPF oder DKIM nicht bestehen.

Das Tückische an diesen Records ist, dass ihre Störung völlig unsichtbar ist, bis die Zustellung leidet. Ändert sich der DKIM-Eintrag versehentlich, wird er bei einem Serverumzug nicht mitgenommen oder überschreibt eine DNS-Änderung den SPF-Record, dann läuft der Mailserver weiter tadellos, aber die verschickten Mails werden bei den Empfängern plötzlich als nicht authentifiziert eingestuft und landen im Spam oder werden abgewiesen. Der Kunde sieht keinen Fehler auf seiner Seite; er merkt nur, dass seine Mails „nicht mehr ankommen".

Genau hier setzt die Überwachung der Auth-Records an. Weil DKIM, SPF und DMARC im DNS als TXT-Records liegen, lassen sie sich gegen einen erwarteten Wert prüfen, so, wie man auch einen A-Record überwacht. Ein DNS-Monitor, der diese TXT-Records im Blick hat, schlägt an, sobald der reale Wert vom hinterlegten Soll-Wert abweicht. Bei Uptimeify lässt sich das über einen DNS-Monitor abbilden, der etwa den SPF- oder DKIM-TXT-Record gegen den erwarteten Inhalt prüft und bei Abweichung (oder wenn der Record gar nicht mehr auflösbar ist) alarmiert. So wird eine stille Konfigurationsänderung sichtbar, bevor sie die Zustellbarkeit kippt.

Wo dieser Winkel aufhört: Erreichbarkeit vs. Reputation

Zur Ehrlichkeit gehört eine klare Abgrenzung, denn „Mail funktioniert" hat mehr als eine Ebene. Dieser Artikel behandelt zwei davon: die Erreichbarkeit des Mailservers (läuft SMTP, läuft IMAP?) und die Konfiguration der Authentifizierung (stimmen DKIM, SPF, DMARC?). Beide sind technische Voraussetzungen, die man gegen einen Soll-Zustand prüfen kann: ist der Server da, ist der Record korrekt, ja oder nein.

Davon zu unterscheiden ist die dritte Ebene: die Reputation und Zustellbarkeit im engeren Sinne, also die Frage, ob deine korrekt verschickten, korrekt authentifizierten Mails am Ende trotzdem im Spam landen, etwa weil die sendende IP auf einer Blacklist steht. Das ist kein Erreichbarkeits-, sondern ein Reputationsproblem, mit eigenen Ursachen und eigenen Werkzeugen (etwa einer Blacklist-Überwachung). Es ergänzt die hier beschriebene Ebene, ersetzt sie aber nicht, und umgekehrt.

Die saubere Trennung hilft bei der Diagnose. Wenn Mail-Probleme auftreten, arbeitest du die Ebenen der Reihe nach ab: Ist der Mailserver überhaupt erreichbar (SMTP/IMAP)? Sind die Auth-Records korrekt (DKIM/SPF/DMARC)? Und erst dann: Gibt es ein Reputationsproblem (Blacklist)? Dieser Artikel deckt die ersten beiden Ebenen ab, die Grundvoraussetzungen, ohne die die dritte gar nicht erst relevant wird.

Warum das für Agenturen besonders zählt

Für viele Kunden ist ein Mail-Ausfall geschäftskritischer als ein kurzer Website-Ausfall, und genau deshalb ist der blinde Fleck im Mail-Teil so gefährlich. Eine Website, die zehn Minuten nicht erreichbar ist, kostet ein paar Besucher. Ein Mailserver, der einen halben Tag keine Mails annimmt oder verschickt, kann bedeuten, dass Bestellungen, Anfragen, Rechnungen oder Terminbestätigungen verloren gehen, und zwar unbemerkt, weil eine nicht angekommene Mail keine Fehlermeldung erzeugt. Der Kunde erfährt vom Schaden oft erst, wenn ein Geschäft schon geplatzt ist.

Für eine Agentur, die die digitale Infrastruktur ihrer Kunden verantwortet, ist das ein doppeltes Risiko. Erstens ist der Ausfall für den Kunden besonders schmerzhaft, was den Vertrauensverlust vergrößert. Zweitens ist es besonders peinlich, wenn die Antwort auf „warum habt ihr das nicht gemerkt?" lautet „unser Monitoring schaut nur auf die Website". Ein Kunde erwartet zu Recht, dass „ihr passt auf unsere Systeme auf" auch die Systeme umfasst, über die sein Geschäft kommuniziert.

Umgekehrt ist die Überwachung von Mail-Erreichbarkeit und Auth-Records ein leises, aber starkes Differenzierungsmerkmal. Sie deckt genau den Bereich ab, den viele einfache Web-Monitoring-Tools auslassen, und den ein Kunde selten explizit anfragt, aber schmerzlich vermisst, wenn er fehlt. Wer den Mail-Teil mit überwacht, bietet eine Vollständigkeit, die aus „wir überwachen eure Website" ein glaubwürdiges „wir überwachen eure digitale Infrastruktur" macht.

Den blinden Fleck schließen

Der Kern dieses Themas ist eine Erweiterung des Sichtfelds, die überfällig ist. Die meisten Monitoring-Setups enden bei der Website, dem sichtbarsten, aber eben nur einem Teil der digitalen Präsenz eines Kunden. Die E-Mail-Infrastruktur, über die oft der eigentliche Geschäftsverkehr läuft, bleibt außen vor, weil ein Web-Check sie technisch nicht erreichen kann. Dieser blinde Fleck ist kein exotisches Randthema, sondern eine der häufigsten Ursachen für den frustrierten Kundenanruf, dem kein grünes Uptime-Dashboard widerspricht.

Ihn zu schließen ist unkompliziert, wenn man die richtigen Werkzeuge nutzt. Ein SMTP-Monitor für den Versand, ein IMAP/POP-Monitor für den Empfang und eine Überwachung der Auth-Records für die Zustellbarkeit decken zusammen die Ebenen ab, die ein Browser-Check systematisch übersieht. Jede dieser Prüfungen läuft nach demselben ruhigen Prinzip wie das übrige Monitoring: von mehreren EU-Standorten bestätigt, mit Alarm über deine gewohnten Kanäle, EU-gehostet.

Am Ende geht es um dieselbe Vollständigkeit, die gutes Monitoring insgesamt ausmacht: keine unsichtbaren Lücken zu lassen, in denen ein Ausfall wachsen kann, ohne dass jemand es sieht. Die Mail ist die größte dieser Lücken in einem reinen Web-Monitoring, und zugleich eine der wichtigsten, weil über sie das Geschäft des Kunden läuft. Wer sie mit überwacht, macht aus einem grünen Dashboard, das nur die halbe Wahrheit zeigt, eines, das der ganzen standhält.