メールが届かない障害の切り分け｜SMTP・SPF・DKIMの確認
「登録完了メールが届かないってお客さんから言われて」「昨日まで来てた通知メールが、今日だけ来ないんだけど」——そんな一言で呼ばれて、まずメールの管理画面を開いてみる。でも、送信ログには「送信済み」と出ている。じゃあ届いているはずなのに、なぜ相手に届いていないのか。ここで、頭が止まりますよね。
メールの「届かない」は、切り分けの場所がとても多い障害です。そもそも自分のサーバーから送れていないのか、送れてはいるけど相手のメールサーバーに弾かれているのか、届いてはいるけど迷惑メールフォルダに落ちているのか。見る場所によって、次にやることがまったく変わります。しかも相手側の中は見えないので、余計に手探りになりがちです。
この記事では、「メールが届かない」を自分の送信側から、相手のメールサーバーへと順番にたどる切り分けを、SMTP のログ・SPF・DKIM・DMARC という基本の順で一緒に整理します。全部を今日覚えなくて大丈夫です。まずは「送れていないのか、送れているのに届かないのか」を分けるところから、落ち着いて見ていきましょう。
結論：「メールが届かない」と言われたら、①自分のサーバーから送れているかを確かめる（メールログで送信結果と相手サーバーの応答を見る）②相手に受け取ってもらえる設定になっているかを確かめる（SPF・DKIM・DMARCが正しく引けているか）③迷惑メール判定で埋もれていないかを確かめる——の順で、自分に近い側から一方向に進めます。まずは「送信ログに何と出ているか」を見るところから。
前提として、メールの仕組みや認証は環境（メールサーバーの種類・送信サービス・DNSの設定）で細かく異なります。ここは切り分けの地図として使い、コマンドや設定は本番へ反映する前に、必ず自分の環境と公式情報・各サービスの管理画面で確認してください。
まず「送れていないのか、届いていないのか」を分ける
いきなり「SPFが」「DKIMが」と設定を疑う前に、一段引いて「そもそも自分のサーバーから送れているのか」を先に確かめます。ここを飛ばすと、認証設定を延々と見直したあとで「実はメール送信のプログラムがエラーで止まっていた」といった遠回りをしがちだからです。
順番の考え方はシンプルです。自分の送信サーバーにいちばん近いところから、相手の受信サーバーへ向かって、一方向に確かめていく。上流が白（問題なし）だと分かったら、その先へ進む。これだけです。
- 送信：自分のサーバーが、相手のメールサーバーへ実際にメールを渡せているか（メールログ）。
- 認証（SPF）：その送信元IPが、ドメインの持ち主が「送ってよい」と認めたものか（
digで確認）。 - なりすまし対策（DKIM）：メールに正しい電子署名が付いていて、途中で改ざんされていないと相手が確かめられるか。
- 迷惑判定（DMARC・スパム判定）：受け取ってはもらえたが、迷惑メール扱いで埋もれていないか。
まずは「送れていないのか、送れているのに届かないのか」の一本目の分かれ道を決めるだけで、見るべき場所がぐっと狭まります。
① 自分のサーバーから送れているかを確かめる（SMTPのログ）
意外と多いのが、認証やDNSの話に入る前に、そもそも送信できていないケースです。メール送信の処理がエラーで落ちていた、送信キューに溜まったまま流れていない、送信サービスの認証情報が切れていた——原因がドメインの外ではなく、自分のサーバーの中にあるパターンです。
まず見るのは、メールサーバー（Postfix なら /var/log/mail.log など、環境により場所は違います）の送信ログです。SMTP（メールを送るための通信のやり取り）は、送った結果を相手サーバーが応答コードで返してくれます。ここを読むと、「渡せたのか」「断られたのか」が分かります。
ログで見たいのは、ざっくり次の3種類です。
status=sent（250番台の応答）：相手サーバーが受け取った。ここまで来ていれば、送信側は白に近い。次は届いた先（迷惑メール等）を疑う。status=bounced（500番台の応答）：相手に恒久的に断られた。「そんな宛先はない」「なりすましと判断した」など、断り文句がログに書いてあることが多い。status=deferred（400番台の応答）：一時的な失敗で、あとで再送される。相手の一時的な混雑や、送信元の評価（レピュテーション）が理由のこともある。
エラーで断られているときは、応答メッセージの中に理由が書かれています。「SPF」「DKIM」「DMARC」「blocked」「rejected」といった単語が入っていたら、次の章の認証の話につながります。逆にログ自体に送信の記録がまったく無ければ、メールを送る側のプログラムやキューを先に見ます。
ここで「送信ログに何も出ていない」と分かるだけでも、大きな前進です。原因がDNSではなく自分の中にあると絞れたので、DNSの設定を触らずに済みます。
② 相手に受け取ってもらえる設定かを確かめる（SPF・DKIM・DMARC）
送信ログでは「送れている」のに届かない。あるいはログに「SPF」「DKIM」といった単語が出ている。そんなときは、送信ドメインの認証設定を確かめます。この3つは、受け取る側が「このメールは本当にそのドメインから正しく送られたものか」を判断するための仕組みで、DNS（ドメインの情報を引く仕組み）に設定を書いておきます。
一気に3つ直そうとせず、上から順に一つずつ確認します。設定はDNSに書かれているので、dig などで実際に引けているかを見られます。
SPF：送ってよいサーバーの一覧
SPF（Sender Policy Framework）は、「このドメインのメールは、これらのIP／サーバーから送ります」という宣言です。受信側は、実際の送信元IPがこの一覧に入っているかを照合します。送信サーバーを増やしたり、送信サービスを変えたりしたときに、この一覧の更新を忘れると、正規のメールが「なりすまし疑い」で弾かれます。
確認は、送信ドメインのTXTレコードを引いて、v=spf1 で始まる記述の中に、今の送信元が include: などで含まれているかを見ます。
dig +short TXT example.com
# → "v=spf1 include:_spf.example-mail.jp ~all" のような1行が返る送信サービスを乗り換えたのに、前のサービスの include: のままだった、というのはよくある見落としです。
DKIM：メールに付ける電子署名
DKIM（DomainKeys Identified Mail）は、メールに電子署名を付けて、「確かにこのドメインが送った」「途中で改ざんされていない」ことを受信側が確かめられるようにする仕組みです。署名を検証するための公開鍵を、DNSに置いておきます。
鍵の置き場所は「セレクタ」という名前で決まっていて、（セレクタ）._domainkey.（ドメイン） の形で引けます。
dig +short TXT selector1._domainkey.example.com
# → "v=DKIM1; k=rsa; p=..." のような鍵が返れば公開されているここが空で返る（鍵が引けない）と、受信側は署名を検証できず、認証に失敗します。送信サービス側でDKIMを有効にしたのに、DNS側にレコードを入れ忘れている、というズレが起きやすいところです。
DMARC：SPF・DKIMが失敗したときの扱い方
DMARC（Domain-based Message Authentication, Reporting & Conformance）は、「SPFやDKIMの認証に失敗したメールを、受信側にどう扱ってほしいか」を宣言する仕組みです。none（そのまま受ける）／quarantine（迷惑メール隔離）／reject（拒否）といった方針を指定できます。
dig +short TXT _dmarc.example.com
# → "v=DMARC1; p=quarantine; rua=..." のような方針が返るここで注意したいのは、DMARCの方針を reject にしていると、SPFやDKIMのちょっとした設定漏れが、そのまま「拒否＝届かない」に直結することです。設定を変えた直後に届かなくなったなら、この組み合わせを疑うと当たりを付けやすくなります。
③ 届いてはいるが迷惑メールで埋もれていないか
送信ログは sent、SPF・DKIM・DMARCも正しく引ける。それでも「届かない」と言われる。このときは、相手には届いているが、迷惑メールフォルダに振り分けられている可能性が高いです。
迷惑メール判定は、認証だけでなく、送信元IPやドメインの評価（過去に大量送信していないか、苦情が多くないか）、本文の内容など、いろいろな要素で決まります。一人運用ですべてをコントロールするのは難しいですが、まず確かめられるのは次のあたりです。
- 相手に、迷惑メールフォルダを見てもらう（ここで見つかれば、原因は「届かない」ではなく「振り分け」だと確定できる）。
- 受け取ったメールのヘッダー（詳細情報）に、
spf=pass・dkim=pass・dmarc=passと出ているか。ここがfailなら②に戻る。 - 短時間に大量の同報メールを送っていないか。急に送信量が増えると、評価が下がって振り分けられやすくなる。
ここまで来ると、「サーバー障害」ではなく「相手側の受信環境や振り分けの問題」だと切り分けられます。原因の在りかが分かるだけでも、社内やお客さんへの説明がずいぶん落ち着いてできるようになります。
明日から使える切り分けチェックリスト
「メールが届かない」と言われたときに、上から順にたどるためのチェックリストです。全部を一度にやらなくて大丈夫です。上が白なら、次へ進むだけです。
- まず「いつから・誰宛が・全部か一部か」を聞く（全員に届かない／特定の相手だけ、で見る場所が変わる）
- メールログに送信の記録があるか（無ければ送信プログラム・キューを先に見る）
- 送信ログの結果を見る（
sent／bounced／deferred） -
bouncedなら応答メッセージの断り文句を読む（SPF・DKIM・DMARC・blocked 等の単語を探す） - SPFレコードに、今の送信元が含まれているか（
dig +short TXT ドメイン） - DKIMの公開鍵が引けるか（
dig +short TXT セレクタ._domainkey.ドメイン） - DMARCの方針を確認（
rejectなら設定漏れが即・不達につながる） - 相手に迷惑メールフォルダを見てもらう（あれば「不達」ではなく「振り分け」）
- 受信ヘッダーで
spf=pass・dkim=pass・dmarc=passを確認 - 直近で送信サーバー・送信サービス・DNSを変更していないか振り返る
最後に、切り分けた結果は短くていいので記録に残しておくと、次に同じ連絡が来たときに一気に楽になります。「今回は送信サービス変更でSPFの更新漏れだった」の一行が、未来の自分を助けてくれます。
メールの障害は、見えない相手側が絡む分だけ、どうしても手探りになりがちです。でも、自分に近い側から一方向にたどっていけば、必ず「どこで止まっているか」に近づけます。今日ひとつ、送信ログの見方に慣れておけたなら、それだけでもう次の対応はずいぶん落ち着いてできるはずです。
よければ、こちらも
困ったときの手順は、運用ドキュメント最低限テンプレートやサーバー構成ドキュメント一覧と合わせておくと、いざというときに迷わず引けます。