Das ist vermutlich von Alexander so gewollt. So das es allgemein gültig ist.Nur aus dem einen Grund, dass im Dashboard als DKIM-HOST nur default._domainkey angegeben ist.
Denn er weiß nicht, ob der FQDN für KeyHelp eine Domain, eine Sub Domain, etc ist. Des weiteren weiß er auch nicht, wie das DNS Zonendesign aussieht. Sprich es wird zwar eine Sub-Doamin für das Panel verwendet, aber es gibt "nur" eine Zone für die Domain. Genauso kann es aber eine DNS-Zone für die Sub-Domain auf einem externen DNS-Server geben, welche entsprechend über NS Einträge delegiert wurde.
Richtig, über den DMARC Eintrag kann man steuern, wie bei einem Failed bei einer Sub Domain reagiert werden soll. Wird der Parameter sp nicht angegeben, ist der Wert standardmäßig reject.ja wohl auch DMARC so konfigurieren, dass die DKIM-Signatur der Domain auch für Subdomains gilt, was ich normalerweise nicht wi
Da kann ich dir nicht folgen...So kann ich vermeiden, dass auch Mails von anderen Subdomains mit validem DKIM ankommen.
Wir haben dafür eine dedizierte Domain, welche für diesen Zweck verwendet wird. Diese wird von autoritativ von einem externen DNS-Anbieter betreut. Somit können wir niemals den Ast absägen, auf dem wir sitzen.Es wäre aber bei einem halben Dutzend Server aus der selben Domain anders eventuell doch einfacher.
Natürlich kannst du das. Ist sehr sinnvoll bei einem Key Rollover oder wenn du verschiedene Server hast, welche mit der (Sub)Domain E-Mails verschicken sollen. Dann wird logischerweise eine andere DKIM Schlüssel verwendet und der muss zusätzlich im DNS veröffentlicht werden.Ich kann ja wohl nicht ein halbes Dutzend Domainkeys mit dem selben Selektor im DNS veröffentlichen?!?
Bei meinem AG haben wir für eine Sub Domain mehrere Keys im DNS veröffentlicht. Funktioniert seit > Jahren problemlos.
. Zumindest könnte man an der Stelle eventuell ein paar Worte zur Klarstellung einfügen, dass das nicht notwendigerweise der einzutragende DKIM-HOST ist.