独自ドメインのメールが迷惑メールに入る原因は？認証設定とそれ以外を切り分ける

独自ドメインから送ったメールが相手の迷惑メールフォルダに入ってしまう。「届かない」のではなく「届いているが迷惑メール扱いされる」という状態です。

この2つは、別の問題です。送信自体がエラーになっている場合は、原因が異なるため、独自ドメインのメールが届かない原因を先に確認してください。相手の迷惑メールフォルダにメールが入っているのを確認できた場合は、このまま読み進めてください。

迷惑メールに入ったメールを1通確保する

最初にすべきことは迷惑メール判定されたメールを実際に1通手に入れることです。原因を推測で絞り込むよりそのメール自体の情報を見るほうが早く進みます。

自分が管理していないメールボックスで起きている場合は、相手に「迷惑メールフォルダに入っていた、そのメールのヘッダー情報を見せてほしい」と依頼する必要があります。難しい場合は、自分がログインできるGmailやYahoo!メールなどのアカウント宛に独自ドメインから自分でテストメールを送ってみてください。多くの場合、同じ認証設定の問題であれば自分宛のテストメールでも同様の判定を再現できます。

すべての相手か、特定の事業者だけかを確認する

次に、迷惑メール判定が起きている範囲を確認します。

Gmail宛だけで迷惑メール判定されるのであれば、Gmail側の評価基準に関わる要因を疑います。特定の1社だけであれば、その事業者固有の受信設定や評価が影響している可能性もあります。逆に、送信先を問わずどこでも迷惑メール判定されるのであれば、送信元ドメインやサーバー自体に関わる要因である可能性が高くなります。

この段階では断定は、できません。次の手順で実際の判定結果を確認します。

メールヘッダーで実際の認証結果を見る

確保したメールの全文ヘッダーを表示してください。多くのメールソフトには通常は、隠れているヘッダーをすべて表示する機能があります(Gmailであれば「メッセージのソースを表示」など)。

Authentication-Results ヘッダーを探す

ヘッダーの中に Authentication-Results という行があるかを探してください。これは、受信側のメールサーバーが SPF・DKIM・DMARCなどの認証を実際に評価した結果を記録したヘッダーです。認証チェックを行ったメールサーバーがヘッダーの先頭付近に追加するもので(RFC 8601 セクション4、セクション4.1)、どの段階の受信サーバーが認証したかが分かるよう、既存のヘッダーの前に追記される決まりになっています。

このヘッダーが無い場合、受信側が認証チェックの結果をヘッダーに残さない設定になっているか、認証チェック自体が行われていない可能性があります。その場合は、次の「SiteKensaで公開DNSの設定を診断する」に進んでください。

spf= / dkim= / dmarc= の読み方

Authentication-Results には、次のような形式で各認証の結果が記録されています(RFC 8601 Appendix B の例を実際の書式に合わせたもの)。

Authentication-Results: mx.example.com;
  spf=pass smtp.mailfrom=example.jp;
  dkim=pass header.d=example.jp;
  dmarc=pass header.from=example.jp

SPFやDKIMなどの認証方式には、pass(成功)・fail(失敗)・none(その認証方式が適用されなかった。DKIMなら署名が無かった)などの結果が記録されます(RFC 8601 セクション2.7)。spf=fail・dkim=fail・dmarc=fail になっている項目が、迷惑メール判定に関わっている可能性のある箇所です。

ここで分かるのはそのメールが実際に送られた時点での認証結果です。DNSにレコードが正しく置かれていても送信に使ったメールサービス側でDKIM署名が有効化されていなければ dkim=none になりますし、複数の送信経路を使っている場合は、経路によって、結果が変わることもあります。逆に、ここで fail や none が見つかった場合、その原因がDNS側の設定にあるのか、送信サービス側の設定にあるのかは、このヘッダーだけでは分かりません。次の手順で自分のドメインのDNS側の設定を確認します。

SiteKensaで公開DNSの設定を診断する

ヘッダーで認証が失敗している箇所が分かったら、その原因がDNS側の設定にあるかどうかを確認します。ドメイン名を入力するとSPF・DKIM・DMARC・MXの現在の公開DNS設定をまとめて確認できます。

ドメインの設定を診断する

診断するとたとえば次のような項目が表示されます。

診断で見ているのは公開DNSに置かれたSPF・DKIM・DMARC・MXの各レコードです。実際に送信されたメールにDKIM署名が付いているか、送信元IPアドレスの評価、過去の迷惑メール報告率といった、DNSの外側にある要因までは確認できません。前の手順で見た Authentication-Results ヘッダーとこの診断結果を突き合わせることで原因がDNS側の設定にあるのか、それ以外にあるのかを切り分けられます。

自分でDNSの値を直接確認したい場合は、dig txt example.jp でSPFレコードを dig txt _dmarc.example.jp でDMARCレコードのTXTレコードを直接引くこともできます。

認証が失敗している場合の対処

診断結果とヘッダーの両方で認証の失敗が確認できた場合、次を確認してください。

SPFとDKIMの両方が欠けている場合、DMARCは成立しない

SPFとDKIMの両方が設定されていない、あるいは両方とも認証に失敗する状態だとDMARCの認証は、成立しません。DMARCは、Fromアドレスのドメインと整合した形でSPFまたはDKIMのどちらか一方が認証に成功することを前提にした仕組みだからです。片方だけが欠けている場合は、もう一方で認証が成立する可能性がありますが、両方が欠けているとそのドメインから送るすべてのメールがDMARCの認証に失敗します。まずSPFとDKIMのどちらかを設定してください。

• SPFの設定は、SPFレコードチェックから確認できます
• DKIMの設定は、DKIMレコードチェックから確認できます

SPFはあるがDKIMがない場合、転送で崩れる

SPFだけが設定されている状態は、メールが転送されると認証が失敗しやすくなります。転送元のサーバーから送信される形になり、元の送信者のSPFレコードには転送サーバーが含まれていないためです。DKIMは、メールの内容に電子署名を付ける仕組みで、転送されても署名自体は、維持されるため、SPFの弱点を補えます。

DKIMのセレクタが分からない場合

DKIMは、セレクタ名._domainkey.ドメイン名 という形でDNSに公開鍵を登録しますが、セレクタ名は、自由な文字列を取れるため、よく使われるセレクタを試して見つからなかったとしてもDKIMが存在しないと断定は、できません。利用しているメールサービスの管理画面でセレクタ名を確認し、DKIMレコードチェックのセレクタ入力欄に指定して再診断してください。事業者ごとに確認済みのセレクタの一覧は、DKIMセレクタの確認方法と事業者別ガイドにまとめてあります。

認証がすべて通っている場合に確認すること

Authentication-Results でSPF・DKIM・DMARCすべてが pass になっているのに迷惑メール判定される場合は、認証設定そのものではなく、別の要因を確認します。

DMARC未設定は送信者要件に関係するが、ポリシーを強めても受信箱行きは保証されない

DMARCが未設定の場合、一定量以上のメールを送る送信者にはGmailがDMARCの設定を要件としています。Googleのメール送信者のガイドラインは、1日5,000件を超える送信者に対し、「ドメインに SPF および DKIM メール認証を設定します」「送信元ドメインに DMARC メール認証を設定します」と定めており、DMARCのポリシーについては、「DMARC 適用ポリシーは none に設定できます」としています。5,000件未満の送信者の要件は、「送信元ドメインに SPF または DKIM メール認証を設定します」で、どちらか一方で足り、DMARCは、要件に含まれていません。

Yahoo!メール(@yahoo.co.jp)は、送信量がしきい値を超えると制限すると説明していますが、その通数は、このページには書かれていません。迷惑メール対策の説明は、「SPFかDKIM、もしくはDMARCの認証を導入・判定クリアしていないメールは迷惑メールと判定したり、受信を拒否したりする場合があります」としており、3つのうちいずれか1つを求める書き方です。DMARC単独を必須にしているわけではありません。なお、senders.yahooinc.com が公開している送信者要件は、Yahoo Inc.が運営するメール(@yahoo.comなど)向けのもので、LINEヤフーが運営するYahoo!メールとは別のものです。混同すると実際には求められていない設定を急ぐことになります。

日常的な範囲でメールを送る個人や小規模事業者であれば、まずSPFかDKIMのどちらかが正しく機能していることが出発点になります。

DMARCが未設定のとき、具体的に何ができない状態なのかはDMARCを設定していないリスクと最初に置く設定にまとめています。

一方で、DMARCのポリシーを p=none から quarantine や reject に強めることが、迷惑メール判定を防ぐとは限りません。DMARCの認証に成功したメールであっても受信側は、独自の判断で迷惑メールフォルダに振り分けたり、拒否したりできます。RFC 9989 セクション5.4 は、「Mail Receivers MAY choose to reject or quarantine a message even if it passes the DMARC validation check」(メール受信者は、メッセージがDMARCの検証を通過した場合でもそのメッセージを拒否または隔離することを選択してよい)と明記しています。DMARCが指示できるのは認証に失敗したメールの扱いだけで、認証に成功したメールが迷惑メール扱いされない保証にはなりません。

DNS認証とは別に確認する項目

DNSの認証設定が正しくても次のような要因が迷惑メール判定に影響することがあります。いずれも本サイトの診断が確認している範囲の外です。

• 送信元のIPアドレスやドメイン自体の評価
• 過去の迷惑メール報告(受信者が「迷惑メールに登録」を押した件数)
• 許諾を得ていない宛先や古いメールリストへの送信
• 本文中のリンク先や短縮URLの評価
• 送信量や送信パターンの急な変化
• 送信元IPアドレスやドメインがブラックリストに登録されていないか(DNS認証とは別に確認すべき項目です)

これらは、送信の実績や内容に関わる要因で、DNSレコードを直すことでは解決しません。心当たりがある場合は、利用しているメール配信サービスやサーバー会社に相談してください。

修正したら、再送して確認する

DNSの設定を直したあと、実際に反映されているかを確認してください。

修正後の設定を再診断する

診断結果で該当の項目が消えたことを確認したら、改めて自分宛にテストメールを送り、Authentication-Results ヘッダーでSPF・DKIM・DMARCがすべて pass になっているかを見てください。DNSの設定変更が世界中に行き渡るまで時間がかかることがあるため、診断結果がすぐに変わらない場合は、設定を重ねて変更せず少し時間を置いてから再確認してください。

まとめ

独自ドメインのメールが迷惑メールに入る場合、まず認証設定(SPF・DKIM・DMARC)がDNSと実際の送信結果の両方で機能しているかを確認するのが出発点です。メールヘッダーの Authentication-Results とDNS側の診断結果を突き合わせることで原因がDNSの設定にあるのか、それ以外の要因にあるのかを切り分けられます。認証設定は、迷惑メール判定を防ぐための土台であり、それだけで受信箱への到達を保証するものではないこともあわせて覚えておいてください。