SiteKensa

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

公開日 メールSPFDKIMDMARC独自ドメイン
「届かない」と「迷惑メールに入る」は別の問題であること、原因をDNSで確認できる認証設定とDNSの外側にある要因に分けて確認することを示す図

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

この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

各認証方式には、pass(成功)、fail(失敗)、none(その認証方式の記録が見つからなかった)などの結果が記録されます(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設定をまとめて確認できます。

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

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

所見 内容
DMARCレコードが設定されていません DMARCの指示がなく、なりすましメールの扱いを受信側に伝えられない状態
DKIMセレクタを特定できませんでした よく使われるセレクタを試したが公開鍵が見つからなかった状態(未設定とは限らない)
SPFはあるがDKIMが確認できません 転送時にSPF認証が失敗しやすい状態

診断で見ているのは、公開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はあるがDKIMがない場合、転送で崩れる

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

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

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

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

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

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

DMARCが未設定の場合、一定量以上のメールを送る送信者には、GmailとYahoo!メールがそれぞれDMARCの設定を要件としています。Googleのメール送信者のガイドラインでは、1日5,000件を超える送信者に対しSPF・DKIMに加えてDMARCの設定(ポリシーは p=none でも可)を求めています。Yahoo!メールも送信者向けのベストプラクティスで、大量送信者に対し p=none 以上のDMARCポリシーの公開を必須としています。日常的な範囲でメールを送る個人や小規模事業者であれば、まずSPFかDKIMのどちらかが正しく機能していることが出発点になります。

一方で、DMARCのポリシーを p=none から quarantine や reject に強めることが、迷惑メール判定を防ぐとは限りません。DMARCの認証に成功したメールであっても、受信側は独自の判断で迷惑メールフォルダに振り分けたり拒否したりできます。RFC 7489 §6.7 は「Mail Receivers MAY choose to reject or quarantine email even if email passes the DMARC mechanism 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の設定にあるのか、それ以外の要因にあるのかを切り分けられます。認証設定は迷惑メール判定を防ぐための土台であり、それだけで受信箱への到達を保証するものではないことも、あわせて覚えておいてください。

まずは全体を診断してみましょう

専門知識がなくても、いまの設定状況と具体的な対処方法をわかりやすく確認できます。

ドメイン設定を診断する