• ログイン
  • サインアップ
  • お問い合わせ
PowerDMARC
  • 特徴
    • PowerDMARC
    • ホスティングされたDKIM
    • PowerSPF
    • PowerBIMI
    • PowerMTA-STS
    • PowerTLS-RPT
    • PowerAlerts
  • サービス
    • デプロイメントサービス
    • マネージドサービス
    • サポートサービス
    • サービス特典
  • 価格
  • パワーツールボックス
  • パートナー
    • リセラープログラム
    • MSSPプログラム
    • テクノロジーパートナー
    • 業界パートナー
    • パートナーを探す
    • パートナーになる
  • リソース
    • DMARCとは何か?
    • データシート
    • 導入事例
    • あなたの国のDMARC
    • 産業別のDMARC
    • サポート
    • ブログ
    • DMARCトレーニング
  • について
    • 私たちの会社
    • クライアント
    • お問い合わせ
    • デモを予約する
    • イベント情報
  • メニュー メニュー

のタグアーカイブです: SPFの制限

メール認証におけるSPFの制限を理解する

ブログ

センダー・ポリシー・フレームワーク SPF企業メールをフィッシングやスパムから守るには、SPFだけでは不十分です。 フィッシングやスパムの攻撃から企業の電子メールを保護するには不十分です。SPFのDNSルックアップの最大回数制限や、Fromアドレスとドメインの不整合は、メール配信の問題を引き起こす実装エラーを引き起こします。このブログでは、これらの問題と、DMARCがどのようにSPFの制限を克服するのに役立つかを説明します。

SPFレコードの制限事項とは何ですか?

SPFには2つの大きな制限があり、実装と維持が少し厄介です。 

1.SPF10-Lookupの制限について

ユーザーがDNSサーバーに問い合わせると、バンド幅、時間、CPU、メモリなどの バリデータのリソースが使用される。バリデータの負荷を回避するため、SPFの追加検索回数は10回に制限されています。ただし、SPFポリシーレコード自体のDNSクエリーは、この制限にカウントされません。

RFC7208の4.6.4項と同様 RFC7208の4.6.4節にあるようにによると、受信者のメールサーバは10ルックアップの制限に達するとそれ以上処理しないはずです。このような場合、メールはPermerrorエラーでSPFの検証を拒否します。SPF Permerrorは、SPFの実装プロセスでよく現れるメッセージの一つです。1つのドメインに複数のSPFレコードが存在する場合、構文エラーがポップアップする場合、SPFレコードの上限を超えた場合などに発生し、メールの不達の原因となります。

無料の SPFレコードチェッカーを使用すると、このエラーを排除し、安全な電子メールの会話を確保することができます。

さらに、RFCによると、MXレコードで見つかったホスト名のDNSクエリは MXレコードは10個以上の AレコードまたはAAAAレコードを生成してはなりません。DNSのPTRクエリが10件以上の結果を生成した場合、最初の10件だけが表示・使用されます。

2.人間が読み取れるFromアドレス

SPFの2つ目の制限は、SPFレコードが特定のReturn-Pathドメインに適用され、Fromアドレスには適用されないことです。一般に、受信者はReturn-Pathアドレスにあまり注意を払わず、メールを開くときにFromアドレスにのみ注目します。ハッカーはこの抜け穴を利用して、Fromアドレスを偽造し、フィッシング攻撃を試みます。

SPFレコードのサイズがメール配信に与える影響について

受信者がSPFレコードの上限を超えた場合、SPFチェックに失敗し、Permerrorが発生します。このエラーは、DMARCモニタリングで確認することができます。受信者は、Permerrorが発生したメールをどのように処理するかを選択することができます。受信者は、Permerrorが発生したメールを拒否することができます。一部の受信者は、「ニュートラル」なSPF結果(SPFが使用されていないかのような)を表示するように設定することができます。また、「fail」または「softfail」を選択すると、SPF認証チェックに失敗したメールは拒否されず、スパムフォルダに振り分けられることになります。 

この結果は、DMARC、DKIM、スパム評価の結果も考慮して決定されます。SPFの上限を超えると は、意図した受信者の主受信箱にメールが着信する確率を低下させることにより、メールの配信性に影響を与えます。

バリデータはSPFポリシーを左から右へ評価し、送信者IPアドレスに一致するものが見つかれば、処理を停止する。現在、送信者によっては、SPFポリシーが完全に評価するために10回以上の検索を要求しても、バリデータは必ずしも検索制限に達しない場合があります。これにより、SPFレコードの制限に関連するメール配信の問題を特定することが困難になります。 

必要なルックアップの数を減らすには?

2006年(RFC4408が実装された時期)とはメール交換の習慣が大きく変わったため、一部のドメイン所有者にとって、SPFの参照回数を10回に制限することは困難になっています。現在、企業は1つのドメインで複数のクラウドベースのプログラムやサービスを利用しています。そこで、この一般的なSPFの制限を克服するための方法を以下に紹介します。

  • 未使用のサービスを削除する

SFレコードを評価し、未使用または未要求のサービスがあるかどうかを確認します。をチェックし、'include' など、使われなくなったサービスのドメインが表示される仕組みがないか確認します。

  • SPFのデフォルト値を削除する

デフォルトのSPFポリシーは、通常、'v=spf1 a mx' に設定されています。. ほとんどの A レコードおよび AAAA レコードはメールを送信しないウェブサーバに使用されるため、'aと'mx'の仕組みは必要ありません。

  • の使用は避けてください。 ptr機構を使わないでください。

は ptr 機構は、セキュリティが弱く信頼性が低いため、非常に推奨されない。この機構は、より多くのルックアップを必要とするため、SPFの制限問題を引き起こします。したがって、可能な限り避けるべきです。

  • を使用しないようにします。 mx機構

は mxのメカニズムはメールを受信するために使われるもので、必ずしも送信するために使われるわけではありません。そのため、ルックアップ時に設定されるSPFレコードの制限内に収まるように、使用を控えることができます。クラウドベースのメールサービス利用者であれば、'include' を使用してください。の仕組みを代わりに使用してください。

  • IPv6 または IPv4 を使用する 

IPv4とIPv6は、追加の検索を必要としないので、SPFの10回以内の検索という制限を超えないようにすることができます。ただし、この2つのメカニズムは再調整しないとエラーが発生しやすくなるため、定期的に更新して維持する必要があります。

  • SPFレコードを平らにしない

一部のリソースでは、SPFポリシーがより平坦(または短い)であればあるほど、ドメインの評判が良くなると主張しています。彼らは、検索時に設定されたSPFレコードの制限内に収まるように、この方法を提案しています。しかし、平坦化すると、レコードにエラーが発生しやすくなり、定期的な更新が必要になるため、推奨されません。 

SPFの制限を克服するためのDMARCの役割

DMARCは、人間が読めるFromフィールドとSPFによって認証されたサーバーとの間の一致または整合を要求することによって、人間が読めるFromアドレスのSPFの制限に対処している。

そのため、あるメールがSPFチェックに合格しても、ドメインがFromアドレスと同じでない場合、DMARCはその認証を無効にします。つまり、そのメールは認証テストに不合格となる。

SPFレコードのフラット化は、10回のDNSルックアップ制限をどのように克服するのでしょうか。

SPFレコードの平坦化は、SPF(Sender Policy Framework)レコードを最適化し、SPFの10DNSルックアップ制限を克服するために使用される技術です。10 DNSルックアップ制限は、多くのDNSリゾルバが課す制限であり、ドメインのSPFレコードを検証する際に実行できるDNSクエリの数を制限しています。

電子メールを受信すると、受信者のメールサーバーは送信者のドメインのDNSにSPFレコードを問い合わせ、送信者がそのドメインからメールを送信することを許可されているかどうかを検証します。しかし、SPFレコードが多くのネストしたインクルードを含む場合、DNSルックアップの上限である10件をすぐに超えてしまい、SPF検証の失敗やスパムの誤検知につながる可能性があります。

この制限を克服するために、SPFレコードの平坦化が使用されます。SPFレコードのフラット化とは、SPFレコード内のすべてのネストされたinclude文を、対応するIPアドレスまたはCIDR範囲に置き換える技術です。これにより、含まれる各ドメインに個別に問い合わせる必要がなくなるため、SPFレコードを検証するために必要なDNSクエリーの回数が減ります。

SPFレコードを平坦化することで、SPFレコードの検証に必要なDNSクエリーの回数を大幅に削減し、元のレコードのDNSルックアップ回数が10回以上であっても、メールメッセージのSPF検証をパスすることが可能になります。また、DNSクエリーのタイムアウトやDNSサーバーの一時的な問題によるSPFレコードの検証失敗のリスクも軽減されます。

大企業におけるSPF導入の課題

SPFでは、DoS攻撃を防ぐために、ルックアップを10回以下に制限することを余儀なくされています。 DoS攻撃やDDoS攻撃.残念ながら、これらのルックアップは、特に大企業では、非常に速く追加される可能性があります。以前は、企業は独自のメールサーバーを運用していましたが、現在ではサードパーティの送信者を利用しています。これは、それぞれが3、4台のサーバーを使用することができ、非常に迅速に限界に達するという問題が発生します。

SPFリミット

2023年2月27日/によって Ahona Rudra

電子メールのセキュリティ

なりすましメールの防止とメール配信能力の向上

15日間無料体験


カテゴリー

  • ブログ
  • ニュース
  • プレスリリース

最新のブログ

  • オンラインでメッセージのヘッダーを閲覧・分析する方法
    メッセージのヘッダーをオンラインで閲覧・分析する方法とは?9月 26, 2023 - 12:59 pm
  • 銀行におけるサイバーセキュリティ - トップの脅威と最善の予防策
    銀行業務におけるサイバーセキュリティ:銀行におけるサイバーセキュリティ:脅威のトップとそれを防ぐ最善の方法9月 25, 2023 - 10:47 am
  • 電子メールの送信元が信頼できるかどうかを確認する方法
    電子メールの情報源が信頼できるかどうかをチェックする方法とは?9月 25, 2023 - 10:40 am
  • AIからパスワードを守る方法
    AIからパスワードを守る方法2023年9月20日 - 午後1時12分
ロゴ・フッター・パワーマーク
SOC2 GDPR GDPRに準拠したPowerDMARC クラウン・コマーシャル・サービス
グローバル・サイバー・アライアンス・サーティファイド・パワー・マーク csa

知識

メール認証とは何ですか?
DMARCとは何ですか?
DMARCポリシーとは何ですか?
SPFとは何ですか?
DKIMとは何ですか?
BIMIとは何ですか?
MTA-STSとは何ですか?
TLS-RPTとは何ですか?
RUAとは何ですか?
RUFとは何ですか?
スパム対策とDMARC
DMARCの調整
DMARCのコンプライアンス
DMARCの施行
BIMI実装ガイド
ペルメラー
MTA-STSおよびTLS-RPT実装ガイド

ツール

無料のDMARCレコードジェネレータ
フリーのDMARCレコードチェッカ
無料のSPFレコードジェネレータ
無料のSPFレコード・ルックアップ
無料のDKIMレコードジェネレーター
無料のDKIMレコード検索
無料のBIMIレコードジェネレーター
無料の BIMI レコード ルックアップ
Free FCrDNS Record Lookup(無料の FCrDNS レコード検索
無料の TLS-RPT レコード チェッカー
無料の MTA-STS レコード チェッカー(MTA-STS Record Checker
無料の TLS-RPT レコード ジェネレーター

製品

製品ツアー
特徴
パワーSPF
PowerBIMI
PowerMTA-STS
PowerTLS-RPT
PowerAlerts
API ドキュメント
マネージドサービス
なりすましメール対策
ブランド保護
フィッシング対策
DMARC for Office365
DMARC(Google Mail GSuite用
Zimbra用DMARC
無料DMARCトレーニング

お試しください

お問い合わせ
無料トライアル
デモを予約する
パートナーシップ
価格について
よくある質問
サポート
ブログ
イベント情報
機能リクエスト
変更履歴
システム状況

  • English
  • Français
  • Dansk
  • Nederlands
  • Deutsch
  • Русский
  • Polski
  • Español
  • Italiano
  • 中文 (简体)
  • Português
  • Norsk
  • Svenska
  • 한국어
© PowerDMARCは登録商標です。
  • ツイッター
  • Youtube
  • リンクトイン
  • フェイスブック
  • インスタグラム
  • お問い合わせ
  • ご利用条件
  • プライバシーポリシー
  • クッキーポリシー
  • セキュリティポリシー
  • コンプライアンス
  • GDPRに関するお知らせ
  • サイトマップ
トップへスクロール