SPF設定で起こしがちなミスと注意点

SPF、DKIM、DMARCを導入する際は、いずれもDNSのTXTレコードの記述が必要になります。この記述にミスがあって動作しないケースが意外と多いです。Hornetsecurityの日本法人が2024年12月に、日本語のホームページを持つ206,390個のドメインを無作為に抽出し、DMARCの導入状況について調査を行った結果では、全体の5%にSPFの設定ミスがありました。

SPFの設定方法の基本は、「DNSのTXTレコードにメール送信サーバのIPアドレスを記述する」「別のSPFレコードを含めることができる」というシンプルなものですが、その記述方法が覚えにくいためミスに気付きづらいという特徴もあります。

例えば、送信サーバのIPアドレスが「192.0.2.25」、配信事業者が指定するSPFが「SPF:_spf.sender.example.jp」であった場合、次のように記述します。


example.com. TXT “v=spf1 ip4:192.0.2.25 include:_spf.sender.example.jp -all”

最初の「v=spf1」はバージョン番号で、SPFのバージョンが1であるため、このように記述します。「v=spf1.0」ではエラーになるので注意が必要です。そしてIPv4(IPv6の指定も可能)のIPアドレス「192.0.2.25」と、配信事業者の「example.jp」を加えた(include)アドレスのみ(-all)を登録し許可するということを意味します。

先述の調査の結果、記述ミスの多くはSPFの文法間違いでした。中には文法は正しいが、複数のSPFレコードが登録されているケースもありました。SPFレコードは1つしか記述できませんので、これも間違いです。また、よく確認されるSPFの文法ミスは、スペルミス、空白(スペース)が入っていない、不要な空白が入っている、「:」であるべきところが「=」になっているなど様々です。

  • SPF設定でよくある文法の間違い

SPFレコードは頻繁に設定や変更するものではないので、ミスが発生してしまうことは仕方ないかもしれません。また、DNSをファイルで直接変更する場合は「”」(ダブルクォーテーション)で分割する際の仕様を勘違いして必要な空白が入っていないようなミスも起こりえます。

しかし、設定ミスはエラーやSPFが機能しないことにもつながり、DMARCにも影響を与えてしまいます。DNSのTXTレコードとしては何を記述してもエラーにはなりませんので、SPFとして文法が正しいかどうかを確認する仕組みが必要といえるでしょう。

また、しばしばエラーの要因となるのがSPFのDNS参照(Lookup)の回数制限です。SPFにはDNS参照回数は10回までという上限がありますが、記述上は一つの参照先であっても、そこに複数の参照先が含まれている場合があるので注意が必要です。

例えば、「v=spf1 include:_spf.google.com -all」と設定した場合、実際には次の参照が発生します。

(1) _spf.google.com
(2) netblocks.google.com
(3) netblocks2.google.com
(4) netblocks3.google.com

その結果、DNS参照回数は4回となります。DNS参照回数は、例えばWindows上のコマンドプロンプトでも確認できます。SPF設定の際には確認しておきたいポイントです。このように、SPF設定においても多くの注意点があり、それはDMARCの設定においても同様です。

適切なDMARCソリューションを選定するポイント

DMARCを正しく導入し、運用するにはSPFやDKIMの設定が必要ですが、その設定にミスは許されません。また、DMARCの導入後も適切な管理と運用が求められ、多くの課題に直面します。例えば次のような課題が発生します。

  • 設定の文法が難しく、適切に設定できない。
  • DNSの管理部署が異なり、設定変更に時間がかかる。
  • SPFのDNS参照が10回を超えてしまう。
  • 「p=none」と設定すれば十分だと誤解している。
  • メール送信サーバや配信事業者を把握できていないため、「p=reject」にすると正しいメールがとどかなくなることを懸念している。
  • DMARCレポートの見方、解析が難しい。

DMARCソリューションはこうした課題を解決します。以下、適切なソリューションを選定する際に重要となるポイントを紹介します。

まず、DMARCへの対応において設定ミスを防ぐ、以下のような機能があるかを確認しましょう。

直観的なドメイン設定ツール

DMARC、DKIM、SPFの適切な導入・管理を容易にする機能。DNSを直接編集するのではなく、直感的で分かりやすいインタフェースで設定・管理できることを確認しましょう。

SPFのフラット化機能

SPFのDNS参照回数を減らし、includeを10回を超えて設定できる機能です。現時点で参照回数が10回を超えてしまっているドメインには必須の機能といえます。手動でIPアドレスに変換して回数制限を下回ることができても、定期的かつ継続的にそのIPアドレスが正しいかを確認して反映するのは容易ではありません。SPFのフラット化機能を用いれば、その設定が一度で済むため、その後の細かい調整が不要になります。

送信元別のDMARCレポート分析

DMARCレポートはさまざまな受信環境から送られてくるため、送信元別に分析することが容易ではありません。送信元別にDMARCに対応できているかどうかを分析するためには、このようなレポートを送信元別に串刺しで分析できる機能が必要となります。送信元のサービス別にDMARCの結果をわかりやすく表示できるものが望ましいです。

送信元の分類機能

DMARCが失敗した送信元には、設定忘れ設定ミスなどの自組織の送信元・メール配信事業者のほかに、なりすましや送信先での転送メールなども含まれます。これらを定期的に分類管理することで、設定忘れや設定ミスの環境をあぶり出すことが可能になります。分類する際に送信元がIPアドレス別ではなくサービス単位でグループ化されていると、より直感的に操作可能になります。分類した結果、なりすまし等の不要なものを非表示にできると、次回以降の分類がより簡単になります。

送信元のレピュテーション表示

DMARCレポートから送信元を分類する際に、送信元のレピュテーションが分かれば参考になります。送信元がスパムの配信者として登録されているか等の情報があると便利です。

監視やアラート

何らかの原因でDMARCが失敗している可能性がある場合、できるだけ早く状況を把握する必要があります。このような普段と異なる状況が発生した場合にメールなどで通知する機能が役に立ちます。

メールの到達状況の確認

DMARCレポートの中には検証結果にかかわらず、メールの配送状況も含まれます。メールの配送状況を確認することで自組織からの必要なメールがきちんと届いているかどうかを確認することができます。

その他、DMARCとは直接関係ありませんが、次のような機能が搭載されていれば、メールセキュリティの運用がより効率的になると考えられます。

MTA-STS設定・分析

自組織のメール受信サーバがSTART TLSに対応している場合、MTA-STSを使用することで、メール受信の通信経路が確実に暗号化されます。また、メールサーバをなりすましてメールを傍受しようとする攻撃も防ぐことができます。MTA-STSの設定はWebサーバやSSL/TLS証明書の管理も必要になり、運用が煩雑になりがちですので、DMARC設定とまとめて管理できる機能があると便利です。

BIMI対応によるブランド強化

ドメインがDMARCに適合していると、対応する受信トレイにおいてメールの横にブランドロゴが表示される機能。メールキャンペーンの効率、ブランド認知度、信頼性を最大限に向上できます。BIMI(Brand Indicators for Message Identification)については後述します。

DMARCの先にあるBIMIと、その有効性は?

Yahooメールやキャリアメールの一部は、以前からメールにアイコンを表示しています。主にオフィシャルのメールやショッピングサービスに登録している事業者などが対象で、送信元の真正性をユーザーに知らせることを目的としています。この機能に証明書を組み合わせて規格化したものがBIMIです。

BIMIは、DMARC認証に成功したメールに対してアイコンを表示させる送信ドメイン認証技術です。アイコンには証明書が付与され、正しい事業者からのメールでなければアイコンは表示されないようになっています。対応メール環境も拡大しており、正規のメールであることが視覚的に分かることが特長です。

  • BIMIの特長

BIMIの証明書はSSL/TLS証明書などのように認証局から発行されます。BIMIの場合はVMC(認証マーク証明書)と呼ばれ、商標登録されたロゴと企業や団体が実在することをドメインとひもづけて証明します。

証明書によって認証されたブランドアイコンや証明書情報を表示することで、ブランドアイコンのないメールは偽物であると判断できます。たとえアイコンをなりすます送信者がいたとしても証明書があるかどうかで判断することができます。これにより、ブランドアイコンのあるメールは安全という認識が広がり、メールの開封率やブランドイメージの向上が期待できます。

著者プロフィール


伊藤 利昭(いとう としあき)Hornetsecurity株式会社 カントリーマネージャー
2020年1月に、Hornetsecurity株式会社の前身であるVade Japan株式会社のカントリーマネージャーに就任。クラウドベースのセキュリティ、コンプライアンス、バックアップ、セキュリティトレーニングなどを提供するHornetsecurityの日本国内におけるビジネスを推進する責任者。これまで実績を重ねてきたサービスプロバイダー向けのメールフィルタリング事業の継続的な成長と新たに企業向けのメールセキュリティを展開するに当たり、日本国内のパートナーネットワークの構築に注力している。

平野 善隆(ひらの よしたか)Hornetsecurity株式会社 プリンシパル メッセージング エンジニア
メールセキュリティの専門家として、M3AAWGやJPAAWGなどの業界団体で積極的に活動。講演・セミナーに多数登壇し、最新のAI技術を活用したフィッシング対策や誤送信防止の研究・普及に努める。奈良先端科学技術大学院大学を修了後、クオリティアにて19年間チーフエンジニアを務める。2023年9月より現職。