ポスト

SPFは、あなたのドメインのDNSにTXTレコードとして存在し、多くのメカニズムや特定の指示を表す修飾子があります。SPFのすべてのメカニズムは、SPFレコードの右端に存在し、「-」または「~」が前に付いています。ここでは、SPFの-allと~allのメカニズムにどのような違いがあるのか、どのような場合に設定すべきかを見ていきましょう。

SPF -all vs ~all

SPF -all と ~all の両メカニズムは、SPF 認証の "NOT PASS" を意味します。最近では、大多数のメールサービスプロバイダーにおいて、-allと~allの仕組みに違いはなく、同じ結果が返されます。しかし、数年前まではそうではありませんでした。

DMARC以前のSPFオール(Softfail vs Fail)の仕組みはどのように運用されていたのでしょうか?

DMARCは、SPFが標準的なメール認証プロトコルとして市場に出てから、かなり時間が経ってから作られたものです。この時、SPF -all softfailの仕組みは次のように動作していました。 

あなたのSPFレコードがそうだったとしましょう。 

v=spf1 include:spf.domain.com ~all(ここで ~all は SPF Softfail を意味します)

受信者のメールサーバーは、送信者のDNSにSPFレコードを問い合わせるために、DNSルックアップを実行したはずです。メールのReturn-pathドメインが送信者のレコードに記載されていない場合、受信サーバーはSPF "NOT PASS "の結果を返しますが、次のようになります。 メールを配信したを受信者の受信箱に送る。

ここで、あなたのSPFレコードがそうだったとします。 

v=spf1 include:spf.domain.com -all(ここで -all は SPF Fail を意味します)

受信者のメールサーバーは、送信者のDNSにSPFレコードを問い合わせるために、DNSルックアップを実行したはずです。メールのReturn-pathドメインが送信者のレコードに記載されていない場合、受信サーバーはSPFの「NOT PASS」結果を返しますが、この場合、メールは「NOT PASS」されています。 される。拒否され、配信されないを受信者の受信箱に送る。

Sender Policy Frameworkの歴史についてはこちらをご覧ください。 

メールサービスプロバイダーは、現在、SPF -all vs ~allの仕組みをどのように扱っているのでしょうか?

現在、ほとんどのメールボックスプロバイダーで、SPF -all または ~all を自由に使用することができ、正当なメールに対する配信失敗を心配する必要はありません。 all属性の場合、サーバーがあなたのメールを拒否する状況が発生する可能性があります。.

より安全にするために、SPFレコードの作成時にSPF hard fail -all メカニズムを使用しないようにすることができます。これは、その方法です。

  • PowerDMARCを開く SPFレコードジェネレーターをクリックすると、無料でレコードの作成を開始できます。
  • 送信者のIPアドレスとドメインを入力した後、最後のセクションまでスクロールして、メールサーバーがお客様のメールを検証する際の厳密さを指示します。
  • Generate SPF Record "ボタンを押す前に、"Soft-fail "オプションを選択します。

おすすめは?SPF -all または SPF ~all

SPF -allメカニズムに関連するメール配信の問題は、ごく稀に発生する可能性があります。これは、頻繁に発生する問題ではありません。この問題に遭遇しないようにするには、次の手順を実行することができます。

  • 設定 DMARCDMARCレポートを有効にします。
  • DMARCポリシーを監視に設定し、SPF認証結果を精査することで、メール配信の不整合箇所を発見する。
  • 問題がなければ、SPFレコードに-allメカニズムを使用することができます。ハードフェール属性は、メールの信頼性に自信があることを証明し、ドメインの評判を高めることができるため、使用することをお勧めします。

現在、SPF -allの使用を迷っている方は、以下の手順で使用することができます。

  • allメカニズムを使用してSPFレコードを設定します。
  • メールにDMARCを設定し、DMARCレポートを有効にする
  • DMARCポリシーを拒否するように設定する

その他のSPFエラーのトラブルシューティング

オンラインツールを使用していると、しばしば「?SPFレコードが見つかりません「これは、サーバーがドメインのSPFレコードを検索したときに返されたNULL結果が原因で発生する一般的なエラー状態です。この問題の詳細と解決方法については、こちらの記事で解説しています。詳しくは、リンク先のテキストをクリックしてください。

SPFに加え、お客様のドメインでDMARCを導入している場合、メールサーバーはお客様のドメインのDMARCポリシーを確認し、認証に失敗したメールがどのように扱われたいかを確定します。このDMARCのポリシーによって、メールが配信されるか、隔離されるか、拒否されるかが決まります。 

DMARC拒否は、なりすまし、フィッシング、ランサムウェアなどの様々ななりすまし攻撃からドメインを保護するのに役立ちます。

SPF認証に失敗するメールを見たことがありますか?もし見たことがあるのなら、なぜSPF認証が失敗するのかを正確に説明します。Sender Policy Framework(SPF)は、スパムを防ぐために長年使用されてきたメール認証基準の1つです。意識していなかったとしても、Facebookのログインアカウントの設定を確認すると、「友達からのメールのみ受信する」という「オプトイン」が表示されていると思います。これは事実上、SPFと同じことです。

SPF認証とは何ですか?

SPFはメール認証プロトコルで、メール送信者がメッセージのFrom: フィールドにあるドメイン名と一致するかどうかを確認するために使用されます。送信MTAは、DNSを使用して事前に設定されたSPFサーバのリストを照会し、送信IPがそのドメインのメール送信を許可されているかどうかを確認します。SPFレコードの設定方法には矛盾がある場合があります。これは、メールがSPF検証に失敗する理由を理解し、自社のメールマーケティング活動で問題が発生しないようにするために、どのような役割を果たすことができるかを理解する上で重要です。

SPF認証が失敗する理由 :なし、ニュートラル、ハードフェイル、ソフトフェイル、TempError、PermError

SPF認証の失敗は、以下のような原因で起こります。

  • 受信側のMTAが、お客様のDNSで公開されているSPFレコードを見つけられない
  • 同一ドメインのDNSに複数のSPFレコードが発行されている
  • お客様のSPFレコードで更新されていないESPのIPアドレスが変更または追加されている。
  • SPFのDNS検索回数が10回を超えると
  • 許可されたボイドルックアップの最大数である2を超えると
  • フラット化されたSPFレコードの長さが、SPF文字数制限の255文字を超えています。

上記は、SPF認証が失敗する様々なシナリオです。当社のDMARCアナライザーでドメインを監視し、SPF認証失敗のレポートを得ることができます。DMARCレポートを有効にすると、受信側のMTAは、メールがSPF認証に失敗した理由に応じて、以下のSPF認証失敗結果のいずれかを返します。もっとよく知っておこう。

SPF Fail Qualifiersの種類

SPF Fail qualifiers の種類は以下のとおりで、それぞれ SPF Fail メカニズムの前にプレフィックスとして付加される。

"+" "合格"
"-" "不合格"
"~" "ソフトフェイル"
"?""Neutral(ニュートラル)"

どのような意味があるのでしょうか?SPFに失敗した場合、受信者にどの程度厳しく対応させるかを選択できます。チェックに失敗したメッセージを「通過」させる(配送する)か、「失敗」させるか、「中立」な立場(何もしない)に立つかを指定することができます。

ケース1:SPF Noneの結果が返ってくる場合

最初のケースでは、受信側のメールサーバーがDNSルックアップを実行して、DNSにドメイン名が見つからない場合、noneの結果が返されます。送信者のDNSにSPFレコードが見つからない場合にもnoneが返されます。これは、送信者がこのドメインに対してSPF認証を設定していないことを意味します。この場合、メールのSPF認証は失敗します。

このような事態を避けるために、無料のSPFレコード生成ツールを使って、今すぐエラーのないSPFレコードを生成しましょう。

ケース2:SPF Neutralの結果が返ってくる場合

ドメインのSPFを設定する際に、SPFレコードに ?all メカニズムを付けた場合、送信メールのSPF認証チェックの結論がどうであれ、受信側のMTAはニュートラルな結果を返すことになります。これは、SPFをニュートラルモードにすると、自分に代わってメールを送信することを許可されたIPアドレスを指定せず、許可されていないIPアドレスにもメールを送信させることになるためです。

ケース3:SPF Softfailの結果

SPF softfailは、SPF neutralと同様に、~allメカニズムによって識別されます。これは、受信側のMTAがメールを受け入れ、受信者の受信箱に配信することを意味しますが、DNSにあるSPFレコードにIPアドレスが記載されていない場合は、スパムとしてマークされ、SPF認証がメールに失敗する原因となります。以下にSPFソフトフェイルの例を示します。

 v=spf1 include:spf.google.com ~all

ケース4: SPF Hardfailの結果

SPF hardfailはSPF failとも呼ばれ、受信側のMTAがSPFレコードに記載されていない送信元からのメールを破棄してしまうことです。ドメイン偽装やメールスプーフィングからの保護を受けたい場合は、SPFレコードにSPFハードフェイルを設定することをお勧めします。以下に、SPF hardfailの例を示します。

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

ケース5:SPF TempError(SPF一時エラー

SPF認証が失敗する非常に一般的で無害な理由の1つに、SPF TempError(一時的エラー)があります。これは、SPF認証チェックが受信MTAによって実行されている間に、DNSタイムアウトなどのDNSエラーが原因で発生します。そのため、名前が示すように、通常はSPFの一時的な失敗の原因となる4xxステータスコードを返す一時的なエラーですが、後で再試行するとSPFパスの結果が得られます。

ケース 6:SPF PermError(SPFパーマネントエラー

ドメインエラーが直面するもう一つの一般的な結果はSPF PermErrorです。これは、ほとんどのケースでSPF認証が失敗する理由です。これは、SPFレコードが受信側のMTAによって無効にされた場合に起こります。DNSルックアップの実行中に、MTAによってSPFが壊れて無効になる理由はたくさんあります。

  • 10個のSPF検索の制限を超えること
  • 誤ったSPFレコード構文
  • 同一ドメインに複数のSPFレコードが存在する場合
  • SPFレコードの長さ制限(255文字)を超える場合
  • お客様のSPFレコードがESPによる変更に対応していない場合

注:MTAが電子メールに対してSPFチェックを行う際には、DNSに問い合わせを行うか、DNSルックアップを行って電子メールの送信元の信頼性をチェックします。理想的には、SPFでは最大10回のDNSルックアップが許可されており、これを超えるとSPFが失敗し、PermErrorの結果が返されます。

Dynamic SPF FlatteningはSPF PermErrorをどのように解決するのですか?

他のSPFエラーとは異なり、SPF PermErrorは解決するのが非常に厄介で複雑です。PowerSPFでは、自動的にSPFをフラット化することで、このエラーを簡単に軽減することができます。あなたをサポートします。

  • SPFのハードリミットを下回る
  • SPFレコードを瞬時に最適化
  • レコードを単一のインクルード・ステートメントにフラット化する
  • ESPによる変更に伴い、SPFレコードが常に更新されていることを確認してください。

あなたのドメインにSPFが正しく設定されているかどうかを試してみませんか?今すぐ無料のSPFレコードルックアップツールをお試しください。