Ein CNAME Eintrag ist unter Root ("@") nicht erlaubt. Es muss dann schon ein A (oder auch AAAA) Eintrag sein.
Wenn du die DNS Server von Netlify verwendest, musst du dort die Einträge für den Netcup-Mailserver erstellen (MX, usw.).
Ich würde vorschlagen, dass du bei den netcup DNS-Servern bleibst und dort einfach für "*" und "@" die IP von Netlify einträgst.
Wie du schon richtig zusammengefasst hast, ist Netlify in allen Fällen für das SSL-Zertifikat zuständig.
Ich schätze mal, dass du dich 1:1 an die Anleitung gehalten hast. Denn dort wird angegeben, dass man "Kein SSL" auswählen soll. Ich denke das könnte ganz vielleicht der Grund sein, warum TLS nicht funktioniert. 
mx2e30.netcup.net und mail.fpr-hamburg.de meine ich. Ich schätze mal, dass du möchtest, dass nur MS für die Mails zuständig sein soll. Aktuell kann es in Ausnahmefällen passieren, dass Mails auch mal an den netcup Mailserver zugestellt werden und nicht an MS.
Die anderen Einträgen sollten natürlich gelöscht werden: https://mxtoolbox.com/SuperTool.aspx…afpr-hamburg.de
Besitzt du bei netcup ein Webhostingpaket? Wenn ja, geht der Weg mit der Frame-Weiterleitung so: WCP -> Domain -> Hosting Settings -> Hosting Type [Change] -> Forwarding -> Frame forwarding
Hab's auch nochmal mit einem Webhosting "EiWoMiSau" getestet. Ich kann von da aus problemlos eine Verbindung zu einer Datenbank bei einem anderen Hoster aufbauen.
Für reines Weiterleiten benutze ich immer gerne mailgun.
So, mittlerweile habe ich eine sehr ausführliche Antwort vom Support erhalten:
wie vom Kollegen angefordert benötigen wir einen MTR der Hin- und Rückroute welche uns die Routen zum Fehlerzeitpunkt aufzeigen um hier irgendeinen Rückschluss ziehen zu können. Alle derzeit uns vorliegenden Routenabfolgen sind zu Zeitpunkten erstellt wo keine Störung vorlag.
Wir können bislang keine Störung auf der Route von uns in Richtung ntppool feststellen. Es bleibt somit nur die Möglichkeit der Rückroute offen.
Wir Announcen unsere Netze an alle unsere Peers gleich, zudem gab es keinerlei Engpässe auf unseren Transit oder Peering links. somit sind alle Punkte auf die wir direkten Einfluss haben bereits geprüft und wir können zusichern, dass derzeit keine Fehlfunktion in unserem Verantwortungsbereich vorliegt.
Für eine Funktionierende Verbindung spielen viele Netzbetreiber eine Rolle, gerade für Verbindungen die einmal um die halbe Welt gehen. Dort kann zwischendrin bei einem einzelnen Carrier oder Leitungsprovider eine Störung oder ein Engpass auftreten. um das zu identifizieren, wird aber ein MTR der Rückroute vom Fehlerzeitpunkt benötigt. Nur so können wir feststellen an welchem Punkt es zum Paketverlust kommt. Alles ändere wäre eine Suche nach einer Nadel in einem Heuhaufen so groß wie der Mount Everest, mit verbundenen Augen.
wir können nur unsere eigenen Netzwerkkomponenten prüfen. Alles was Außerhalb unseres Netzwerks liegt, liegt weitestgehend außerhalb unseres Einflussbereiches.
Ich kann daher nur nochmal die Bitte meines Kollegen nach aussagekräftigen MTR Verfolgungen der Rückroute vom ntppool zu uns wiederholen. Andernfalls haben wir hier keinerlei handhabe etwas zu bewirken, da wir alles uns mögliche bereits ausgeschöpft haben. Der Fehler wird irgendwo auf seitens ntppool oder auf deren Verbindung zu uns auftreten.
Wir scheinen aber nicht ganz alleine mit unserem Problem zu sein: https://community.ntppool.org/t/monitoring-s…tp-servers/1261
Falls trotzdem jemand Lust und Zeit hat nochmal die Admins vom NTP-Pool zu kontaktieren: server-owner-help@ntppool.org
Statt "my-nutri-diary.de" musst du "@" eingeben. "@" steht für die Root Domain (also "my-nutri-diary.de"). Was du angelegt hast ist "my-nutri-diary.de.my-nutri-diary.de"
Jetzt bekomme ich schon keine Antworten mehr vom Support. Habt ihr mal Kontakt zum Support aufgenommen? Gestern war ja wieder mal ein Tief in den Statistiken zu verzeichnen.
Oder vielleicht kann [netcup] Felix P. sich mal einschalten. Keine Antworten mehr zu bekommen finde ich nicht nämlich nicht sehr kundenfreundlich.
Mittlerweile habe ich leider gar keinen Erfolg mehr beim delisting. Angeblich wird meine IP gar nicht geblockt:
As stated previously, I do not see anything offhand that would be preventing your mail from reaching our customers for the following IP (xxx.xxx.xxx.xxx).
Bekomme darauf auch keine Antworten mehr von dem sch*** Verein. 
Aber damit nimmt man sich die Möglichkeit des URL-Rewritings, richtig?
Ja, das kann ich soweit bestätigen. Das ist dann der Nachteil. Sowie die Fehlermeldung mit den Systemumgebungsvariablen.
Ich hatte bei allen Konfigurationen außer FPM served by nginx das Problem, dass Downloads über eine langsame Verbindung irgendwann abgebrochen sind. Hier mein Thread dazu: https://forum.netcup.de/anwendung/ples…-ab/#post117403
Vielen Dank customer
Darf ich euch bitten selber den Support mal anzuschreiben? Ich drehe mich mit denen gerade im Kreis. Vielleicht haben wir ja mehr Erfolg, wenn die mehrere Tickets zu dem Thema bekommen.
Der Support möchte unbedingt ein MTR von NTP-Pool-Monitoring -> mein Server.
Die Admins vom NTP-Pool können mir dieses jedoch nicht anfertigen. Ich sehe es jedoch nicht in meiner Verantwortung für meinen Hosting Provider die Fehleranalyse durchzuführen. Ich habe auf eine eindeutige Einschränkung im Peering hingewiesen. Ich finde alles weitere liegt nicht mehr in meiner Verantwortung.
Neue Rückmeldungen vom Support:
Im MTR aus dem Forum ist deutlich zu sehen, dass wohl Telia zu dem Zeitpunkt ein Routingproblem hatte.
und
Stand Jetzt liegt kein Problem vor. Ohne eine entsprechende Rückroute können wir hier keine Analysen anfertigen.
Tja, jetzt bin ich mit meinem Latein so langsam am Ende...
Die letzte Antwort vom Support:
Ich habe hier einmal Rücksprache mit unserem Network Operation Center gehalten. Ihre Analysen zeigen keine Auffälligkeiten. Um dies tiefer zu analysieren wären noch MTRs von der Gegenstelle in unser Netzwerk vonnöten.
Daraufhin habe ich nochmal mit einem Admin vom NTP-Pool geschrieben und ihn gebeten ein MTR vom Monitoring aus durchzuführen:
Looking at your server's score for the last couple of days, it has generally been above 10, so it has been in the pool. There are only a couple of times in the last two days where two polls have failed in succession and reduced the score to below the 10 limit.
I don't have access to the monitoring server to run mtr, but I have run it from my location in the UK to your server and a random IP address on your list and I don't see any significant packet loss.
Unfortunately (or fortunately depending which way you look at it!) internet routing and traffic levels change, so unless we happen to be monitoring at the time an intermittent problem occurs it doesn't help to find the issue.
Given your server is generally in the pool I would probably hold off any more investigation unless i/o timeouts happen again regularly and we are able to run further tests at that point.
Ich habe den Support mal auf das MTR von customer hingewiesen. Zudem habe ich eine Seite mit Statistiken von IP-Adressen aus AS197540 im NTP-Pool erstellt, die ich so finden konnte: https://cldup.com/eMad21gfq1.html
Achja, gibt es Tools, mit denen ich nachprüfen kann, ob die E-Mails, die ich mit meinem E-Mail Server sende auch beim MailServer des Empfängers korrekt akzeptiert werden, oder ob meine Mails als SPAM identizifiert werden?
Dafür benutze ich immer ganz gerne https://www.mail-tester.com/
Ich habe auch mal die Leute vom NTP-Pool angeschrieben und diese Antwort bekommen:
Hi Jens, volunteer admin here. The IPs of the pool monitor are:
139.178.64.42 and 2604:1380:2:6000::15
I see your server XXX.XXX.XXX.XXX is reported as having intermittent timeouts.
If things are fine at your end, it's probably an issue with the internet route between your server and the monitor as the DE and Europe pools look ok.
You can see a traceroute from the server by running:
curl http://trace.ntppool.org/traceroute/XXX.XXX.XXX.XXX
Another command that may be useful is:
mtr --udp -P 123 <IP address>
which will send UDP packets over port 123.
Running "mtr --udp -P 123 XXX.XXX.XXX.XXX" from here in the UK I see a fair amount of packet loss within NTT.
Hope that helps. Thank you for volunteering your server to the pool!
Laurence
Bin erst heute Abend wieder zu Hause. Dann teste ich weiter.
Deine IP ist statisch. Aber aktuell wird die IP über DHCP bezogen. Du musst auf den Netzwerkadapter gehen und da bei Eigenschaften die IP, Netzwerkmaske und den Gateway eintragen.
Du musst noch den Treiber der Netzwerkkarte installieren. Schau mal im Gerätemanager. Da werden einige unbekannte Geräte auftauchen.
Anschließend die IP statischen konfigurieren, die dir im SCP angezeigt wird.
