ある日、こんな一言から始まりました。
「すみません、システムからのメール、こちらに届いてないみたいなんですが…」
ドキッとしました。
その通知メールは、Amazon SES から自動で送っているもの。あわててSESのコンソールを開くと、送信ステータスは 成功 でエラーも出ていません。
ちゃんと送れてるぞ？？
最初は受信側の設定の問題だと思っていました。でも、同じ報告が何件か続くうちに、ようやく届いていないのだと認めました。。。
送ったはずのメールが、相手には届かない。送信ログはどう見ても成功なのに。この気持ち悪さ、味わったことのある方も多いのではないでしょうか。
この記事は、原因を調査して調査して、やっとこさ 送信ドメイン認証（SPF / DKIM / DMARC） にたどり着くまでの記録です。
専門用語には、「💡 解説」 印を付けたので、この分野がはじめての方は参考にしてみてください。
こんな人に読んでほしい
- Amazon SES など外部サービスでメールを送っている人
- 「送信は成功しているのに届かない」で頭を抱えている人
- 送信ドメイン認証を、名前は知っているけど手をつけていない人
ちなみに私は社内AWS環境のインフラ運用を管理している立場です！
結論（先に書いておきます）
- SESの「送信成功」は、「相手に届いた」を意味しない
- Gmailなどに届かない原因の多くは、SPF / DKIM / DMARC の設定不足
- SESなら、まず Easy DKIM を自ドメインで有効化 するのが第一歩
■ 「送信成功」の文字に、何度もだまされた
最初のうちは、半信半疑でした。
SESのダッシュボードはきれいな緑。Bounce も Complaint も、目立った数字は出ていません。送信側から見えるかぎり、すべて順調なのです。
💡 バウンス／コンプレイントって？
バウンス（Bounce） は、宛先が存在しないなどの理由でメールが戻ってくること。コンプレイント（Complaint） は、受け取った人に「迷惑メール」として報告されることです。どちらも率が高いと「問題のある送信者」とみなされ、最悪は送信を止められます。
それなのに、「届いていない」という声だけが、ぽつぽつと届く。
「送れた」と「届いた」はまったくの別物 だということをよく理解した経験になりました。。。
送信側のログがいくら成功でも、受信側で弾かれていれば、相手にとっては届いていないのと同じなんですよね。
■ ヘッダを開いて、ようやく犯人が見えた
解決の糸口になったのは、届かなかったメール（迷惑メールに入っていたもの）を1通開いて、「メッセージのソース」を表示 したことでした。
💡 メールのヘッダ（メッセージのソース）の見かた
メールには、本文の裏側に「いつ・どこを経由して・検査結果はどうだったか」という情報が書かれています。これが ヘッダ です。
- Gmail：メールを開いて右上の「︙」→「メッセージのソースを表示」
- Outlook：メールを開いて「…」→「表示」→「メッセージのソース」
開いたらAuthentication-Resultsを検索（Ctrl+F）してみてください。
その Authentication-Results には、こんな結果が並んでいました。
spf=none （または softfail）
dkim=none
dmarc=fail
見た瞬間、ああ、と声が出ました。
💡 これは何を意味する？
passは合格、fail／noneは「確認できなかった／失敗」です。受信側から見ると 「本当にそのドメインから来たのか確認できない」 メールなので、迷惑メール行きや受信拒否もやむなし、というわけです。
しかも間の悪いことに、2024年以降、Gmailやyahoo!の送信者ガイドラインが強化 され、ある程度のメッセージ量を送る人にとっては SPF/DKIM の設定とDMARCが事実上の必須になっていました。「これまで何となく届いていたメールが、ある時期から急に弾かれ始める」のは、たいていこれが背景にあります。
こっち側のせいじゃないと思っていた問題は、実のところ 送信側の宿題（ドメイン認証）を放置していた というオチでした。
■ そもそも SPF / DKIM / DMARC って？（30秒で）
犯人の名前は分かりました。でも3つの関係がぼんやりしていると対策も手探りになるので、ここで整理します。
- SPF：送信元のIPが「そのドメインから送ってよいIPか」を、DNSのレコードで照合するしくみ。見られるのは Return-Path（エンベロープFrom） のドメイン。
- DKIM：メールに電子署名を付け、受信側がDNS上の公開鍵で検証するしくみ。なりすまし・改ざん対策。
-
DMARC：上の2つの結果を束ねる方針。SPFかDKIMのどちらかが成功し、かつ From と整合（アライメント）していれば合格。失敗時の扱いを
none／quarantine／rejectで指定できる。
💡 たとえると、メールは「封筒に入れた手紙」です
- SPF … 封筒の差出人住所を見て「この住所から出していい配達業者？」を住所録で照合すること。
- DKIM … 手紙に偽造できないハンコを押し、受け取った人が「このハンコ、本物だね」と確認すること。中身を書き換えられていないかも分かります。
- DMARC … 受付の最終ルール。「身分証(SPF)かハンコ(DKIM)のどちらかが本物で、名乗っている差出人と一致していれば通す。怪しければ別室(迷惑メール)か門前払い(拒否)」という方針です。
💡 DNS とは
ざっくり「インターネットの住所録」です。ここに SPF・DKIM・DMARC の“張り紙”を貼っておくと、受信側のメールサーバーが確認しに来てくれます。
ここがSESの落とし穴でした
SESでそのまま送ると、Return-Path が amazonses.com 側 のドメインになります。SPF自体はAmazon側で通っていても、自分のFromドメインと一致しない（＝アライメントが取れない） ため、DMARC的にはSPFが効いてくれません。
💡 「封筒の裏」と「便箋の差出人名」は別物
メールには“差出人”が2つあります。封筒の裏の返送先（Return-Path＝エンベロープFrom）と、便箋に書いて相手に見える差出人名（ヘッダFrom）です。SPFが見るのは前者。
SESの初期設定だと、この“封筒の裏”がAmazonの住所になり、便箋の差出人名（自分のドメイン）と食い違います。これが 「アライメントが取れない」 状態で、DMARC的にSPFがノーカウントになってしまうわけです。
つまり、自分のドメインでDMARCを通したいなら、DKIM署名を自分のドメインで行う のが本筋。ここに気づけたのが、解決の分かれ目でした。
■ やったのは、3つだけ
身構えていたわりに、やることはシンプルでした。
1. Easy DKIM を有効化して、CNAMEを3本立てる
SESの「検証済みID」で対象ドメインの Easy DKIM を有効にすると、3つのCNAMEレコード（xxxx._domainkey.example.com → xxxx.dkim.amazonses.com）が払い出されます。これを送信元ドメインのDNSに登録するだけ。
💡 CNAME って？／Easy DKIM って？
CNAME はDNSに貼る“転送メモ”。「この名前で聞かれたら、こっちを見てね」と案内するレコードです。
Easy DKIM は、署名用の鍵をSESが用意し、その在りかを指すCNAMEを3枚貼るだけで署名が始まる便利機能。鍵を自前で管理する手間が要りません。
これで、SESが 自分のドメイン（d=example.com）でDKIM署名 を付けてくれます。DKIMがpassし、Fromとも一致するのでアライメントもOK。DMARCの合格条件をクリアできます。
2.（必要なら）Custom MAIL FROM でSPFも自ドメインに揃える
DKIMだけでもDMARCは通せます。それでもSPFまで自分のドメインで揃えたいなら、Custom MAIL FROMドメイン（例：mail.example.com）を設定します。指定されたMXと、v=spf1 include:amazonses.com ~all をDNSに追加すれば、Return-Pathが自ドメインになり、SPFのアライメントも取れます。
💡 これは何をしている？
「封筒の裏（返送先）」を、Amazonの住所から 自社の住所 に書き換える設定です。これで封筒の裏も便箋の差出人名もそろい、SPFの面でも“きちんと名乗れた”状態になります。
3. DMARCは、いきなり強くしない
_dmarc.example.com にTXTレコードを足します。
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
💡
none/quarantine/rejectは「受付の厳しさ」
none… 監視カメラだけ回す（何もしないが記録は取る）quarantine… 怪しいものは別室へ＝迷惑メールフォルダ行きreject… 門前払い＝そもそも受け取らない
rua=は、認証の合否レポートを受け取るメールアドレスの指定です。
ここで p=reject から始めるのは危険です。認証が漏れている正規のメールまで巻き添えで落ちてしまうから。まずは p=none（監視のみ） でレポートを受け取りながら様子を見て、問題ないと確認できてから quarantine → reject と段階的に上げていきます。
直ったかどうかは、こう確かめました
- 受信メールの「メッセージのソース」で、
Authentication-Resultsが spf=pass / dkim=pass / dmarc=pass になっているか -
digでTXT（SPF）、CNAME（DKIM）、TXT（_dmarc）が引けるか -
mail-tester.comでスコアを確認
💡
digって？／mail-tester って？
digは、DNSに貼った“張り紙”がちゃんと見えるか確認するコマンドです（WindowsならnslookupでもOK）。例：dig TXT _dmarc.example.com
mail-tester.com は、表示されたアドレスにテストメールを送るだけで、SPF/DKIM/DMARCや迷惑メールっぽさを100点満点で採点してくれる無料サービスです。
設定して、しばらく待って、おそるおそる再送してみると——今度はGmailの 受信トレイ にすとんと届きました。ヘッダの認証結果も、ぜんぶ pass。あの緑色のログが、ようやく「本当の成功」になった瞬間でした。
■ 正直、ハマったところ・残った課題
うまくいった話だけだとフェアじゃないので、つまずいた点も書いておきます。
- DNSの反映は、すぐじゃない：レコードを入れても、TTLや伝播の都合で即時には効きません。「設定したのに直らない」と焦りましたが、答えは「もう少し待つ」でした。
- 認証を通す＝迷惑メールに入らない、ではない：SPF/DKIM/DMARCは「なりすましでないことの証明」にすぎません。送信頻度や送信元IPのレピュテーション、本文の中身も到達率に効きます。認証はあくまでスタートライン。
- SESには「送る前」のハードルもある：本番でまとまった量を送るにはサンドボックス解除の申請が要りますし、バウンス率・苦情率が高いとアカウントが制限されます。「送る前」と「届いた後」、見るべき指標は両側にあります。
💡 サンドボックスって？
SESを使い始めた直後の「お試し制限モード」です。検証済みのアドレスにしか送れず、1日の送信量にも上限があります。本番運用するには、AWSに利用目的を添えて解除を申請します。
■ まとめ：「送れた」じゃなく「届いて、気づかれた」がゴール
今回いちばん身にしみたのは、送信側で「成功」と表示されても、それは「相手に届いた」ことを保証しない、という当たり前の事実でした。
Amazon SESのようなサービスは、“送る”までは驚くほど簡単 です。だからこそ油断する。
本当のゴールは
- 送信ドメイン認証で「なりすましじゃない」と証明し、
- 受信側にちゃんと届き、
- 相手に気づいてもらう
ところまで。ここまでやって、はじめて「メールを送れた」状態になると理解しました。
もし今、「送ったはずなのに届かない」で消耗している方がいたら、まずは 届かなかったメールのヘッダを開いて Authentication-Results を見てみてください。spf / dkim / dmarc のどれが失敗しているか分かれば、解決はもう半分終わったようなものです。
この記事が同じところでつまずいた誰かのアドバイスになれば！
用語集（ざっくり版）
| 用語 | ざっくり説明 |
|---|---|
| SPF | 差出人のIPが正規かをDNSで照合するしくみ（封筒の差出人住所チェック） |
| DKIM | メールに電子署名を付け、本物か検証するしくみ（偽造できないハンコ） |
| DMARC | SPF/DKIMの結果と方針をまとめる最終ルール（受付の判断基準） |
| Return-Path（エンベロープFrom） | 封筒の裏の返送先。SPFが見る“差出人” |
| ヘッダFrom | 便箋の差出人名。相手の画面に見える送信者 |
| アライメント | 上の2つの“差出人”が同じ組織かの一致確認 |
| DNS | インターネットの住所録。各レコードを公開する場所 |
| CNAME | 「この名前は別をどうぞ」と案内するDNSの張り紙 |
| Easy DKIM | SESがDKIM署名を簡単に設定できる機能 |
| Custom MAIL FROM | 封筒の裏の返送先を自社ドメインにする設定 |
| Authentication-Results | メールのヘッダにある“検査結果票”。spf/dkim/dmarcの合否が載る |
| サンドボックス | SESの初期制限モード。本番運用には解除申請が必要 |
| バウンス／コンプレイント | 宛先不明で戻ること／迷惑メール報告されること |