Bestätigen Sie, dass Dynadot maßgeblich ist
Eine bei Dynadot registrierte Domain kann DNS eines anderen Unternehmens nutzen. Beginnen Sie mit der Überprüfung der Delegierten Nameserver und Identifizieren des Kontos, das die autorisierende Zone steuert. Wenn die Domain externe Nameserver verwendet, veröffentlichen Sie sie dort. Die bloße Änderung der Registrar-Nameserver zur Verwendung des Dynadot-Editors ist eine DNS Migration und keine gewöhnliche Bearbeitung des Authentifizierungsdatensatzes.
Erfassen Sie den genauen Datensatztyp der sendenden Plattform, den vollständigen Besitzernamen und -wert sowie die vorhandenen Zoneneinstellungen. In diesem Leitfaden wird die Veröffentlichung erläutert, nicht der Absender, der autorisiert werden sollte. Der E-Mail-Administrator muss die E-Mail bereitstellen und genehmigen SPF Politik, DKIM aufzeichnen bzw DMARC Richtlinie, bevor der DNS Betreiber sie speichert.
Übersetzen Sie Eigentümer in die Felder des Editors
Dynadot dokumentiert Meine Domains > Domains verwalten, Auswahl der Domain, Aktion > DNS Einstellungen und die Dynadot DNS Option. Für Apex TXT -Daten verwenden Sie den Domänendatensatz mit TXT und geben den Wert in „IP-Adresse/Ziel“ ein. Es weist Benutzer an, umgebende Anführungszeichen wegzulassen. TXT -Anweisungen
Die Regeln für den Eigentümernamen sind wichtig: Eine @-Anweisung bezieht sich auf den Abschnitt „Domänendatensatz“, nicht auf eine wörtliche @-Bezeichnung. Ein Nicht-Apex-Besitzer gehört zum Subdomain-Datensatz, und bei einem angegebenen vollqualifizierten Namen muss das Zonensuffix entfernt werden, bevor das Präfix eingegeben wird. Beispielsweise wird der illustrative Eigentümer _dmarc.example.com in der Zone example.com zu _dmarc . Ein DKIM Besitzer wie selector1._domainkey.example.com wird zu selector1. _domainkey . Dies sind Syntaxbeispiele, keine echten Kontowerte.
Speichern Sie mit „Einstellungen speichern“ und überprüfen Sie dann den vollständigen veröffentlichten Eigentümer. Gehen Sie nicht davon aus, dass eine erfolgreiche Formularübermittlung bedeutet, dass der DNS Name richtig ist. Die Eingabe der gesamten Domäne, bei der nur ein Präfix erwartet wird, kann zu einem doppelten Suffix führen und den erforderlichen Eigentümer leer lassen.
Behalten Sie die erforderliche Root-Konfiguration bei
TXT Leitfaden von Dynadot heißt es, dass für die DNS Konfiguration auch ein Root A, AAAA, erforderlich ist. CNAME oder Weiterleitungseintrag. Dies ist eine Einschränkung des Anbietereditors und keine allgemeine DNS Regel. Behalten Sie die echte, genehmigte Root-Konfiguration der Domäne bei. Erfinden Sie keine Platzhalteradresse und ändern Sie die Website nicht, nur um das Formular zu erfüllen. Wenn ein Nur-Mail-Design keinen geeigneten Root-Eintrag hat, fragen Sie Dynadot vor dem Speichern nach einer unterstützten Konfiguration.
Verwenden Sie für einen DKIM CNAME den Subdomain-Eintragsbereich mit dem bereitgestellten Wähler Label, CNAME Typ und Ziel. Dynadots CNAME Komplettlösung verwendet ein Website-Beispiel; Ersetzen Sie den tatsächlichen Mail-Selektor, anstatt www oder das Beispielweiterleitungsziel zu kopieren. Vermeiden Sie einen CNAME bei einem Eigentümer, der bereits einen anderen aktiven Dienst anbietet.
Überprüfen Sie den Datensatz, den die Empfänger abfragen
Ursprüngliche Verifizierungsmethode: Behalten Sie verlässliche Vorher-Nachher-Antworten für jeden genauen Eigentümer und Typ bei. Überprüfen Sie für SPF die entsprechende Umschlagdomäne und stellen Sie sicher, dass nur eine mögliche SPF Richtlinie vorhanden ist. Fragen Sie für DKIM den von der sendenden Plattform bereitgestellten Selektor ab und folgen Sie dessen CNAME falls vorhanden. Fragen Sie für DMARC den vorgesehenen _dmarc Eigentümer ab und vergleichen Sie die Richtlinie mit der genehmigten Änderung.
Nutzen Sie als Nächstes die Verifizierungskontrolle der sendenden Plattform und senden Sie dann eine harmlose Nachricht über die vorgesehene Route. Zeichnen Sie die Authentifizierungsergebnisse des Empfängers auf und vergleichen Sie die übergebene SPF oder DKIM Domäne mit der sichtbaren Von-Domäne. DNS Veröffentlichung, Provider-Verifizierung und Nachricht Ausrichtung sind unterschiedliche Beobachtungen; Behalten Sie alle drei bei, anstatt jeden einzelnen grünen Indikator als schlüssig zu betrachten.
Stellen Sie den genauen Datensatz wieder her
Beispielhafter Fehler: _dmarc.example.com wurde in ein Nur-Präfix-Feld eingegeben, wodurch ein doppeltes Suffix erstellt wurde. Korrigieren Sie den Eigentümer, nachdem Sie überprüft haben, was tatsächlich veröffentlicht wurde. Erstellen Sie zur Umgehung dieses Problems nicht mehrere DMARC -Richtlinien beim beabsichtigten Eigentümer. Ohne Zusammenhang bewahren TXT Datensätze wie zum Beispiel Service-Verifizierungs-Tokens.
Stellen Sie bei jedem Fehler den betroffenen Datensatz in seinen genehmigten vorherigen Zustand wieder her und ermöglichen Sie die Zwischenspeicherung. Nach einer Nameserver-Migration oder Datensatzbereinigung erneut prüfen. Die Dokumentation wurde am 8. November 2026 überprüft. Hier wurde kein Dynadot-Konto, keine Live DNS Änderung oder zugestellte Nachricht getestet.
Bereiten Sie eine Karte mit der Namensübersetzung des Eigentümers vor
Behalten Sie für jeden Datensatz die Sendedienstanweisung, den vollständigen beabsichtigten DNS Eigentümer, das Zonensuffix, das Editorfeld, die eingegebene Bezeichnung, den Datensatztyp und das maßgebliche Ergebnis bei. Beispielsweise wird _dmarc.example.com in der Zone example.com der Unterdomänenbezeichnung _dmarc zugeordnet; Der Scheitelpunkt wird dem Domänendatensatz zugeordnet. Vergleichen Sie den rekonstruierten vollständigen Eigentümer vor dem Speichern. Wenn die aktuelle Schnittstelle vom dokumentierten Modell abweicht, halten Sie an und bestätigen Sie die Feldsemantik, anstatt zu raten.