IT担当者なら一度は耳にしたことがあるであろうDMARC, DKIM, SPF。なんとなく分かってはいるけど今更聞けない、メールセキュリティを確保するための3つの重要なメカニズムであるSPF、DKIM、そしてDMARCについて解説します。さらにこれらのメカニズムが大手メールサービスプロバイダーのセキュリティガイドライン、特にGoogleやYahooの要件とどのように連携しているのかも解説します。
SPFとは何か？
SPF（Sender Policy Framework）は、電子メールの送信者が正当なものかどうかを確認するために用いられるメール認証システムです。この仕組みにより、ドメイン名を詐称したスパムやフィッシング詐欺を防ぐことができます。具体的には、ドメインのDNSレコードにSPFレコード（txtレコード）を追加することで、そのドメインからの正規のメール送信サーバーを公開します。メール受信サーバーは、メールが指定されたサーバーから送られたものかどうかを検証できます。
例えば、ドメインexample.comのSPFレコードは以下のようになります：
v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 include:_spf.google.com ~allSPFレコードの構文はv=spf1で始まります。これはバージョン番号を示し、後に続く各項目が送信を許可するIPアドレス、送信サーバー、またはポリシーを定義します。このレコードは、192.0.2.0/24と198.51.100.0/24のIPアドレスレンジと、_spf.google.comに紐づくIPアドレスを持つサーバーからのメールを正当なものと認証します。最後の~allは、これらの指定されたサーバー以外からのメールにはSoft fail（ソフトな失敗）を適用することを意味します。これにより、SPFレコードが設定されたドメインを偽装した不正なメールを送信する行為を抑止し、メール受信者は信頼できる送信元からのメールであることを確認できます。
以下はメールヘッダーで確認できるSPF認証の例です。このメールヘッダーを見てみると、recipient@example.netはmail.example.com. [192.0.2.1]というメールサーバーからメールを受け取っています。また、192.0.2.1は先ほどのSPFレコードに記載されているip4:192.0.2.0/24の範囲内なので、recipient@example.net側のメールサーバーがSPFレコード確認を実施した結果、pass（sender@example.comから許可されたメールサーバー）となります。
Delivered-To: recipient@example.net
Received: by 2002:a1b:de05:0:0:0:0:0 with SMTP id f5csp1234567iob;
Mon, 4 Mar 2024 10:18:59 -0800 (PST)
Received: from mail.example.com (mail.example.com. [192.0.2.1])
by mx.google.com with ESMTP id x12si12345678wrx.123.2024.03.04.10.18.59
for <recipient@example.net>;
Mon, 04 Mar 2024 10:18:59 -0800 (PST)
Received-SPF: pass (google.com: domain of sender@example.com designates 192.0.2.1 as permitted sender)
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of sender@example.com designates 192.0.2.1 as permitted sender) smtp.mailfrom=sender@example.com
From: sender@example.com
To: recipient@example.net
Subject: Example Email Subject
Date: Mon, 4 Mar 2024 10:18:58 -0800
Message-ID: <CA+0aQHgf=4r5B6J2N5XUPj0QJ5+3nVtMx9=8a6bJ@mail.example.com>
Content-Type: text/plain; charset="UTF-8"DKIMとは何か？
DKIM（DomainKeys Identified Mail）は、メールが特定のドメインから正式に発信されたことを証明するための電子メール認証プロセスです。この方式では、送信ドメインが公開鍵をDNSレコードに登録し、送信サーバーがメールにデジタル署名を添付します。受信メールサーバーはその公開鍵を用いて署名を検証し、メールの真正性や改ざんされていないことを確認します。
例えば、example.comのDKIMレコードは以下ような形式でDNSに登録されます。
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrZyp6x0Clmu..."- selector: DKIMのセレクタで、同じドメインで異なるDKIMキーを区別するために使用されます。セレクタは、実際には任意の文字列であり、メールを送信するシステムや用途によって異なるキーを使用したい場合に便利です。
_domainkey: これはDKIMレコードを示す標準的な固定テキスト。example.com: 実際のドメイン名に置き換えます。v=DKIM1: DKIMのバージョンを示します。現在DKIM1が唯一の有効な値。k=rsa: キーのタイプを示します。現在、DKIMで広く使用されているのはRSAキー。p=...: 公開鍵を示します。これは非常に長い文字列になることがあり、メールの署名を検証するために受信者によって使用される。
以下は、example.comのDKIM署名が付いたメールヘッダの例です：
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector;
c=relaxed/relaxed; q=dns/txt; i=@example.com; t=1518123456;
h=From:Subject:Date:To:Mime-Version:Content-Type;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSLRiVJbat+LhFd1EzRai/0DiFw1nSxwWGLCyzCJ
k2pdW3UTtOFT+1eDiB/pBkTy...;
ここで、d=example.comは署名ドメインを指し、s=selectorは署名に用いられる公開鍵のセレクタを指します。bhはメール本文のハッシュ値、bは署名データを表しており、これらを利用してメールの真正性が検証されます。
DMARCとは何か？
DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、電子メールにおけるなりすましの試みを防ぐために設計された電子メール認証プロトコルです。DMARCは、既存のSPF（Sender Policy Framework）とDKIM（DomainKeys Identified Mail）の認証手法を利用して、それらに基づいてドメインの所有者が電子メールの取り扱い方法を定義できるようにします。これにより、フィッシングやその他の詐欺的なメールが受信者の受信トレイに届くのを防ぎます。
DMARCの動作原理
DMARCポリシーは、ドメインのDNSレコードに追加されるテキストレコードを通じて公開されます。このレコードは、電子メールメッセージがSPFやDKIMの検証をパスしたかどうかに基づいて、メール受信サーバーがどのように行動すべきかを指示します。具体的には、以下の3つの指示が可能です。
- なにもしない（none） – DMARCポリシーの違反を報告するだけで、メッセージの取り扱いには影響しない。
- 隔離（quarantine） – メッセージをスパムフォルダなどの隔離エリアに移動させる。
- 拒否（reject） – メッセージを完全に拒否し、受信者の受信トレイに届かないようにする。
example.comのDKIMレコードは以下ような形式でDNSに登録されます。_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; fo=1;"- _dmarc.example.com.: DMARCレコードは、ドメイン名の前に
_dmarc.を付けたドメインに対して設定。この例では、example.comドメインのDMARCレコードを示しています。 - v=DMARC1: DMARCのバージョンを指定。現在は
DMARC1が唯一有効な値。 - p=reject: ポリシーを指定します。この場合、
rejectはDMARCの認証に失敗したメールを受信者が拒否するべきことを意味します。他のオプションにはnone（何もしない）やquarantine（隔離する）がある。 - rua=mailto:dmarc-reports@example.com: 集約レポートを送信するメールアドレスを指定。これらのレポートには、DMARCのポリシーに基づいたメールの処理結果が含まれる。
- ruf=mailto:dmarc-failures@example.com: 個々の失敗レポート（フォレンジックレポート）を送信するメールアドレスを指定。これらのレポートには、DMARCによって拒否または隔離された特定のメールに関する詳細が含まれる。
- fo=1: 失敗レポートのオプションを指定。
fo=1は、SPFまたはDKIMのいずれかが失敗した場合にレポートを生成することを意味します。他のオプションには0（両方が失敗した場合のみ）、d（DKIMの検証に失敗した場合）、s（SPFの検証に失敗した場合）がある。
DMARCの利点
- フィッシング詐欺の防止：DMARCは、フィッシング攻撃者が合法的なドメインから送信されたように見せかけることを困難にする。
- ブランド保護：企業は自社のドメイン名が詐欺目的で悪用されるのを防ぎ、ブランドイメージを保護できる。
- 透明性の向上：DMARCポリシーに違反するメールに関する報告を受け取ることで、企業は認証されないメールの流れをよりよく理解し、管理することができるようになる。
GoogleやYahooのメール送信ガイドラインとの関連性は？
GoogleやYahooは、2024年2月から、GoogleやYahooにメールを送信するアカウントに対し、SPF、DKIM、また1日に5,000件以上のメールを送信するアカウントに対しては追加でDMARCといったセキュリティメカニズムの実装を義務付ける新しいガイドラインを施行しました。特に大量のメールを送信する組織に対して、これらのメカニズムを適切に設定することが求められています。
また、GoogleやYahooはメール送信者に対して、DMARCのポリシーを「none」から始めて徐々に強化し（例えば「quarantine」や「reject」への移行）、不正なメールがユーザーに届くのを防ぐことを推奨している。
SPF、DKIM、およびDMARCなどのメールセキュリティメカニズムの実装を怠ると、以下のような問題が生じる可能性あり。
- メールがスパムとしてマークされる – メールが適切な認証を受けていない場合、多くのメールサービスプロバイダー（MSP）はそのメールをスパムや迷惑メールと見なします。これは、メールが受信者の受信トレイに届く代わりに、スパムフォルダに直接送られることを意味し、その結果、重要なメールが見逃されたり、完全に無視されたりする可能性がある。
- メール配信率の低下 – 認証されていないメールは、メールサーバーによって拒否されることがよくあります。これは、特に企業にとっては、顧客やクライアントとのコミュニケーションが妨げられ、信頼性の低下や機会の損失につながる可能性がある。
- ブランドの信頼性と評判の損失 – 上記と同じ理由で、信頼性の低下や機会の損失につながる可能性がある。
これらのレコードを設定するプロセスは複雑で時間がかかる場合があり、ポリシーが厳しすぎたり緩すぎたりすると、ドメインに大きな悪影響を及ぼす可能性もあります。ポリシーが厳しすぎると、正当なメールまでブロックされる可能性がありますし、緩すぎるとスパムやフィッシングメールの受信リスクが高まります。そのため、これらのレコードを設定する際には、会社のセキュリティポリシーを参考にしつつ、必要なセキュリティレベルを慎重に検討することが重要でしょう。
