小西秀和です。
2024年2月1日以降、Gmailでは迷惑メール削減を目的として、Gmailアカウントにメール送信する送信者は送信元アドレスのドメインにDKIM(DomainKeys Identified Mail)、SPF(Sender Policy Framework)の設定が必要となりました。
また、Gmailアカウントに1日あたり5000件以上のメールを送信する場合にはDMARC(Domain-based Message Authentication, Reporting, and Conformance)の設定も必要となっています。
参考：Email sender guidelines - Google Workspace Admin Help
このような事情から最近再びDKIM, SPF, DMARCの設定に関する話題が多くなっていたので、今後の新規ドメインによるメール送信も考慮し、改めてAmazon SESとAmazon Route 53によるDKIM, SPF, DMARCの設定について個人的に調査した内容を備忘録としてまとめておきたいと思います。
加えて、今回はAmazon Route 53ではなく別のDNSサービスを使用している場合のレコード設定に関する注意点や DMARCパラメータの概要と設定例も記載しておきたいと思います。
※本記事および当執筆者のその他の記事で掲載されているソースコードおよび設定内容は自主研究活動の一貫として作成したものであり、動作を保証するものではありません。使用する場合は自己責任でお願い致します。また、予告なく修正することもありますのでご了承ください。
※本記事執筆にあたっては個人でユーザー登録したAWSアカウント上でAWSサービスを使用しています。
今回の記事の内容は次のような構成になっています。
- DKIM, SPF, DMARCの概要
- Amazon SESにおけるDKIMとSPFの設定
- Amazon SESにおけるDMARCの設定
- GmailアカウントにおけるDKIM, SPF, DMARCの確認
- まとめ
DKIM, SPF, DMARCの概要
Amazon SESとAmazon Route 53の具体的な設定を見ていく前にDKIM, SPF, DMARCの概要について説明します。
DKIM、SPF、DMARCという3つの主要な技術は電子メールセキュリティを向上させることを目的とし、メール送信時の認証プロセスの強化、フィッシングやスプーフィングなどの不正行為の防止をするように設計されています。
これら3つの技術は、互いに補完しあいながら、メールベースの攻撃に対して堅牢なセキュリティを提供します。
ドメインの所有者はこれらの技術を適切に設定し運用することで、不正なメール送信を防ぎ、送信者の信頼性を高めることができます。
以下では、それぞれの技術について簡単に解説します。
DKIMとは
DKIM(DomainKeys Identified Mail)は、電子メールの送信者がそのメールが正当なものであることを受信者に証明するためのメカニズムです。
DKIMは電子メールにデジタル署名を付加し、この署名は送信者のドメインに関連付けられた公開鍵によって検証されます。
受信者は公開鍵(DNSレコードに公開されている)を使用して署名を検証し、メールが改ざんされていないことを確認します。
これにより、メールの真正性と完全性が保証されます。
SPFとは
SPF(Sender Policy Framework)は、ドメインから送信されるメールの送信元を検証するための技術です。
ドメインの所有者はDNSレコードにSPFレコードを設定し、そのドメインから送信が許可されているIPアドレスを公開します。
受信メールサーバーはこのレコードを参照し、メールが許可されたIPアドレスから送信されたものかどうかを確認します。
これにより、偽装されたメールの送信を防ぐことができます。
DMARCとは
DMARC(Domain-based Message Authentication, Reporting, and Conformance)は、DKIMとSPFの認証結果に基づいて、ドメインの所有者がどのようにメールを取り扱うかを指示するためのポリシーです。
DMARCポリシーはDNSレコードに設定され、認証に失敗したメールの取り扱い(報告のみ、隔離、拒否)を指定します。
また、認証結果とポリシー違反に関する報告をドメインの所有者に送信することで、メールの認証プロセスを透明にし、ドメインの評判を守ります。
Amazon SESにおけるDKIMとSPFの設定
ここからは、Amazon SESとAmazon Route 53の具体的な設定の説明をしていきたいと思います。
Amazon SESを使用すればDKIMとSPFの設定は簡単にできます。
さらにドメインのネームサーバーにAmazon Route 53を使用していればHosted zoneへのDNSレコード設定も自動的にしてくれます。
Amazon SESでは自動的にamazonses.comのサブドメインをデフォルトのMAIL FROMドメインとしてメッセージ送信をします。
このデフォルトのMAIL FROMドメインはメールを送信したAmazon SESアプリケーションと一致するため、デフォルトの状態でもSPF認証のメッセージ検証をPASSします。
ただし、MAIL FROMドメインに自分が所有する独自ドメインのサブドメインを使用したい場合にはAmazon SESの「Custom MAIL FROMドメイン」を設定する必要があります。
また、後述するDMARCにAmazon SESを準拠させるためには、SPFによってDMARCに準拠する方法と、DKIMによってDMARC に準拠する方法のいずれか、または両方を実施する必要があります。
このAmazon SESでSPFによってDMARCに準拠する方法では、「Custom MAIL FROMドメイン」を設定する必要があります。
参考：
Using a custom MAIL FROM domain - Amazon Simple Email Service
Complying with DMARC authentication protocol in Amazon SES - Amazon Simple Email Service
これらのことから、今回の記事ではデフォルトのMAIL FROMドメイン「amazonses.com」ではなく、独自ドメインのサブドメインを使用するように「Custom MAIL FROMドメイン」の設定を含む例で説明したいと思います。
Amazon Route 53を使用している場合
ドメインのネームサーバーにAmazon Route 53を使用し、Hosted zoneを作成している場合は次の手順でDKIMとSPFを設定できます。
- AWSマネジメントコンソールにログインする。
- Amazon SES > Verified identities > Create identity と画面遷移する(「Create identity | Amazon Simple Email Service | us-east-1」画面を開く)。
- 次の設定例を参考に画面の項目を設定し、「Create identity」ボタンを押下する(設定値は要件に応じて変更してください)。
- Identity detailsの設定
Identity type: 「Domain」を選択。
Domain: メール送信に使用するドメインを入力。
Use a custom MAIL FROM domain: チェックボックスにチェックを入れる。
MAIL FROM domain: Custom MAIL FROM domainで使用するサブドメインを入力する。
Behavior on MX failure: 「Use default MAIL FROM domain」を選択する。
Publish DNS records to Route53: 「Enabled」にチェックを入れる。 - Verifying your domainの設定
「Advanced DKIM settings」メニューを開く。
Identity type: 「Easy DKIM」を選択する。
DKIM signing key length: 「RSA_2048_BIT」を選択する。
Publish DNS records to Route53: 「Enabled」にチェックを入れる。
DKIM signatures: 「Enabled」にチェックを入れる。
- Identity detailsの設定
上記の設定のうち「Identity details」の「Custom MAIL FROM domain」がSPF設定に関係しており、「Verifying your domain」がDKIM設定に関係しています。
「Create identity」画面の設定例を以下にスクリーンショットで示します(この例はDomainにho2k.comを設定し、MAIL FROM domainにemail.ho2k.comを設定した場合です)。
「Create identity」を実行すると「Verified identities」にメール送信に使用するドメインが追加され、DKIMとCustom MAIL FROM domainの検証に必要なDNSレコードがAmazon Route 53に自動追加されます。
DKIMとCustom MAIL FROM domainの検証のためにAmazon Route 53へ追加されるのDNSレコード例を示すと次のようになっています(この例はDomainにho2k.comを設定し、MAIL FROM domainにemail.ho2k.comを設定した場合です)。
DKIMの検証用DNSレコード
| Type | Name | Value |
|---|---|---|
| CNAME | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx._domainkey.ho2k.com |
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.dkim.amazonses.com |
| CNAME | yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy._domainkey.ho2k.com |
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy.dkim.amazonses.com |
| CNAME | zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz._domainkey.ho2k.com |
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.dkim.amazonses.com |
Note: digコマンドなどでAmazon SESのDKIM設定で使用する3つの検証用DNSレコードを確認すると、そのうち2つが空の文字列（""）になることがあります。
ただし、これは正常な動作で、SESの公開鍵ローテーションプロセスの一部です。
新しいキーが生成され、古いキーが段階的に削除される過程で、空のレコードは使用されなくなったキーを示し、セキュリティを維持するために必要な処理となります。
この現象は設定の誤りではなく、自動的なキー更新プロセスによるものです。
以下にdigコマンドでDKIM検証用DNSレコードを確認した場合の出力例を示します。
[ho2k_com@ho2k-com ~]$ dig TXT xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx._domainkey.ho2k.com +short xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.dkim.amazonses.com. "p=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" "BBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB" [ho2k_com@ho2k-com ~]$ dig TXT yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy._domainkey.ho2k.com +short yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy.dkim.amazonses.com. "" [ho2k_com@ho2k-com ~]$ dig TXT zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz._domainkey.ho2k.com +short zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.dkim.amazonses.com. ""
参考：DKIM Troubleshooting Series: Your DKIM Status is Pending | AWS Messaging & Targeting Blog
Custom MAIL FROM domainの検証用DNSレコード
| Type | Name | Value |
|---|---|---|
| MX | email.ho2k.com |
10 feedback-smtp.us-east-1.amazonses.com |
| TXT | email.ho2k.com |
"v=spf1 include:amazonses.com ~all" |
Note: 上記の例では"v=spf1 include:amazonses.com ~all"をValueにもつTXTレコードがSPFレコードに該当します。
Amazon Route 53を使用していない場合(他のDNSサービスを使用している場合)
他のDNSサービスを使用しているなどAmazon Route 53を使用していない場合には前述の手順において「Publish DNS records to Route53」の項目で「Enabled」にチェックを入れずに「Create identity」を実行します。
その後、「Verified identities」から対象のドメインの画面に遷移し、表示されたDKIMおよびCustom MAIL FROM domainの検証用DNSレコードを使用しているDNSサービスのゾーンに設定する必要があります。
他のDNSサービスにDKIMおよびCustom MAIL FROM domainの検証用DNSレコードを設定する場合の主な注意点は以下になります。
- CNAMEレコード、MXレコードはValueの末尾に「.」(ドット)を付けて入力する。
- TXTレコードはValueを「"」(ダブルクォーテーション)で囲んだまま入力する。
これらの点を実施しない場合にはAmazon SES側でDKIMおよびCustom MAIL FROM domainの検証が正常に完了しない場合があるので気をつけたほうが良いでしょう。
Amazon SESにおけるDMARCの設定
Amazon SESにおいてDMARCを設定するには、DMARCポリシーを登録するDMARCレコードをDNSサービスのゾーンに追加します。
これはAmazon Route 53を使用している場合も使用していない場合も共通です。
次にDMARCレコードにおけるパラメータの説明とDMARCレコードの例を示します。
DMARCレコードのパラメータ
以下の表は、DMARCのパラメータとそれぞれのパラメータ値の簡単な説明を含めたものです。
このパラメータを使用してDMARCレコードにDMARCポリシーを設定します。
| パラメータ | 概要 |
|---|---|
| adkim | DKIM認証識別子のアライメントモード (r = relaxed, アライメントは部分的な一致で許容; s = strict, 完全一致が必要) |
| aspf | SPF認証識別子のアライメントモード (r = relaxed, アライメントは部分的な一致で許容; s = strict, 完全一致が必要) |
| fo | 失敗レポートのオプション (0 = 両方の認証手法が失敗した場合のみレポート, 1 = いずれかの認証で失敗したらレポート, d = DKIM検証失敗のみレポート, s = SPF検証失敗のみレポート) |
| p | メール受信者に要望する認証失敗時の動作 (none = 行動を取らず報告のみ, quarantine = メールを隔離 (例: スパムフォルダへ移動), reject = メールの受信を拒否) |
| pct | ポリシーを適用するメールの割合 (0〜100, デフォルトは100; 指定された割合でポリシー適用) |
| rf | 失敗レポートの形式 (afrf = 認証失敗報告書式, iodef = インシデントオブジェクト交換フォーマット) |
| ri | 集約レポートの送信間隔 (秒数で指定、デフォルトは86400秒=24時間; レポートの頻度を制御) |
| rua | 集約レポートの送り先 (URIで指定; 例: mailto:example@example.com) |
| ruf | 失敗レポートの送り先 (URIで指定; 例: mailto:fail@example.com) |
| sp | サブドメインに対するポリシー (none, quarantine, reject; メインドメインのポリシーと異なる場合に指定) |
| v | バージョン番号 (現状 DMARC1 のみ; DMARCのバージョンを指定) |
DMARCのアライメント(Alignment)について
DMARCにおけるアライメントは、電子メール認証プロセスにおいてメールが正当な送信者から来たことを確実にするための機能です。
アライメントによってDMARCはDKIMとSPFの両方の認証結果を厳格に評価してドメイン名の一致を検証します。
次にアライメントの概念と設定がDMARCポリシーにどのように効果を発揮するかについて記載します。
アライメントとは
アライメントは電子メールのFromヘッダー内のドメインがDKIM署名のd=タグやSPFのReturn-Pathで使用されるドメインとどのように一致するかを評価します。
この評価はメールが正規の送信源から来ているかどうかを判定するためのものです。
DMARCではDKIMのアライメント(adkim)、SPFのアライメント(aspf)があり、それぞれrelaxed(緩和)とstrict(厳格)の2種類のアライメントモードがあります。
アライメント設定はDMARCポリシーの効果を調整するためのもので、relaxedモードはより柔軟な認証を可能にし、正当なメールが誤って拒否されること(False Positive)のリスクを減らしますが、strictモードはより厳格な認証を提供し、セキュリティを強化しますが設定の不備によって不正なメールが許可されること(False Negative)のリスクが高まります。
ドメインの所有者は自身のセキュリティニーズとリスク許容度に基づいて適切なアライメントモードを選択する必要があり、正確なアライメント設定が不正なメール送信を防ぎ、正当なメールの配信を確実にするために不可欠です。
DKIMのアライメント(adkim)
- Relaxedモード (
r): このモードでは、送信ドメインとDKIM署名のドメインが部分的に一致していれば良いとされます。具体的には、サブドメインが異なる場合でも、メインのドメインが一致していれば合格とみなされます。 - Strictモード (
s): こちらのモードでは、完全なドメイン名の一致が必要です。つまり、サブドメインを含めた全てが一致しなければなりません。
SPFのアライメント(aspf)
- Relaxedモード (
r): SPFにおいても、relaxedモードではメインのドメインが一致していれば良いとされ、部分的な一致が許容されます。 - Strictモード (
s): こちらでは、メールのReturn-PathドメインとFromヘッダーのドメインが完全に一致する必要があります。
参考：
DMARC 詳細仕様-2 | なりすまし対策ポータル ナリタイ
Define your DMARC record - Google Workspace Admin Help
DMARCレコードの例
前述のDMARCレコードパラメータを使用したDMARCレコードの例を挙げると次のような記述になります。
| Type | Name | Value |
|---|---|---|
| TXT | _dmarc.ho2k.com |
"v=DMARC1; p=none; rua=mailto:dmarc@ho2k.com; ruf=mailto:dmarcfail@ho2k.com; sp=none; pct=100" |
このDMARCレコードの例では、以下のような設定をしています。
v=DMARC1: これはDMARCのバージョンを示しており、現在のバージョンDMARC1を使用しています。DMARCレコードではこのフィールドが最初に来る必要があり、DMARCポリシーの宣言であることを示します。p=none: これはドメインの所有者がDMARCに準拠していないメールに対して取るべき行動を指定しています。noneは、DMARCに準拠していないメールに対して特に行動を取らないことを意味しますが、報告は受け取ります。このモードは、主にポリシーの監視とトラブルシューティングのために使用され、実際のメールの拒否や隔離を行わない「監視モード」とも呼ばれます。rua=mailto:dmarc@ho2k.com: これは集約されたDMARC報告を受け取るメールアドレスを指定しています。集約報告は、DMARCに準拠しているかどうかに関わらず、ドメインから送信されたメールの概要を提供します。これらの報告は、通常、一日に一度送信されます。ruf=mailto:dmarcfail@ho2k.com: これはDMARCに準拠していない個別のメールに関する失敗報告（フォレンジックレポート）を受け取るメールアドレスを指定しています。これらの報告は、ポリシー違反の詳細な情報を提供し、問題の診断に役立ちます。sp=none: これはサブドメインに適用されるポリシーを指定しており、noneはサブドメインに対してもメインドメインと同様にDMARCポリシーに準拠していないメールに対して特に行動を取らないことを意味します。pct=100: このパラメータは、ポリシーが適用されるメールの割合を指定しています。100は、ドメインから送信される全てのメール（100%）がこのDMARCポリシーの対象であることを意味します。
このDMARCレコードではメール送信の認証状態を監視し、認証失敗に関する詳細な情報を収集することを目的としており、受信者側でのメールの扱いには影響を与えません。
これにより、ドメインの所有者は認証の問題を特定し、解決するための情報を得ることができます。
また、将来的にquarantineやrejectなどのより厳格なポリシーに変更する前の準備段階としても使用できる内容です。
ただし、これはあくまで例なので実際にDMARCレコードを設定する際には要件に応じてDMARCポリシーにあったDMARCパラメータの設定をしてください。
ruaとrufで指定している場合にはメールアドレスにはレポートが送信される可能性があるため、メールを受信できるメールサーバーを構築するか、Amazon SESで「Email receiving」の設定をしてメールを受信できるようにする必要があります。
Amazon SESで「Email receiving」を設定する方法については次のAWSドキュメントを御覧ください。
Email receiving with Amazon SES - Amazon Simple Email Service
GmailアカウントにおけるDKIM, SPF, DMARCの確認
DKIM, SPF, DMARCを設定したAmazon SESから実際にGmailアカウントへメールを送信してDKIM, SPF, DMARCをそれぞれPASSしているかを確認します。
Amazon SESからテストメールを送信するには「Verified identities」から対象のドメインの画面に遷移し、右上の「Send test email」ボタンから「Send test email」画面に遷移し、自分自身が利用しているGmailアカウントにテストメールを送信します。
「Send test email」画面の使い方については次のAWSドキュメントを御覧ください。
Sending test emails in Amazon SES with the simulator - Amazon Simple Email Service
Gmailアカウントで受信したテストメールを開き、右上の三点リーダ「︙」から「Show original(メッセージのソースを表示)」を選択すると、次の「Original Message(元のメッセージ)」の画面例のようにDKIM, SPF, DMARCの項目がそれぞれPASSとなっていることを確認できます(この例はho2k.comをドメインとしてメール送信した場合です)。
参考：
Email sender guidelines - Google Workspace Admin Help
Define your DMARC record - Google Workspace Admin Help
What is Amazon SES? - Amazon Simple Email Service
Tech Blog with related articles referenced
まとめ
今回は、Amazon SESとAmazon Route 53を用いてDKIM、SPF、DMARCの設定を行う方法、およびAmazon Route 53以外の他のDNSサービスを使用する際の注意点について解説しました。
さらに、DMARCポリシーをDMARCレコードに設定するためのパラメータと、その設定例についても触れました。
そして、実際にAmazon SESを使用してGmailアカウント宛に送信したメールが、DKIM、SPF、DMARCの各認証をPASSしたことを確認できました。
Amazon SESとAmazon Route 53を併用することで、Eメール送信サービスにおけるDKIM、SPF、DMARCの設定を容易に行うことが可能です。
Amazon SESとAmazon Route 53が活かせる場面では、その利点を最大限に活かしつつ、今後も新しいアップデートに注目していこうと思います。
- [English Edition] Setting up DKIM, SPF, DMARC with Amazon SES and Amazon Route 53 - An Overview of DMARC Parameters and Configuration Examples
