SPFレコード チェッカーは、ドメインの公開されたSPFレコードをDNSから読み取り、 RFC 7208のルールに照らして検証します。レコードが 1 つだけあることを確認し、構文を解析し、すべてのインクルード チェーンを展開し、 DNSルックアップの合計をカウントして、制限の 10 を下回っているか超えているかを確認します。優れたチェッカーは、レコードが存在するかどうか、さらに重要なことに、レコードが受信サーバーで実際に渡されるかどうかを示します。
チェッカーが検証するもの
検証では、 SPF運用環境で機能するかどうかを決定する仕組みが取り上げられます。これらはそれぞれ一般的な障害点であり、ほとんどの場合、気付かれるような跳ね返りもなく静かに壊れます。
- 単一レコード: 2 つあるとpermerrorが発生するため、 SPF TXTレコードが 1 つだけ存在することを確認します。
- ルックアップ数: すべての include、a、および mx チェーンを展開し、制限の 10 に対してDNSルックアップを合計します。
- 構文: v=spf1タグ、メカニズムの順序、および有効な all 修飾子をチェックします。
- 送信者のカバレッジ: 承認した送信元が表示されるので、すべての実際の送信者が存在することを確認できます。
- 修飾子: -all 、 ~all 、またはそれより弱いもので終わるかどうかを報告します。
ルックアップのカウントが最も重要な理由
SPFエラーの最も一般的な原因は、クワイエット ルックアップ オーバーフローです。新しいベンダーを追加すると、さらにいくつかのルックアップがインクルードされ、合計が 10 を超えます。その時点から、受信者はpermerror返し、正規のメールが認証に失敗する可能性がありますが、自分の受信箱には問題を示すものはありません。フルチェーンを展開するチェッカーが実際の数値を確認する唯一の方法です。レコードは表面的には短く見えますが、舞台裏では 10 をはるかに超えて解決されるためです。
無料のドメイン スキャンを実行する
EmailAuthインクルード チェーンを拡張し、すべてのルックアップをカウントし、10 を超えるベンダーに正確にフラグを立てます。
確認から修正まで
問題を見つけることがステップ 1 です。スキャンで 10 を超えるルックアップが表示された場合、 EmailAuth SmartSPFインクルード チェーンを 1 つの最適化されたレコードにフラット化し、 Salesforce 、 SendGrid 、 Microsoft 365 、およびGoogle Workspaceのサードパーティ IP 範囲を、ベンダーの変更に応じて同期させます。これにより、プロバイダーがインフラストラクチャを更新するたびにレコードを手動で編集することなく、永続的に制限内に留まります。
DKIMおよびDMARCと並行してSPFを確認します
SPFは電子メール認証の 1 つの要素です。完全なチェックでは、 DKIM署名が適切に設定されていること、およびDMARCポリシーが調整を強制していることも確認する必要があります。これは、 SPFだけでは転送時に中断され、表示されている From アドレスを単独で保護できないためです。 3 つすべてを一緒に検証して、合格したSPFレコードが単独ではなく実際に配信可能性に貢献するようにします。
よくある質問
自分のSPFレコードが有効かどうかを確認するにはどうすればよいですか?
DNSから公開されたTXTレコードを読み取るSPFレコード チェッカーを通じてドメインを実行します。レコードが 1 つであることを確認し、構文を解析し、すべてのインクルードを展開し、 DNSルックアップを 10 の制限に対してカウントします。EmailAuth EmailAuth無料のドメイン スキャンがこれを実行し、ベンダーがあなたを押しのけていることを警告します。
私のSPFレコードはDNSルックアップを何回使用しますか?
各インクルードはその内部にさらにルックアップをネストできるため、レコード テキストだけからは判断できません。チェッカーはチェーン全体を展開し、実際の合計を報告します。 10 を超えると、受信者はpermerror返し、メールは認証に失敗する可能性があります。
SPFチェッカーでは実際に何が分かるのでしょうか?
有効なレコードが 1 つあるかどうか、正確なDNSルックアップ数、構文エラー、末尾にあるすべての修飾子、および承認したすべての送信元が明らかになります。これにより、すべての正当な送信者がカバーされており、制限を下回っていることを確認できます。
SPFレコードがチェッカーに合格しても、メールは依然として失敗するのはなぜですか?
SPFエンベロープ送信者をチェックし、メールの転送時に中断するため、有効なレコードが受信側で失敗する可能性があります。また、表示されている From アドレスだけを保護することはできません。 DKIMおよびDMARCポリシーと組み合わせて、転送と調整を通じて認証が保持されるようにします。
企業の来歴
一流の金融機関と政府が選ばれる理由 電子メール セキュリティ ダッシュボードを廃止しました。
従来の電子メール認証プラットフォームはダッシュボードを販売し、エンジニアに作業を依頼します。一か八かの環境では、手動による監視は適用の遅れ、構成のドリフト、および監視されていないシャドウ ドメインを意味します。
EmailAuthは、エージェントの電子メール来歴プラットフォームです。 当社のエージェントが執行します p=reject、サードパーティの送信者を調整し、ドメインを完全に移動します。 RFC 9989 新しいDMARC標準に準拠し、人間による監査機能を備えています。
SaaS · 専用テナント · エアギャップオンプレミス · BYOK 暗号化