XserverドメインとGmailでSPF、DKIM、DMARCを設定する

Googleのフリーメールサービスとして有名な「Gmail」、利用者も大変多いかと思います。

このGmailですが、2023年10月ころに新しい「メール送信者のガイドライン」が発表されました。メールのなりすましを防ぐため、ユーザーに対してより厳格なセキュリティ対策をするよう要求しています。

具体的には、送信ドメイン認証である「SPF」「DKIM」「DMARC」へ対応するように求めています。これが達成されないと、Gmailへ送るメールが迷惑メールとして分類されたり、受信を拒否されたりとメール到達率が低下する恐れがあります。

2024年2月以降から順次実施予定で、最初は1日5000件を超えるような一括送信者に対してガイドラインが適用されるようですが、今後はより広い範囲のユーザーに適用される可能性が高いです。特に独自ドメインを利用している場合は早めの対処が必要です。

今回は、独自ドメインとGmailの組み合わせとして多いと思われる「Xserverドメイン」を一例に、独自ドメインを使用したGmailで送信ドメイン認証が行えるよう設定してみたいと思います。

送信ドメイン認証

近年、電子メールを起点とした情報の漏洩や金銭被害が拡大しています。

取引先の問い合わせメールや、配達業者からの配達メールなどを装ってマルウェアに感染させたり、機密情報を入力してしまったりして情報漏洩、金銭被害が発生してしまった事例は数多くあります。

現在の電子メールの技術では、送信元とされるFromアドレス（ヘッダーFrom）を簡単に書き換えることができ、一見すると正規のメールアドレス（ドメイン）から送られてきたように見える「なりすまし」が容易な状態となっています。このため、単純なアドレスチェックでは見抜けない可能性が高くなっています。

このメールのなりすましを防ぐため、「SPF」「DKIM」「DMARC」と呼ばれる「送信ドメイン認証」を利用することが近年、特に推奨されています。

これは送信元となるメールサーバーのIPアドレスや、ドメインのDNSレコードを参照しながら、かつ電子署名の仕組みを利用してメールがなりすまされていないかを確認する技術です。

この記事では簡単な説明にとどめます。詳細な技術内容に関しては、また別のウェブサイトを参考にしてください。

SPF （Sender Policy Framework）

通常、メールのなりすましは送信元となるメールサーバーまで乗っ取られていることは希です。

SPFは、メール受信サーバーで受信したメールに対して、メールを送ってきたメールサーバーのIPアドレスと送信元のドメインと紐付いているSPFレコードを照会することで、メール送信元が改ざんされていないかを確認します。

ドメインのDNSレコードに予め、送信元メールサーバーのIPアドレスなどの情報を記録したSPFレコードを登録しておくことで、正規のメールかどうかを検証することができるようになります。送信元メールサーバーのIPアドレスと、SPFレコードで登録されているIPアドレスを照会し、適合しなければなりすましメールであると判別できます。

「Xserverドメイン」と「Gmail」の組み合わせの場合は、数クリックで簡単に設定できます。

DKIM （DomainKeys Identified Mail）

DIKMは、送信側では送信するメールに対して「電子署名」を付与し、受信側ではメール受信時にその署名が正しいメールサーバーから送られてきたものかを、ドメインのDNSレコードに登録されている公開鍵を使って検証します。

因みに、読み方は「ディーキム」のようです。

いわゆる「秘密鍵」と「公開鍵」の組み合わせで検証する「公開鍵暗号方式」を利用した送信ドメイン認証です。

送信メールサーバー上では、秘密鍵を所有したもののみが作れる「電子署名」をメールに付与します。秘密鍵に対する公開鍵はDNSレコード上で予め登録しておきます。受信メールサーバーでは、ドメインのDNSレコードに登録されている公開鍵を使って、受信したメールに付与されている電子署名を検証します。

メールの内容も含めて電子署名とするため、仮に途中でメール内容が改ざんされたとしてもDKIMに適合しなくなります。DKIMでは、送信元のほかメール内容の完全性も保証することができます。

「Xserverドメイン」と「Gmail」の組み合わせの場合は、Gmial側で「DKIM 鍵」を作成して「Xserverドメイン」のDNSレコードに登録する作業が必要になります。

DMARC （Domain-based Message Authentication、Reporting and Conformance）

DMARCは、上記のSPFやDKIMからさらに追加の認証を行うことで、より厳重な改ざん防止を行います。

因みに、読み方は「ディーマーク」のようです。

DMARCでは、新たに「識別子アライメント（Identifier Alignment）」と呼ばれる概念が導入されました。DMARCは、メールに表示されている送信元アドレス（ヘッダーFrom）と、SPFとDKIMで認証を行ったドメインが一致しているかを追加で検証します。SPFとDKIMの両方が設定されていれば両方にチェックが入ります。

また、ヘッダーFromのドメインとSPFで認証したドメインが一致することを「SPFアライメント（SPF調整）」、DKIMで認証したドメインと一致することを「DKIMアライメント（DKIM調整）」と呼びます。

SPFとDKIMで送信元の証明を行い、追加でドメインの改ざんまで行われていないかをDMARCで確認することで、メールのなりすましをより防ぐことができます。

SPFとDKIMの認証が通っても、ドメインの一致性が確認できなければアライメントは失敗します。ただ、SPFとDKIMのどちらか一方で認証とアライメントが成功していればDMARC認証は合格となるため、DMARC認証が合格となった場合でも、SPFとDKIMの認証とアライメントがすべて合格となっているかどうかは確認が必要です。

また、SPF、DKIM、DMARCによる認証が失敗となったとき、つまり「メールのなりすましや改ざんが疑われる」と判断されたときに、そのメールをどのように扱うかをルールとして事前に決めることもできます。これを「DMARCポリシー」と呼びます。

メール送信側は、SPFやDKIMによる認証失敗時の推奨アクションを事前にDNSレコードへ「DMARCレコード」として登録しておきます。メール受信側はDMARCレコードが確認できると、DMARC認証を開始して合格するかチェックします。DMARC認証に失敗した場合は「DMARCポリシー」に従ってメールを処理します。

認証失敗時の処理は「none（何もしない）」「quarantine（検疫）」「reject（拒否）」の3つが指定できます。「none」はDMARC認証に合格せずともそのまま受信します。「quarantine」は迷惑メールのフラグを立てるなどして一旦隔離するよう指示します。「reject」はそもそも受信しないよう指示します。

また、合否についてレポートをメール送信側へ報告する機能も持っています。これにより、相手側のDMARC認証の合否を送信側でもある程度確認できるようになりました。

「Xserverドメイン」では簡単に「DMARCレコード」を設定できる項目があります。

Gmailの新しいガイドライン

世界最大規模のフリーメールサービス「Gmial」ですが、新しく「メール送信者のガイドライン」が発表されました。

特にメールのなりすまし被害を防ぐため、上記の「送信ドメイン認証」を設定していない場合、Gmial宛てのメールが届かない場合がでてくると発表されています。

現時点ではまだ「一括送信者」に対して適用されるようですが、今後段階的に全ユーザーにも適用されることが予想されますので、早めの対策が必要かと思います。

XserverドメインとGmailの組み合わせで送信ドメイン認証を設定する

利用しているメールサーバー（メールサービス）やドメインの管理場所によって設定方法が変わってきますが、今回は個人・中小企業での利用が多いと思われる、Xserverによるドメインサービス「Xserverドメイン」と「Gmail」の組み合わせを例として「SPF」「DKIM」「DMARC」の3つを設定していきたいと思います。

前提として、「Xserverドメイン」を契約して独自ドメインを取得していること、「Xserverドメイン」で取得した独自ドメインをGmail（Google Workspace）ですでに運用していることを想定しています。

SPFの設定

「Xserverドメイン」を契約していて追加している場合、自動でSPFは設定されていますが、一度確認してみます。

DKIMの設定

DKIMを設定するためには、GmailのDKIM 鍵を取得する必要があります。

DMARCの設定

DMARCは、Xserver側での設定となります。DMARCポリシー設定を行います。

Xserverのサーバーパネルにログインし、「メール」→「DMARC設定」を開きます。

DMARCポリシー設定

SPF、DKIM、DMARCなどの認証で合格せず、対象ドメインが第三者に利用されたと疑われる場合、受信側のメールサーバーに対して対処方法を指示します。

何もしない

なりすましや改ざんが行われた場合でも、メールをそのまま受信するようにします。DMARCレコードにおける「none（何もしない）」になります。ただ、実際はSPF、DKIMの認証が通らないことから受信側のポリシーによって検疫されることが多いと思われます。

迷惑メールとして配送する

なりすましや改ざんを検知した場合、配送先メールサーバーに対して迷惑メールとして扱うよう指示します。DMARCレコードにおける「quarantine（検疫）」になります。

メールを配送しない

なりすましや改ざんを検知した場合、配送先メールサーバーに対して受信しないよう指示します。DMARCレコードにおける「reject（拒否）」になります。

レポート通知をONにした上で、しばらくは「何もしない」で様子を見ます。レポートから送信したメールの認証状況に問題がないことを確認したら、「迷惑メールとして配送する」「メールを配送しない」などに変更してセキュリティ強化に努めます。

特にDMARCポリシーは1つのドメインに対して1つしか設定できないため、例えば1つのドメインでカスタマーサービスやマーケティングなど広く利用している場合、そのドメインを利用しているすべてのメールでDMARCポリシーが適用されます。

場合によっては影響範囲が大変広くなるので、送信したメールすべてが送信ドメイン認証の合格を貰っているかどうか、注意深く観察します。

レポート通知設定

SPF、DKIM、DMARCなどの合否状況についてレポートを通知します。

「ON」に設定し、「通知先メールアドレス」にレポートを受信するメールアドレスを入力すると、DMARCレポートが送信されます。

メールがどのメールサーバーから配信されているか、送信ドメイン認証の結果がどのようになっているかを確認できます。管理しているドメインから送信されるすべてのメールについて、DMARC認証に合格していることが確認できれば、DMARCポリシーを「迷惑メールとして配送する」「メールを配送しない」へ変更します。

メールの送信数によりますが、大量に送っている場合はレポートの数も膨大になる可能性があるため、レポート送信先のメールアドレスはレポートを受信する専用のものを用意することが推奨されています。

また、設定するメールアドレスはDMARCレコードで設定しているドメインである必要があります。例えば、「example.jp」でDMARCを設定したのであれば、レポート送信先もexample.jpに属するアドレスである必要があります。

別のドメインのメールアドレスへ送りたい場合は、相手側のドメインのDNSレコードで相互の関係性を指定する必要があります。詳細は以下のWebサイトの「2.3.3 DMARCレポートの委譲」をご確認ください。

オプションの追加 （rufタグの追加）

DMARCには必須項目の他にもオプション（任意）となる項目があります。

先ほど、「レポート通知設定」にてレポート送信先を指定しましたが、DNSに登録されるDMARCレコードを確認すると、2つあるDMARCレポートのうち「ruaレポート（集計レポート）」の送信先のみ設定されているようでした。

DMARCレポートは、一定期間内の認証結果を集計した「ruaレポート（アグリゲートレポート：集計レポート）」と、DMARC認証に失敗した個々のメールについて通知する「rufレポート（フォレンジックレポート：失敗レポート）」があります。

どちらかというと大事なのは認証に失敗した個々のメールがピンポイントで分かるrufレポートの方なので、レポートが送信されるよう手動で設定してみます。

ただ、現時点ではrufレポートを送信してくれるサーバーが少ないようなので、メールマガジンのように大量のメールを送信していなければ、実際にrufレポートが送られてくることは珍しいかもしれません。（Gmailもrufタグには対応していない様子。）

サーバーパネルにログインして「ドメイン」→「DNSレコード設定」を開き、「DNSレコード一覧」からDMARCレコード（ホスト名が「_dmarc.example.jp」など）を探して「変更」をクリックします。

「内容」でTXTレコードが編集できます。DMARCレコードは各項目を「;（セミコロン）」で区切ります。

rufレポートの送信先を指定したい場合は、「ruf=mailto:送信先メールアドレス」と追記してください。

追加した場合は最終的に以下のようなTXTレコードになるかと思います。

v=DMARC1; p=認証失敗時の処理方法指定; rua=mailto:ruaレポート送信先; ruf=mailto:rufレポート送信先;

DMARCレポートの見方

標準設定では1日に1回、レポートが送信されます。XML形式のファイル、またはそれをアーカイブ（zipやgzなど）にしたファイルが送信されます。

ここにはSPF、DKIMの認証結果やアライメントの認証結果などが記録されています。

レポートの見方まで書いていると長くなってしまうため、こちらは別のウェブサイトを参照してください。

送信ドメイン認証が合格（PASS）しているか確認

設定したドメインでメールを送信し、それぞれの送信ドメイン認証が合格しているかどうかを確認します。

今回はGmailのガイドライン更新によって「gmail.com」宛てのメールが受信されなくなる場合があるとのことでしたので、Gmail宛てにメールを送信し、メールヘッダの情報を確認してみます。

送信ドメイン認証を設定したドメインでメールをGmail宛てに送信します。Web版のGmailを開き、受信したメールの右にある三点マークをクリック、メニューから「メッセージのソースを表示」をクリックします。

メールヘッダの情報が確認できます。Gmailでは特に「SPF」「DKIM」「DMARC」の3つの認証状況がわかりやすく確認できるようになっています。

それぞれのドメイン認証の項目がすべて「PASS」となっていれば合格です。「DKIM」では設定したドメインになっているかも確認します。認証が通っていない場合は項目自体が無くなるか、または「FAIL」と表記されます。

Gmail以外でも、メールヘッダを確認すればそれぞれの認証状況が確認できます。メールヘッダから確認する場合は、「ARC-Authentication-Results」という項目に認証状況が記されています。それぞれの送信ドメイン認証が「pass」となっていれば認証が成功しています。「fail」などpass以外の表示となっていれば認証が失敗しています。

また、SPFとDKIMの両方を設定しているとき、DMARC認証はSPFとDKIMどちらか一方の認証とアライメントが成功していれば合格となるため、もう片方のアライメントが失敗している場合もあり得ます。メールヘッダでSPF、DKIMで検証されているドメインと、ヘッダーFromのドメインを比較すれば両方のアライメントが成功しているか確認できます。

また、他にもWeb上でチェックできるツールがありますので、それらで確認する方法もあります。

例えば、以下のようなチェックツールでは「SPF」「DKIM」「DMARC」それぞれの認証についてどのように設定されているかを確認してくれます。

まとめ

長くなりましたが、これでXserverドメインとGmailという組み合わせでの送信ドメイン認証「SPF」「DKIM」「DMARC」の設定方法を一通り解説できたかと思います。

今回のGmailの新しいガイドラインではまだ影響範囲が限定的となっていますが、これからすべてのユーザーに対して対応を求める可能性もあるため、早めに対策を行うのがよいかと思います。

実際、セキュリティ対策としても重要な要素なので、Gmail以外でも効果は発揮されます。メールの信頼性が上がれば業績にも好影響を与えることができますので、なるべく設定をしてみましょう。

特に企業規模が大きいとDMARCレポートの量が膨大になるので、専門の解析ツールの導入も検討します。DMARCは設定した後が本番となるので、余裕を持った対応を心がけたいところです。