GoDaddy SPF-Record-Einrichtungsanleitung für 2026

Sie haben den Eintrag in GoDaddy hinterlegt, die letzte Kampagne wurde versendet und Gmail hat trotzdem die Hälfte Ihrer Nachrichten so behandelt, als kämen sie von einem Fremden. Dann fügt jemand ein CRM, ein Newsletter-Tool und eine Transaktionsplattform hinzu, und das gesamte Setup beginnt sich wie ein Haufen loser Kabel zu verhalten. Genau an diesem Punkt hört ein GoDaddy SPF-Record auf, nur ein Häkchen zu sein, und wird zu dem Element, das Ihre Zustellbarkeit zusammenhält.

Das Problematische daran ist, dass sich SPF-Fehler selten deutlich ankündigen. Ein Absender wird hinzugefügt, das DNS wird einmal bearbeitet, und Wochen später bemerkt das Team Spam-Platzierungen, Authentifizierungsfehler oder dass eine Plattform funktioniert, während eine andere aus der Liste fällt. Wenn Ihnen das bekannt vorkommt, haben Sie es mit DNS-Besitzverhältnissen, der Record-Struktur und der 10-Lookup-Grenze zu tun, nicht nur mit einfachen E-Mail-Problemen.

Warum Ihr GoDaddy SPF-Record wichtiger ist, als Sie denken

SPF ist vom Konzept her einfach, aber in der Praxis gnadenlos. Ein empfangender Server prüft die veröffentlichte Richtlinie der Domain im DNS und fragt dann, ob der sendende Server berechtigt ist, für diese Domain zu senden. Wenn die Antwort nicht übereinstimmt, kann die Nachricht als nicht autorisiert behandelt werden, selbst wenn der Absender legitim ist.

Deshalb schadet ein fehlerhafter GoDaddy SPF-Record mehr, als viele realisieren. Sowohl Microsoft 365 als auch Google Workspace verlassen sich auf Authentifizierungssignale, die Mailbox-Anbieter im Hintergrund auswerten. Ein fehlender oder falsch formatierter SPF-Record kann die Zustellung in den Posteingang beeinträchtigen, lange bevor jemand einen sichtbaren Fehler bemerkt. Der Unterschied zwischen hardfail und softfail ist hier wichtig, da der abschließende Qualifizierer den Empfängern mitteilt, ob nicht autorisierte E-Mails direkt abgelehnt oder mit Misstrauen behandelt werden sollen.

Der Teil, den die meisten Teams übersehen

SPF sagt nicht nur: „Gehört diese Domain Ihnen?“ Es sagt: „Ist dieser Absender auf der im DNS veröffentlichten Liste der zugelassenen Absender?“ Hier beginnt auch die SPF-Ausrichtung eine Rolle zu spielen, da DMARC später prüft, ob die sichtbare Von-Domain mit der authentifizierten Quelle übereinstimmt.

Praktische Regel: Wenn ein Absender nach der Erstellung des ursprünglichen SPF-Records zum Stack hinzugefügt wurde, ist dieser Absender wahrscheinlich das Problem, es sei denn, der DNS-Record wurde ebenfalls überarbeitet.

GoDaddys eigene Anleitung spiegelt den modernen Ansatz wider, bei dem SPF als TXT-Record und nicht als separater SPF-Typ-Record veröffentlicht wird, und der Arbeitsablauf konzentriert sich auf die DNS-Bearbeitung innerhalb des Domain-Portfolios. Dieses Setup klingt gewöhnlich, ist aber genau der Grund, warum SPF so oft fehlschlägt. Der Record ist leicht einmal hinzuzufügen und nach der Genehmigung des nächsten Tools leicht zu vergessen.

Hinzufügen Ihres ersten SPF-Records in GoDaddy DNS

Beginnen Sie im Domain-Portfolio, öffnen Sie DNS und fügen Sie einen Record als TXT hinzu. GoDaddys eigene Hilfe zeigt diesen Pfad für die SPF-Einrichtung, wobei die SPF-Richtlinie in das Feld Wert (Value) eingetragen und der Host auf das Root-Verzeichnis gesetzt wird, wenn die Richtlinie für die gesamte Domain gilt, während die TTL im dokumentierten Beispiel für zugehörige Mail-Records auf Standard (Default) bleibt GoDaddys Hilfe zum SPF-Record GoDaddys DNS-Record-Felder für E-Mail-Authentifizierung.

Die Felder, auf die es ankommt

Typ sollte TXT sein, nicht SPF. GoDaddys Dokumentation verwendet TXT, da dies das Standard-Veröffentlichungsformat für SPF im modernen DNS ist und diese Wahl Mehrdeutigkeiten bei Validatoren vermeidet.

Name sollte normalerweise @ für eine Root-Domain-Richtlinie sein. Das teilt GoDaddy mit, dass der Record an die Spitze der Domain gehört und nicht auf eine Subdomain. Wert ist der Ort, an dem der SPF-String lebt, also fügen Sie dort die Richtlinie selbst ein.

TTL kann auf Standard bleiben, wenn Sie GoDaddys dokumentiertem Setup folgen, insbesondere wenn Sie nicht gerade bei der Fehlersuche sind. Die genauen Feldnamen sind leicht zu übersehen, aber sie machen den Unterschied zwischen einem Record, der an der Domain-Wurzel lebt, und einem, der irgendwo nutzlos ist.

Ein einfaches, von GoDaddy verwaltetes Mail-Beispiel sieht so aus: v=spf1 include:secureserver.net -all, was der Form entspricht, die GoDaddy für Hosting-E-Mails zeigt. Wenn Sie nur eine Absenderquelle autorisieren, ist das die Form, die Sie wollen: ein Record, eine Richtlinie, ein Ort.

Für eine Gmail-spezifische Variante zeigt dieser SPF-Leitfaden für Gmail-Nutzer dieselbe TXT-zuerst-Logik in der Praxis.

Wenn Sie den Record-Typ als etwas anderes als TXT eingeben oder den Host leer lassen, wenn die Richtlinie an der Wurzel sitzen muss, existiert der Record möglicherweise in der Benutzeroberfläche, schlägt aber auf DNS-Ebene dennoch fehl.

Später im Prozess wird GoDaddys eigene Schnittstelle weniger wichtig als die autoritative DNS-Zone, aber der erste Erfolg besteht darin, den Record im richtigen Feld, mit dem richtigen Typ und beim richtigen Host einzugeben.

SPF-Syntax für die von Ihnen verwendeten Absender

Viele Organisationen betreiben nicht nur einen Absender. Sie betreiben ein primäres Postfach, eine Marketingplattform, ein CRM und ein Transaktionssystem. Der SPF-Record ist die einzige Anweisung, die alle autorisiert. Die eigentliche Aufgabe besteht also darin, die richtigen Mechanismen zu wählen und die Liste kurz genug zu halten, damit sie validiert werden kann, bevor das GoDaddy-DNS anfängt, gegen Sie zu arbeiten.

Sofort einsatzbereite SPF-Strings für gängige Absender-Stacks

Absender-Setup	SPF-Wert	Verwendete Lookups
Google Workspace	v=spf1 include:_spf.google.com -all	Ein Include, dann die abschließende Richtlinienprüfung
Microsoft 365	v=spf1 include:spf.protection.outlook.com -all	Ein Include, dann die abschließende Richtlinienprüfung
Google Workspace plus ein Marketing-Tool	v=spf1 include:_spf.google.com include:servers.mcsv.net -all	Zwei Includes, plus alle verschachtelten Lookups innerhalb der enthaltenen Records
Microsoft 365 plus ein Transaktions-Absender	v=spf1 include:spf.protection.outlook.com include:amazonses.com -all	Zwei Includes, plus alle verschachtelten Lookups innerhalb der enthaltenen Records

Diese Strings sind nützlich, weil sie das Muster zeigen: ein Record, eine Richtlinie, ein Ort zur Steuerung in GoDaddy. Wenn Ihr Stack mit Google Workspace oder Microsoft 365 beginnt und dann in Marketing- und Transaktions-E-Mails hineinwächst, geht es bei dem Record meist nicht mehr um Syntax, sondern darum, wie viele DNS-Lookups jeder Anbieter im Hintergrund verbraucht.

Was die Mechanismen bewirken

include weist an, die SPF-Richtlinie einer anderen Domain zu prüfen und deren Autorisierung zu übernehmen. Das ist das Arbeitstier für Google Workspace, Microsoft 365, Mailchimp, SendGrid und ähnliche Plattformen.

ip4 ist für feste Sende-IP-Adressen gedacht, was hilfreich ist, wenn Sie die Quell-IP kontrollieren und nicht von der Richtlinienkette eines anderen Anbieters abhängen möchten. all am Ende legt die Regel für alles fest, was noch nicht autorisiert ist, und der Qualifizierer entscheidet, wie streng der Fehler sein soll.

Praktische Regel: Verwenden Sie ein strengeres Ende, wenn Ihre Absenderliste stabil ist, und ein weicheres Ende nur, während Sie den Stack noch bereinigen.

Eine nützliche externe Perspektive auf die Absenderplanung ist Ratschläge für E-Mail-Kampagnen kleiner Unternehmen, da Kampagnenteams oft Tools hinzufügen, ohne deren Auswirkungen auf das DNS zu prüfen.

Der Teil, der bei echten GoDaddy-Setups zu Problemen führt, ist das Lookup-Budget. Jedes zusätzliche Include verbraucht dieses Budget, und ein Record kann sauber aussehen, während er dennoch fehlschlägt, weil die Kette zu tief wird. Bauen Sie die Syntax um den Stack herum auf, den Sie betreiben, nicht um den, den Sie gerne hätten.

Zusammenführen mehrerer Absender, ohne das Lookup-Limit zu erreichen

Der große Fehler bei einem GoDaddy SPF-Record ist nicht die Syntax, sondern die Anhäufung. Eine Domain beginnt mit einem Absender, dann fügt das Marketing einen weiteren hinzu, dann fügt der Vertrieb ein CRM hinzu, dann fügt der Betrieb eine Transaktionsplattform hinzu, und niemand bemerkt, dass SPF jetzt versucht, mehr Systeme zu validieren, als der Standard zulässt.

Die Regel ist stumpf und lässt sich nicht biegen. Veröffentlichen Sie niemals mehr als einen SPF-Record unter demselben Namen. Wenn zwei SPF-TXT-Records für dieselbe Domain existieren, können Empfänger das Ergebnis als ungültig oder mehrdeutig behandeln, was bedeutet, dass der Record, von dem Sie dachten, er würde helfen, möglicherweise die Authentifizierung stört.

Wie der Zusammenführungsprozess funktioniert

Beginnen Sie damit, jeden legitimen Absender aufzulisten. Fassen Sie diese dann in einer TXT-Richtlinie zusammen, indem Sie include-Anweisungen verwenden, bei denen der Anbieter seine eigene Sendeinfrastruktur verwaltet. Wenn Sie bereits einen Record in GoDaddy haben, bearbeiten Sie diesen, anstatt eine zweite Kopie zu erstellen.

Die zweite Falle ist die Verschachtelung. Ein einzelnes Include kann mehrere weitere Lookups innerhalb der SPF-Richtlinie des Anbieters verbergen, und deshalb können Domains das Budget schneller ausschöpfen, als das Team erwartet. GoDaddy-fokussierte Anleitungen warnen Benutzer davor, das Limit von 10 DNS-Mechanismus-Lookups zu überschreiten, und dieses Limit gilt während der Auswertung, nicht im Nachhinein SPF-Einrichtungs-Best-Practices für GoDaddy-Domains SPF-Anleitung 2026 für GoDaddy-Domains.

Ein saubereres Betriebsmodell

• Überprüfen Sie zuerst jeden Absender: Entfernen Sie alte Tools, die keine E-Mails mehr versenden, da veraltete Includes weiterhin Budget verbrauchen.
• Konsolidieren Sie in eine Richtlinie: Behalten Sie die gesamte Autorisierung in einem einzigen TXT-Record unter dem richtigen Namen.
• Überprüfen Sie die Lookup-Anzahl vor dem Speichern: Ein ordentlich aussehender Record kann immer noch fehlschlagen, wenn verschachtelte Includes ihn über die Grenze treiben.

Mail Merge for Gmail passt logisch genau hier hinein. Es sendet über Googles authentifizierte Infrastruktur, benötigt also kein eigenes separates Include und belastet das SPF-Budget nicht, wenn Sie bereits Google Workspace autorisieren.

Der Grund, warum das so wichtig ist, ist einfach. Ein Team kann monatelang unter dem Limit bleiben, dann treibt ein neuer Anbieter den Record über die Grenze, und SPF beginnt ohne offensichtlichen DNS-Fehler in der GoDaddy-Oberfläche zu scheitern.

Überprüfen, ob Ihr Record tatsächlich funktioniert

Das Speichern des Records in GoDaddy ist kein Beweis. Es bedeutet nur, dass die Änderung eingegeben wurde, nicht dass die autoritative Zone sie bereitstellt, nicht dass Caches aktualisiert wurden und nicht, dass die Richtlinie sauber geparst wird.

Drei Prüfungen, drei verschiedene Antworten

Die erste Prüfung ist ein DNS-Lookup gegen die Live-Zone. Eine dig- oder nslookup-Abfrage zeigt Ihnen, was die autoritativen Nameserver zurückgeben. Das ist wichtig, weil die GoDaddy-Oberfläche einen Wert anzeigen kann, bevor die Verbreitung abgeschlossen ist, und sie Ihnen nicht mitteilt, ob ein anderer DNS-Host die Zone besitzt.

Die zweite Prüfung ist ein SPF-Parser wie der SPF-Check von MXToolbox. Diese Art von Tool ist nützlich, weil es gleichzeitig die Syntax liest und die Lookups zählt, was genau der Punkt ist, an dem verschachtelte Includes und überlastete Ketten auftauchen.

Die dritte Prüfung ist der Nachweis auf Nachrichtenebene. Senden Sie einen Test an Gmail, öffnen Sie die ursprüngliche Nachricht und untersuchen Sie die Header. Die Zeile Authentication-Results zeigt normalerweise an, ob SPF für die sendende Domain bestanden oder fehlgeschlagen ist, was Ihnen mitteilt, wie ein Mailbox-Anbieter die Nachricht bewertet hat, nicht nur, was das DNS sagt.

Praktische Regel: Wenn das DNS korrekt aussieht, aber die Header immer noch fehlschlagen, liegt das Problem normalerweise auf der Validierungsebene, nicht in der GoDaddy-Benutzeroberfläche.

Es gibt auch eine Realität der Verbreitung, die Teams auf eigenes Risiko ignorieren. GoDaddys TTL-Verhalten ist normalerweise schnell, aber DNS-Änderungen in Randfällen können dennoch Zeit benötigen, um sich über Resolver hinweg zu stabilisieren. Wenn Sie Records zwischen Anbietern verschieben, bestätigen Sie zuerst die autoritativen Nameserver und validieren Sie dann gegen die tatsächliche Zone, nicht gegen das Kontrollpanel, das Sie zufällig verwendet haben. Für die Nachverfolgung von Nachrichten von Anfang bis Ende ist dieser E-Mail-Trace-Leitfaden der sauberere Begleiter.

Vom SPF-Erfolg zur vollständigen E-Mail-Authentifizierung

Ein SPF-Erfolg fühlt sich beruhigend an, löst aber nicht das ganze Problem. SPF autorisiert nur Sendequellen, signiert die Nachricht nicht und verhindert nicht, dass eine Nachricht nach dem Verlassen des Absenders verändert wird. Deshalb kann SPF allein immer noch Weiterleitungs-Randfälle und Identitätsdiebstahl-Lücken hinterlassen.

Wo DKIM und DMARC hineinpassen

DKIM fügt der Nachricht selbst eine kryptografische Signatur hinzu. Im GoDaddy-verwalteten DNS bedeutet das normalerweise einen TXT-Record unter dem Selektor-Host, und Google Workspace verwendet häufig google._domainkey als Teil dieses Setups.

DMARC sitzt auf SPF und DKIM. Es teilt empfangenden Systemen mit, was zu tun ist, wenn die Authentifizierung fehlschlägt und wohin Berichte gesendet werden sollen, normalerweise über einen TXT-Record bei _dmarc auf der Domain. Ohne DMARC haben Mailbox-Anbieter keine gemeinsame Richtlinie, der sie folgen können, wenn SPF oder DKIM nicht übereinstimmen.

Die wichtigste Erkenntnis ist, dass SPF nur eine Ebene des Vertrauens ist. Eine gefälschte Nachricht kann immer noch eine schwache Ausrichtung ausnutzen, wenn DKIM nicht vorhanden ist, und eine weitergeleitete Nachricht kann sich immer noch anders verhalten als eine ursprüngliche Sendung, selbst wenn SPF an der Quelle sauber war.

Der praktische Stack ist unkompliziert. SPF autorisiert den Absender, DKIM signiert die Nachricht und DMARC weist die Empfänger an, wie sie handeln sollen, wenn beide nicht übereinstimmen. Der frühere Abschnitt zur Verifizierung ist hier wichtig, da Sie die Richtlinie nicht verschärfen möchten, bevor Sie wissen, dass jeder legitime Absender authentifiziert wird.

Für einen tieferen Einblick in den gesamten Stack verbindet dieser E-Mail-Authentifizierungsleitfaden SPF, DKIM und DMARC in einem Arbeitsablauf.

SPF während echter Mail Merge-Kampagnen sauber halten

Eine Mail Merge-Kampagne setzt die DNS-Arbeit schnell unter Druck. Vertriebs-, Recruiting- oder Event-Teams können eines Tages eine saubere Sequenz von Gmail aus senden und dann in der nächsten Woche den Inhalt beschuldigen, wenn die Antworten nachlassen, obwohl das tiefere Problem die Authentifizierungsdrift war.

Mail Merge for Gmail sendet über Googles authentifizierte Infrastruktur, erstellt also keinen separaten Absender, der ein eigenes SPF-Include benötigt. Das größere Risiko besteht darin, dass sich der umgebende Stack ändert, der Domaininhaber eine weitere Plattform hinzufügt und die Mailbox-Anbieter beginnen, eine Nachrichtenhistorie auszuwerten, die nicht mehr konsistent aussieht.

Eine Checkliste vor der Kampagne, die tatsächlich hilft

• Bestätigen Sie, dass SPF für das sendende Google-Konto besteht: Testen Sie das genaue Postfach, das die Kampagne versenden wird, nicht einen zufälligen Alias.
• Bestätigen Sie, dass DKIM in der Google Workspace-Verwaltung aktiviert ist: SPF allein ist zu fragil für weitergeleitete oder neu verpackte E-Mails.
• Bestätigen Sie, dass DMARC mindestens auf p=none mit aktivierter Berichterstattung steht: Das gibt Ihnen Sichtbarkeit, bevor Sie die Richtlinie verschärfen.

Ein grünes SPF-Ergebnis allein bedeutet nicht, dass die Kampagne sicher gestartet werden kann. Es bedeutet nur, dass der Absender in diesem Moment mit der aktuellen DNS-Richtlinie übereinstimmte.

Die beste Gewohnheit ist es, den SPF-Record wie Sanitäranlagen zu behandeln. Überprüfen Sie ihn vor der Kampagne, überprüfen Sie ihn, wenn ein neuer Absender hinzugefügt wird, und überprüfen Sie ihn erneut, wenn eine Plattform ihren Sendepfad ändert. So verhindern Sie, dass ein GoDaddy SPF-Record zu einem Zustellbarkeitsproblem altert.

---

Mail Merge for Gmail hilft Teams dabei, personalisierte Kampagnen von Gmail aus zu versenden, während der Sendepfad an Google Workspace gebunden bleibt. Das macht SPF leichter nachvollziehbar, wenn der Domain-Stack überfüllt ist. Wenn Sie vor Ihrem nächsten Outreach-Lauf ein GoDaddy-DNS-Setup bereinigen, besuchen Sie Mail Merge for Gmail und prüfen Sie, wie es in einen Arbeitsablauf passt, der bereits darauf angewiesen ist, dass SPF, DKIM und DMARC sauber bleiben.