externe Domain: E-Mail-Empfang geht nicht

Wenn ich es richtig im kopf habe, wird alle X Stunden überprüft ob der MX auf das Webhosting Paket zeigt.

Wie lange ist das setzen des MX her?

Moin Bud,

du kannst bei Plesk den Empfang von Mails deaktivieren, schau da mal rein.

Email -> Email Einstellungen, Domain wählen -> Services aktivieren / deaktivieren.

Bildschirmfoto 2025-04-24 um 21.55.04.png

Zitat von Bud

ca. 1. Woche - hatte da einen ähnlichen Gedanken und wollte dann erstmal 48h warten, bin aber jetzt erst wieder dazu gekommen.

ok das ist lang genug 😅

Tippfehler beim MX hast du wahrscheinlich geprüft?

Bei den ganzen Produkten die du hier hast, könnte man den Überblick verlieren 😜

Ich hatte ein ähnliches Problem da lag es daran dass beim MX Record hinten bei der Domain mein „.“ hingelegt war.

Beispiel aus dem Ticket:

In euren DNS Einstellungen ist folgendes hinterlegt im CPP
mxe962.netcup.net

Bei meinem Domainanbieter musste ich dort aber mit einem Punkt hinten versehen.
also mxe962.netcup.net.

Bei den DNS-Einträgen, in denen ein FQDN angegeben wird, ist am Ende ein Punkt anzuhängen. Hierdurch wird verhindert, dass die Domain angehangen wird.

Bud: Ich sehe da eine Inkonsistenz zwischen autoconfig und cloud (das Letzteres sollte falsch sein).

Bud: Ausschlaggebend ist immer, "was 'rauskommt" – Ein "dig +short -t CNAME autoconfig.example.org" sollte dasselbe Ergebnis liefern wie ein "dig +short -t CNAME cloud.example.org", und zwar immer mit einem abschließenden Punkt (auch für MX). Eine Browser-Eingabemaske sollte diese Korrekturen ggf. automatisch vornehmen (allerdings würde ich erwarten, dass dann auch eine Vereinheitlichung in der Eingabemaske stattfindet).

EDIT: "Von wem ist es abhängig, ob ein . folgen muss oder nicht?" – das ist softwarespezifisch (siehe hier).

wer ist nochmal DH?

Zitat von Olivetti

wer ist nochmal DH?

Dreamhost aber ich könnte mich auch irren, wäre nicht das erste mal.

Zitat von Bud

Aber woher soll die Browser-Eingabemaske wissen, ob ein . hinten ran kommt, oder nicht? Durch einen im Hintergrund durchgeführten dig?

Die Browser-Eingabemaske ist ja den Netcup-eigenen DNS-Servern vorgeschaltet, also muss (/sollte) sie validieren/liefern, was diese Server bzw. andere Netcup-eigene Systeme wollen/verarbeiten können. Bei einer ccTLD ("Country code top-level domain") auf der rechten Seite findet offensichtlich vor der Veröffentlichung/Auslieferung eine Prüfung/Vereinheitlichung statt (vgl. "dig"-Ausgabe – mit "+short +unknownformat" sieht man hier die "Rohdaten" der Antwort).

(Die linke Seite in der Netcup-Eingabemaske wird bei Auslieferung generell um die zugehörige Domäne ergänzt, sofern sich kein Alias "*"/"@" findet.)

Zitat von Bud

Demnach braucht die Nextcloud vom roten H die Zone dahinter nicht, bzw. will sie nicht, netcup möchte sie aber bei der autoconfig mit dabei haben? Weil die dahinterliegende Software das wsl. wünscht?

"Zone" bezieht sich oben auf den abschließenden Punkt, nehme ich an (unter "Zone" versteht man aber eine Konfigurationsdatei).

Nextcloud als PHP-Anwendung liefert mit und ohne abschließenden Punkt dasselbe Ergebnis für dns_get_record("example.org[.]"); – analog sollte das jeder anderen Anwendung wie beispielsweise einem Browser normalerweise auch egal sein für ccTLD-Abfragen (wenn diese im Fall von CNAME-Einträgen nicht sowieso für die Auflösung an die jeweiligen DNS-Server delegiert werden), schon deshalb, weil bei ccTLD die entsprechenden Antworten durch die zugrundeliegenden Bibliotheken vereinheitlicht werden.

Wo es nicht egal ist, und darauf bezog sich das vorgenannte "softwarespezifisch" – vielleicht etwas zu generisch formuliert, sorry – sind DNS-spezifische Konfigurationen (wo man insbesondere die Auflösung/Interpretation von nicht-ccTLD vollumfänglich selbst steuert), vgl. "man resolv.conf".

wusste ich nicht dass ich auch example.com. eingeben kann und es funktioniert.

Also als ich diesen wildcard lets encrypt bestellt hatte (den ich ja garnicht brauchte) da hab ich ja auch diesen abchliessenden punkt eingegeben aber das war falsch (acme-challenge. ) und dann hab ich 1 stunde lang 8.8.8.8 gefragt ob was zu sehen ist bis ich darauf gekommen bin dass der punkt weg muss und dann ging es. Hätten die in dem popup (acme-challenge). gezeigt statt acme-challenge. dann wär mir das nicht passiert.

/r wie kann der das fett drucken statt in klammern zu setzen? /r - oder fett drucken und dahinter in klammern (aber ohne den punkt da am Ende) ... how hard can it be?

Zitat von Bud

Also ist es irrelevant, ob der . da ist, oder nicht?

Irrelevant, aber laut Bildschirmfoto inkonsistent.

Zur ursprünglichen Problemstellung – Frage: Kann es sein, dass der MX-Eintrag auf den falschen Netcup-Hostnamen verweist?

Theoretisch kann man sich unterschiedliche Verhalten vorstellen, welche beim Versand und beim Empfang von E-Mails an Domänen mit mehreren MX-Einträgen zutage treten.

Ich würde testweise die Gültigkeitsdauer der Einträge minimieren (um Tests zu beschleunigen), sicherstellen, dass die lokalen DNS-Caches "sauber" sind und die Tests wiederholen, nachdem jeweils nur einer der beiden MX-Einträge im DNS steht. (Unabhängig davon, ob es mit anderen Domänen/Webhostings funktioniert oder nicht).

Hier - ich hab das Orakel gefragt - nicht in der Hoffnung dass es recht hat sondern das beim Durchlesen vielleicht etwas einfällt/auffällt das Dich weiterbringt:

Thought for 3m 50s

What “554 5.7.1 Relay access denied” actually means

The host that received the SMTP connection ( mail.<your-domain> ) does not believe it is responsible for the domain that appears after RCPT TO:. In other words, an outside server reached a machine that thinks the message is “relay” traffic instead of local mail and therefore rejects it.

That can only happen when DNS or the Plesk mail configuration is still pointing somewhere else (often an old server or the wrong IP/IPv6).

1 Check your public DNS first

Run the following from any terminal that has dig or use an online tool such as mxtoolbox.com → “DNS Lookup”:

dig +short MX yourdomain.tld

dig +short A mail.yourdomain.tld

dig +short AAAA mail.yourdomain.tld

The MX with the lowest priority (in your zone that’s priority 10) should be mail.yourdomain.tld.

mail.yourdomain.tld must resolve to the IPv4 and IPv6 that netcup shows for your web-hosting package (WCP → Hosting & Domains → Web-Hosting Access).

Most “moved-from-oldhost” cases break right here:

Where it goes wrong Symptom Fix

mail A-record still points to oldhost All providers bounce Change A-record to the new IP

You deleted A but forgot AAAA Only IPv6-capable senders (Gmail, Microsoft, etc.) bounce

Delete the old AAAA record or add the correct one

You left the MX pointing to oldhosts server (e.g. mx**.oldhost.net) Bounce from everywhere Replace by mail.<domain> / mx1.netcup.net, TTL 3600

After you correct a record you have to wait for its TTL (in your zone: 1 hour) for world-wide propagation.

2 Make sure Plesk will actually accept the mail

Even when DNS is fine, Postfix can still refuse mail if the domain is not in its internal maps.

Plesk → Websites & Domains → Mail Settings

“Activate mail service on this domain” must be ticked.

“Switch off the mail service and use external mail” must not be selected.

Tools & Settings → Mail Server Settings

Relay must be “closed” (default).

If you recently imported the domain, click “Rebuild Configuration Files” or, with shell access, run

plesk repair mail -y

On many Plesk servers that single command alone fixes the relay access denied issue.

Create at least one mailbox (or an alias that forwards someplace else) so there is a valid recipient.

3 Test again

nc -vz mail.yourdomain.tld 25

You should now see a banner like:

220 mail.yourdomain.tld ESMTP Postfix (Plesk)

Then try an SMTP session (manual or with a test-tool):

EHLO tester

MAIL FROM:<me@example.net>

RCPT TO:<youruser@yourdomain.tld>

250 OK at RCPT TO → everything is fixed.

550 5.1.1 user unknown → domain is now accepted, you just need to create that mailbox.

Still 554 5.7.1 relay access denied → double-check DNS (especially AAAA) and that the domain actually appears in Plesk → Mail.

Quick checklist

dig +trace MX yourdomain ends in mail.yourdomain.tld. or mx1.netcup.net.

A and (if you publish one) AAAA for mail. are the new netcup IPs.

Port 25 on that IP answers with your own server banner.

Mail service is enabled for the domain inside Plesk.

plesk repair mail shows no errors.

Once those five ticks are green, outside mail starts flowing within the TTL. Good luck—post back if one of the steps still gives trouble!