E-Mailzustellung nicht möglich, da falscher MX-Record verwendet wird

1. offizieller Beitrag

    Hallo zusammen,


    nach dem nun diverse Recherchen, Telefonaten und E-Mailverkehr mit dem ISP nicht geholfen haben, hier mein Problemstellung, mit der Hoffnung das jemand weiter weiß.


    Im Einsatz Exchange Server 2007 mit SP3. Kein Smarthost. MX-Datensätze werden zum Weiterleiten von E-Mails verwendet.


    Beim Versuch eine E-Mail an eine bestimmte Domain zu senden, erhalten die Benutzer von unserem Mailserver eine NDR mit dem Hinweis:"#554 Sorry, no mailbox here by that name. ".
    Okay, deutet darauf hin, dass die Mailbox des Empfänger nicht existiert. Jedoch existiert die Empfänger-Domain und auch das Postfach.
    Eine Zustellung von E-Mails über einen externen Server(web.de, gmail.com, etc....) funktioniert.


    Jetzt hat sich nach diversen Recherchen und Tests herausgestellt, dass die Empfänger-Domain drei MX-Einträge mit den Pref-Werten 10, 20 und 30 besitzt.


    Trotz eines DNS-Flush auf den internen AD-Controllern und unserem Mailserver, versucht dieser die E-Mails immer an den MX-Record mit dem Wert 30 zu senden.
    Dieser MX-Record jedoch verweist nicht auf die anderen MX-Einträge bzw. leitet diese nicht weiter. Er nimmt die E-Mail an, prüft ob das Postfach existiert, was ja nicht der Fall ist
    und teilt unserem Mailserver die 554 Meldung mit.


    Wie bringe ich nun meinen Mailserver dazu, nicht den MX-Record mit dem Pref-Wert von 30 zu verwenden? Kann ich evtl. feststellen, welche Hops meine Nachricht nimmt? Vielleicht leitet die Telekom das Ganze falsch weiter? ?(



    Grüße

    • Offizieller Beitrag

    Moin,


    auf den 1ten Blick und wenn das korrekt ist, dann hat der Empfänger ein Problem.


    Welche MX mit welcher Reihenfolge existieren zeigt dir mxtoolbox.com - mx sind nicht geheim, wäre ja auch quatsch.


    Du könntest für das senden einen externen DNS verwenden, ich überlege gerade, wie das bei 2007 war.


    Ja kannst du, dafür verwendet man Tracert oder die gui-variante


    ;)

    Hallo Norbert,


    die MX-Einträge wurden schon durch den ISP und bei mxtoolbox.com geprüft. Das passt soweit alles.
    Es steht die Aussage im Raum, dass unsere Mailserver ein falsches Routing hat, noch was im Cache hat und dadurch die Nachrichten auf den MX-Record mit dem höchsten Wert verweist und sendet.
    Dies kann ich leider nicht nachvollziehen. Der DNS-Cache ist geleert und per nslookup bekomme ich die MX-Einträge richtig angezeigt.


    Mit Tracert kann ich zwar die Route und die Hops zur Zieldomain feststellen, jedoch wüsste ich nicht, dass ich ein Tracert bzgl. Mailversand machen kann, um zu sehen, welche Hops beim E-Mailversand verwendet werden bzw. welchen Weg meine E-Mail geht und welcher Hop quasi an den falschen MX-Eintrag sendet.


    Grüße

    • Offizieller Beitrag

    Moin,


    fasse ich das richtig zusammen:


    Die Empfänger-Domäne hat drei eingetragen MX:
    MX1 -> Prio 10
    MX2 -> Prio 20
    MX3 -> Prio 30


    Hinter jedem hängt nur ein A-Eintrag (das ist wichtig)?


    Und nur der MX3 nimmt die Mails nicht an?


    Das wäre dann eine Fehlkonfiguration beim Empfänger. Es gibt keine Pflicht, die MX in der Reihenfolge der Prios zu durchlaufen. Es wird empfohlen, aber es gibt diverse Mail-Software, die das ignoriert und einfach einen aus der Liste wählt.


    Das ist dann auch ein gutes Beispiel, wie man Backup-MX nicht konfigurieren darf.


    Exchange hälte sich zwar an die korrekte Reihenfolge, merkt sich aber, wenn ein MX nicht geantwortet hat. Es kann also sein, dass MX1 und MX2 mal nicht (schnell genug) reagiert haben und Exchange daher MX3 nimmt. Diese Fehler hier führt NICHT dazu, dass ein andere MX genommen wird.


    IMHO kann man den "Speicher" beim Exchange leeren, wenn man den Transport-Dienst neustartet.


    Ach ja: Und unbedingt auch prüfen, dass in der Kette der Namensauflösung kein Fehler ist.

    Hallo Norbert,


    in der Zwischenzeit wurde der Pref-Wert geändert.


    Was die MX-Einträge angeht, mach ich da kein Geheimnis draus.


    Es wir versucht eine E-Mail an die unten aufgeführte Domain zu senden. Der MX-Eintrag mit dem Pref-Wert 15, hatte vorher den Wert von 30.




    DNS Lookup für den MX-Eintrag mit dem Pref-Wert 10 ergibt:



    DNS Lookup für den MX-Eintrag mit dem Pref-Wert 15 ergibt:



    DNS Lookup für den MX-Eintrag mit dem Pref-Wert 20 ergibt:




    DNS-Cache auf den AD-Controllern und Mailserver wurden gelöscht.


    nslookup mit type=mx ergeben unterschiedliche Ergebnisse, wenn man die Abfrage wiederholt:





    Beim Versuch eine Mail an ein Postfach zu senden, generiert unser Mailserver ein NDR mit folgendem Hinweis.




    Der ISP sagt, unser Mailserver versucht die E-Mail an den MX-Eintrag mit dem Pref-Wert 15(vorher 30) zu senden.
    Dies wäre Ihr Server, welcher wiederum die Postfächer nicht kennt und dadurch die Zustellung nicht möglich sei.


    Grüße

    • Offizieller Beitrag

    Moin,


    ich sehe das wie Robert - die Suedwestbank oder deren Hoster hat einen Fehler bei den MX-Records.


    Die Prio 10 und 20 landen ja bei dem gleich Server / Cluster


    Die Prio 15 landet aus meiner Sicht beim Provider und er MX hat da nichts verloren - aber das muss die Suedwestbank klären, nicht du.


    Hast du eine Telefon-Nummer von deren IT? Denn die müssen dem Hoster auf die Füße treten.


    Die Reihenfolge hat Robert ja geschildert.


    ;)

    • Offizieller Beitrag

    Moin,


    suedwestbank ist bei DomainFactory und nutzt auch die DomainFactory Nameserver.


    Irgendjemand hat bei der Mailumstellung von DomainFactory auf Symantec (=Messagelabs) vergessen, den Default Eintrag zu löschen. Ich sehe den Fehler im Kundenmenü quasi vor mir, da ich das dF Kundenmenü gut kennt.


    Die unterschiedlichen Ergebnisse in NSLOOKUP rühren von Round Robin der A-Einträge her. Sollte man eigentlich nicht nutzen bei Mailserver, da es zu vielen lustigen Seiteneffekten führen kann (Verzögerungen und Rückläufer sind dabei üblich). Aber na ja..... Ist halt Symantec, die haben noch nie mit viel Kompetenz überzeugt.

    Hallo,


    zur Info: der MX-Record auf Seitens des Providers wurde gelöscht und nun gehen die E-Mails wieder durch.


    Danke für die Hilfe.