【ITニュース解説】Your SPF and DKIM passed last month. Here is why they can fail today without you touching DNS

システムエンジニアを目指す皆さんにとって、メールシステムの信頼性はサービスの基盤を支える重要な要素だ。その中でも、メールのなりすましを防ぎ、正規のメールであることを証明する「SPF」と「DKIM」という二つの認証技術は、安全なメール運用には欠かせない。これらは一度設定すればそれで終わりだと思われがちだが、実は時間と共に予期せぬ理由で認証が失敗し、メールが届かなくなる事態が発生する可能性がある。ここでは、なぜDNS設定を一切変更していないにもかかわらず、SPFやDKIMの認証が突然失敗するのか、そのメカニズムと対処法を詳しく解説する。

まず、SPF認証の失敗原因の一つとして「DNSルックアップ制限」が挙げられる。SPFレコードは、メール送信元として許可されたIPアドレスやドメインを指定するものだが、その中に「include」というメカニズムがある。これは、別のドメインのSPFレコードを取り込んで適用するというもので、例えばメール配信サービスを利用している場合にそのサービスのSPFレコードを含める、といった使い方をする。この「include」は入れ子構造になっており、取り込んだ先のドメインがさらに別のドメインを「include」していることがある。RFC 7208という技術標準では、SPF評価時に許可されるDNSクエリ（情報の問い合わせ）の回数を最大10回と定めている。もし、あなたが設定した「include」によって取り込まれるドメインが、さらに多くのドメインを「include」しており、その結果として全体のDNSクエリ数が10回を超えてしまうと、SPF認証は「permerror」という恒久的な失敗を返し、メールは配送されなくなる。この問題は、あなたがDNSレコードを一切変更していなくても、あなたの「include」しているプロバイダ側がレコードを変更し、入れ子の深さが増しただけで発生する可能性があるため、特に注意が必要だ。

次に、DKIM認証の失敗原因として「DKIMセレクタの変更」がある。DKIMは、送信されたメールが改ざんされていないこと、そして正規の送信者から送られたことを証明するために、電子署名を利用する技術だ。この署名に使われる公開鍵は、通常DNSのTXTレコードとして公開される。多くの企業では、メールサービスのプロバイダが提供する公開鍵をCNAMEレコード（別名レコード）として自社ドメインのDNSに登録し、プロバイダ側の鍵を参照する方式を採用している。この場合、プロバイダ側でセキュリティ上の理由やシステム更新のために、DKIMの鍵（セレクタと呼ばれる）が定期的にローテーションされたり、古くなった鍵が削除されたりすることがある。もし、あなたのCNAMEレコードが参照しているプロバイダ側のセレクタが削除されてしまうと、メールは正しく署名されていても、受信側が公開鍵を見つけられなくなり、DKIM認証は「fail」または「none」という結果を返す。この場合も、あなたが自社のDNS設定に手を加えていなくても、プロバイダ側の変更によって認証が失敗し、メールが届かなくなる可能性がある。

さらに、新しいメール送信元が追加されることも、メールの配送問題を引き起こす一因となる。例えば、マーケティング部門が新しいニュースレター配信ツールを導入したり、サポート部門が新しいヘルプデスクシステムを使い始めたりすることがある。これらの新しいシステムがあなたのドメインからメールを送信する場合、それらの送信元IPアドレスがSPFレコードに適切に追記されていなかったり、DKIM署名が設定されていなかったりすると、問題が発生する。DMARC（Domain-based Message Authentication, Reporting & Conformance）というSPFとDKIMを組み合わせた認証ポリシーでは、最初は「p=none」というポリシーが設定されていることが多く、この段階では認証失敗したメールも通常通り配送されるため、問題が表面化しにくい。しかし、セキュリティ強化のためにDMARCポリシーを「p=quarantine」（隔離）や「p=reject」（拒否）に変更した途端、新しい送信元からのメールはスパムフォルダに振り分けられたり、完全に配送が拒否されたりする事態に発展する可能性がある。

このような予期せぬ認証失敗を防ぎ、健全なメール運用を維持するためには、問題を推測するのではなく、「DMARC集約レポート」を定期的に確認することが極めて重要だ。DMARC集約レポートは、あなたのドメインから送信されたメールが、SPFとDKIMの認証結果がどうであったかを、送信元IPアドレスごとに詳細に記録して、「rua=」アドレスに指定されたメールアドレスへ送信してくれる。このレポートを定期的に確認することで、普段見慣れないIPアドレスからの送信や、これまで認証が成功していた送信元が突然「fail」と表示されるなどの異常を早期に発見できる。これこそが、問題の兆候を捉え、具体的な対策を講じるための唯一の証拠となる。

健全なメール設定とは、SPFのDNSルックアップ数が常に10回未満であることを確認し、メールプロバイダの変更があった際には必ずこの回数を再確認することから始まる。また、正規のメール送信元は全て、SPFかDKIMのいずれかで正しく認証されるように設定されている必要がある。そして何よりも、DMARC集約レポートを定期的に確認し、認証失敗の原因を特定し、速やかに対応できる体制を整えることが不可欠だ。これらのチェックは一度実施すれば終わりではなく、システムの変更やプロバイダ側の更新によって状況が変わり得るため、定期的な見直しと確認が求められる。そうしなければ、先月まで正常に動作していたメールシステムが、今月には突然メールを配送できなくなる、という事態に見舞われることになるだろう。システムエンジニアとして、メールの信頼性を守るためには、このような継続的な監視と対応が求められる。