SPF チェッカー

ドメインは、v=spf1 で始まる TXT レコードを公開していません。受信側には評価対象がないため、何も許可されず、拒否もされません。

まずレコードを生成してください。存在しないレコードを SPF レコードチェッカーで検証することはできません。

複数の v=spf1 TXT レコードがあると permerror になります。受信側は結合せず、評価を断念します。多くの場合、プロバイダーが既存レコードを確認せずに追加したことが原因です。

メカニズムを 1 つのレコードに統合し、余分なレコードを削除してください。SPF レコードチェッカー兼バリデーターで、統合後に問題なく解決されることを確認できます。

再帰的な照会が 10 回を超えると permerror になります。プロバイダーの include をもう 1 つ追加したことが、上限超過のきっかけになる場合がほとんどです。

プロバイダーが安定したアドレスを公開している場合は、include を明示的な ip4 範囲に置き換えてください。ip4 は照会を消費しません。その後、無料の SPF レコードチェッカーを再実行し、回数が減ったことを確認します。

+all はインターネット上のすべての送信者に、そのドメインとしての送信を許可します。?all は何も強制しません。どちらもレコードを飾りだけのものにします。

送信者を監査している間は ~all に変更し、その後 -all にしてください。この問題を指摘しない SPF チェッカーは役割を果たしていません。

include ホスト名のタイプミス、不正な CIDR、不明なメカニズム名があると、評価が停止して permerror が返されます。

無料の SPF レコードチェッカーが示したトークンを修正し、再照会してください。反映の遅延により、SPF レコードチェッカーには数分間キャッシュされた結果が表示される場合があります。

SPF レコードチェッカーが解決するのは 1 つのレコードだけです。メッセージ署名と From ドメインのアライメントは、それぞれ別のレコードであり、障害の起こり方も異なります。

ドメインが SPF に完全に合格しても、表示上の From 行では簡単になりすまされる可能性があります。

転送ではエンベロープ送信者を維持したまま配信元 IP が書き換えられるため、正当なメールでも SPF に失敗します。これを攻撃と区別できる SPF チェッカーはありません。

この問題を解決するために、DKIM と DMARC のアライメントがあります。

完璧なレコードでも、送信先アドレスが存在するとは限りません。送信者認証と受信者検証は、まったく別の問題です。

キャンペーンの前には、どちらか一方ではなく両方を実行してください。

基本的な認証に合格した後は、コンテンツ、苦情率、退信率、送信レピュテーションのすべてが認証より重視されます。

無料の SPF レコードチェッカーで SPF レコードを整えてから、ほかの要素を改善してください。