Webhosting / E-Mails über Externe Domain empfangen

  • Das Problem wurde hier schon mehrfach beschrieben, trotzdem rätsele ich, was da vor sich geht und würde mich freuen, wenn es mir jemand erklären und vielleicht einen Tipp geben kann.

    Ich habe in einen Netcup-Webhosting-Tarif mehrere Domains als "Externe Domain" eingebunden, die derzeit noch bei einem anderen Provider liegen, wobei die Nameserver auf Cloudflare verweisen. Die Website läuft bei wieder einem anderen Provider.

    Nachdem ich eine Externe Domain validiert und bei Netcup einem Webhosting-Tarif zugewiesen habe, konnte ich E-Mail-Adressen für diese Domain anlegen und Webmail aktivieren.

    Nun habe ich bei Cloudflare bei der betreffenden Domain den MX-Record auf den von Netcup für mein Webhosting vorgegebenen Server geändert (mxXecX.netcup.net.)

    Das Ergebnis:

    - ich kann mich per IMAP in die neuen Mail-Konten einwählen und auch E-Mails verschicken

    - Wenn Mails ankommen, erhalten Sie allerdings vom Netcup-Mailserver die Antwort zurück:

    Code
    Action: failed
    Status: 5.7.1
    Remote-MTA: dns; mxXecX.netcup.net. (XXXX, the server for the domain XXX.de.)
    Diagnostic-Code: smtp; 554 5.7.1 <XXX@XXX.de>: Relay access denied

    "Relay access denied" - dazu hat man hier schon einiges gehört.

    - Es wurde empfohlen, doch mal über SMTP mal eine Mail zu verschicken - habe ich gemacht

    - Es wurde dringend angeraten, andere MX-Einträge mit niedrigerer Priorität (also höherem Priority-Wert) zu löschen - habe ich auch gemacht, wobei mir der Sinn nicht klar ist

    Und dann habe ich es für verschiedene Domains ausprobiert, alle mit demgleichen Setup (externer Provider, Nameserver:Cloudflare, als externe Domain importiert, validiert, Mail-Postfächer angelegt). Bei verschiedenen Tests dauerte es zwischen 60 und 120 Minuten, bis die Mails, teils noch etwas wackelig, ankommen.

    Und dann habe ich die große Umstellung für die eine, wichtige Domain gemacht, und nach 190 Minuten abgebrochen. Denn hier hat es nicht geklappt. Es entsteht einfach ein Schaden, denn jeder, der in dieser Zeit eine E-Mail schickt, bekommt die besagte Fehlermeldung zurück ("Relay access denied"). Nach 3 Minuten kamen wieder alle Mails beim alten Provider an, wie wenn nie etwas gewesen wäre.

    Ich würde gerne verstehen, was da das Problem ist und warum der Netcup-Mailserver sich so verhält, wie er sich verhält.

    An der DNS-Propagierung kann es meiner Ansicht nach nicht liegen (TTL war Tage vorher auf 1 verändert worden). Und außerdem antwortet ja auch fast sofort der Netcup-Server. Nur, warum frägt er selbst nochmal die MX-Records ab und verweigert die Annahme, wenn es noch einen anderen (Backup)-MX gibt?

    Wie kann man so eine Umstellung vornehmen, dass im Idealfall keine Mail verloren geht?

    Und dann noch zum Thema Webmail: Das klappt sowieso nicht, obwohl aktiviert. "Verbindung zum Speicherserver fehlgeschlagen" kommt da immer. Hat es etwas mit Cloudflare zu tun?

  • Du musst für die Subdomain „mail“ den Cloudflare-Proxy deaktivieren, der zumindest in der kostenlosen Variante kein IMAP / SMTP beherrscht. Das sollte in jedem Fall das Problem beheben, dass du den Webmailer nicht mehr nutzen kannst, der verwendet nämlich mail.deinedomain.tld zum IMAP-Verbindungsaufbau.

    Die netcup-Mailserver prüfen regelmäßig, ob die Domain korrekt mit allen MX-Einträgen auf die IP des Mailservers zeigt. Ist das nicht der Fall, wird die Mail mit „Relay access denied“ abgelehnt. Bei einer DNS-Änderung gibt es hier natürlich eine gewisse Latenz. Aber somit würde auch das dein Problem erklären können.

    Edit:

    Nur, warum frägt er selbst nochmal die MX-Records ab und verweigert die Annahme, wenn es noch einen anderen (Backup)-MX gibt?

    Den darf es definitiv nicht geben, das wird nicht unterstützt. Alle MX-Einträge der Domain dürfen ausschließlich auf den Mailserver von netcup zeigen.

    Einmal editiert, zuletzt von sudo (27. Dezember 2025 um 09:58)

  • Du musst für die Subdomain „mail“ den Cloudflare-Proxy deaktivieren, der zumindest in der kostenlosen Variante kein IMAP / SMTP beherrscht. Das sollte in jedem Fall das Problem beheben, dass du den Webmailer nicht mehr nutzen kannst

    Vielen Dank, das hat das eine Problem "Webmail-Zugang" tatsächlich behoben.

    Zitat

    Die netcup-Mailserver prüfen regelmäßig, ob die Domain korrekt mit allen MX-Einträgen auf die IP des Mailservers zeigt. Ist das nicht der Fall, wird die Mail mit „Relay access denied“ abgelehnt


    Was mich dazu noch interessieren würde, ob es Tipps gibt, wie man die Latenz verringern kann.

    Zugegeben verhält sich ein anderer großer Provider auch so ähnlich, allerdings ist hier stets nach ca 30 bis 40 Minuten (ich habe es mehrfach getestet) die Umstellung durch und die Mails werden akzeptiert.

    Bei Netcup hat es in einem besonders glücklichen Fall 60 Minuten gedauert, in allen anderen aber eher 1,5 bis 2 Stunden. Und wie gesagt habe ich einmal (nachts) nach über 3 Stunden abgebrochen.

    Gibt es da Erfahrungswerte, ob es zu bestimmten Tageszeiten vielleicht schneller geht?

    Da nachts über Stunden nichts passiert ist, drängt sich der Verdacht auf, ob so etwas womöglich manuell angestoßen wird?

    Diese Frage ist für mich relevant, weil man natürlich eine ideale Tageszeit für die Umstellung wählen will, damit wenig E-Mails verloren gehen.

    Zitat

    Den darf es definitiv nicht geben, das wird nicht unterstützt


    Naja, "nicht unterstützt" ist aus meiner Sicht nicht so ganz der richtige Ausdruck. Es ist ja vielmehr so, dass irgendwo bei Netcup ganz bewusst geprüft wird, dass der Kunde auf gar keinen Fall in den MX-Records einen Backup definieren darf für den Fall, dass Netcup selbst sich verabschiedet. Das machen andere Provider definitiv nicht so und ich verstehe auch nicht, worin der Sinn liegt.

    In meiner Idealvorstellung würde es gerade bei einer Umstellung großen Sinn machen, dass man den alten Provider noch mit niedrigerer Priorität (also höherem Wert) in den MX-Records belässt, und dann kommen halt die Mails, wenn etwas nicht klappt, in der einen Box an, die anderen bei Netcup.

    Stattdessen läuft die Propagierung weltweit sehr schnell in 3 Minuten durch, und dann erklärt sich Netcup für zuständig, aber verschickt für 2 Stunden Fehlermeldungen. Das finde ich schade. Wenn noch jemand einen Tipp hat, wie man das optimieren kann, würde ich mich sehr freuen.

  • Noch ein Nachtrag: Offensichtlich gibt es keine bestimmte "Mindestwartezeit", die man nach einer Umstellung der MX-Records abwarten muss, bis Mails durchgestellt werden, sondern es gibt vermutlich so eine Art internen Systemdurchlauf bei Netcup, der in bestimmten Abständen gemacht wird.

    Wohlgemerkt: Es geht nicht um die Propagierung des MX-Records beim sendenden Provider (die dauert 0-5 Minuten), sondern um den Zeitraum, bis Netcup selbst gewillt ist, die Mails anzunehmen und nicht mehr mit einer Fehlermeldung zu beantworten.

    Ich habe eben bei Domain A gegen 12:30 Uhr den MX-Record auf Netcup gestellt. Der sendende Provider hat nach etwa einer Minute Netcup angesprochen, aber von dort kamen dann konstant bis ca. 14:25 Uhr Fehlermeldungen. Danach lief es, also nach 115 Minuten.

    Bei Domain B - mit absolut identischem Setup in jeglicher Hinsicht - gegen 14:15 Uhr die MX-Records auf Netcup gestellt und hier kam ebenfalls um 14:25 Uhr die erste Mail durch, also schon nach 10 Minuten.

    Die Frage ist nun, ob man diesen "Update"-Zeitpunkt irgendwie vorhersagen, vorhersehen oder beeinflussen kann... Und ob das rund um die Uhr stattfindet?