01

記録を静かに破る 10 回のルックアップ制限

これは誰も予期しない失敗であり、ほとんどの人が最終的に遭遇します。

受信サーバーが SPF レコードを評価するときは、次のことを行う必要があります。検出されたすべての include:、a、mx、ptr、および redirect を解決します。それぞれに同じものがさらに含まれる可能性があります。 標準では、DNS ルックアップ 10 回が上限です。 これを超えても、評価は合格または不合格に戻りません。永続的なエラーが返され、ほとんどの受信機はそれを SPF がまったくないものとして扱います。 成長することで記録はそれを上回る。ここにマーケティング プラットフォーム、そこにヘルプデスク、給与計算プロバイダー、新しい CRM のそれぞれに 1 つの include: が追加され、各 include: にはその中に複数のルックアップが隠されている可能性があります。 何も警告しません。 DNS パネルではレコードはまだ正常に見えますが、4 か月前に行われた変更に誰も接続しないため、配信に問題が発生し始めます。

02

誰も許可せず、何も停止しないソフト フェイル

すべての SPF レコードは次の文字で終わります。all メカニズムとその前の文字がすべてを決定します。

ほとんどのドメインは ~all で終わりますが、これは出発点としては適切ですが、ここで留まるのは間違っています。つまり、あなたの記録には、主張することなく誰が送信できるかが記載されており、それは声明であって、声明ではありません。防衛。

03

追加した include: は他の人のリストであり、変更されます

include: はプロバイダーのサーバーをレコードにコピーしません。プロバイダーのサーバーを指し、チェック時に存在するものはすべてインポートします。

これは便利であり、メール認証の一部は、あなたが管理していない会社によって維持されていることを意味します。彼らがインフラストラクチャを追加すると、あなたの記録はより多くのものをカバーします。再構築すると、検索数が増加しますジャンプできる。 include: エントリのうちどのエントリが大きいかを把握することは価値があります。これらのエントリは制限を超える可能性があるためです。

04

メールをまったく送信しないドメイン

自分が所有していて送信元のないドメインは、誰も返信を見ておらず、誰も苦情に気づかないため、なりすますのが最も簡単です。

このようなドメインには、何も許可しない SPF レコードが引き続き必要です。

v=spf1 -all

それは完全で正しい記録です。 「このドメインとして送信を許可されているサーバーはありません」と表示されます。パークされているドメイン、古いブランド、防御的に購入されたドメインはすべて、1 つの価値があります。

05

レコードが 1 つあるはずの場所に複数のレコードがある

ドメインには SPF レコードが 1 つだけ存在する場合があります。両方とも v=spf1 で始まる 2 つの TXT レコードは、保護が 2 倍ではありません。これは永続的なエラーであり、結果は何もない場合と同じになります。

2 番目のプロバイダーのセットアップ ウィザードの実行時に発生します自分のレコードを編集するのではなく、独自のレコードを追加します。解決策は、それらを 1 つにマージすることです。問題は気づいていることだ。

06

特定の日付における記録が正しかったという証拠

「SPF を設定しました」というのは主張です。記録とそのポリシーを示す日付付きのレポートは証拠であり、保険会社や顧客のセキュリティ審査が実際に望んでいることです。その記録を構築することはそれ自体が主題です。