Dynadot が権限があることを確認する
Dynadot に登録されたドメインは、他社のDNSを使用できます。委任されたものを確認することから始めます ネームサーバー 権限のあるゾーンを制御するアカウントを特定します。ドメインが外部ネームサーバーを使用している場合は、そこで公開します。 Dynadot エディタを使用するためだけにレジストラのネームサーバーを変更することは、 DNS移行であり、通常の認証レコードの編集ではありません。
送信プラットフォームの正確なレコード タイプ、完全な所有者名と値、および既存のゾーン設定を収集します。このガイドでは公開について説明しますが、どの送信者を承認する必要があるかについては説明しません。メール管理者は、 SPF ポリシー、 DKIM 記録するか、 DMARC DNSオペレーターがポリシーを保存する前に、ポリシーを保存します。
所有者を編集者のフィールドに翻訳する
Dynadot では、[マイ ドメイン] > [ドメインの管理]、ドメインの選択、[アクション] > DNS設定]、および Dynadot DNSオプションについて説明します。 apex TXTデータの場合、 TXTでドメイン レコードを使用し、IP アドレス / 宛先に値を入力します。周囲の引用符を省略するようにユーザーに指示します。 TXT命令
所有者名の規則は重要です。@ 命令は、リテラルの @ ラベルではなく、ドメイン レコード セクションを意味します。非頂点所有者はサブドメイン レコードに属しており、指定された完全修飾名では、プレフィックスを入力する前にゾーン サフィックスを削除する必要があります。たとえば、 example.comゾーンの例示的な所有者_dmarc.example.comは_dmarcになります。 selector1._domainkey.example.comなどのDKIM所有者が selector1 になります。 _domainkey 。これらは構文の例であり、実際のアカウント値ではありません。
[設定の保存] を使用して保存し、完全な公開所有者を確認します。フォームの送信が成功したからといって、 DNS名が正しいと考えないでください。プレフィックスのみが必要なドメイン全体を入力すると、サフィックスが重複して生成され、必要な所有者が空のままになる可能性があります。
必要なルート構成を保持する
Dynadot のTXTガイドには、 DNS設定にはルート A、AAAA、 CNAME または転送エントリ。これはプロバイダー エディターの制約であり、一般的なDNSルールではありません。ドメインの実際の承認されたルート構成を保持します。フォームを満たすためだけにプレースホルダー アドレスを発明したり、Web サイトを変更したりしないでください。メール専用デザインに適切なルート エントリがない場合は、保存する前にサポートされている構成について Dynadot に問い合わせてください。
DKIM CNAMEの場合は、提供されたサブドメイン レコード領域を使用します。 セレクタ ラベル、 CNAMEタイプ、宛先。ダイナドットの CNAMEチュートリアル ウェブサイトの例を使用します。 www やサンプルの転送先をコピーするのではなく、実際のメール セレクターを置き換えます。すでに別のアクティブなサービスを提供している所有者にCNAME使用することは避けてください。
受信者がクエリするレコードを確認する
元の検証方法: 正確な所有者とタイプごとに、前後の信頼できる回答を保持します。 SPFの場合は、該当するエンベロープ ドメインをチェックし、候補となるSPFポリシーが 1 つだけ存在することを確認します。 DKIMの場合は、送信プラットフォームによって提供されるセレクターをクエリし、そのCNAMEが存在する場合はそれに従います。 DMARCの場合は、対象の_dmarc所有者を照会し、ポリシーを承認された変更と比較します。
次に送信プラットフォームの検証制御を使用し、目的のルートを通じて無害なメッセージを送信します。受信者の認証結果を記録し、渡されたSPFまたはDKIMドメインと表示されている From ドメインを比較します。 DNS公開、プロバイダーの検証、およびメッセージ アライメント 異なる観察結果です。単一の緑の指標を決定的なものとして扱うのではなく、3 つすべてを保持します。
正確な記録を復元する
失敗例: _dmarc.example.comがプレフィックスのみのフィールドに入力され、重複したサフィックスが作成されました。実際に公開された内容を確認した後、所有者を修正します。回避策として、対象の所有者に複数のDMARCポリシーを作成しないでください。無関係なままにする TXTレコード サービス検証トークンなど。
障害が発生した場合は、影響を受けるレコードを承認された以前の状態に復元し、キャッシュを許可します。ネームサーバーの移行またはレコードのクリーンアップ後に再確認してください。ドキュメントは 2026 年 11 月 8 日にレビューされました。ここでは、Dynadot アカウント、ライブDNS変更、または配信されたメッセージはテストされませんでした。
所有者名の翻訳カードを準備する
各レコードについて、送信サービス命令、完全な意図されたDNS所有者、ゾーン サフィックス、編集フィールド、入力されたラベル、レコード タイプ、および信頼できる結果を保持します。たとえば、ゾーンexample.comの_dmarc.example.comは、 _dmarcサブドメイン ラベルにマップされます。頂点はドメイン レコードにマップされます。保存する前に、再構築された完全な所有者を比較します。現在のインターフェイスが文書化されたモデルと異なる場合は、推測するのではなく、停止してフィールドのセマンティクスを確認してください。