【ITニュース解説】Catch Broken Email DNS Before Your Client Hears “Your Messages Are Bouncing”

企業が顧客とやり取りする上で、メールは非常に重要なツールだ。顧客からの問い合わせや注文メールが届かない事態は、ビジネスにとって大きな損失となりかねない。ウェブサイトが問題なく表示され、社内のメールシステムも正常に稼働しているように見えるのに、顧客からのメールが届かない、または顧客に送ったメールがエラーで戻ってきてしまうという状況は、実は珍しいことではない。このような場合、多くの場合、メールの送受信を制御するDNS（Domain Name System）レコードに問題がある可能性が高い。

ウェブサイトの表示は、ドメイン名がどのサーバーを指しているかを示すAレコードやCNAMEレコードといったDNSレコードに依存する。しかし、メールの送受信はこれらのレコードとは異なる、専用の4つのDNSレコードによってコントロールされている。そのため、ウェブサイトが正常に稼働しているかを確認するだけの監視では、メールのトラブルを見つけることはできない。顧客がメールのエラーに最初に気づき、それをクライアントに伝え、クライアントがシステムの担当者に連絡する頃には、既に多くのビジネスチャンスが失われているかもしれない。担当者は、顧客がトラブルの「監視システム」になる前に、これらの重要なDNSレコードを外部から監視し、異常があれば事前にクライアントに警告できる立場にある。

メール送受信に影響を及ぼす4つの主要なDNSレコードは以下の通りだ。

一つ目は「MXレコード（Mail Exchanger Record）」である。これは、特定のドメイン宛てのメールをどのメールサーバーに配送すべきかを他のすべてのメールサーバーに伝える役割を持つ。例えば、「dig example.com MX +short」とコマンドを実行すると、そのドメインのMXレコードが表示され、メールが配送されるべきサーバーのアドレスを確認できる。MXレコードが壊れる主な原因は、ドメインを新しいDNSプロバイダへ移行した際に古い情報が残ったり、新しい情報が正しく設定されなかったりする場合だ。また、企業内でドメインの管理者が変更され、新しい担当者が記憶に基づいてDNS設定を再構築した際にも誤りが生じることがある。MXレコードが間違っている場合、メールはすぐにエラーになるわけではない。間違ったサーバーが稼働していれば、メールはそこに配送されてしまい、誰も読まないメールボックスに永遠に届かない状態になる。もし指定されたサーバーが存在しない場合でも、送信元サーバーは数日間メールの再送を試みるため、すぐに問題に気づきにくい。このMXレコードは通常めったに変わらないため、監視の重要性を説明しやすい。

二つ目は「SPFレコード（Sender Policy Framework）」である。これは、ドメインのメール送信者として認証されたサーバーを定義するTXTレコードの一種だ。「dig example.com TXT +short | grep spf1」のようなコマンドで内容を確認できる。SPFレコードはドメインのルートに設定されるため、様々なサービスが所有権確認のために追加を要求するTXTレコードと一緒に扱われることが多い。これが弱点となり、不要なTXTレコードを整理する際に、SPFレコードが誤って削除されたり、一部が破損したりすることがある。もう一つの一般的な問題は、SPFレコードが複数存在してしまうケースだ。新しいツールを導入する際に、既存のSPFレコードに追記するのではなく、誤って新しいSPFレコードを追加してしまうと、受信側はどちらを信頼すべきか判断できず、SPF認証に失敗する。SPFレコードに問題があっても、メール自体は送信される。しかし、受信側で送信元認証に失敗するため、スパムとして扱われたり、受信拒否されたりする可能性が高まる。この問題も、顧客からの指摘によって初めて発覚することが多い。

三つ目は「DKIMレコード（DomainKeys Identified Mail）」である。これは、送信するメールに電子署名を追加するための公開鍵を提供するDNSレコードだ。これにより、メールの送信元が正当であり、内容が途中で改ざんされていないことを受信側が検証できるようになる。DKIMの公開鍵は、「s1._domainkey.example.com」や「k2._domainkey.example.com」のような「セレクタ名」を含むサブドメインにTXTレコードとして設定される。これらのセレクタ名は人間にとって意味を持たない文字列に見えるため、古いレコードや不要なデータと誤認されて削除されてしまうことがある。送信側のメールサービスプロバイダは引き続き秘密鍵でメールに署名するが、受信側がDNSで公開鍵を見つけられなくなると、その署名検証はすべて失敗する。自分のドメインのDKIMセレクタ名が何であるか覚えていない人も多いため、確認するには自分宛てにメールを送信し、メールヘッダーの「DKIM-Signature」部分にある「s=」の値を参照するか、DNSレコードスキャナーを使う必要がある。「dig selector1._domainkey.example.com TXT +short」のように、セレクタ名を指定してレコードを照会する。

四つ目は「DMARCレコード（Domain-based Message Authentication, Reporting, and Conformance）」である。これは、SPFとDKIMの両方の認証結果を統合し、それらが失敗した場合に受信側のメールサーバーがどう対処すべきかを指示するポリシーを定義するTXTレコードだ。例えば、「dig _dmarc.example.com TXT +short」とコマンドを実行すると、「v=DMARC1; p=reject; rua=mailto:dmarc@example.com」のような情報が見つかるだろう。DMARCの主なトラブルは、デバッグ作業中に発生する。メールの到達性が悪いときに、DMARCポリシーを一時的に「p=none」（認証失敗しても何もしない）に緩和し、問題の原因が他にあることが判明した後も、ポリシーを元に戻し忘れてしまうケースだ。これにより、ドメインからのなりすましメールを拒否するよう世界に指示するのをやめてしまい、外部からの不正なメールに対する防御が弱まる。しかも、この変更はシステム上のエラーを引き起こさないため、誰も気づかないまま放置されがちだ。もう一つ注意すべきは、「rua」で指定されるレポート送付先アドレスだ。ここに指定されたメールアドレスに、ドメインからのメール送信状況に関する集計レポートが送られるため、このアドレスが見覚えのないものに変更されている場合、重要な情報が他の誰かに渡ってしまうことになる。

これらの4つのDNSレコードは、いずれも単なるDNSレコードであり、「dig」コマンドを使えばその内容を確認できる。したがって、これらのコマンドを定期的に実行し、期待される値と比較することで、監視システムを構築することが可能だ。値に差異が見られた場合、古い値と新しい値を記録して通知することで、迅速な対応が可能になる。特にSPFやDKIMのTXTレコードは長いことが多く、複数の文字列に分割されて登録されることがあるため、比較する際にはそれらを結合して検証することが重要だ。これにより、単純な表示形式の違いによる誤報を避けられる。

どのような方法を選ぶにせよ、今すぐ自分のドメインのこれら4つのレコードの現在の値を控えておくことを強く推奨する。なぜなら、SPFレコードが壊れた際に最も困難なのは、以前どのような内容だったかを思い出すことだからだ。現在の正しい状態を把握しておくことで、将来的に問題が発生した際に、迅速かつ正確な復旧作業が可能になる。これらのDNSレコードは、メールシステムを健全に保ち、顧客との円滑なコミュニケーションを維持するための目に見えない、しかし極めて重要な基盤である。システムエンジニアを目指す上では、ウェブサイトだけでなく、メール送受信の仕組みも理解し、その健全性を確保する知識が不可欠となる。