DNSを推測で扱うのをやめる：開発者向けのMX、SPF、DKIM、DMARC入門
メール認証レコードは難解に見えますが、魔法ではありません。それぞれが実際に何をしているのか、配信を壊さずにどう設定するのかを説明します。
目次
なぜ今、メールのDNSレコードが重要なのか
メール認証は、かつては任意のものでした。2026年には、すでに前提条件です。GmailとOutlookはいずれも、大量送信者に対してSPFとDKIMを強制しており、トランザクションメールを送信するあらゆるドメインにとってDMARCも急速に必須になりつつあります。DNSレコードが間違っていると、メールは届きません。バウンスも警告もなく、ただ沈黙するだけです。
問題は、これらのレコードがツールのようにではなく、RFCのように文書化されていることです。多くの開発者はメールプロバイダーのセットアップガイドから例をコピー＆ペーストし、うまくいくことを願います。それで済むのは、トラブルシュートが必要になったり、2つ目の送信サービスを追加したり、問い合わせフォームのメールがなぜスパムに入るのかをクライアントに説明する必要が出てくるまでです。
このガイドでは、実際に遭遇する順番にMX、SPF、DKIM、DMARCを見ていきます。正しく設定するために十分な詳細と、壊れたときにデバッグするために必要な文脈を含めています。
MXレコード：受信メールの行き先
MXレコードは、あなたのドメイン宛てのメールをどのメールサーバーが受け取るかをインターネットに伝えます。4つの中では最も単純ですが、同時に最も設定ミスしやすいものでもあります。
MXレコードには、優先度の数値とホスト名の2つの部分があります。優先度の数値が小さいものから先に試行されます。Google Workspaceを使っている場合、MXレコードは次のようになります。
example.com. MX 1 aspmx.l.google.com.
example.com. MX 5 alt1.aspmx.l.google.com.
example.com. MX 5 alt2.aspmx.l.google.com.末尾のドットは重要です。ホスト名が完全修飾名であることを示します。ほとんどのDNSプロバイダーは自動的に追加しますが、すべてではありません。
よくあるミスは、MXレコードをホスト名ではなくAレコードに向けること、すべての優先度を同じ数値にしてしまうこと（バックアップを持つ意味がなくなります）、プロバイダーを移行したときに古いMXレコードを削除し忘れることです。古いMXレコードは無害に残っているだけではありません。メールループを引き起こしたり、2つの受信箱に配信が分割されたりする原因になります。
自前の問い合わせフォームを運用していて、サードパーティサービスに頼らずスパムを避けたい場合は、フォームがどのようにスパムの媒介になるかを理解することが良い出発点です。
SPF：あなたとして送信してよいサーバー
SPF（Sender Policy Framework）は、あなたのドメインに代わってメールを送信することを許可されたIPアドレスとドメインを列挙するTXTレコードです。あなたからのメールだと主張するメッセージを受け取ったとき、多くのメールサーバーが最初に行うチェックです。
基本的なSPFレコードは次のようになります。
v=spf1 include:_spf.google.com ~all分解すると次のとおりです。
v=spf1はSPFのバージョンを宣言しますinclude:_spf.google.comはGoogleのSPFレコードに委任します~allはソフトフェイルです。列挙されていない送信元からのメールを拒否対象にしますが、厳格すぎない扱いにします
特定のアドレスをホワイトリストに入れるには ip4: や ip6: も使えますし、自ドメインのAレコードやMXレコードを参照するには a や mx を使えます。末尾の all メカニズムは、列挙していない送信元からのメールに何が起こるかを制御します。-all はハードフェイル（拒否）、~all はソフトフェイル（疑わしいものとして扱う）、?all はニュートラル（判断しない）、+all は無制限（使わないでください）です。
SPFには鋭い落とし穴が2つあります。1つ目は、メールが転送されると壊れることです。転送サーバーはあなたのSPFレコードに含まれていないからです。2つ目は、SPFレコードにはDNSクエリ10回というルックアップ制限があることです。サードパーティサービスを含めすぎると制限を超え、SPFは機能しなくなります。対策はSPFレコードをフラット化すること、つまり include: ディレクティブを実際のIP範囲に置き換えることですが、プロバイダーがIPを変更したときにメンテナンスが必要になります。
DKIM：送信者IDの暗号学的な証明
DKIM（DomainKeys Identified Mail）は、送信メールにデジタル署名を追加します。受信サーバーは、DNSに公開されている公開鍵を使って署名を検証します。署名が有効で、メッセージが改ざんされていなければ、DKIMはpassになります。
SPFと違い、DKIMは転送されても維持されます。署名がメッセージと一緒に移動するからです。また、より柔軟でもあります。送信サービスごとに複数のDKIMキーを持ち、それぞれに独自のセレクターを持たせることができます。
DKIMのDNSレコードは次のようになります。
default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."セレクター（この例では default）は任意です。メールプロバイダーが選びます。p= の値は公開鍵で、通常は長いbase64エンコード文字列です。メールプロバイダーは秘密鍵を生成し、それを使って送信メッセージに署名します。
DKIMの設定は、ほとんどの場合メールプロバイダーが処理します。あなたの作業は、提示されたTXTレコードをコピーしてDNSに貼り付けることです。難しいのは、一部のDNSプロバイダーが長いTXTレコードをうまく扱えない点です。値を切り詰めてしまったり、複数の引用符付き文字列に分割することを要求したりします。
DKIMが機能しているか確認するには、Gmailアドレスにテストメールを送り、ヘッダーを確認します。Authentication-Results ヘッダー内の dkim=pass を探してください。
DMARC：ポリシーの適用とレポート
DMARC（Domain-based Message Authentication, Reporting and Conformance）は、SPFとDKIMを結び付け、認証に失敗したときに受信サーバーがどう扱うべきかを伝えます。またレポートも有効にするため、あなたのドメインとして誰がメールを送っているのか、正当なものと詐称されたものの両方を把握できます。
最小限のDMARCレコードは次のようになります。
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"p=noneは監視のみを意味します。失敗したメッセージを拒否したり隔離したりしませんrua=mailto:[email protected]は集計レポートの送信先を指定します
SPFとDKIMが機能していると確信できたら、ポリシーを p=quarantine（失敗したものをスパムへ）または p=reject（完全にバウンス）へ強化できます。sp= でサブドメインポリシーを設定したり、pct= でポリシーを適用するメッセージの割合を指定したりすることもできます。
DMARCレポートは、主要な受信側から毎日送信されるXMLファイルです。冗長で生のままでは読みにくいですが、どのメッセージが認証に成功または失敗したのか、その理由まで正確に教えてくれます。正当なメールが拒否されている場合、どのSPFまたはDKIMチェックが失敗しているかをレポートで確認できます。
注意点が1つあります。DMARCにはアラインメントが必要です。SPFの場合、Return-Path ヘッダーのドメインが From ヘッダーのドメインと一致している（またはサブドメインである）必要があります。DKIMの場合、DKIM署名内の d= ドメインが From ドメインと一致している必要があります。サードパーティの送信サービスを使っている場合、そのサービスは自社ドメインではなく、あなたのドメインでカスタムreturn pathまたはDKIM署名をサポートしている必要があります。
現在の設定を監査する方法
ほとんどのDNS問題は、問題を起こすまで見えません。壊れる前にレコードを確認する方法は次のとおりです。
- MXレコードを照会する：
dig MX example.comは、メールサーバーのホスト名と優先度を返すはずです。メールプロバイダーのドキュメントと一致していることを確認してください。
- SPF構文を確認する：
dig TXT example.comを実行し、v=spf1レコードを探します。SPFバリデーターにかけて、構文エラーやルックアップ制限違反を検出します。
- DKIMキーを検証する：テストメールを送信し、
DKIM-Signatureヘッダーを調べます。セレクターとドメインを抽出し、dig TXT selector._domainkey.example.comを照会して公開鍵が存在することを確認します。
- DMARCポリシーを検証する：
dig TXT _dmarc.example.comはDMARCレコードを返すはずです。rua=が実際に監視しているアドレスを指していることを確認してください。
- エンドツーエンドでテストする：mail-tester.comのようなサービスを使うか、Gmailアドレスに送信して完全なヘッダーを確認します。
Authentication-Resultsヘッダー内のspf=pass、dkim=pass、dmarc=passを探してください。
メールが届かない理由をデバッグしているなら、ヘッダーが最良のツールです。ほとんどのメールクライアントでは生のヘッダーを表示できます。Gmailではメッセージを開き、3点メニューをクリックして「Show original」を選択します。Authentication-Results ヘッダーが、どのチェックがなぜ失敗したのかを正確に教えてくれます。
サブドメインポリシーを使うべき場合
複数のサブドメインからメールを送信している場合、たとえばマーケティング用の newsletter.example.com とトランザクションメール用の app.example.com がある場合は、サブドメインごとのDMARCポリシーを設定できます。これにより、管理しているサブドメインには厳格なポリシーを適用しつつ、メインドメインにはより緩いポリシーを維持できます。
トレードオフは複雑さです。各サブドメインには独自のSPF、DKIM、DMARCレコードが必要で、どの送信サービスがどのサブドメインに対して許可されているかを追跡する必要があります。ほとんどの小規模チームにとっては、単一の適切に設定されたドメインの方がシンプルで、同じくらい安全です。
認証が壊れたときにすべきこと
最も一般的な失敗パターンは、DNSを更新せずに新しい送信サービスを追加することです。新しいトランザクションメールプロバイダーを使い始める場合、そのSPF includeまたはIP範囲を追加し、あなたのドメインでDKIM署名を設定し、DMARCアラインメントを確認する必要があります。
2番目によくある問題は転送です。ユーザーがあなたのメールを別のアドレスに転送すると、転送サーバーはあなたのSPFレコードに含まれていないため、SPFは失敗します。DKIMは通常、転送されても維持されるため、DKIMがpassし、DMARCポリシーが部分的なアラインメントを許可していれば、メッセージは引き続き配信されるはずです。転送メールが拒否されている場合は、DMARCポリシーを確認してください。厳格なアラインメントで p=reject にしていると、転送は壊れます。
3番目の問題はDNS伝播です。DNSレコードの変更が伝播するまでには数時間かかることがあり、メールサーバーごとにレコードをキャッシュする時間も異なります。レコードを更新したばかりで動作していない場合は、数時間待ってから再テストしてください。伝播状況はwhatsmydns.netのようなツールで確認できます。
重要なポイント
- MXレコードは受信メールをルーティングし、SPF、DKIM、DMARCは送信メールを認証します。それぞれ解決する問題が異なり、4つすべてが必要です。
- SPFは転送で壊れ、10回のルックアップ制限があります。DKIMは転送されても維持されますが、サービスごとの設定が必要です。DMARCはそれらを結び付け、レポートを有効にします。
- DMARCは
p=noneから始め、数週間レポートを監視し、正当なメールが通っていると確信できたらp=quarantineまたはp=rejectに強化します。 - DNSエラーは静かです。実際のメールで設定をテストし、ヘッダーを確認してSPF、DKIM、DMARCがpassしていることを確かめてください。
- 新しい送信サービスを追加した後に認証が壊れた場合は、SPF include、DKIMセレクター、DMARCアラインメントを確認してください。ヘッダーが、どのチェックに失敗したかを教えてくれます。
FAQ
Q: SPFレコードを複数持てますか？
A: いいえ。複数のSPFレコードがあると、すべて無視されます。複数のサービスを許可する必要がある場合は、単一のSPFレコード内で include: ディレクティブを使うか、IP範囲を直接列挙してください。10回のルックアップ制限に注意してください。
Q: 1日に数通しかメールを送らない場合でもDMARCは必要ですか？
A: はい。DMARCは量の問題ではありません。あなたが名乗っている通りの存在であることを証明するためのものです。小さなドメインでも、DMARCによって詐称を防ぎ、配信問題の可視性を得られます。p=none とレポート先アドレスから始めてください。
Q: DKIMとSPFの両方が失敗したが、メールが正当に見える場合はどうなりますか？
A: DMARCポリシーによります。p=none なら、メールは警告付きで配信されます。p=quarantine なら、スパムに入ります。p=reject なら、バウンスされます。厳格なポリシーを適用する前にDMARCレポートを監視すべき理由はここにあります。把握していない正当な送信者がいるかもしれません。
Q: 複数のドメインで同じDKIMキーを使えますか？
A: 技術的には可能ですが、やめてください。各ドメインは独自のDKIMキーペアを持つべきです。キーを共有するとローテーションが難しくなり、秘密鍵が侵害された場合の影響範囲も広がります。
Q: DKIMキーはどのくらいの頻度でローテーションすべきですか？
A: 普遍的なルールはありませんが、ほとんどのドメインでは年に1回が妥当です。キーが侵害された疑いがある場合は、ただちにローテーションしてください。新しい秘密鍵で署名を始める前に、新しい公開鍵をDNSに公開しておくこと、また遅延メールに対応するため、ローテーション後も数日間は古いキーをDNSに残しておくことを確認してください。
<!-- tool-cta:start -->
💡 お試しください: DMARC Lookupで任意のドメインの公開ポリシーを調べ、MX、SPF、DMARCレコードが実際にどのように連携しているかを確認できます。
<!-- tool-cta:end -->
Sources
- RFC 7208: Sender Policy Framework (SPF) — SPF仕様。構文ルールと10回のルックアップ制限を含みます。
- RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM仕様。署名の生成と検証を扱います。
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC仕様。ポリシー構文と集計レポート形式を含みます。
- Google Workspace: Prevent spoofing and spam — Google Workspaceドメイン向けのSPF、DKIM、DMARC設定に関する実践的なガイダンス。
よくある質問
SPFレコードを複数持てますか？
1日に数通しかメールを送らない場合でもDMARCは必要ですか？
DKIMとSPFの両方が失敗したが、メールが正当に見える場合はどうなりますか？
複数のドメインで同じDKIMキーを使えますか？
DKIMキーはどのくらいの頻度でローテーションすべきですか？
参考文献＆さらなる読み物
