GoDaddy: SPF, DKIM und DMARC in der DNS-Zone veröffentlichen

Von Thomas · virtueller CISO · 10. September 2026

GoDaddy ist vor allem ein Registrar und DNS-Host: Viele Domains haben ihre Zone dort, unabhängig davon, wer ihre Post tatsächlich versendet — eine Office-Suite, ein ESP, ein hauseigener Server. Das Veröffentlichen von SPF, DKIM und DMARC für diese Domains läuft daher über die DNS-Verwaltungsoberfläche von GoDaddy, die ihre eigenen Konventionen hat. Die meisten Schwierigkeiten kommen nicht von DMARC selbst, sondern von der Art, wie GoDaddy die Eingabe der Einträge erwartet.

Eine Konvention verursacht mehr Fehler als alle anderen zusammen: die Art, wie GoDaddy die Einträge im Feld „Host" (oder „Name") benennt. Sie falsch zu handhaben, erzeugt Einträge mit verschobenem Namen — _dmarc.beispiel.de.beispiel.de statt _dmarc.beispiel.de —, die für die Prüfer unsichtbar bleiben und die Domain ungeschützt lassen, obwohl „alles veröffentlicht scheint".

Dieser Leitfaden behandelt diese Host-Feld-Konvention, das Veröffentlichen von SPF, dann DKIM, dann DMARC in der GoDaddy-Oberfläche, den Sonderfall der von GoDaddy verkauften Mail, sowie die häufigen Eingabefehler und den abschließenden Gegenbeweis über die RUA-Berichte.

Das Host-Feld: die Konvention `@` und `_dmarc`

GoDaddy erwartet im Host-Feld den relativen Namen des Eintrags, niemals die vollständige Domain. Zwei Werte tauchen ständig auf:

@ bezeichnet die Root-Domain selbst (beispiel.de). Dort wird der SPF-Eintrag veröffentlicht.
_dmarc bezeichnet die Subdomain _dmarc.beispiel.de. GoDaddy hängt die Domain automatisch an; es ist also nur _dmarc einzugeben, nicht _dmarc.beispiel.de.

Hier passiert der häufigste Fehler. _dmarc.beispiel.de reflexartig ins Host-Feld einzugeben, lässt GoDaddy den Eintrag _dmarc.beispiel.de.beispiel.de anlegen — einen Namen, den es für die empfangenden Server nirgends gibt und den DMARC nie findet. Dieselbe Falle gilt für die DKIM-Selektoren: Man gibt sel._domainkey ein, niemals sel._domainkey.beispiel.de. Die Regel ist einfach und spart viel Zeit: Bei GoDaddy den Namen ohne die Domain eingeben, die Plattform ergänzt sie.

Den SPF-Eintrag veröffentlichen

Der SPF-Eintrag wird auf der Root-Domain veröffentlicht. In der GoDaddy-Oberfläche: einen Eintrag vom Typ TXT hinzufügen, Host-Feld @, und der SPF-Wert, der zu den für die Domain sendenden Diensten passt:

Typ: TXT
Host: @
Wert: v=spf1 include:_spf.google.com ~all

Der Include hängt vom tatsächlichen Absender ab — hier Google Workspace als Beispiel; es wäre include:spf.protection.outlook.com für Microsoft 365 oder der Include eines ESP. Eine Domain darf nur einen SPF-Eintrag tragen: Senden mehrere Dienste, werden ihre Includes im selben v=spf1 …-Wert kombiniert, niemals in zwei getrennten TXT-Einträgen. GoDaddy blockiert die Erstellung eines zweiten SPF nicht; auf die Eindeutigkeit zu achten, liegt beim Verfasser.

Eine GoDaddy-spezifische Gewohnheit hilft hier: nach Einträgen sehen, die die Plattform von sich aus hinzugefügt haben könnte. Der Abschluss eines GoDaddy-Mail-Angebots oder eine geparkte Seite kann ein Standard-SPF oder Platzhalter-Einträge säen. Beim Setzen des echten SPF bearbeitet man den bestehenden Eintrag, statt einen zweiten anzulegen — die Zwei-SPF-Falle beginnt oft genau dort, mit einem vergessenen Standardeintrag neben dem neuen. Die vorhandenen TXT-Einträge aufzulisten, bevor irgendetwas hinzugefügt wird, bringt diese Überbleibsel zum Vorschein.

Die DKIM-Einträge veröffentlichen

DKIM wird unter einem vom Versanddienst gelieferten Selektor veröffentlicht. Die Form des Eintrags hängt vom Anbieter ab: Manche geben einen CNAME (Delegation), andere einen öffentlichen Schlüssel als TXT. In beiden Fällen nimmt das Host-Feld den Selektor ohne die Domain auf:

Typ: CNAME
Host: sel._domainkey
Wert: sel.dkim.anbieter.example.

DKIM-Werte als TXT sind lang (ein 2048-Bit-Schlüssel). GoDaddy akzeptiert diese langen Werte in seiner Oberfläche; historisch verlangten manche Zonen ein Aufteilen in Segmente von 255 Zeichen, doch die Eingabe über die Oberfläche handhabt es heute. Der Wert ist exakt einzufügen, ohne störendes Leerzeichen oder Zeilenumbruch — ein abgeschnittener oder veränderter DKIM-Schlüssel verifiziert nicht, und das Symptom (DKIM fehlt in den Berichten) ist dasselbe wie bei einem nie veröffentlichten Schlüssel.

Den DMARC-Eintrag veröffentlichen

Der DMARC-Eintrag ist ein TXT unter der Subdomain _dmarc:

Typ: TXT
Host: _dmarc
Wert: v=DMARC1; p=none; rua=mailto:berichte@beispiel.de

GoDaddy bietet keinen dedizierten DMARC-Assistenten: Anders als manche Mail-Einträge, die ein Menü vorausfüllen kann, wird der _dmarc-Eintrag stets von Hand hinzugefügt, wie ein gewöhnlicher TXT. Das ist kein Mangel — ein DMARC-Eintrag läuft auf seinen Wert hinaus — erklärt aber, warum er nicht unter einer „DMARC aktivieren"-Schaltfläche zu finden ist: Er ist selbst zu verfassen. Man beginnt stets mit p=none: Die Richtlinie erzwingt nichts, aber die rua=-Adresse löst die aggregierten Berichte aus, die dazu dienen, vor dem Verschärfen alles zu prüfen. Die Zeile für Zeile aufgeschlüsselten Einträge schlüsseln die verfügbaren Tags auf (sp, adkim, aspf, pct unter DMARCbis entfernt) und die je nach Kontext zu behaltenden Werte. Unter DMARCbis wird die Subdomain-Zugehörigkeit über den DNS Tree Walk bestimmt, ohne die Art zu ändern, wie der Eintrag bei GoDaddy veröffentlicht wird.

Der Fall der von GoDaddy verkauften Mail

GoDaddy hostet nicht nur DNS: Es verkauft auch Mail-Angebote weiter, und das ist eine Quelle der Verwirrung. Zwei Produkte bestehen nebeneinander: das ältere „Workspace Email" (ein GoDaddy-Erbe, dessen SPF-Include include:secureserver.net ist) und das von GoDaddy weiterverkaufte Microsoft 365 (dessen Include include:spf.protection.outlook.com ist). Eine Domain, deren Post von einem dieser Produkte ausgeht, muss den entsprechenden Include verwenden — nicht den anderen.

Die klassische Falle: eine von Workspace Email zu Microsoft 365 migrierte Domain, die den alten include:secureserver.net in ihrem SPF behält. Der Include passt nicht mehr zum tatsächlichen Sendedienst, und SPF scheitert. Zu prüfen, welches Mail-Produkt wirklich aktiv ist — und den Include darauf auszurichten —, gehört zur Bereinigung einer bei GoDaddy gehosteten Domain. Erschwerend kommt hinzu, dass beide Produkte über dieselbe GoDaddy-Oberfläche verwaltet werden: Die Namensähnlichkeit verschleiert, welches tatsächlich zustellt, weshalb der Blick in die aggregierten Berichte hier oft schneller Klarheit schafft als die Kontooberfläche selbst.

Prüfen, ob die Zone wirklich von GoDaddy verwaltet wird

Bevor irgendetwas eingegeben wird, vermeidet eine Prüfung den frustrierendsten Fehler: sicherzustellen, dass die DNS-Zone der Domain wirklich von GoDaddy verwaltet wird. Eine Domain kann bei GoDaddy registriert sein, aber ihre Nameserver (NS) anderswo delegiert haben — ein anderer Host, ein Infrastrukturanbieter, ein CDN. In diesem Fall zeigt die DNS-Oberfläche von GoDaddy zwar eine Zone, doch sie ist nicht mehr autoritativ: Die dort hinzugefügten Einträge werden nie ausgeliefert, und die Domain bleibt ungeschützt, trotz Stunden in der richtigen Oberfläche — am falschen Ort.

Die Prüfung ist schnell: Die effektiven Nameserver der Domain lesen sich in einer NS-Abfrage. Zeigen sie auf GoDaddy (ns*.domaincontrol.com), ist die GoDaddy-Zone autoritativ und die Einträge dort zählen. Zeigen sie anderswohin, sind SPF, DKIM und DMARC in jener anderen Oberfläche zu veröffentlichen. Diese vorherige Prüfung ist der erste Reflex jeder Diagnose „Ich habe DMARC veröffentlicht, aber nichts kommt an".

Propagierung und TTL

Eine Zonenänderung bei GoDaddy ist für den Rest der Welt nicht sofort wirksam. Jeder Eintrag trägt eine TTL (Lebensdauer), die angibt, wie lange Resolver den alten Wert im Cache halten dürfen. GoDaddy wendet standardmäßig eine TTL von einer Stunde an: Nach einer Änderung muss man also bisweilen bis zu dieser Frist warten, bis die empfangenden Server den neuen Wert sehen.

Zwei praktische Folgen. Erstens: nicht zu schnell schließen, dass ein Eintrag „nicht funktioniert", wenige Minuten nach dem Setzen — die Propagierung mag nicht abgeschlossen sein, und eine erste negative Prüfung ist kein Urteil. Zweitens: Vor einer heiklen Änderung — einem DKIM-Schlüsselwechsel, einem Richtlinienwechsel — die TTL vorab zu senken (etwa auf fünf Minuten) verkleinert das Fenster, in dem alter und neuer Wert in den Caches nebeneinander bestehen. Ist die Änderung stabil und geprüft, kann die TTL wieder steigen.

Häufige Eingabefehler

Mehrere Fallen tauchen im Korpus der Berichte regelmäßig auf, die der kostenlose DMARC-Analyzer täglich verarbeitet.

Die vollständige Domain ins Host-Feld eingeben. Falle Nummer eins, oben beschrieben: _dmarc.beispiel.de statt _dmarc erzeugt einen Eintrag mit verschobenem, unauffindbarem Namen.

Zwei SPF-Einträge veröffentlichen. GoDaddy lässt einen zweiten v=spf1-TXT anlegen; zwei SPF-Einträge machen SPF vollständig ungültig. Die Includes sind in einem zusammenzuführen.

Einen abgeschnittenen DKIM-Schlüssel einfügen. Ein unvollständiger Wert oder einer mit einem störenden Leerzeichen verifiziert nicht; das Symptom täuscht, weil der Eintrag existiert, aber ungültig ist. Ein erneutes Kopieren des Werts aus der Quelle behebt das meist schneller als jede weitere Analyse.

Die Richtlinie zu früh verschärfen. Der Wechsel zu p=reject, bevor die Berichte bestätigen, dass sich der gesamte legitime Verkehr ausrichtet, bedeutet, die eigenen Nachrichten abzuweisen — die Reihenfolge p=none, dann Beobachtung, dann Verschärfung ist nichts GoDaddy-Spezifisches, bleibt aber die einzige sichere Abfolge.

Der Gegenbeweis: die RUA-Berichte

Der einzige Beleg dafür, dass eine Konfiguration hält, ist nicht der GoDaddy-Bildschirm, sondern das, was die Empfänger melden. Sobald ein _dmarc-Eintrag mit einer rua=-Adresse veröffentlicht ist, treffen die aggregierten Berichte binnen weniger Tage ein und schlüsseln Quelle für Quelle auf, was sich ausrichtet und was scheitert. Das Lesen der aggregierten DMARC-Berichte bestätigt zuerst, dass der Eintrag tatsächlich gelesen wird — war er falsch benannt (die Host-Feld-Falle), kommt kein Bericht an, was an sich ein Signal ist.

Eine einfache Kadenz genügt: eine erste Durchsicht wenige Tage nach der Veröffentlichung, sobald mehrere Empfänger gemeldet haben, danach ein wöchentlicher Blick, solange die Richtlinie bei p=none bleibt. Man prüft, dass jede legitime Quelle — der Mail-Dienst, der ESP, die Anwendungen — sich ausrichtet, und verschärft erst dann. Sobald diese Abdeckung über mehrere Tage bestätigt ist, erfolgt der Wechsel zu p=reject ohne Risiko. Der Online-Analyzer setzt diesen Zustand aus den veröffentlichten Einträgen und den empfangenen Berichten zusammen und verortet die Domain auf dem Weg, der zu p=reject führt.