Bleiben eingehende E-Mails in MailPlus aus, obwohl die Synology grundsätzlich erreichbar ist, liegt die Ursache meist in einer der Verbindungen zwischen Domain, DNS, Portfreigaben, Zertifikat und Maildienst. Für die Fehlersuche ist die richtige Reihenfolge entscheidend: Zuerst muss die Domain auf den passenden Server zeigen, danach muss der Zugriff von außen funktionieren, und am Ende muss MailPlus die Verbindung korrekt annehmen.
In vielen Fällen ist nicht der Maildienst selbst defekt, sondern eine kleine Abweichung in den DNS-Einträgen, eine blockierte Portweiterleitung oder ein Zertifikat, das nicht zum verwendeten Hostnamen passt. Wer hier systematisch vorgeht, spart sich riskante Änderungen am Mailserver und vermeidet Nebenwirkungen für bestehende Konten, Freigaben und laufende Zustellungen.
Erst die Zustellungskette verstehen
Bevor du an Einstellungen änderst, hilft ein kurzer Blick auf den Weg einer eingehenden Mail. Der Absender fragt per DNS nach dem MX-Eintrag deiner Domain, verbindet sich mit dem dort hinterlegten Ziel und spricht anschließend auf dem passenden SMTP-Port mit deinem NAS. Erst wenn dieser Weg sauber funktioniert, kann MailPlus die Nachricht annehmen und intern weiterverarbeiten.
Genau an diesen drei Stellen treten die meisten Fehler auf: Der MX-Eintrag zeigt auf den falschen Host, der Port 25 ist nicht von außen erreichbar oder das Zertifikat passt nicht zum Namen, unter dem der Mailserver angesprochen wird. Auch ein funktionierender Login in DSM sagt noch nichts darüber aus, ob der Maildienst für andere Mailserver tatsächlich erreichbar ist.
DNS-Einträge auf Plausibilität prüfen
Für eingehende E-Mails ist der MX-Eintrag der wichtigste Startpunkt. Er muss auf den Hostnamen zeigen, unter dem deine Synology im Internet erreichbar ist. Typisch ist ein eigener Mail-Hostname wie mail.deinedomain.tld, nicht die bloße DSM-Adresse oder eine interne lokale IP.
Prüfe danach den A- oder AAAA-Eintrag dieses Hostnamens. Er muss auf die öffentliche IP deines Anschlusses zeigen. Nutzt du IPv6, sollte auch der AAAA-Eintrag stimmen, denn manche Mailserver bevorzugen IPv6, sobald es verfügbar ist. Ein falscher oder veralteter Eintrag sorgt dafür, dass Zustellungen ins Leere laufen oder an einem anderen Ziel landen.
Wichtig ist außerdem die TTL. Eine sehr hohe TTL verlängert die Zeit, bis Änderungen weltweit greifen. Nach einer Korrektur kann es deshalb dauern, bis wieder überall Zustellungen ankommen. Das ist kein MailPlus-Fehler, sondern eine Folge der DNS-Verteilung.
Portfreigaben und Firewall gezielt prüfen
Für eingehende SMTP-Verbindungen ist Port 25 der zentrale Punkt. Wenn dein NAS hinter einem Router steht, muss dieser Port von außen an die Synology weitergeleitet werden. Zusätzlich darf eine Firewall auf NAS- oder Router-Ebene den Zugriff nicht blockieren. Ohne diese Freigabe erreicht kein externer Mailserver deinen Maildienst.
Je nach Konfiguration kommen weitere Ports hinzu. Für den Abruf per Mailclient sind 143, 993, 110 oder 995 relevant, für den Versand oft 587 oder 465. Wenn nur der Eingang gestört ist, liegt der Fokus jedoch zuerst auf Port 25. Die übrigen Ports helfen beim Abruf und Versand durch Benutzer, lösen aber kein Zustellproblem von außen.
Ein häufiger Fehler ist eine doppelte Blockade: Der Router leitet korrekt weiter, aber die Synology selbst blockiert den Zugriff durch eine Sicherheitsregel. Prüfe deshalb beide Ebenen. Auch Cloud- oder Provider-Firewalls können eingehende Verbindungen auf Port 25 unterbinden, selbst wenn im Heimnetz alles richtig aussieht.
Zertifikat und Hostname sauber aufeinander abstimmen
Mailserver reagieren empfindlich auf Zertifikate, deren Name nicht zum angesprochenen Host passt. Wird dein Dienst als mail.deinedomain.tld kontaktiert, muss das Zertifikat genau diesen Namen enthalten. Ein Zertifikat für die DSM-Oberfläche oder für einen anderen Alias reicht dafür nicht aus.
Besonders kritisch wird es, wenn mehrere Dienste dieselbe Domain nutzen, aber unterschiedliche Namen im Zertifikat stehen. Dann kann die Verbindung zwar aufgebaut werden, doch der Gegenspieler der Mailzustellung bewertet sie als unsauber oder lehnt sie ab. Bei ausgehenden Verbindungen fällt das eher auf, bei eingehenden Verbindungen zeigen manche Systeme nur eine verzögerte oder komplett verweigerte Zustellung.
Auch ein abgelaufenes Zertifikat kann E-Mails indirekt stören. Externe Systeme akzeptieren dann die TLS-Aushandlung nicht mehr oder stufen deinen Server als unsicher ein. Deshalb sollte das Zertifikat nicht nur vorhanden, sondern aktiv dem Maildienst zugeordnet sein und den verwendeten Mail-Hostnamen vollständig abdecken.
MailPlus Server und DSM-Dienste prüfen
MailPlus Server muss installiert, aktiv und für den betroffenen Domainnamen eingerichtet sein. Wenn die Grundkonfiguration fehlt, nimmt das System keine eingehenden Nachrichten an, selbst wenn DNS und Ports stimmen. Prüfe daher die Domainzuordnung, die Mailboxen und die erlaubten Postfächer im Maildienst.
Auch DSM-seitige Einstellungen können Einfluss haben. Dazu gehören Zeit, Datum und Zeitzone, denn ein stark abweichender Systemzeitpunkt kann Zertifikatsprüfungen und Protokollabläufe stören. Eine falsche Uhrzeit fällt im Alltag oft erst dann auf, wenn Verbindungen mit TLS sauber verhandelt werden sollen.
Wenn du mehrere Mail-Dienste auf derselben Synology betrieben hast, ist eine saubere Abgrenzung wichtig. Alte Regeln, nicht mehr genutzte Ports oder verwaiste Konfigurationen können den neuen Dienst überlagern. In so einer Lage hilft es, die aktuell genutzte Domain und den aktiven Serverpfad einmal klar zu dokumentieren.
Saubere Prüfreihenfolge für die Fehlersuche
Die beste Reihenfolge beginnt außen und arbeitet sich nach innen. Zuerst prüfst du den MX-Eintrag der Domain, dann den A- oder AAAA-Eintrag des Mail-Hosts, danach die Erreichbarkeit von Port 25 und anschließend das zugeordnete Zertifikat. Erst wenn diese Punkte stimmen, lohnt sich der Blick in MailPlus selbst.
- MX-Ziel der Domain prüfen.
- Öffentliche IP des Mail-Hosts kontrollieren.
- Portweiterleitung und Firewall-Regeln testen.
- Zertifikat auf passenden Hostnamen prüfen.
- MailPlus-Domain und Dienststatus kontrollieren.
Diese Reihenfolge verhindert unnötige Änderungen an Benutzerkonten oder Mailboxen. Wer zuerst im Mailserver selbst sucht, übersieht leicht die eigentliche Ursache außerhalb des NAS.
Typische Sonderfälle im Alltag
Nach einem Providerwechsel stimmt oft die öffentliche IP nicht mehr, obwohl die Domain unverändert bleibt. Dann zeigt der MX-Eintrag noch auf den richtigen Namen, aber der A-Eintrag verweist auf eine alte Adresse. In diesem Fall kommen keine Nachrichten mehr an, bis die DNS-Werte aktualisiert sind.
Ein weiterer Sonderfall betrifft dynamische Anschlüsse. Wenn die öffentliche IP regelmäßig wechselt, muss der DNS-Eintrag zuverlässig nachgezogen werden. Geschieht das verzögert, sind Zustellprobleme nur zeitweise sichtbar und wirken dadurch schwer greifbar.
Auch ein Umzug auf einen neuen Router kann Portweiterleitungen zurücksetzen. Selbst wenn MailPlus auf der Synology unverändert bleibt, ist der externe Zugriff dann unterbrochen. Nach einem solchen Wechsel gehören die Freigaben immer wieder auf die Kontrollliste.
Wenn du zusätzlich Relaying, Weiterleitungen oder mehrere Domains nutzt, sollte jede Domain einzeln betrachtet werden. Ein korrekt funktionierender Hauptdomain-Eintrag sagt noch nichts über Alias-Domains oder zusätzliche Mailnamen aus.
Wann du vorsichtig mit Änderungen sein solltest
Bei produktiven Postfächern gilt besondere Zurückhaltung. Ein laufender Mailserver speichert Nachrichten, Zustellversuche und teils auch Warteschlangen, die bei vorschnellen Änderungen verloren gehen oder verzögert verarbeitet werden können. Deshalb ist es sinnvoll, vor größeren Umstellungen den Ist-Zustand festzuhalten.
Wenn bereits E-Mails auf dem Weg zum Server hängen, sollte die Ursache zuerst stabilisiert und nicht durch neue Tests überlagert werden. Mehrere schnelle Änderungen an DNS, Zertifikat und Portregeln machen die Analyse meist schwieriger. Besser ist es, eine Variable nach der anderen zu prüfen und erst danach den nächsten Schritt zu setzen.
Gerade bei Maildiensten ist eine saubere Dokumentation hilfreich: Welcher Hostname wird verwendet, welches Zertifikat ist aktiv, welcher Port ist offen und welche externe IP ist aktuell eingetragen. Mit diesen vier Angaben lässt sich die Ursache meist deutlich schneller eingrenzen.
Posteingang und Weiterleitung als erste Gegenprobe
Bevor tiefer an DNS oder Zertifikaten gearbeitet wird, lohnt sich ein Blick auf die Gegenseite der Zustellung. Viele Probleme sitzen nicht im Empfangen selbst, sondern in einer Regel, die Nachrichten abfängt, umleitet oder verwirft. Das betrifft Alias-Adressen, automatische Weiterleitungen, serverseitige Filter und externe Gateways ebenso wie ein versehentlich aktiviertes Antispam-Modul beim Provider. Eine Nachricht kann technisch sauber ankommen und trotzdem nicht im Zielpostfach sichtbar werden.
Auch lokale Regeln in Mailclients werden oft übersehen. Verschieben Filter neue Nachrichten direkt in einen Unterordner, markiert ein externer Client sie als gelesen oder sortiert eine Gruppenrichtlinie den Verkehr um, wirkt die Zustellung auf dem NAS fehlerhaft, obwohl die Mail bereits im Konto liegt. Darum ist es sinnvoll, das Postfach über mehrere Wege zu prüfen: in der Weboberfläche von MailPlus, über einen zweiten Client und zusätzlich über die Protokolle der Gegenstelle, sofern verfügbar.
- Serverseitige Regeln und Filter in MailPlus prüfen.
- Weiterleitungen und Alias-Ziele im externen System kontrollieren.
- Ordner wie Spam, Archiv und benutzerdefinierte Filterziele durchsuchen.
- Testmails mit eindeutigem Betreff und ohne Anhänge senden.
DNS-Metadaten jenseits von MX und A-Einträgen prüfen
Neben MX-, A- und AAAA-Einträgen spielen weitere DNS-Details eine Rolle, die bei der Annahme von Nachrichten zu Problemen führen können. Dazu gehören PTR-Einträge für den ausgehenden Server, saubere Forward- und Reverse-Auflösung im lokalen Netz sowie Konsistenz zwischen Hostname, Zertifikat und Mail-Dienst. Viele Empfänger bewerten eingehende Verbindungen strenger, sobald der Mailserver nicht eindeutig zu einem geprüften Namen passt. Das betrifft nicht nur den Versand, sondern indirekt auch Rückmeldungen und Zustellprotokolle, die bei der Analyse helfen.
Besonders wichtig ist die Frage, ob derselbe Name von außen und innen korrekt aufgelöst wird. Weicht die interne Namensauflösung von der öffentlichen ab, können Clients und Dienste unterschiedliche Ziele verwenden. Das erschwert die Fehlersuche, weil ein Test über das Heimnetz erfolgreich sein kann, während externe Zusteller ein anderes Verhalten sehen. Sinnvoll ist daher ein Abgleich aller beteiligten Namen: Maildomain, Hostname des NAS, Zertifikatsname und eventuell genutzte Alias-Namen.
- MX-Ziel und zugehörige A- oder AAAA-Adresse vergleichen.
- PTR-Eintrag der öffentlichen IP kontrollieren, sofern ein eigener Mailserver beteiligt ist.
- Interne und externe Namensauflösung getrennt testen.
- Subdomains wie mail.example.tld und example.tld auf Gleichlauf prüfen.
Verbindungsaufbau aus Sicht des Gegenübers nachvollziehen
Ein sauberer Zustellpfad endet nicht am offenen Port. Erst das Zusammenspiel aus Banner, TLS-Handshake, erlaubtem Cipher-Set und Serverantwort entscheidet darüber, ob externe Systeme die Verbindung akzeptieren. Manche Gateways brechen ab, sobald der vorgestellte Servername nicht zum Zertifikat passt oder die TLS-Aushandlung zu alt wirkt. Andere nehmen Verbindungen an, liefern aber bei späteren SMTP-Befehlen Fehlermeldungen zurück, die in der MailPlus-Oberfläche nur indirekt sichtbar werden.
Deshalb ist es hilfreich, die Verbindung aus Sicht eines externen Absenders zu betrachten. Ein kurzer Test mit Telnet oder einem SMTP-Testwerkzeug zeigt, ob der Dienst auf Port 25 überhaupt antwortet. Ein separater TLS-Check prüft, ob der Zertifikatsname und die Kette stimmen. Wer zusätzlich die Meldungen im Mail-Log liest, erkennt schnell, ob der Fehler vor der Annahme, während der Authentifizierung oder erst beim Zustellversuch im internen Postfach auftritt.
- Erreichbarkeit von Port 25, 465 oder 587 von außen testen.
- SMTP-Banner und Servername vergleichen.
- TLS-Zertifikat auf Gültigkeit und vollständige Kette prüfen.
- Logeinträge zum Zeitpunkt des Tests mitlesen.
Mailbox- und Kontokonfiguration sauber abgleichen
Selbst bei korrekter Netzwerkkonfiguration kann die Zustellung scheitern, wenn das Zielpostfach nicht passend eingerichtet ist. Dazu zählen deaktivierte Konten, volle Postfächer, falsche Quoten, versehentlich eingeschränkte Berechtigungen oder ein nicht sauber angelegter Benutzer. In Gruppenumgebungen treten außerdem Probleme auf, wenn ein Konto zwar als Adresse existiert, das zugehörige Postfach aber nicht vollständig bereitgestellt wurde. Dann werden Nachrichten angenommen, aber nicht dort abgelegt, wo sie erwartet werden.
Auch die Zuordnung von Aliasen und Sammeladressen verdient Aufmerksamkeit. Wird eine Adresse an mehrere Ziele verteilt, kann eine Mail je nach Regelwerk an einer anderen Stelle landen oder durch Konflikte ganz blockiert werden. Bei mehreren Domains im selben System sollte jedes Konto eindeutig einer primären Adresse zugeordnet sein. Das reduziert Verwechslungen bei der Zustellung und erleichtert die Analyse im Log, weil sich die Zieladresse klar zuordnen lässt.
- Kontostatus und Speicherquoten im Benutzerbereich prüfen.
- Alias-Adressen und Sammelpostfächer auf Überschneidungen testen.
- Neue Testnutzer mit minimaler Konfiguration anlegen.
- Prüfen, ob die betroffene Adresse im richtigen Mandanten oder Teamraum liegt.
FAQ
Warum kommen trotz aktiver Domain keine Nachrichten an?
Oft liegt die Ursache nicht an der Domain selbst, sondern an der Zustellungskette davor. Entscheidend ist, ob der MX-Eintrag auf den richtigen Host zeigt und ob dieser Host von außen erreichbar ist.
Woran erkenne ich, ob der MX-Eintrag passt?
Der MX-Eintrag muss auf den Namen verweisen, unter dem der Mailserver aus dem Internet angesprochen wird. Weicht der Zielname vom tatsächlichen Hostnamen ab, landen Verbindungen schnell am falschen Ziel oder werden abgewiesen.
Warum ist der DNS-Resolver des Mailservers wichtig?
Der Server muss externe Namen zuverlässig auflösen können, damit er fremde MX-, A- und AAAA-Einträge korrekt findet. Falsche Resolver oder interne DNS-Ausnahmen führen dazu, dass Zustellungen hängen bleiben oder gar nicht erst aufgebaut werden.
Welche Rolle spielt Port 25 bei eingehenden Nachrichten?
Port 25 ist für den Server-zu-Server-Verkehr entscheidend. Ist dieser Port blockiert, erreichen fremde Mailserver das System nicht, auch wenn die Weboberfläche und andere Dienste einwandfrei laufen.
Reicht eine Weiterleitung im Router aus?
Nur dann, wenn sie auf die richtige interne Adresse zeigt und keine zweite Firewall den Verkehr erneut filtert. Zusätzlich muss das Zielgerät eine feste IP besitzen, damit die Regel nicht auf ein wechselndes Ziel zeigt.
Warum scheitert die Annahme trotz geöffnetem Port?
Häufig blockiert die DSM-Firewall, der Provider oder ein vorgeschalteter Sicherheitsdienst die Verbindung. In manchen Netzen ist eingehend nur eine begrenzte Auswahl an Ports erlaubt, sodass die Weiterleitung allein nicht genügt.
Wozu dient das Zertifikat bei eingehenden Verbindungen?
Für reine Annahme ist ein Zertifikat nicht immer zwingend, doch es spielt eine große Rolle bei TLS-gesicherten Verbindungen und beim sauberen Handshake. Passt der Zertifikatsname nicht zum verwendeten Hostnamen, brechen Gegenstellen die Verbindung unter Umständen ab.
Kann ein falscher Hostname die Zustellung verhindern?
Ja, besonders dann, wenn der Mailserver sich mit einem Namen meldet, der nicht zum Zertifikat oder zum öffentlichen DNS passt. Viele Gegenstellen werten solche Abweichungen als Hinweis auf ein unsauberes Ziel und senden die Nachricht nicht weiter.
Was sollte ich nach Änderungen zuerst prüfen?
Nach jeder Anpassung lohnt sich ein Blick auf DNS-Auflösung, Erreichbarkeit von außen und die Protokolle des Mailservers. So lässt sich schnell erkennen, ob die Ursache bei der Namensauflösung, der Netzfreigabe oder beim TLS-Aushandeln liegt.
Welche Hinweise liefern die Protokolle?
Die Logeinträge zeigen oft, ob Verbindungen gar nicht ankommen, abgelehnt werden oder während der Aushandlung abbrechen. Zeitstempel, Gegenstellen und Fehlermeldungen helfen dabei, den fehlerhaften Abschnitt der Kette einzugrenzen.
Fazit
Für einen störungsfreien Empfang müssen DNS, Portfreigaben und Zertifikate als zusammenhängendes System betrachtet werden. Wer die Zustellkette in dieser Reihenfolge prüft, findet die Ursache meist schneller als mit einzelnen Schnelltests. Sobald Name, Erreichbarkeit und Verschlüsselung zusammenpassen, läuft die Annahme in der Regel stabil.