「で、うちの場合はどうすればいいんですか？」
仕組みを学んだ後に必ず出てくるのが、この問いです。メールの設計には、正解が1つとは限りません。機器の対応状況、社外に送るかどうか、量、体制、期限……どの要件を重く見るかで、選ぶ案が変わります。
連載の最終回となる第12回では、第1回から第11回までの知識を使って、5つの設計演習に取り組みます。答えを覚えるのではなく、要件から案を選ぶ筋道を身に付けましょう。
演習の進め方
- 各問は「問題 → 解答例 → 解説」の順に進みます
- まず5分考え、選ぶ案と、その理由を書き出します。可能なら、確かめるコマンド（dig・openssl・nc、PowerShellのResolve-DnsName・Test-NetConnection）も書きます
- 最初にすべきことは、要件と現状の確認です。問題文に書かれていない条件（機器の対応状況、体制、予算、規程）は、どう仮定したかを明記します
答えの一致より、要件から案を選んだ筋道を比べてください。
問1 機器・システムからの通知メールを送り直す
- 状況：社員500名の会社で、メールはMicrosoft 365。複合機12台（うち5台は5年以上前の機種）、vCenter 8、監視サーバー（Zabbix）、自社開発の勤怠アプリが、
smtp.office365.comへSMTP AUTH（Basic認証）で通知を送っている - 経緯：2026年12月末の既定での無効化に備えて、試しにBasic認証を止めたところ、複合機の一部とvCenterから通知が届かなくなった（今は元に戻している）
- 要件①：監視の通知は、社内に加えて保守会社（社外）にも送る
- 要件②：機器にメールボックスのパスワードを保存し続けたくない
- 要件③：機器ごとの設定の変更はできるだけ少なくし、どこで止まったかを追えるようにする
考えるポイント：機器ごとのOAuthの対応、社外宛ての有無、送信元のIPと証明書、どこに送信を集めるか。
問1 解答例
| 案 | 構成 | メリット | デメリット |
|---|---|---|---|
| A | 対応する機器は OAuth 2.0 の SMTP AUTH に、勤怠アプリは Microsoft Graph の sendMail に切り替える。残りは HVE へ | 追加のサーバーが要らない。パスワードを機器に置かずに済む | vCenter と古い複合機は OAuth に非対応で残る。HVE は社外へ送れず要件①を満たさない |
| B | 社内にリレーサーバー（Postfix を2台、仮想 IP）を置く。機器は IP で許可して認証なしでリレーへ送り、リレーから Microsoft 365 へ証明書のコネクター（SMTP リレー）で送る | 機器の変更は宛先の変更だけ。社外にも送れる。ログが1か所に集まる | リレーの冗長・更新・監視が必要。証明書か固定のグローバル IP が要る |
| C | 機器を自社の MX へ向け、ダイレクト送信にする | 設定の変更が最も少ない | 社外へ送れない。認証がなく、ダイレクト送信を拒否する設定と両立しない |
要件①②③から案Bが有力です。勤怠アプリのようにコードを変えられるものは、案AのGraph APIで直接送る組み合わせにします。社外への通知が大量なら、リレーの中継先をSESにする選択肢もあります（第10回）。
問1 解説
決め手は、機器の対応状況と社外宛ての有無です。vCenterは8.x・9.xでもSMTPのOAuthに対応せず（第10回）、古い複合機はファームウェアの更新が止まっていることがあります。全機器をOAuthにそろえるのは現実的でないため、送信を社内リレーに集め、リレーだけがMicrosoft 365と認証付きで話す形にします。
注意点は4つです。
- オープンリレーにしない：接続元を機器のアドレスに、送信元のアドレスを自社のドメインに限る（第8回）
- 冗長：2台のリレーを仮想IPの後ろに置く
- 証明書の更新：コネクターが確かめる名前が変わると
5.7.64で止まる - SPF：出口のIPを登録する
移行は、Basic認証を止める前に、機器の宛先を1台ずつ切り替え、リレーのログで確かめながら進めます。
問2 DMARCをp=noneからp=rejectへ進める
- 状況：自社ドメインexample.jpのDMARCは、3年前から
v=DMARC1; p=none; rua=mailto:dmarc@example.jpのまま。集計レポートは届いているが、誰も読んでいない - 送信元：社員のメールはMicrosoft 365、Webサイトのお問い合わせの自動返信はレンタルサーバー、メールマガジンは配信サービス、請求書は会計SaaSから、example.jpのFromで送っている。ほかにもあるかもしれない
- 背景：取引先から、自社を名乗るなりすましメールが届いたと連絡があった。また、社員が参加している社外のメーリングリストがある
- 要件：正規のメールを止めずに、半年以内にp=rejectにする
考えるポイント：送信元の棚卸しの方法、SPFとDKIMのアラインメント、段階の進め方、転送とメーリングリストの影響。
問2 解答例
| 案 | 進め方 | メリット | デメリット |
|---|---|---|---|
| A | すぐに p=reject にし、届かないと言われた送信元から直す | なりすましをすぐに止められる | 把握していない正規の送信（請求書など）が拒否され、事業に影響する |
| B | 集計レポートで送信元を棚卸しし、各送信元の SPF・DKIM を From とそろえてから、quarantine、reject と段階的に強める | 正規のメールを止めずに進められる。根拠を示せる | 数か月かかる。レポートの集計と送信元の担当者との調整が要る |
| C | p=none のまま、SPF を -all にして守る | DNS の変更が1つで済む | From は守れない（SPF はエンベロープの送信者を見る）。転送で正規のメールも失敗しやすい |
案Bです。目標は、すべての正規の送信元が、SPFかDKIMの少なくとも一方で、Fromと同じドメインのまま合格することです。移行中の段階では、RFC 9989で追加されたt=y（テストモード）で、宣言したポリシーより1段弱い扱いを求めることもできます（pctは廃止されました。第6回）。
問2 解説：p=rejectまでの進め方
| 時期 | 作業 | 確かめること |
|---|---|---|
| 1か月目 | レポートの宛先を共有のアドレスにし、集計レポートを可視化するツールで読む | 送信元の IP・件数・SPF と DKIM の結果（RFC 9990 の集計レポート） |
| 1〜2か月目 | 送信元ごとに担当者を決め、DKIM を自社ドメインで署名させる。SaaS はカスタム MAIL FROM か DKIM の CNAME を設定する | 各送信元で dkim=pass、header.d=example.jp |
| 2か月目 | SPF を整理し、DNS の参照を10回以内に収める | dig TXT example.jp で include の数、使っていない送信元の削除 |
| 3〜4か月目 | p=quarantine（最初は t=y を付ける）にし、失敗の残りを潰す | 失敗している正規の送信元が無いか、転送による失敗か |
| 5〜6か月目 | p=reject にし、サブドメインも sp=・np= で守る | なりすましの件数、取引先からの問い合わせ |
転送やメーリングリストではSPFが失敗し、本文の書き換えでDKIMも失敗することがあります。自社から送るメールにDKIMの署名が付いていれば、多くの転送ではDKIMが残ります。受信側がARCを信頼する仕組みもあります（第6回）。DNSの書き方は、連載「DNS入門」第6回を参照してください。
問3 Webサービスから会員へ大量のメールを送る
- 状況：会員20万人のWebサービスをAWS上に新しく作る。送るメールは、登録の確認やパスワードの再設定などの取引のメール（1日約1万通）と、月2回のお知らせメール（1回20万通）
- 現状：社員のメールはMicrosoft 365で、example.jpのFromで送っている。DMARCは
p=reject - 要件①：取引のメールは数分以内に届くこと。お知らせメールの評判が悪化しても、取引のメールに影響させないこと
- 要件②：Gmail・Yahoo・Microsoftの送信者ガイドラインを満たすこと
- 要件③：宛先の誤りや配信停止を、人手をかけずに処理すること
考えるポイント：送る仕組みの選択、送信ドメインの分け方、登録解除、バウンスと苦情の処理。
問3 解答例
| 案 | 構成 | メリット | デメリット |
|---|---|---|---|
| A | Microsoft 365 の共有メールボックスから SMTP AUTH で送る | 既存の契約で済む | 1メールボックス1日1万宛先の上限に当たる。大量配信は利用の対象外で、社員のメールの評判まで巻き込む |
| B | EC2 に Postfix を立て、直接配送する | 細かく制御できる | 25番の解除、PTR、IP の評判、ウォームアップ、バウンスの処理をすべて自分で持つ |
| C | Amazon SES を使い、取引のメールは mail.example.jp、お知らせは news.example.jp とサブドメインと設定セットを分ける | 送信の基盤と評判の管理を任せられる。バウンス・苦情の通知と抑制リストを使える | サンドボックスの解除と上限の引き上げの申請が要る。苦情率の基準が厳しい |
案Cが有力です。サブドメインを分けると、ドメインの評判を用途ごとに分けられ、社員のメール（example.jp）とも切り離せます。お知らせの量が多い場合は、専用IPを用途ごとに分けることも検討します。
問3 解説
決め手は、量と評判の分離です。
- 分離：送信ドメインを用途で分ける。取引のメールとお知らせを同じドメインやIPで送ると、お知らせへの苦情で取引のメールまで迷惑メールフォルダーに入りかねない（第7回）
- 認証：SESのEasy DKIMで各サブドメインを署名し、カスタムMAIL FROMでSPFもそろえると、DMARCのアラインメントが両方そろう（第5回）
- 処理の輪：お知らせにはList-UnsubscribeとList-Unsubscribe-Postを付けてワンクリック登録解除（RFC 8058）に対応し、2日以内に反映する。バウンスと苦情は設定セットのイベントで受け取り、会員のデータベースに反映する
最初は数日かけて量を増やし、迷惑メール率をPostmaster Toolsなどで見て、0.1%未満を目安に保ちます。分けて、そろえて、自動で回す、が合言葉です。
問4 「一部の取引先にだけメールが届かない」
- 状況：月曜の朝、営業から「取引先のA社とB社にメールが届かない」と連絡があった。C社など多くの取引先には届いている
- 構成：社員のメールは、オンプレのPostfix（送信専用）からインターネットへ直接配送している。先週末、このサーバーを新しいサーバーへ入れ替え、送信元のIPが
203.0.113.25から203.0.113.30に変わった - 自社のDNS：example.jpのSPFは
v=spf1 ip4:203.0.113.25 -all、DMARCはp=reject。旧サーバーではOpenDKIMで署名していた - バウンス：A社（Microsoft 365）からは
550 5.7.509、B社（Gmailを利用）からは550 5.7.26が返っている。C社は自社で運用するメールサーバー
考えるポイント：どの順に何を確かめるか、A社・B社だけに起きる理由、恒久対策と再発防止。
問4 解答例と解説
| 案 | 対応 | メリット | デメリット |
|---|---|---|---|
| A | A社・B社に、自社のドメインを受信の許可リストに入れてもらう | すぐに届く可能性がある | 原因が残り、ほかの取引先でも起きる。なりすましまで許可させる |
| B | バウンスの文言から DMARC の失敗と判断し、新サーバーの IP、SPF、DKIM の署名を順に確かめて直す | 原因を直せる。全取引先に効く | DNS の反映と、署名の設定の確認に時間がかかる |
| C | 旧サーバーを戻し、そこから送る | 以前の状態に戻る | 撤去の理由（保守切れなど）が解決しない。原因の理解が進まない |
案Bです。2つのバウンスは、どちらもDMARCの失敗です（第11回）。IPが変わってSPFが失敗し、DKIMの署名（OpenDKIM）も移っていないため、p=rejectで拒否されました。
C社に届いているのは、C社がDMARCを検査していないだけで、迷惑メールフォルダーに入っているかもしれません。SPFと署名を直し、dig -x（Resolve-DnsName）でPTRも確かめ、サーバー入れ替えの手順書にSPF・DKIM・PTRの確認を加えます。エラーコードが、見るべきDNSレコードを教えてくれるのです。
問5 オンプレのPostfixのメール基盤をクラウドへ移す
- 状況：社員300名のメールを、オンプレのPostfixとDovecotで運用している。MXは
mail.example.jp（TTL 86400）、社内の機器やシステムの通知もこのサーバーで中継している - 方針：社員のメールボックスはMicrosoft 365へ、システムの通知はAmazon SESへ移し、オンプレのサーバーは半年後に撤去する
- 要件①：移行中もメールの受信を止めないこと。取りこぼしたメールが出ないこと
- 要件②：移行は部署ごとに段階的に進め、問題があれば元に戻せること
- 要件③：移行後もなりすましの対策（SPF・DKIM・DMARCの
p=reject）を保つこと
考えるポイント：MXの切り替えとTTL、並行稼働の方法、送信経路の移し方とSPF、切り戻し。
問5 解答例と解説
| 案 | 進め方 | メリット | デメリット |
|---|---|---|---|
| A | 週末に全員のメールボックスを移し、MX・SPF を一度に切り替える | 手順と期間が短い | 失敗の影響が全員に及ぶ。旧 TTL の間は新旧の両方に届き、取りこぼしやすい |
| B | 送信経路（通知 → SES）と SPF・DKIM を先に整え、メールボックスは部署ごとに移す。移行中は MX を旧 Postfix のままにして、移行済みの人宛ては Microsoft 365 へ転送する。最後に TTL を下げて MX を切り替える | 影響を部署ごとに限れ、戻せる。受信が止まらない | 期間が長い。共存の間の転送の設定と、宛先の台帳の管理が要る |
| C | Postfix と Dovecot を EC2 にそのまま載せ替える | 設定と運用の手順を活かせる | 25番の解除、PTR、IP の評判、メールボックスの冗長を自分で持ち続ける |
案Bです。ポイントは、MXを最後に切り替えるまで、受信の入口を1つのままにすることです。
- 移行中のSPFには、旧サーバーとMicrosoft 365（
include:spf.protection.outlook.com）を並べ、SESはカスタムMAIL FROMのサブドメインで合格させる - MXの切り替えの2日以上前にTTLを300秒に下げ、切り替え後もしばらく旧サーバーで受信する（TTLの考え方は連載「DNS入門」第7回）
- DMARCのレポートで、新しい経路の合格を確かめてから撤去する
- 旧サーバー（Dovecot）のメールボックスの中身を新しいサーバーへ写す方法と、移行後にメールソフトが全メールを取り直すことがある理由は、連載「POP・IMAP入門」第12回（サーバーの構築と運用 後編）で扱います
振り返りと持ち帰り
全12回を通じて、持ち帰ってほしいことは3つです。
- 配送はエンベロープ、表示はヘッダー。届かないときは、送信側のキューとログ → DNS → 経路 → 受信側の順にたどり、応答コードの1桁目と拡張ステータスコードで止まった場所を突き止める
- 送信ドメイン認証はFromとそろえて初めて効く。SPF・DKIM・DMARCを整え、レポートで送信元を棚卸ししてから、
p=rejectへ段階的に進める - 機器やアプリの送信は、経路を設計して集める。Basic認証は2026年12月末に既定で無効になる。OAuth・コネクター・社内リレー・SESから選び、25番・IP・証明書の制約を先に確かめる
まずは、dig TXT _dmarc.自社のドメイン（WindowsはResolve-DnsName _dmarc.自社のドメイン -Type TXT）を実行し、職場の機器がどの方式でメールを送っているかを確かめてみてください。メールを受け取る側（POP・IMAP）の仕組みは、連載「POP・IMAP入門」で扱います。
困ったときに戻る場所は、第11回の「連載の早見表」にまとめています。DNSの基礎は連載「DNS入門」、TLSと証明書は連載「証明書入門」もあわせてどうぞ。
まとめ
- 設計は要件と現状の確認から。書かれていない条件は仮定を明記する
- 問1：OAuthに対応しない機器がある限り、社内リレーに集める
- 問2：DMARCは棚卸し → none → quarantine（t=y） → reject
- 問3：大量送信は分けて、そろえて、自動で回す
- 問4：エラーコードが見るべきDNSレコードを教える。手順書に反映する
- 問5：移行は送信を先に、MXは最後に。TTLを事前に下げる
「メール入門」全12回、最後までお読みいただき、ありがとうございました。
コメント