Merge pull request #1695 from future-architect/feature

mail guidelines

Author: ma91n

source/_posts/2025/20251003a_メール設計ガイドラインを公開しました.md

@@ -0,0 +1,121 @@
+---
+title: "メール設計ガイドラインを公開しました"
+date: 2025/10/03 00:00:00
+postid: a
+tag:
+  - ガイドライン
+  - メール
+category:
+  - Infrastructure
+thumbnail: /images/2025/20251003a/thumbnail.png
+author: 藤井亮佑
+lede: "有志メンバーの協力により、[アーキテクチャ設計ガイドライン]を作成しました。本記事では、このメール設計ガイドラインについて、内容にも触れつつご紹介をしていきます。"
+---
+## はじめに
+
+こんにちは。TIG-DXの藤井です。
+
+当社の有志メンバーの協力により、[アーキテクチャ設計ガイドライン](https://future-architect.github.io/arch-guidelines/)というものを作成・公開しています。
+
+各分野におけるアーキテクチャ設計の指針となるべく作成されているガイドライン集ですが、この度、新たに[メール設計ガイドライン](https://future-architect.github.io/arch-guidelines/documents/forMail/mail_guidelines.html)を作成しました。
+
+本記事では、このメール設計ガイドラインについて、内容にも触れつつご紹介をしていきます。
+
+## メール設計ガイドライン概要
+
+皆さん、普段からメールは利用されているかと思います。その手軽さ・利用者の多さから、純粋なコミュニケーションツールとしてはもちろん、webシステムにおけるユーザ認証や、販促・各種取引など、多岐にわたって活用されています。
+
+一方、実際にメールという通信手段がどのように実現されているのか・どういった技術が利用されているのか、等を意識することはあまり無いのではないでしょうか。
+当然のことではありますが、メール送受信の裏側にはそれを実現しているシステムが存在しています。そういったシステムが正常に稼働しなくなった場合に生じる影響の大きさは、想像に難くないでしょう。
+
+しかしながら、現実問題としてメールに関するシステムトラブルは決して珍しいものではありません。利用者・用途が多いだけに、その分トラブルが起きる余地も大きいのです。
+
+本ガイドラインでは、メール送信を伴うシステムを構築する際に、どのようにシステムを設計すれば安定してメール送信を行うことができるか・ハマりどころは何か、といった内容を整理し、推奨事項に落とし込んでいます。一通り目を通すことで、システムにおけるメール設計の肝が理解できるようなガイドラインを目指して作成しています。
+
+逆に、SMTPそのものの仕様等の、アーキテクチャ設計に直結しない内容については省略しています。メルマガなどの手動送信されるメールや、システム監視等におけるメール通知なども、部分的に参考にできるところはあるかと思いますが、基本的にはスコープ外としています。
+
+あくまで、システムがユーザにメールを送信するためのシステム設計を対象としていることを前提に読んでいただければと思います。
+
+## コンテンツ紹介
+
+大前提として考慮すべき要素から、メールを取り扱う上で必要な事柄まで幅広く盛り込んだ結果、公開済の他のガイドラインに見劣りしない分量となりました。
+
+メールについて書くだけでそんな量を？と思われるかもしれませんが、実はそれだけ考慮しなければいけないことの量と質が求められるのが、メールという分野であると考えています。
+
+とは言え、ここで全てをご紹介することはできないため、一部を抜粋の上、簡略化してお伝えしようと思います。興味を持って頂けた・より詳しく知りたい方は、ぜひ[メール設計ガイドライン](https://future-architect.github.io/arch-guidelines/documents/forMail/mail_guidelines.html)をご覧ください。
+
+### なぜメール送信は難しいのか
+
+いきなりガイドラインには（明示的には）記載していない内容なのですが、そもそも何故メールを送信することが難しいのでしょうか。送信プロトコルであるSMTPをはじめとして、技術自体はかなり古く、高度すぎるものではないはずです。
+
+この問への回答は単純で、**スパムメールが存在するせい**です。メールの歴史は正当な送信者やプロバイダと、スパムメールを送信する悪質な送信者との戦いの歴史と言っても過言ではありません。
+
+先述の通り、メールは利用者が多く、その用途は多岐にわたります。そのため、全ての受信者に対して高いリテラシーを要求することはできず、またその手軽さから悪用のハードルも低くなっています。そのような状況を踏まえ、メールプロバイダは受信者を悪意ある送信者から守る必要があると考え、スパムであると判定したメールを受信者に届けず処分するという選択を取っています。しかしながら、そのようなスパム判定はもちろん機械的に行わざるを得ないため、（受信者にとっては）正当なメールもスパムメールであると判定してしまい、結果届かなくなるということが起こるのです。
+
+（代表的なプロバイダの動向として、2024年に施行された、[Gmailにおけるメール送信者のガイドライン](https://support.google.com/a/answer/81126?hl=ja)があります。Gmailが求めるガイドラインに準拠しない送信者からのメールはブロックする（可能性がある）としたもので、多くのシステムが準拠のための対応を行うことになりました。）
+
+そのため、（正当な）メール送信者側は、プロバイダに「これはスパムメールではない」と判断してもらうため、適切な対応をとる必要があります。
+
+### ドメイン認証
+
+第一の手立てとして、送信者が送信元メールアドレスに記載されているドメインの所有者であることを確認する、**ドメイン認証**があります。ドメイン認証を一つも行っていない場合、ほとんどのケースでスパム認定がされてしまうため、必ず実施する必要があります。
+
+スパムメールの送信者は、メールが正当なものであると誤認させるために、送信元メールアドレスのドメインを（社会的信頼のある企業などの）ドメインに書き換えてメールを送信することがあります。これはSMTPの仕様として認められており、極めて容易に実現することができます。これを**ドメインのなりすまし**と呼びます。受信者がなりすまされたドメインのみを確認し、メールを信用してしまえば、フィッシング詐欺などの被害にあってしまう可能性があります。これを防ぐため、ドメインのなりすましを機械的に検知できる仕組みとしてドメイン認証が導入されました。
+
+ここでは詳細は割愛しますが、SPF/DKIM/DMARCと呼ばれる3種の仕組みがあり、いずれも本来は名前解決に用いるDNSを活用した仕組みです。ドメイン認証が成功するメールを送信するためには、DNSに適切なレコードを登録できる人物 = ドメインの所有者でなくてはならない、というロジックで送信元の正当性を担保しています。
+
+<img src="/images/2025/20251003a/image.png" alt="image.png" width="1200" height="488" loading="lazy">
+
+ただしこのドメイン認証は、スパムメールを防ぐための機構として完全なものではありません。
+
+ガイドライン上ではTipsとして記載していますが、正規のドメインに酷似していたり、タイプミス等で誤入力しやすい、いわゆるドッペルゲンガードメインと呼ばれるドメインを保有している人物が当該ドメインを攻撃に利用した場合、ドメイン認証は通過してしまいます。ドメイン認証はあくまで、送信者がドメインを所有していることを保証するのみで、送信者自身の正当性を担保するものではないのです。（冒頭記載の通り、ドメイン認証すら通過しない送信者を不正と断じてしまえるため、完全に意味がないということはもちろんありません。）
+
+### レピュテーション
+
+ドメイン認証の結果が必ずしも送信者の正当性を担保しないことを踏まえ、メールプロバイダは別の方針での送信者評価を行い、ドメイン認証の結果と合わせてメールの取り扱いを判断しています。それが**レピュテーション**と呼ばれるもので、言葉通りメール送信者の「評判」を意味します。レピュテーションが十分な送信者からのメールは通常通り受信者に配信し、レピュテーションが低い送信者からのメールはスパムメールであると判断し処分してしまう、という単純な仕組みです。
+
+そのため送信者としては、**レピュテーションを向上し、高い状態を維持する**ことが安定したメール送信のために取れる手立ての2つ目となります。このレピュテーションは主に、送信元のIPアドレスとドメインに対して評価されます。ドメイン認証の結果と合わせて見ると、**レピュテーションが高いドメインの所有者が送信したメール**であれば高い確率で正常に配信されることが期待されます。
+
+このレピュテーションは、メールの送信状況や受信者のアクション（迷惑メール報告等）により、プロバイダごとに常に変動して管理がされるため、送信状況の監視・適切なコンテンツの作成が安定したメール配信に強く影響します。
+
+<img src="/images/2025/20251003a/image_2.png" alt="image.png" width="1200" height="424" loading="lazy">
+
+### 自作メールサーバ vs メール送信SaaS
+
+メール送信を実現する場合、大きく分けて「メールサーバを自作する」・「メール送信用のSaaSを利用する」の二方針に分類されますが、ガイドラインでは圧倒的に**SaaSの利用を推奨**しています。SaaSを利用することで、各種設定の簡易化・送信状況等の監視機能が利用可能となる・（IP）レピュテーションがある程度担保されている等のメリットを享受できるためです。
+
+ここまでに記載したドメイン認証・レピュテーションの管理ともに、適切な設定・運用は容易ではありません。その一方で、設定誤りや運用ミスが有った場合の影響は極めて大きい（最悪の場合、一切のメールが宛先に届けられない）です。このようなリスクがSaaSの利用により極小化できるのです。
+
+もちろん利用コストが生じることや、（レピュテーションを低下させる行動を繰り返したなどにより）SaaSの利用が停止されてしまうなどのリスクは存在しますが、それを補って余りあるメリットであると考えています。
+
+### コンテンツの工夫
+
+レピュテーションには、受信者のアクション（迷惑メール報告等）が影響すると記載しました。つまり、受信者にとってスパムであるかのように映るメールを送信するとレピュテーションが下がり、結果としてメール未達などに繋がってしまいます。そのため、システム面のみならず、実際に送信されるメールの内容についても工夫が必要です。
+
+ガイドラインでは、以下要素などが工夫すべきポイントとしています。
+
+- 件名: 要件が正しく伝わり、優良誤認とならない範疇で簡潔にする。
+- 本文: マルチパート配信とする。css等による装飾は過剰となりすぎないようにする。
+- 送信者名: 送信者・目的が分かるものとする。
+- 送信元メールアドレス: info, noreply等、メールの性質が伝わるアドレスにする。
+
+### トラブルシューティング
+
+ここまでに記載したこと、およびガイドラインに記載したことに準拠していても、突然メールが届かない、といった事態が発生することは想定されます。これは送信者・プロバイダ・受信者という3者が関わる仕組みである以上、確実に回避できるものではありません。
+
+メール送信が正常に行えないという状況自体、影響として大きなものですが、誤った対応や放置をしてしまうと状況は更に悪化してしまいます。
+
+基本的には継続的な問題が確認された時点でメール送信機能は停止し、状況把握を行った上で対処を開始することを推奨しています。ガイドラインには具体的な調査するべき内容等も記載しているので、合わせてご確認ください。
+
+## おわりに
+
+先述の通り、メール送信を伴うシステムは一度構築したら終わりというものではなく、継続的な監視・適切な運用が必要なものとなっています。構築・運用方針を誤ってしまうと、最悪の場合メール配信が行えなくなってしまいます。
+
+今回作成したガイドラインには、本記事では触れられなかった（量・質ともに）内容も多く記述されています。ぜひ通しでご覧いただき、安定したメールシステムの構築に活用いただければと思います。
+
+最後になりますが、ガイドラインへのご意見や訂正PRなどは広く募集しております。目を通していただいて、疑問に思った点・誤り等ありましたらご意見いただけますと幸いです。
+
+- [GitHub](https://github.com/future-architect/arch-guidelines)
+- [ガイドライン一覧](https://future-architect.github.io/arch-guidelines/)
+
+今後も継続してガイドラインは作成していく予定です。既存・新規問わず、アーキテクチャ設計の一助となることを願っております。