ポスト

SPFユーザーが日常的に直面する非常に一般的な問題は、あまりにも多くのDNSルックアップを生成することで、SPFハードリミットを容易に超えてしまうリスクです。これは、DMARCモニタリングが有効な場合、SPF PermErrorの結果を返し、メール配信の問題を引き起こします。この問題を軽減するために、業界の専門家がSPFフラットニングサービスのようなソリューションを提供していることから、PowerSPFは実際にその主張を実現し、期待以上の成果を上げています。その方法をご紹介します。

DNSルックアップが多すぎます。なぜこのようなことが起こるのか?

まず最初に理解すべきことは、なぜ最初に多くのDNSルックアップが発生してしまうのかということです。これは、どのようなメール交換ソリューションを使用していても、サービスプロバイダーがレコードに多くのメカニズムを追加するため、ルックアップが多くなるためです。

例えば、GoogleのメールエクスチェンジャーであるGmailを使用している場合、以下のようなSPFレコードは、実際には4つのDNSルックアップを生成します。 v=spf1 include:[email protected] -all のようなSPFレコードは、実際には合計4つのDNSルックアップを生成します。ネストされたインクルードもさらに多くのルックアップを発生させ、複数のサードパーティ・ベンダーを使用してお客様のドメインを使用してメールを送信している場合、DNSルックアップの制限である10を簡単に超えることができます。

SPFフラット化は解決策になるか?いいえ、違います。

答えはノーです。SPFを手動でフラット化することで、SPF10ルックアップの制限を下回ることができますが、それには独自の制限と課題があります。SPFを手動でフラット化すると、SPFレコード内のinclude文を対応するIPアドレスに置き換えるだけで、ルックアップの必要性がなくなります。これにより、そもそも多くのDNSルックアップが発生しないようになり、10ルックアップのSPF制限を守り、パーマーラーを回避することができます。しかし、手動によるSPFフラット化ソリューションの問題点は次の通りです。

  • SPFレコードの長さが長すぎる(255文字以上)ことがあります。
  • お客様のメールサービスプロバイダーは、お客様に通知することなくIPアドレスを変更または追加することができます。
  • メールフローの監視、ドメインやメカニズムの変更・更新、アクティビティの追跡を行うためのダッシュボードはありません。
  • SPFレコードを更新するためには、常にDNSを変更する必要があります。
  • 頻繁なIP変更により、メールの配信に影響が出る可能性がある

これらがどのように影響するのでしょうか?メールサービスプロバイダーが使用している新しいIPアドレスのSPFレコードが更新されていない場合、これらのIPアドレスが使用されると、必然的に受信者側でSPFに失敗 することになります。

多すぎるDNSルックアップを解決するためのダイナミックSPFフラットニング

DNSルックアップエラーに別れを告げるためのよりスマートなソリューションが、SPFレコードの自動フラット化を行うPowerSPFです。PowerSPFはリアルタイムのSPFフラット化ソリューションで、あなたをサポートします。

  • 数回のクリックでお客様のドメインのSPFを簡単に設定できます。
  • 1つのインクルードステートメントでSPFレコードをフラット化し、自動SPFインクルード管理を楽しむことができます。
  • DNSルックアップの上限を常に10個以下にする
  • ネットブロックを自動更新し、変更されたIPアドレスを常にスキャンすることで、SPFレコードを最新の状態に保ちます。
  • ユーザーフレンドリーなダッシュボードを維持し、ポリシーの変更、ドメインやメカニズムの追加、メールフローの監視などを簡単に行うことができます。

なぜ、一時的な結果しか得られないSPF圧縮ツールに頼るのでしょうか?自動SPFでSPFレコードを最適化し、SPFのハードリミットを緩和しましょう。今すぐPowerSPFに登録しますか?

SPFフラット化を避けるべき理由

Sender Policy Framework(SPF)は、SPFレコードに登録されているお客様のドメインに登録されているすべての許可されたIPアドレスに対してメッセージを認証することで、広く評価されているメール認証プロトコルです。電子メールを認証するために、SPFは受信側のメールサーバーに許可されたIPを確認するためのDNSクエリを指定し、結果としてDNSルックアップを行います。

SPFレコードは、さまざまなメカニズムの集合体であるDNS TXTレコードとして存在します。これらの仕組みのほとんど(include、a、mx、redirect、exists、ptrなど)はDNSルックアップを生成します。ただし、SPF認証のためのDNSルックアップの最大数は10に制限されています。様々なサードパーティベンダーを利用して、自分のドメインを使ってメールを送信している場合、SPFのハードリミットを簡単に超えてしまいます。

この制限を超えるとどうなるのか、と疑問に思うかもしれません。10回のDNSルックアップの制限を超えると、SPFの失敗につながり、あなたのドメインから送信された正当なメッセージであっても無効になります。このような場合、DMARCモニタリングを有効にしていれば、受信メールサーバーはSPF PermErrorレポートをあなたのドメインに返します。SPFフラット化です。

SPFフラットニングとは?

SPFレコードフラットニングは、SPFレコードを最適化し、SPFハードリミットを超えないようにするために、業界の専門家がよく使う方法のひとつです。SPFフラットニングの手順は非常に簡単です。SPFレコードのフラット化とは、すべてのインクルード機構をそれぞれのIPアドレスに置き換えることで、DNSルックアップの必要性をなくす作業です。

例えば、あなたのSPFレコードが最初は以下のようなものだったとします。

v=spf1 include:spf.domain.com -all

フラット化されたSPFレコードは以下のようになります。

v=spf1 ip4:168.191.1.1 ip6:3a02:8c7:aaca:645::1 -all

このフラット化されたレコードは、複数のルックアップを行う代わりに、1つのDNSルックアップのみを生成します。メール認証時に受信サーバーが実行するDNSクエリの数を減らすことで、DNSルックアップの制限である10回を下回ることができますが、それなりの問題があります。

SPFフラット化の問題点

手動でフラット化したSPFレコードが長すぎてドメインのDNSで公開できない(255文字の制限を超える)という事実の他に、メールサービスプロバイダーがユーザーに通知することなくIPアドレスを変更または追加する可能性があることを考慮しなければなりません。メールサービスプロバイダがインフラを変更しても、その変更はSPFレコードには反映されないことがあります。したがって、これらの変更された、または新しいIPアドレスがメールサーバで使用されるたびに、そのメールは受信者側でSPFに失敗します。

PowerSPF: 動的SPFレコードジェネレータ

PowerDMARCの最終的な目標は、ドメイン所有者が10のDNSルックアップ制限に達するのを防ぐことができるソリューションを考え出すことでした。また、SPFレコードを最適化して、メールサービスプロバイダーが使用している最新のIPアドレスを常に更新することもできます。PowerSPFは、SPFレコードから単一のインクルードステートメントを生成する、自動化されたSPFフラットニングソリューションです。PowerSPFは次のようなことに役立ちます。

  • IPやメカニズムを簡単に追加・削除できる
  • ネットブロックの自動更新により、許可されたIPが常に最新の状態に保たれます。
  • 10個のDNSルックアップ制限を簡単にクリア
  • 最適化されたSPFレコードをワンクリックで取得
  • パーマラー」を永続的に倒す
  • エラーフリーなSPFの実現

今すぐPowerDMARCに登録して、メールの配信と認証を強化するとともに、DNSのSPFルックアップ 数を10以下に抑えることができます。

この記事では、SPFレコードを簡単に最適化する方法をご紹介します。企業や中小企業で、顧客やパートナー、従業員との間でメッセージを送受信するためにメールドメインを所有している場合、受信サービスプロバイダーによって設定されたSPFレコードがデフォルトで存在している可能性が高いです。既存のSPFレコードがあっても、新たに作成する必要があっても、SPFレコードがメール配信の問題を起こさないようにするためには、SPFレコードをドメインに合わせて正しく最適化する必要があります。

メール受信者の中には、SPFを厳しく要求する人もいます。つまり、あなたのドメインにSPFレコードが発行されていない場合、あなたのメールは受信者の受信箱でスパムとしてマークされる可能性があるということです。さらに、SPFは、あなたのドメインを代表してメールを送信する未承認のソースを検出するのに役立ちます。

まず、SPFとは何か、なぜSPFが必要なのかを理解しましょう。

送信者ポリシーフレームワーク(SPF

SPFは、基本的に標準的な電子メール認証プロトコルであり、あなたのドメインからの電子メール送信を許可されたIPアドレスを指定します。SPFは、特定のドメインのDNSで公開されている送信許可ホストとIPアドレスのリストと送信者アドレスを比較して動作します。

SPFは、DMARC(Domain-based Message Authentication, Reporting and Conformance)とともに、メール配信時に偽造された送信者アドレスを検出し、なりすまし攻撃やフィッシング、メール詐欺などを防ぐために設計されています。

ホスティングプロバイダーがお客様のドメインに統合したデフォルトのSPFは、お客様のドメインから送信されるメールがSPFに対して認証されることを保証しますが、お客様のドメインから複数のサードパーティベンダーがメールを送信する場合、この既存のSPFレコードをお客様の要件に合わせて調整・変更する必要があることを知っておくことが重要です。どのようにすればよいのでしょうか?最も一般的な方法を2つご紹介しましょう。

  • 新しいSPFレコードの作成
  • 既存のSPFレコードの最適化

SPFレコードを最適化する方法の説明

全く新しいSPFレコードの作成

SPFレコードの作成とは、ドメインにSPFを設定するために、ドメインのDNSにTXTレコードを発行することです。これは、SPFレコードを最適化する方法を始める前の必須ステップです。認証を始めたばかりで、構文がよくわからない場合は、無料のオンラインSPFレコードジェネレータを使って、ドメインのSPFレコードを作成することができます。

正しい構文のSPFレコードエントリは以下のようになります。

v=spf1 ip4:38.146.237 include:example.com -all

v=spf1使用しているSPFのバージョンを指定する
IP4/IP6この仕組みでは、ドメインからのメール送信を許可された有効なIPアドレスを指定します。
インクルード受信側のサーバーに、指定したドメインのSPFレコードの値を含めるように指示する仕組みです。
-すべてこの仕組みにより、SPFに準拠していないメールを拒否することができます。これは、SPFレコードを公開する際に使用できる推奨タグです。ただし、SPF Soft Failを意味する~に置き換えることもできます(SPFに準拠していないメールはソフトフェイルとしてマークされますが、それでも受け入れられます)。また、+は、あらゆるサーバーがあなたのドメインに代わってメールを送信することを許可することを指定しますが、これは強く推奨されません。

すでにドメインにSPFを設定している場合は、無料のSPFレコードチェッカーを使って、SPFレコードを検索して検証し、問題を検出することもできます。

SPFを設定する際のよくある問題とエラー

1) 10個のDNSルックアップの制限 

ドメイン所有者がSPF認証プロトコルを設定・採用する際に直面する最も一般的な問題は、SPFにはDNSルックアップ数が10を超えてはならないという制限があることです。複数のサードパーティベンダーに依存しているドメインでは、10回のDNSルックアップの制限が簡単に超えてしまい、SPFが破損してSPF PermErrorが返されます。このような場合、受信サーバーは自動的にSPFレコードを無効にし、ブロックします。

DNSルックアップを開始するメカニズム。MX、A、INCLUDE、REDIRECT修飾子

2) SPFボイドルックアップ 

ボイドルックアップとは、NOERRORレスポンスまたはNXDOMAINレスポンス(ボイドアンサー)を返すDNSルックアップのことです。SPFを実装する際には、DNSルックアップがそもそもボイドアンサーを返さないようにすることが推奨されます。

3) SPF再帰的ループ

このエラーは、指定されたドメインのSPFレコードに、1つ以上のINCLUDE機構の再帰的な問題が含まれていることを示しています。これは、INCLUDEタグで指定されたドメインの1つに、SPFレコードに元のドメインのINCLUDEタグが含まれているドメインが含まれている場合に発生します。これにより、メールサーバがSPFレコードのDNS検索を継続的に行うという終わりのないループが発生します。その結果、最終的にはDNSルックアップの上限である10件を超えてしまい、SPFに失敗するメールが発生します。

4) シンタックスエラー 

SPFレコードがドメインのDNSに存在していても、構文エラーがあると意味がありません。SPF TXTレコードにドメイン名や機構名を入力する際に不要なホワイトスペースが含まれていると、受信サーバーが検索を行う際に余分なスペースの前の文字列が完全に無視され、SPFレコードが無効になります。

5) 同一ドメインに複数のSPFレコードがある場合

1つのドメインがDNSに登録できるSPF TXTエントリは1つだけです。お客様のドメインに複数のSPFレコードがある場合、受信サーバーはすべてのSPFレコードを無効にし、メールがSPFに失敗する原因となります。

6) SPFレコードの長さ 

DNSにおけるSPFレコードの最大長は255文字に制限されています。しかし、この制限を超えて、SPF用のTXTレコードに複数の文字列を連結して含めることができますが、DNSのクエリ応答に合わせて512文字の制限を超えることはできません(RFC 4408による)。これは後に修正されましたが、古いバージョンのDNSに依存している受信者は、長大なSPFレコードを含むドメインから送信されたメールを検証することができませんでした。

SPFレコードの最適化

SPFレコードを速やかに修正するために、以下のSPFのベストプラクティスを利用することができます。

  • あなたのSPFレコードに、メールソースを左から右に重要度の低い順に入力してみてください。
  • 廃止されたメールソースをDNSから削除
  • AやMXの代わりにIP4/IP6の仕組みを使う
  • INCLUDE機構の数をできるだけ少なくし、ネストしたインクルードを避けます。
  • DNSで同一ドメインのSPFレコードを複数発行しないこと
  • SPFレコードに余計な空白や構文エラーがないことを確認してください。

注意:SPFフラット化は、一度だけの対応ではないため、お勧めできません。メールサービスプロバイダがインフラを変更した場合、それに合わせてSPFレコードを毎回変更しなければなりません。

PowerSPFで簡単にできるSPFレコードの最適化

SPFレコードを最適化するために、上記のような修正を手動で行うこともできますが、手間をかけずにダイナミックなPowerSPFが自動的にすべての作業を行ってくれます。PowerSPFは、ワンクリックでSPFレコードを最適化することができ、以下のことが可能です。

  • 簡単に送信元を追加・削除できる
  • DNSを手動で変更することなく、簡単にレコードを更新することができます。
  • 最適化された自動SPFレコードをボタン一つで取得
  • DNSルックアップ数を常に10件以内に抑える
  • PermErrorの緩和に成功しました。
  • SPFレコードの構文エラーや設定の問題を解消
  • お客様に代わってSPF制限を解決する負担を軽減します

今すぐPowerDMARC登録して、SPFの制限に永遠に別れを告げましょう。  

DMARCサービスを提供している私たちは、よくこのような質問を受けます。"もしDMARCがSPFとDKIMの認証を使うだけなら、なぜわざわざDMARCを使う必要があるのか?不必要なものではないのか?"

表面的にはほとんど違いがないように見えるかもしれませんが、現実は大きく異なります。DMARCはSPFとDKIMの技術を組み合わせただけではなく、それ自体が全く新しいプロトコルなのです。DMARCにはいくつかの特徴があり、世界で最も先進的なメール認証規格の1つであり、企業にとっては絶対に必要なものです。

しかし、ちょっと待ってください。なぜDMARCが必要なのか、正確な答えが出ていません。SPFやDKIMにはない、DMARCの特徴とは?まあ、それはかなり長い答えで、1つのブログ記事には長すぎます。だから、それを分割して、まずSPFについて話しましょう。慣れていない方のために、簡単にご紹介します。

SPFとは?

SPF(Sender Policy Framework)とは、メール受信者をなりすましメールから保護するためのメール認証プロトコルです。SPFレコードは、お客様(ドメイン所有者)のチャンネルを通じてメールを送信することを許可されたすべてのIPアドレスのリストです。受信サーバーは、あなたのドメインからのメッセージを見ると、あなたのDNSで公開されているSPFレコードをチェックします。送信者のIPがこの「リスト」にあれば、メールは配信されます。そうでなければ、サーバーはそのメールを拒否します。

ご覧のように、SPFは、お客様のデバイスに害を及ぼしたり、組織のセキュリティシステムを危険にさらしたりする可能性のある、多くの好ましくない電子メールを排除するために、かなり良い仕事をしています。しかし、SPFは一部の人が考えているほど良いものではありません。それは、SPFにはいくつかの大きな欠点があるからです。ここでは、その問題点について説明します。

SPFの限界

SPFレコードは、Fromアドレスには適用されません。

メールには、送信者を特定するための複数のアドレスがあります。通常表示されるFromアドレスと、1~2回のクリックで表示される隠れたReturn Pathアドレスです。SPFを有効にすると、受信側のメールサーバーはリターンパスを見て、そのアドレスのドメインのSPFレコードをチェックします。

ここで問題となるのは、攻撃者がリターンパスのアドレスに偽のドメインを使い、Fromセクションに正当な(または正当に見える)メールアドレスを使うことで、これを悪用できることです。仮に受信者が送信者のメールIDを確認したとしても、まずFromアドレスを見て、一般的にはリターンパスをわざわざ確認することはありません。実際、ほとんどの人はReturn Pathアドレスというものがあることすら知らないのではないでしょうか。

SPFは、この単純なトリックを使うことで非常に簡単に回避することができ、SPFで保護されたドメインであってもほとんど無防備になります。

SPFレコードは、DNSルックアップの制限があります。

SPFレコードには、ドメイン所有者がメール送信を許可したすべてのIPアドレスのリストが含まれています。しかし、これには決定的な欠点があります。受信サーバーは、送信者が許可されているかどうかを確認するためにレコードをチェックする必要があり、サーバーの負荷を軽減するために、SPFレコードのDNSルックアップは10回までとなっています。

つまり、あなたの組織が複数のサードパーティベンダーを使用して、あなたのドメインを通じてメールを送信している場合、SPFレコードはその制限をオーバーシュートしてしまう可能性があります。適切に最適化されていなければ(自分でやるのは簡単ではありませんが)、SPFレコードには非常に制限の多い上限が設定されています。この制限を超えると、SPFの実装が無効であるとみなされ、メールはSPFに失敗します。これにより、メールの配信率が低下する可能性があります。

 

メールが転送されたときにSPFが機能しないことがある

SPFには、メール配信に支障をきたすもう一つの重大な障害点があります。お客様のドメインにSPFを実装している場合、誰かがお客様のメールを転送すると、転送されたメールがSPFポリシーによって拒否されることがあります。

これは、転送されたメッセージによってメールの受信者が変更されたが、メールの送信者のアドレスは同じままであるためです。これが問題になるのは、メッセージにはオリジナルの送信者のFromアドレスが含まれているのに、受信サーバーには別のIPが表示されているからです。転送先のメールサーバのIPアドレスは、オリジナルの送信者のドメインのSPFレコードに含まれていません。その結果、受信サーバーでメールが拒否されてしまうことがあります。

DMARCはこれらの問題をどのように解決するのでしょうか?

DMARCは、SPFとDKIMを組み合わせて電子メールを認証します。電子メールがDMARCを通過して正常に配信されるためには、SPFまたはDKIMのいずれかを通過する必要があります。さらに、SPFやDKIMだけの認証よりもはるかに効果的な重要な機能が追加されている。レポーティングです。

DMARCレポートでは、お客様のメールチャネルのステータスに関するフィードバックを毎日得ることができます。これには、DMARCの整合性に関する情報、認証に失敗したメールのデータ、潜在的なスプーフィングの試みに関する詳細が含まれます。

なりすましメールを受け取らないためにはどうしたらいいのかとお考えの方は、メールのなりすましを防ぐための5つの方法をまとめた便利なガイドをご覧ください。