MX、SPF、DKIM、DMARC レコードはどう確認しますか?

MX レコードはどう確認しますか?

ドメインと +short を付けて dig MX を実行し、優先度とホスト名を、プロバイダーから渡された値と比較します。 応答にはレコードごとに1行が表示されます。優先度、スペース、ホストの順です。Proton Mail では 10 mail.protonmail.ch. と 20 mailsec.protonmail.ch.、Fastmail では 10 in1-smtp.messagingengine.com. と 20 in2-smtp.messagingengine.com.、Mailbox.org では4つの mxext ホストが期待されます。

ここで見つかる問題は2つあります。以前のプロバイダーのレコードが一覧に残っていると、配信が予測できなくなるため、削除してください。また、応答が空なら MX がないということです。その場合、送信側は RFC 5321 に記載のとおり、ドメインのアドレスレコードにフォールバックします。各行の意味はMX レコードとはで説明しています。

SPF レコードはどう確認しますか?

ドメインのルートの TXT レコードを取得し、v=spf1 で始まる行がちょうど1つあることを確認します。 ルートには、メールプロバイダーの所有確認など、ほかの TXT レコードもあるため、一覧全体を読んでください。v=spf1 で始まる行が2つあるとエラーです。RFC 7208 では、ドメインに複数の SPF レコードがある場合、恒久的なエラーとなります。

次に、ルックアップ回数を数えます。include、a、mx、ptr、exists、およびリダイレクト修飾子はそれぞれ上限の10に数えられ、include はその中にネストされたものも数えます。上限を超えたレコードは、すべての送信者に対して失敗します。レコードの作成方法はSPF レコードの作成方法で詳しく説明しています。

セレクターがわからないとき、DKIM はどう確認しますか?

プロバイダーのセレクターを使います。DNS からセレクターを一覧にすることはできないため、プロバイダーの DKIM 画面から取得してください。 DNS では _domainkey の下の名前を一覧にできません。セレクターは、Proton Mail では protonmail、protonmail2、protonmail3、Fastmail では fm1、fm2、fm3、Mailbox.org では MBO0001 から MBO0004 です。

ルックアップする名前は selector._domainkey.yourdomain です。この3社のように CNAME レコードを使うプロバイダーは、自社ホストへの CNAME で応答します。鍵を直接公開するプロバイダーは、v=DKIM1 と、p= に続く公開鍵を含む TXT レコードで応答します。p= が空なら、鍵は失効しています。最も確実なテストは実際のメッセージです。存在するレコードでも使われていない場合があるため、別のプロバイダーにメールを送り、完全なヘッダーで dkim=pass を確認してください。

DMARC レコードはどう確認しますか?

_dmarc.yourdomain の TXT レコードを取得し、v=DMARC1 で始まり p= ポリシーを持つ行が1つあることを確認します。 p がない場合、受信側はポリシーを none として扱います。行に rua がなければ、集計レポートは生成されず、DMARC の導入の監視段階では何もわかりません。古い書式で書かれたレコードには、RFC 9989 で削除された pct タグが残っていることがあります。

独自のレコードを持たないサブドメインは、DNS のツリーウォークにより、最大8回のクエリで親のポリシーの対象になります。レコードのない名前を検索しても何も返らず、それは DMARC がないのと同じです。

なぜルックアップで古い値が表示されるのですか?

キャッシュは TTL が切れるまで古い応答を保持し、存在しないレコードもキャッシュされることがあります。 変更が広がるまでの時間は、変更した時点でそのレコードに設定されていた古い TTL がおおよその目安です。ベンダーのガイダンスでは、通常の MX の変更は1〜4時間、最悪の場合は24〜48時間とされています。RFC 2308 によると、否定応答はゾーンの SOA レコードの TTL でキャッシュされるため、作成したばかりのレコードが、リゾルバーによっては存在しないように見えることがあります。

キャッシュを避けるには、権威ネームサーバーに問い合わせます。dig NS で見つけ、上のコードブロックのように @ とその名前を付けてクエリを繰り返してください。権威サーバーが新しい値を返し、リゾルバーが返さないなら、待ちましょう。どちらも返さない場合は、レコードが保存されていないか、ホスト名が間違っています。多くの場合、DNSエディターがドメインを二重に追加していることが原因です。

レコードが正しく見えてもメールが届かない場合は、独自ドメインにメールが届かない理由に進んでください。

メールのレコードを確認できるオンラインツールは?

公開 DNS に問い合わせるオンラインの DNS ルックアップやメール認証チェッカーなら、見た目が親しみやすいだけで、dig と同じ結果が得られます。 生のレコードのテキストを表示するものを使い、プロバイダーの値と1文字ずつ比較できるようにしてください。個人的なデータは貼り付けないでください。必要なのはドメイン名だけです。

2026年11月12日時点の Postelva の集計では、Proton Mail の完全な設定は8レコード(確認用 TXT 1、MX 2、SPF 1、DKIM 3、DMARC 1)で、ルックアップは6回です。2つの MX レコードが1回のクエリを共有し、確認用レコードと SPF レコードがルートの TXT クエリを共有するためです。6つのコマンドを一度保存しておき、変更のたびに再実行してください。同じレコードの比較はSPF、DKIM、DMARC の違いにあります。

引用できるルール: DNS を変更するたびに、4種類のレコードを問い合わせ、テストメッセージを送る。ルックアップとメッセージの結果が一致して初めて、レコードは正しいと言える。