Googleが2024年2月以降、SPF（Sender Policy Framework）やDKIMによるメール認証を実施していないメールは、Gmailアカウントに届かなくなる可能性があると発表されました。これは、多くの企業や組織にとって、メールコミュニケーションに大きな影響を与える可能性がある変更となりました。
そこで、今回はメールシステムに焦点を当て、DKIM（DomainKeys Identified Mail）とDMARC（Domain-based Message Authentication, Reporting and Conformance）についてまとめました。
DKIM・DMARCの基本：メール認証の仕組み
まず、DKIM・DMARCの基本的な仕組みについて、図を用いて説明します。
1. 送信者のメールサーバーでメールが作成されます。
2. DKIMの仕組みにより、メールに電子署名が付与されます。
3. 受信者のメールサーバーでDKIM署名が検証されます。
4. DMARCポリシーに基づいて、メールの認証結果が確認されます。
この過程で、DNSサーバーに登録されたDKIM公開鍵やDMARCポリシーが参照されます。
なりすまし防止におけるDKIMの役割
DKIMは、メールの送信元ドメインの正当性を証明する機能です。
以下の図で、その仕組みを詳しく見てみましょう。
1. 送信者のメールサーバーでメールが作成されます。
2. メールのヘッダーと本文のハッシュ値が計算されます。
3. 送信ドメインの秘密鍵を使用して、このハッシュ値に署名します。
4. 署名情報を含むDKIM-Signatureヘッダーがメールに追加されます。
5. 受信者のメールサーバーでDKIM-Signatureヘッダーが確認されます。
6. DNSから取得した公開鍵を使用して署名が検証されます。
7. メールのヘッダーと本文から計算したハッシュ値と、署名から復号したハッシュ値が一致するか確認されます。
この過程により、メールが送信元ドメインから確かに送信されたものであり、途中で改ざんされていないことが保証されます。
DMARCによる包括的なメール認証
DMARCは、SPF（メール送信元IPの正当性を検証する仕組み。今回は省略)とDKIMの結果を統合し、送信ドメインの所有者が認証に失敗したメールの扱いを指定できるようにします。以下は、DMARCの基本的な仕組みです：
1. 送信ドメインの所有者がDMARCレコードをDNSに公開します。
2. 受信側のメールサーバーは、SPFとDKIMの認証結果を確認します。
3. DMARCポリシーに基づいて、認証に失敗したメールの扱いが決定されます。
DMARCポリシーには主に以下の3つがあります：
– p=none: 何もアクションを取らない（モニタリングモード）
– p=quarantine: 認証に失敗したメールを隔離または迷惑メールフォルダに振り分ける
– p=reject: 認証に失敗したメールを拒否する
自社のメールシステム設定を確認する方法
自社のメールシステムが適切に設定されているか確認するには、以下の手順を踏むことをおすすめします：
1. SPFレコードの確認:
– コマンドラインから `nslookup -type=txt yourdomain.com` を実行し、SPFレコードが存在するか確認します。
このコマンドをコマンドプロンプトで実行すると、以下の様な結果が返ってきます。
yourdomain.com text = "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all"
このレコードの意味を簡単に解説すると：
v=spf1: SPFバージョン1を使用していることを示します。
ip4:192.0.2.0/24: このIPアドレス範囲からの送信を許可しています。
include:_spf.google.com: Googleのメールサーバーからの送信も許可しています（例えばGmail for Businessを使用している場合）。
~all: リストされていないIPアドレスからの送信はソフトフェイルとして扱います。
注意点：
複数のTXTレコードが存在する場合があります。その中にSPFレコードが含まれていればOKです。
SPFレコードの内容は、組織のメール環境に応じて異なります。上記は一例で、実際の内容は各ドメインの設定によって変わります。
SPFレコードが存在しない場合や、構文が正しくない場合は、メール配信に問題が生じる可能性があります。
最新のベストプラクティスでは、-all（強い失敗）または ~all（ソフトフェイル）で終わるSPFレコードが推奨されています。
2. DKIMの確認:
– メールヘッダーに DKIM-Signature フィールドが存在するか確認します。
– オンラインのDKIM検証ツールを使用して、署名の有効性を確認します。
3. DMARCレコードの確認:
– `nslookup -type=txt _dmarc.yourdomain.com` を実行し、DMARCレコードが適切に設定されているか確認します。
具体的には、以下の様な結果が返ってきます。
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100; ri=86400"
この結果の各要素を解説します：
v=DMARC1: DMARCのバージョンを示します。現在は常に “DMARC1” です。
p=quarantine: これはDMARCポリシーを示します。主な選択肢は：
p=none: 何もアクションを取らない（モニタリングモード）
p=quarantine: 認証に失敗したメールを隔離または迷惑メールフォルダに振り分ける
p=reject: 認証に失敗したメールを拒否する
rua=mailto:dmarc-reports@yourdomain.com: 集計レポートの送信先メールアドレスを指定します。
pct=100: ポリシーを適用するメールの割合を示します。100%は全てのメールに適用することを意味します。
ri=86400: レポート間隔を秒単位で指定します。この例では24時間（86400秒）ごとにレポートが送信されます。
他にも以下のようなオプションが含まれることがあります：
ruf=mailto:forensic-reports@yourdomain.com: 詳細な失敗レポートの送信先
sp=reject: サブドメインに対するポリシー
adkim=s: DKIM識別子の一致モード（s=strict、r=relaxed）
aspf=s: SPF識別子の一致モード（s=strict、r=relaxed）
重要なポイント：
DMARCレコードは必ず _dmarc. サブドメインに設定されます。
最初は p=none で始め、徐々に厳しいポリシーに移行することが推奨されます。
pct 値を使って、ポリシーを段階的に適用することができます。
レポート送信先のメールアドレスが正しく設定されていることを確認してください。
DMARCレコードが存在しない場合、または構文が正しくない場合、DMARCによる保護が機能しません。
4. テストメールの送信:
– Gmail等の主要なプロバイダーにテストメールを送信し、認証結果を確認します。
5. DMARC レポートの分析:
– DMARCレポートを定期的に分析し、認証の失敗原因を特定・修正します。
ざっくりと説明させて頂きましたが、如何でしたでしょうか。ビジネスでメール送受信が必須のサービスを提供している場合は、死活問題なので、この仕組みについてはエンジニアではなくとも、しっかりと腹落ちするまで理解する事をお勧めします。
コメント