Sender Policy Framework レコードを検証
DNS とレコード
DNS ルックアップ あらゆるドメインのすべての DNS レコード A レコードルックアップ ドメインの IPv4 アドレス AAAA レコードルックアップ ドメインの IPv6 アドレス MX ルックアップ ドメインのメールサーバー NS ルックアップ 権威ネームサーバー TXT ルックアップ TXT レコード、SPF、検証 CNAME ルックアップ 正規名（エイリアス）レコード SOA ルックアップ Start of Authority レコード SRV ルックアップ サービスロケーションレコード CAA ルックアップ どの CA が証明書を発行できるか 逆引き DNS（PTR） IP アドレスからホスト名へ DNSSEC チェック ドメインは署名され検証されているか？ DNS ヘルスチェック 委任と DNS の総合診断レポートメール到達性
SPF チェック Sender Policy Framework レコードを検証 DMARC チェック DMARC ポリシーを検査・評価 DKIM チェック DKIM 公開鍵を検索・検証 ブラックリストチェック IP をメールブロックリスト（DNSBL）と照合 SMTP テスト メールサーバーに接続し STARTTLS をチェック MTA-STS チェック 受信メールに対する強制 TLS ポリシー BIMI チェック メール用のブランドロゴレコード TLS-RPT チェック SMTP TLS レポートポリシーネットワークとウェブ
SSL 証明書チェック サイトの TLS 証明書と有効期限を検査 HTTP ヘッダーチェック レスポンスヘッダー、リダイレクト、セキュリティを検査 Ping（TCP） TCP 経由での到達性と遅延 ポートチェック どの一般的なポートが開いているかドメイン
WHOIS ルックアップ ドメイン、IP、ASN の登録データSPF（Sender Policy Framework）は、どのホストが自社ドメインのメールを送信してよいかを受信側メールサーバーに伝える仕組みです。レコードの重複、DNSルックアップの過多、'all'メカニズムの欠落など、SPFレコードが正しく設定されていないと、正規のメールが迷惑メールフォルダに振り分けられてしまいます。IPeekはSPFレコードを取得し、各メカニズムを解析して、到達率を損なう問題点を指摘します。
SPFはルートドメインのTXTレコードとして公開され、v=spf1で始まります。受信サーバーは、自社を名乗るメールを受け取ると、このレコードを参照し、送信元IPが許可されているかを確認します。v=spf1 include:_spf.google.com ip4:198.51.100.10 -all というレコードは「GoogleのホストとこのIPを許可し、それ以外はすべて拒否する」という意味になります。各メカニズムは左から右へ評価され、最初に一致したものが採用されます。末尾のallメカニズムは、明示的に列挙されていないホストに対する既定の判定を決めるキャッチオールとして機能します。
allメカニズムはポリシーを定めます。-allはhardfail（列挙されていない送信者を拒否）、~allはsoftfail（受け入れるが疑わしいものとして扱う）、+allは誰でも許可するため決して使用してはいけません。また、SPFはDNSへ問い合わせるメカニズム（include、a、mx、ptr、exists、redirect）を合計10回までに制限しています。これを超えるとpermerrorとなり、失敗として扱われます。ネストされたincludeもカウントされるため、複数のベンダーを追加すると気づかぬうちに上限に達してしまいます。IPeekはすべてのルックアップを数え、上限に到達する前に警告します。
SPFだけでは不十分です。SPFが認証するのはエンベロープ送信者（Return-Path）であり、ユーザーが目にするFromアドレスではありません。そのため、なりすまし業者はSPFを通過しつつ、ブランドを偽装できてしまいます。DMARCは、SPFのドメインとFromドメインのアライメント（整合）を要求し、SPFとDKIMのいずれかでメッセージを認証できるようにすることで、このギャップを埋めます。SPFは3層の1つと捉えてください。SPFがホストを認可し、DKIMがコンテンツに署名し、DMARCがそれらをFromドメインに結び付けてポリシーを適用します。
SPFでは、1回の評価につきDNSへ問い合わせるメカニズムは最大10回までです。include、a、mx、ptr、exists、redirectの各メカニズムがルックアップを消費し、ネストされたincludeも同じ上限にカウントされます。10回を超えるとpermerrorが発生し、受信側は認証失敗として扱います。includeをフラット化または統合して、上限内に収めてください。
違いは強制力です。-allはhardfailで、レコードに列挙されていないホストからのメールを拒否するよう受信側に指示します。一方~allはsoftfailで、受け入れつつも疑わしいものとして扱うよう指示します。テスト中は~allを使い、すべての正規送信者が認可されたことを確認してから-allへ移行してください。誰でも認可してしまう+allは避けてください。
SPFレコードだけでは受信トレイへの到達は保証されません。よくある原因として、10ルックアップ制限の超過（permerror）、allメカニズムの欠落や過度に緩い設定、実際には認可されていない送信ホスト、同一ドメインにおけるSPFレコードの重複などが挙げられます。また、SPFは表示上のFromアドレスを保護しないため、強固な到達率を得るにはDKIMとDMARCを併用する必要があります。
いいえ。1つのドメインには、SPF（v=spf1）のTXTレコードを正確に1つだけ公開する必要があります。SPFレコードが2つ以上あるとpermerrorとなり、受信側がメールを拒否したり認証失敗にしたりする可能性があります。複数の送信者を認可したい場合は、2つ目のレコードを追加するのではなく、include や ip4/ip6 メカニズムを追加して1つのレコードにまとめてください。
いいえ。SPFが認証するのはエンベロープ送信者（Return-PathまたはMAIL FROM）であり、受信者が実際に目にするFromヘッダーではありません。これが、SPFだけではブランドのなりすましを防げない理由です。DMARCはSPFアライメントを追加し、SPFのドメインが表示上のFromドメインと一致することを要求することで、プロトコルレベルのチェックとユーザーが読む内容との間のギャップを埋めます。