SPF レコード検索
SPF レコードをチェックして、スパマーがあなたのドメインからメールを送信できるような誤設定を発見します。
当社の SPF レコード検索は DNS を分析し、よくある落とし穴を明らかにし、正しい設定の適用をお手伝いします。
SPF レコードをチェックして、スパマーがあなたのドメインからメールを送信できるような誤設定を発見します。
当社の SPF レコード検索は DNS を分析し、よくある落とし穴を明らかにし、正しい設定の適用をお手伝いします。
DMARCFlow の SPF チェッカーを使って、送信メールが適切に認証されていることを確認しましょう。SPF レコードは、ドメインから送信されたメッセージが正当で偽造されていないことを証明するのに役立ちます。
まず、ドメインに SPF レコードがあることを確認します。次に、正しく設定されていることを確認します。構文エラーや include の使いすぎといった小さなミスでも、SPF は壊れることがあります。DMARCFlow は、SPF 構造とすべての認可された送信ソースを明確に把握できるようにします。
仕組みをご覧になりたいですか？SPF テストツールの使い方に関する短い動画ガイドをご覧ください。
SPF（Sender Policy Framework）を使うと、どのサーバーがドメインのためにメールを送信できるかを宣言できます。受信サーバーはあなたの DNS SPF レコードを確認し、送信者が認可されていなければ、メッセージにフラグが付けられたり拒否されたりすることがあります。
正しい SPF はフィッシングの防止に役立ち、到達率を向上させて正当なメールが受信トレイに届くようにします。
ドメインを保護し、メールを受信トレイに届けるための段階的なガイド。
信頼できる送信ソースのみを含めます。明確さと速度のために、メカニズムは最小限に保ちます。
実際に使用しているサービス（例：Mailchimp、Google Workspace）のみを含めます。各プロバイダーの SPF 構文を確認してください。
SPF は最大 10 回の DNS ルックアップを許可します。permerror の失敗を避けるためにフラット化・最適化してください。
メールサーバーやプロバイダーを変更した後は SPF を検証し、問題の再発を早期に発見します。
誰がドメインのために送信できるかを監査し、古いまたはリスクのあるソースを削除するよう SPF を更新します。
結果の各ステータスには特定の意味があります。それぞれが何を示し、次に何をすべきかをご説明します。
送信 IP は SPF レコードによって認可されています。メールは SPF 認証を通過します。対応は不要ですが、完全なカバレッジのために DKIM や DMARC と組み合わせてください。
送信 IP は明示的に認可されていません。SPF レコードが -all で終わり、このサーバーが記載されていません。受信者はおそらくメッセージを拒否またはフラグ付けします。不足しているサーバーを追加するか、なぜ認可されていないソースからメールが来ているかを調査してください。
送信者は認可されていませんが、ポリシーが寛容です（~all）。メールは通常受け入れられますが、スパムとしてマークされることがあります。SPF が安定して完全になったら -all への移行を検討してください。
恒久的なエラー - SPF レコードに構文の問題があるか、10 回の DNS ルックアップ制限を超えています。これは DMARC レポートにおける SPF 失敗の最も一般的な原因です。すぐにレコードを修正してください。受信者はまったく評価できません。
ルックアップ中の一時的な DNS の失敗です。通常は自然に解決しますが、DNS インフラの問題を示している場合があります。続く場合は、DNS プロバイダーのステータスを確認してください。
None: SPF レコードがまったく見つかりません。ドメインは無防備です。すぐに SPF レコードを公開してください。Neutral: レコードは存在しますが、何も主張しません（?all）。実質的にポリシーがないのと同じです。
これらは、DMARC レポートで SPF の失敗を最も頻繁に引き起こすミスです。
include:、a、mx、exists の各メカニズムは DNS ルックアップとしてカウントされます。10 を超えると PermError が発生し、SPF レコードが無効になり、受信者はそれを完全に無視します。
修正: SPF フラット化を使って IP アドレスを直接インライン化し、ネストされた include チェーンを削除します。使用しなくなったサービスは削除してください。
同じドメインに v=spf1 で始まる TXT レコードを 2 つ以上公開することは RFC 違反であり、PermError を引き起こします。受信者は SPF 評価全体を拒否します。
修正: すべての送信ソースを 1 つの SPF レコードに統合してください。重複は削除します。
新しいメールサービス（CRM、マーケティングプラットフォーム、ヘルプデスク）を追加しても SPF を更新しないと、そのサービスからのメールは失敗します。これは DMARC 集約レポートに SPF の失敗が現れる最も一般的な理由です。
修正: あなたに代わってメールを送信するすべてのサービスを特定し、その include: ステートメントまたは IP 範囲を SPF レコードに追加してください。
SPF の通過だけでは DMARC には不十分です。SPF で認証されたドメインは、From: ヘッダーのドメインとアライメントしている必要があります。転送メールやメーリングリストは、SPF 自体が通過しても SPF アライメントを頻繁に壊します。
修正: DKIM も設定しアライメントさせてください。DKIM は転送後も維持されますが、SPF は維持されません。
SPF レコードに関するよくある質問
v=spf1 include:example.net -all）。