# 送信ドメイン認証（SPF / DKIM / DMARC）とは（非エンジニア向け） **対象**: monaka の運用者・一般ユーザー（DNSに触るが、メール技術に詳しくない人） **目的**: 「何を設定するのか」「設定すると何が起きるのか」「なぜ必要なのか」を、専門用語に引きずられずに理解できるようにする。 > **繰り返し答えの正本（運用）** > **「サーバに SSH して毎回 `.env` をいじれ」という運用にしない。** 運用側の既定は **`config/putage.php` とデプロイ**で揃える。エンドユーザーにやってもらうのは **DNS に画面の表を転記するだけ**。同じ説明を短くまとめた **`docs/mail-auth-ops-defaults.md`** を運用・サポート・AI の共通参照にする。 --- ## まず結論（何を得るための設定？） 送信ドメイン認証は、ざっくり言うと **「このメールは本当にこのドメインの持ち主が送っている」**と受信側（Gmail、Yahoo、企業メール等）に証明する仕組みです。 - **設定するとどうなるか** - 迷惑メール・プロモーションに入る確率が下がりやすい - なりすまし（例: `support@あなたのドメイン` を名乗る偽メール）を抑止できる - 受信側が「信用できない」と判断したときの挙動（隔離・拒否・レポート）をコントロールできる - **設定しないとどうなるか** - 受信側が厳格な場合、届かない／迷惑メールに入る／警告が付く - ドメインを騙った偽メールが横行しやすく、ブランド毀損や被害が出やすい --- ## SMTP と何が違うの？（よくある誤解） **SMTP** は「メールを送るための経路（郵便局）」です。 一方、**SPF/DKIM/DMARC** は「受信側が“本物か”を確認するための、ドメイン側の公開情報（封印・身分証）」です。 言い換えると: - SMTP: **送る手段** - SPF/DKIM/DMARC: **送った人が本物だと受信側が判断できる材料** SMTPが動いていても、認証が無いと「本物っぽくない」と判定されて不利になります。 --- ## 3つの仕組み（SPF / DKIM / DMARC）を超ざっくり ### SPF（送信元サーバの許可リスト） **SPF** は「このドメインのメールは、どの送信サーバ（IP等）から送られるのが正しいか」をDNSに書きます。 - **受信側が見るもの**: 「送ってきたサーバが許可されているか？」 - **うまくいくと**: 不正なサーバからのなりすましが弾かれやすい monaka では、一般ユーザーがIPを触らなくて済むように、SPFを **`include:` 方式**で案内することがあります（詳細は `docs/manual.md` の SPF節）。 ### DKIM（メールに“署名”を付ける） **DKIM** は、送るメール本文に **電子署名**を付け、受信側がDNSにある公開鍵で検証できるようにします。 - **受信側が見るもの**: 「この署名、改ざんされてない？このドメインの鍵で署名されてる？」 - **うまくいくと**: 到達率が上がりやすい／改ざん検知に強い ### DMARC（SPF/DKIMの結果に基づく“取り扱いルール”） **DMARC** は「SPF/DKIMの結果がダメだったメールを、受信側がどう扱うべきか」を宣言します。 - **受信側が見るもの**: 「失敗したら隔離？拒否？何もしない？」 - **うまくいくと**: なりすまし耐性が上がる／レポートで状況が見える 世の中の解説では **最初は緩め（`p=none`）**で始める例が多いです。本サービスでは **製品既定は `p=quarantine`（`config/putage.php`）**とし、弱めるときだけ運用で `none` を明示します（**利用者にサーバ作業を求めない**方針。詳細は `docs/mail-auth-ops-defaults.md`）。 このサービスでは、**運用側の設定（サーバの `.env` にある `MONAKA_DMARC_POLICY`）** と **画面に表示される DMARC の値** が一致するように DNS に置くと、「設定確認」で照合されます。**`quarantine`（隔離寄り）や `reject`（拒否）** にする前に、**そのドメインから送るすべての経路で SPF／DKIM が通る**ことを確認してください（別ツールから送っていると止まることがあります）。任意で **`MONAKA_DMARC_RUA`** にメールアドレスを入れると、案内に **`rua=mailto:…`** が付き集計レポートを受け取れます（宛先メールボックスの準備も必要です）。 ドメインを **Google Postmaster Tools** 等に登録しておくと、迷惑判定の傾向を把握しやすくなります（DNS の書き換えとは別の「運用の見える化」です）。 --- ## 「DNSに設定する」とは何をすること？ DNSは「ドメイン名（例: `example.com`）に対して、公開情報（レコード）をぶら下げる仕組み」です。 送信ドメイン認証では、主に次のレコードを追加します。 - **TXT**: SPF / DKIM公開鍵 / DMARC などの文字情報を置く - **CNAME**: 「この名前は別の名前を参照してね」を作る（monaka のDKIM案内でよく使う） ※DNSは世界中にキャッシュされるため、**反映まで数分〜最大24時間**かかることがあります。 --- ## monaka での流れ（ユーザーがやること／システムがやること） ここが一番大事です。役割を分けます。 ### ユーザー（一般ユーザー）がやること 1. 管理画面の **「メール・LINE配信 → 送信ドメイン認証」** で、自分の送信元に使いたいドメインを追加する 2. 画面に出る **DNSレコード（タイプ・名前・値）** を、ドメイン管理会社（お名前.com 等）のDNS設定にコピペする 3. 反映を待つ（すぐには効かないことがある） 4. 管理画面の **「設定確認」** を押して状態を更新する - **成功の見え方**: 「設定完了」などの表示になる - **失敗の見え方**: 「未設定」等が残る（反映待ち・入力ミスの可能性） ### システム（運用側）がやること monaka のDKIMは、ユーザーのDNSだけで完結しない場合があります。 ユーザーが設定するCNAMEの“参照先”として、運用側ドメイン配下に **DKIM公開鍵TXT** を用意する必要があるためです。 - **理想（自動化）**: ユーザーがドメインを追加したら、運用側DNSに必要なTXTをAPIで自動追加する - **フォールバック（手動）**: 障害時などは、運用者がTXTを手で追加する 自動化の詳細は運用方式によって変わります（Cloudflare / Route53 など）。運用手順は別紙を参照してください。 --- ## 「設定確認」って何をしてるの？ 管理画面の「設定確認」は、ざっくり言うと **サーバが公開DNSを見に行って、設定が揃っているかチェック**しています。 - **すぐOKにならないことがある理由** - DNSは反映に時間がかかる - 入力欄が「全部のドメイン名を入れる」タイプか「ホスト名だけ入れる」タイプかで、コピペの形が変わる（お名前.com など） - 一部の環境では A/AAAA が無いサブドメインが “存在しない” 扱い（NXDOMAIN）になり、検証に失敗することがある 「設定確認」を押した日時が画面に残るのは、**“いつ確認したか”**を運用上はっきりさせるためです（DNSは待ちが発生するため）。 --- ## よくあるつまずき（原因の見分け方） ### 1) 反映待ち（よくある） - **症状**: 入れたはずなのに未設定のまま - **対処**: 10分〜数時間待ってから、もう一度「設定確認」 ### 2) DNSの入力形式が違う（超よくある） DNS会社のUIによって、レコード名を - `xxx.example.com` のように **全部入れる**場合と - `xxx` のように **ホスト部分だけ**入れる場合があります 迷ったら、DNS会社の画面で「右側に `.example.com` が固定表示されているか」を見ると判別できます。 ### 3) サブドメインが“存在しない扱い”（一部で起きる） 送信元メールアドレスに `info.sub.example.com` のようなサブドメインを使う場合、DNS的にそのサブドメインがNXDOMAIN扱いだと失敗するケースがあります。 必要に応じて **A/AAAA** を入れて “存在” を作ります（運用判断）。 --- ## 参考（運用者向けの詳細） - Cloudflare 委任・自動TXTの運用（monaka）: `docs/monaka-dkim-cloudflare.md` - SPFを include で案内する背景・補助コマンド: `docs/manual.md` の SPF節