SPF・DMARC・DKIM レコードの読み方

アナライザーは貼り付けられたレコードをテキストとして読み、それぞれの仕様が定める規則と照合します。SPF のメカニズムと修飾子（RFC 7208）、DMARC のタグ（RFC 7489）、DKIM の鍵レコード（RFC 6376、RFC 8301 による更新）が対象です。各指摘には、その行が破っている規則を示します。

問い合わせも検証も行いません。DNS 照会はせず、メッセージの署名検証や配信テストもしません。ここを通過したレコードは文字列として整合しているという意味で、実際にそのドメインが公開している内容と一致するかは DNS 側で確認が必要です。

TXT レコードの値を貼り付けるか、「例を読み込む」を押します。v= タグと引用符は公開されているとおりに残します。
種類は「レコードを自動判定」のままにするか、判別しづらい場合は SPF・DMARC・DKIM を選びます。
「ローカルで解析」を押します。レポートには指摘、用語やタグの表、SPF の照会回数（x / 10 の形式）などのカウンターが表示されます。
指摘の横の表を読みます。限定子と備考が指摘箇所を示し、JSON 表示は同じ内容をそのままチケットに持ち込めます。
ゾーン編集画面でレコードを修正し、TTL の経過後に再度貼り付けて確認します。

レコード種別ごとに必要な内容

SPF レポートが数えるもの

メカニズムは限定子（+ pass、- fail、~ softfail、? neutral）とともに順番に読まれます。レコードは all で終わる必要はなく、all も redirect= もなければ、一致しないホストの結果は書かれている内容だけで決まります。

RFC 7208 の10件制限の対象は include、a、mx、ptr、exists、redirect です。ip4・ip6・all・exp は数えず、重複した項目は再度数えます。all の後に書いたメカニズムは表には出ますが、評価されません。

動作を変える DMARC のタグ

v=DMARC1 は先頭に置き、p=（none / quarantine / reject）が受信側の実際の動作を決めます。sp= はサブドメインのポリシー、pct= は適用する割合の指定です。

rua= と ruf= には URI（通常は mailto:）を書きます。adkim と aspf は r か s、fo は ruf= と組でのみ意味を持ち、rf は afrf だけを定義します。DMARC が定義していないタグは、レコードを無効にせず無視されます。

DKIM の鍵と使えるかどうかの判断

鍵レコードはセレクターごとに公開します。v=DKIM1 を先頭に、k= は rsa か ed25519、p= には公開鍵を base64 で入れます。p= が空なのは記入漏れではなく、鍵の失効を意味します。

RFC 8301 が暗号強度の下限を定めています。1024 ビット未満の鍵では有効な署名を作れず、2048 ビットが推奨、SHA-1 は使用できません。s= には email が必要で、t=y はテスト運用の宣言です。

テキスト検査では分からないこと

SPF の include 連鎖、DMARC のアラインメント、DKIM のセレクターレコードは、配信時に DNS で解決されます。アナライザーが判断できるのは目の前の文字列だけなので、指摘がないことは認証済みメールを送信している証明にはなりません。

DKIM の鍵レコードはセレクターに依存します。実際に署名に使うセレクターのレコード（例: selector1._domainkey）を貼り付けてください。ドメイン直下のレコードではありません。