メール到達性チェック
評判よりも前、内容よりも前に、受信者が問うのは一つの質問だけです：このドメインは、そのメールが本当に自らのものだと証明できるか？このチェックはその証明を読み取ります——MXレコード、SPF送信者リスト（受信者の数え方で展開しカウント）、_dmarcにあるDMARCポリシー、そして一般的なセレクタの下にあるDKIMキー——そして運用者が直す順序で、平易な言葉で所見を返します。
これを継続的に監視したいですか？myeventwatchで無料で監視——有効期限とダウンタイムのアラート、カード不要。
このチェックが測るもの
スパムフィルタリングは本人性から始まります。本人性はミリ秒で確認できるからです。あるドメインからのものだと主張するメールが届くと、受信サーバーはそのドメインが公開しているルールを参照します。SPFは送信を許可されたサーバーを列挙します。DKIMは、公開されたキーで検証できる署名を提供します。DMARCは、表示されるFromドメインがその二つの証明のどちらかと一致することを要求し、どちらも一致しないメールへの罰則——なし、隔離、拒否——を定めます。このページはsysosxのサーバー上のGET /api/check/email-authを呼び出し、ヘルスチェックが使うDNSパーサーで同じレコードを読み取り、所見に変換します：プロトコルごと、問題ごと、一つの重大度で、直す価値のある順序に並べて。
所見のうち二つは誠実さについて触れる価値があります。どちらもチェッカーが精度を装いがちな場所だからです。SPFの参照回数は本物です：チェッカーは受信者が適用するのと同じルールでincludeとredirectの連鎖を項ごとに展開するので、報告される数字は厳格な受信者が計算する数字そのものです——ベンダーが自らのレコードを変更するにつれて、そのレコードが10回という上限を静かに超えて漂流している場合も含みます。そしてDKIMの結果は探索であって全数調査ではありません：キーは所有者が選ぶセレクタ名の下に公開され、チェックは一般的なものを試し、どれも見つからなかったとしてもDKIMが存在しないことの証明にはなりません——他のセレクタの下にあるキーは外部からは見えず、結果はドメインが署名していないと宣言するのではなく、それをはっきりと述べます。完全なDKIMテストは今もなお、実際のメッセージとそのAuthentication-Resultsヘッダーだけです。
結果の読み方
失敗から始めてください；それらは迷惑メールフォルダのお気に入りの原因です。MXがないということは、そのドメインはメールをまったく受信できないということです。SPFがない、または+allで終わるSPFレコードは、誰でもあなたを名乗れるということです——後者はその主張が公式に許可されている分、さらに悪い。複数のSPFレコードはSPF評価全体を静かに無効にします。DMARCレコードがないということは、失敗したメールに定められた罰則がなく、そして同じくらい高くつくこととして、誰もあなたのドメインとして送信している者を示す集約レポートを収集していないということです——それらのレポートこそ、なりすましキャンペーンが通常発見される手段です。レポートが届くとき、それは生のXMLとして届きます；DMARCレポートアナライザーは.xml、.gz、.zipファイルをローカルで開き、送信元ごとに誰が合格し、誰が不合格で、何を直すべきかを示す表に変換します。警告は中間の状態です：p=noneはDMARCを始めるには良い場所ですが、止まるには悪い場所です；~allはテストモードであって目的地ではありません。次に全体像のもう半分を見てください：認証は本人性を証明し、一方でDNSブラックリストチェッカーは評判を測ります——両方を実行してください。完全に認証されたドメインでも、リストに載ったIP上にあれば迷惑メールに届きますし、クリーンなIPでもSPFが壊れていれば同じです。すべてを結びつけるガイドはメールが迷惑メールに届く理由です。
よくある質問
SPF、DKIM、DMARCとは何ですか？どう組み合わさるのですか？
これらは「このメールは本当に、それを名乗るドメインからのものか？」という質問に対する、DNSで公開された三つの答えです。SPFはドメインのために送信を許可されたサーバーを列挙します。DKIMはドメインがメッセージに暗号署名できるようにし、受信者はDNSに公開されたキーで署名を検証できます。DMARCはそれらを結びつけます：表示されるFromヘッダーの送信ドメインがSPFまたはDKIMの結果と一致することを要求し、どちらも一致しない場合にどうするか——監視、隔離、拒否——を受信者に伝えます。DMARCのないSPFは署名のない提案です；DMARCこそが他の二つをポリシーに変えるものです。
三つとも合格しているのに、メールがまだ迷惑メールに行きます。なぜですか？
認証は入場券であって、座席の割り当てではないからです。SPF、DKIM、DMARCに合格することは、受信者がそのメールが本当にあなたのものだと信じることを意味します——その後、配置は評判と内容によって決まります：ブラックリストへの掲載（このサイトのブラックリストチェッカーで確認してください）、受信者のエンゲージメント、苦情率、送信量のパターン、そしてメッセージそのもの。認証の失敗は迷惑メール配置の最も一般的な修正可能な原因であり、このチェックが最初に来るのはそのためですが、ここでクリーンな結果が出ても迷惑メール配置が続く場合は、問題は本人性ではなく評判や内容にあります。
チェックではDKIMキーが見つからなかったと表示されます。私のドメインは署名していないということですか？
いいえ——結果自体がその言葉でそう述べています。DKIMキーはドメイン所有者が選ぶセレクタ名の下にあり、ドメインのセレクタを外部から列挙する方法はありません。このチェックは主要プロバイダーが使う一般的なセレクタ（default、google、selector1、selector2、mail、dkim、s1、s2、k1、mandrillなど）を探索します。他の名前の下にあるキーは探索からは見えません。決定的なテストは実際のメッセージです：自分が管理するメールボックスにメールを送り、使用されたセレクタと署名が検証されたかどうかを報告するAuthentication-Resultsヘッダーを確認してください。
なぜチェックはSPFの参照回数を数えるのですか？なぜ上限は10なのですか？
SPFレコードの評価にはさらにDNS参照が必要になることがあります——include、a、mx、ptr、exists、redirectの各項が1回ずつかかります。RFC 7208は合計を10に制限しています；それを超えると受信者は永続的なエラーを返し、SPFの結果は無効になります。これは、きれいに評価できる控えめなレコードよりも悪い場合があります。プロバイダーが追加されるにつれてレコードの参照回数は静かに増えます（各includeは独自の項を持ち込みます）ので、設定時には合法だったレコードが、ベンダーが自らのレコードを変更するにつれて上限を超えて漂流することがあります。このチェックは受信者がするようにレコードを展開し、実際の回数を報告します。これにより、漂流が認証を無効にする前に見えるようになります。
複数の所見が失敗の場合、まず何を直すべきですか？
順序は次のとおりです：複数のSPFレコード（1つに統合してください——それが直るまで、下流のすべては信頼できません）、欠けているか+allのSPFレコード（実際の送信者リストを公開し、-allで終わらせてください）、欠けているDMARCレコード（レポートアドレス付きのp=noneから始めてください。そうすれば、強制する前に誰があなたとして送信しているかが見えます）、そしてレポートがクリーンになってくるにつれてDMARCをp=noneからp=rejectへ引き上げます。ブラックリストへの掲載がある場合は並行作業です——レコードを修復しながら、その原因を直し、掲載解除を申請してください。私たちのガイドはその順序を理由とともに解説しています：メールが迷惑メールに届く理由。