私の意見では、世界で最も大きく革新的な企業でも無視されている重要な問題に注意を喚起したいと思います。 問題は、ほとんどのドメインには、ドメインを電子メールでの不正使用から保護するSPFレコードがないことです。
SPF（Sender Policy Framework）は、DNSドメインのTXTレコード内のテキストエントリです。 レコードには、このドメインに代わってレターを送信する権限を持つサーバーのリストに関する情報と、他のサーバーから送信されたレターを処理するメカニズムが含まれています。
たとえば、SPFレコード「
example.com 」
。 TXT“ v = spf1 + a + mx -all”は、このドメインのAおよびMXレコードで指定されたサーバーがドメイン“ example.com”に代わってレターを送信でき、他のサーバーから送信されたレターは削除（失敗）。
理解することが重要です：
- SPFレコードはサブドメインに継承されません。 第3（およびそれ以下）レベルの各ドメインには、独自のレコードが必要です。
- SPFは、HELOおよびMAIL FROMフィールドのみをチェックします。
この技術に関するすべての詳細情報
は、Sender Policy FrameworkプロジェクトのWebサイトで見つけることができます。
なぜこれが重要なのですか？
現在、すべての高度なスパム対策システムは、主に3種類の電子メール分析（およびそのバリエーション）を使用しています。
- 送信者サーバーのIPアドレスの分析：その評判、AおよびPTRレコードの正確さ。
- SPF / DMARCドメインレコードとDKIMデジタル署名の分析。
- コンテンツ分析：見出し、件名、テキスト、リンクなど
スパム対策システムを正常に通過するには、スパマー（または詐欺師）が必要になります：「クリーンIP」、美しい文字、および保護なしのドメイン（例1および3）。 「あなたの名前」（フィッシング）からの手紙を送信しないようにするには、対応するTXTレコードをドメインに追加するだけです（例2）。
例
例として、telnetおよびSMTPコマンドを使用して3つの簡単な文字を送信しました。 2文字はSpamAssassinスパムフィルター（mail-tester.comサービス）の動作を示し、最後の文字はGmailアンチスパムフィルターを通過します。 実験の純粋さのために、「クリーンな」IPアドレス（見つけるのはそれほど難しくありませんでした）と、リンクとHTMLのないテキストを使用しました。
| ＃ | から | に | 結果 | SPF送信者ドメイン |
| 1 | bill.gates@microsoft.ru | *@mail-tester.com | 成功しました。 mail-tester.comのポイント：7/10 | - |
| 2 | bill.gates@microsoft.com | *@mail-tester.com | 失敗しました。 mail-tester.comのポイント：2.1 / 10 | v = spf1インクルード：_spf-a.microsoft.comインクルード：_spf-c..microsoft.comインクルード：_spf-ssg-a.microsoft.comインクルード：spf-a.hotmail.com ip4：147.243.128.24 ip4：147.243.128.26 ip4：147.243.1.153 ip4：147.243.1.47 ip4：147.243.1.48 -all |
| 3 | bill.gates@microsoft.ru | *@gmail.com | 成功しました | - |
手紙1：
手紙番号2：
手紙3
結果からわかるように、microsoft.comドメインからの手紙は、完全にクリーンなコンテンツがあったとしても、スパム対策フィルターを通過していません。 しかし、ドメイン「microsoft.ru」を代表する手紙は、保護されていないため、SpamAssassinとGmailの両方の検証に合格しました。
ヒント
- SPFレコードをインストールする前に、インターネットにメールを送信するすべてのサーバーが考慮されていることを確認してください。 Webサーバーや他の外部システムを忘れないでください。そうしないと、一部の文字を失い、自分自身やビジネスに損害を与える可能性があります。
- 手紙を処理するためのメカニズムを正しく選択します（Pass、Fail、SoftFail、Neutral）。 あるメールシステムから別のメールシステムに無条件にレターをリダイレクトすると、SPFが最後の「ホップ」のみをチェックするため、問題が発生する可能性があります。
- あなたに代わって手紙を送らなくても、あなたまたはあなたの会社に属するすべての第2レベルドメインのSPFレコードを作成することをお勧めします。 このようなドメインでは、単純なレコード「 v = spf1 -all 」を使用することをお勧めします。これは、これらのドメインから誰も手紙を送信できないことを示しています。
- 第3レベルのドメインは、 * .example.comタイプのワイルドカードレコードを使用して保護できます。 IN TXT "v = spf1 -all" "。 ただし、ワイルドカードは存在しないサブドメインに対してのみ機能することに注意してください。 たとえば、MXレコードを持つサブドメインmoscow.example.comがある場合、エントリは「 * .example.com 」 です。 IN TXT“ v = spf1 -all” 」は適用されません。 詳細については、 WikipediaとRFC 1034の記事を参照してください 。
さらに、ワイルドカードは、照会されたタイプの一致するレコードがない場合だけでなく、ドメインが存在しない場合にのみ一致します。 RFC 1034セクション4.3.2の検索アルゴリズムで定義されている「存在しない」という定義でさえ、ワイルドカードが他のタイプのワイルドカードで予想されるケースと一致しないことがあります。
- ドメインだけでなく、インターネットに電子メールを送信するメールサーバー用にSPFレコードを作成することをお勧めします。 受信サーバーのHELO / EHLOテストに合格する必要があります。 標準エントリ：“ mx.example.com。 IN TXT "v = spf1 a -all" "。
- 複数の主要なMXサーバーがサービスを提供するドメインが多数ある場合は、リダイレクトメカニズムを使用することをお勧めします。 たとえば、メインドメイン「example.com」にはSPFレコード「 v = spf1 + a + mx -all 」があり、他のドメイン（example1.com、example2.comなど）の場合、メンテナンスを簡単にするために、エントリを登録できます。 「 V = spf1 redirect = example.com 」
- 多くのドメインと多くの送信者メールサーバーが地理的および組織的に分散している場合、「含める」メカニズムと別のゾーン「_spf.example.com」を使用できます。 例として、gmail.comドメインのエントリを見ることができます-“ v = spf1 redirect = _spf.google.com ”。
- ドメインを保護することに加えて、外部メールサーバーでSPF / DKIM / DMARCレコードの検証を有効にして、メールシステムとユーザーを保護することをお勧めします。 これは、Cisco IronPortのような強力なハードウェアおよびソフトウェアシステムにとっても優れた追加となります。
- SPFを完全に理解したら、DKIMテクノロジとDMARCポリシーを使用してメールに署名する問題を調査することをお勧めします。これにより、送信メールの評判が大幅に向上します。
IT部門の仲間であり、自分自身とあなたの会社を公開しないでください-すべてのドメインとMXサーバーのSPFレコードを設定してください。
便利なサービス
SPFレコードのテストSpamAssassinスパム対策メール分析多くの有用なテスト（MX、SPF、ブラックリスト、DKIMルックアップなど）メールサーバーとドメインのレピュテーションを確認するドメインと送信者サーバーを確認する（ここでは、ドメインに代わって誰が手紙を送信するかがわかります）MS Sender ID Framework SPFレコードウィザード