SPF設定時に避けたいよくあるミス

ブログ

SPFの設定によくある間違いは、レコードを完全に無効にしてしまい、認証の妨げになることがあります。ここでは、あなたがすべきことを説明します。

byアホナ・ルドラ

読書時間 4 分
SPF設定時に避けたいよくあるミス
目次-

SPFバリデーションは、メールの到達率を向上させ、フィッシングやスパムからドメインを保護するために重要です。 フィッシングやスパム 攻撃からドメインを守るために重要です。しかし、SPFの設定は複雑で、設定中に間違ってしまうこともあります。これらの一般的なエラーを修正し、回避することで、誤検出をなくし、DMARCを保護することができます。 DMARCを遵守するようにしましょう。

主なポイント

  1. 配信の問題を避けるため、SPFレコードは1つのドメインにつき1つだけ存在すべきである。
  2. DNSルックアップ回数が10回を超えると、SPFの検証に失敗することがある。
  3. all'メカニズムは、適切に機能させるためにSPFレコードの末尾に配置する必要があります。
  4. ptr」メカニズムの使用は推奨されておらず、パフォーマンスの問題を引き起こす可能性があるので避けること。
  5. SPFレコードは、適切なメール配信を保証するために、慎重な調査と正確な情報を必要とします。

SPF設定時に避けたい、よくある7つの間違い

いくつかのDNSメカニズムは、電子メールのリターン・パス・アドレスで電子メールを送信することを許可されたシステムのIPを示すために使用される。SPFレコードのサイズ超過、10回以上のDNSルックアップ、2回以上の未解決DNSルックアップなどです。

SPF設定の際によくあるSPFエラーをリストアップしましたので、回避にお役立てください。

間違い1：複数のSPFレコード

SPFエントリーは1ドメインにつき1つであるべきで、そうでなければ受信サーバーは両方を拒否します。現在使われていないSPFエントリーを削除する。例えば、アクティブなSPFエントリーを持つ古いサービス。

このSPFの設定ミスは、2つ以上のレコードを1つに統合することで解決できます。例えば、あるユーザードメインにSPFレコードがあり、Elastic EmailのSPFエントリーが含まれているが、検証チェックに合格していないとします。この場合、ドメインに2つのレコードが存在することが原因として考えられます。 

v=spf1 a mx include:_sampledomain1.com include:_spf.elasticemail.com ~all

v=spf1 a mx include:_sampledomain2.com ~all

のように1つのレコードに統合することで解決できます：

v=spf1 a mx include:_sampledomain1.com include:_sampledomain2.com include:_spf.elasticemail.com ~all

間違い2：DNSのルックアップが多すぎる

include」ルックアップは10回までという制限があり、他のドメインへの参照を10回以上生成できないことを意味します。パラメータ「include」、「a」、「mx」、「ptr」、「exists」、「redirect」が出現するたびに、ルックアップが発生します。さらに、'組み入れる'に別のパラメータが含まれている場合、それも10回のルックアップ制限にカウントされます。このように、ルックアップの上限を超えることは、SPFの設定中に起こりやすいエラーの1つです。

これを修正するには、''を削除する必要があります。を含む'と、非アクティブなドメインへの言及がある。

PowerDMARCでセキュリティを簡素化！

15日間のトライアルデモを予約する

間違い3：寛容 何れもメカニズム

SPFレコードは左から右へと解釈され、'オール の仕組みは、'オール前記の仕組みに合致しない送信者に対しを配置することが提案されています。オール機構をSPFレコードの末尾に追加し、プレフィックスとして ~ (softfail) または - (fail) を付けて使用します。プレフィックスが設定されていない場合は、デフォルトで+（パス）が使用されます。

間違い4：の使い方 伝令係メカニズム

SPFの'ptr'のメカニズムは、ホスト名と対応するIPアドレスを返すDNS逆引きに使用されます。この情報は、特にB2Bブランドにとって有用である。しかし、このメカニズムには信頼性の問題があり、逆引きDNSサーバーやそれに接続されたメールシステムに負担をかけることになる。

そのため、RFC7208では、'の使用を推奨しています。ptr' という仕組みになっています。大半の場合、'で置き換えることができます。a'の機構を採用しています。

間違い5：の使用 エムエックスメカニズム

使用する 'mx' を、メールサーバー名ではなくドメイン名でステーティング mx:mailserver.sample.com は、実際に SPF 検証で 'mailserver.sample.com' ドメインのメールを受け付けるすべてのホストを調べる必要がある場合を除き、不正解と見なされます。ほとんどの場合、'mailserver.sample.com'はそれ自体がホストであり、ドメインではないので、そのようなホストは存在しないでしょう。

構文エラーとして出くわすことはありませんが、単純に何かにマッチするわけではありません。

sample.com」のMXレコードに対する正しい検証方法は以下の通りです。 mx:sample.comです。 特定のメールサーバーのホスト名やIPアドレスを定義する必要がある場合、 a:mailserver.sample.com または ip4:x.x.x を使用する必要があります。

間違い6：適切な調査を行わずにSPFレコードを作成した場合

これは特にISPの場合です。ドメイン、所有者、所属するブランドに関する中途半端な情報でレコードを作成しないようにしましょう。どのようなメールサーバーを使用しているか調査してください。そうしないと、オフィス内のメールサーバーからの送信メール配信経路をブロックすることになるかもしれません。

間違い7：誤字脱字

SPFレコードにタイプミスがないかダブルチェックすることで、SPF設定の際によくあるミスを回避することができます。include」ではなく、「inlcude」と入力してしまうことがあります。これはレコード全体を無効にしてしまう可能性があります。

間違い8：メールサーバーで使用するHELO名のSPFレコードを公開していない

Verifying HELO or EHLO names is encouraged by the SPF RFC. HELO or its developed version EHLO is used when Mail from is <> despite the recipient’s failure in doing 100% HELO checking.

HELOプロトコルの発行には、メールサーバーが使用するHELO FQDNに対応するSPFレコードを生成することが含まれます。例えば、以下のようになります： メールサーバー.sample1.com

一般的には、「sample1.com」にリンクされたドメイン内のFromアドレスをチェックするSPFルールとは、まったく別のSPFルールであるべきです。

間違い9：TXTレコードのコンテンツが二重引用符で表示されない

DNS TXTレコードの内容は常に二重引用符（"-"）の中にあるが、これは実際のDNSレコードの内容の一部であってはならない。これらの引用符は、TXTレコードの内容の開始と終了を区切るためのものであり、表示目的だけのものである。

SPFレコードは、次のように始まります。 v=spf1 で始まるが "v=spf1の場合、全く認識されません。

まだ問題があるのか？

SPFの設定を変更するたびに、インターネットを通じて伝播するためにある程度の時間を必要とします。最大で72時間かかることもあります。それでもまだ問題があるようなら、私たちの無料サービスをご利用ください。 SPFレコードチェッカーツールにアクセスするか、または当社の専門家チームまでご連絡ください。 [email protected].

最新記事 by Ahona Rudra(全て見る)
電子メールのなりすましは簡単か？電子メールのなりすましは簡単かファイルレスマルウェアとはファイルレスマルウェアとは？