メール設計ガイドライン | フューチャー株式会社

本ガイドラインは、世の中のシステム開発プロジェクトのために無償で提供する。
ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社（以下、フューチャー）は一切の責務を負わないものとする。
また、掲載している情報は予告なく変更する場合があるため、あらかじめご了承いただきたい。

はじめに ​

電子メールは、SMTP（Simple Mail Transfer Protocol）プロトコルが1980年代初頭に標準化されて以来、半世紀近くにわたり利用されている。多くのサービスで 「認証」 「販売促進」 「トランザクションの証明」 などにメールが用いられており、ユーザー体験にも直結する。

しかし、その長い歴史ゆえに、古典的な技術知識だけでは対応しきれない到達性の低下や遅延などの課題を引き起こしやすい。これはクラウドプロバイダーが提供するEメール送信サービスを用いても起こりえるため、モダンな環境下でも無視はできない。

そのため、SMTPプロトコルの理解に加えて、クラウドベースのメール配信サービスの特性を理解し、要件に応じて設計する能力が求められる。特に大規模なシステムでは信頼性・費用・保守運用制などの非機能要件も求められる。本ガイドラインは、メール送信で考慮すべき設計事項と推奨案をまとめる。

適用範囲 ​

• コンシューマ（一般ユーザー）向けのメール送信を対象とする
  • ただし、同一用途で使われるLINEについては本ドキュメントでは触れない
• 電気通信事業法でいう「電気通信事業」に該当しない通信である、取引関係に伴う事務連絡や企業からユーザーへの広告宣伝を目的する
• システムからの自動送信メールを対象とする。手動送信でのメルマガ送信や営業メールは対象外とする
• 企業のシステム管理者向けのメール送信（例えば、障害通知など）については、参考にできる部分も多いと思われるが、強く意識していない
• ServiceNowやZendeskといったメールを含む問い合わせ管理のSaaSサービスの運用設計やサービス選定なども対象外とする
• 主要なクラウドサービス（AWS SES, Microsoft Azure Communication Services, Google Cloud, SendGridなど）を用いるとし、スクラッチやOSSなどでのSMTPサーバの構築や運用については、触れないとする

用語 ​

• トランザクションメール: ログイン通知や注文完了通知といったユーザーのアクションや、サービスの重要な変更をきっかけに送信される企業にとって重要な通知。ユーザーとの信頼関係を構築し、アカウントのセキュリティを保つ上で重要である
• マーケティングメール: メールマガジンなどの広告・宣伝に用いるメール。販売促進や顧客との関係構築に重要なツールであるが、一歩間違えると迷惑メールとして認識され、逆にブランドイメージを下げてしまう
• キャリアメール: 国内携帯通信キャリア(docomo, au, Softbank, 楽天）を指す
• ESP: メール配信サービス（Email Service Provider）のこと。SendGridやAmazon SESなどが存在する

ドメイン認証 ​

メールアドレスは、@前後でローカルパートとドメインに分けられ、例えばlocal-part@example.com のようなメールアドレスの場合、 local-partがローカルパートで、example.comがドメインである。システムから配信されるメールの場合、多くの受信者はローカルパートではなく、ドメイン部分を確認する事でメールの送信元と、その妥当性を確認する。

しかし、メールの仕様として送信者はドメイン部分を含め、受信者に通知するメールアドレスを任意に設定できるため、管理していないドメインからのメールであるかのように振る舞うこと、すなわちドメインのなりすましが可能である。ドメインのなりすましは、多くの場合悪意をもって行われる（フィッシング詐欺等）ため、メールの信頼性を高めるために、ドメイン認証（SPF、DKIM、DMARC）が求められる。

SPF（Sender Policy Framework） ​

SPF（エスピーエフ）は、RFC 7208により定められた仕様で、ドメイン所有者がそのドメインを用いてメールを送信できる送信者(Sender)を限定する(Policy)ための仕組み(Framework)である。

具体的には、DNSに送信者として許可するホストのIPアドレスをSPFレコードとして記録しておく。受信者はメールに記載されているドメインを用いてDNSにSPFレコードを問い合わせ、送信元IPアドレスと照合することで、受信したメールがSPFに準拠したものであるかを判定できる。

SPFの導入にあたっては、以下のようなレコードをDNSに設定するのみで、メールサーバ側で必要な設定などは特に存在しない。

example.com. IN TXT "v=spf1 ip4:192.0.2.0 ip4:198.51.100.36 ip4:203.0.113.104 -all"

SPFレコードは複数の要素（ディレクティブと修飾子）から構成され、さらにディレクティブは限定子と機構と呼ばれるものから構成される。それぞれ、メールサーバの構成に応じて適切な値を設定する必要がある。

設定値の推奨は以下の通り。

• ESPから設定値が提供された場合、その値を設定する
  • サービス提供者がそのサービスでメール送信に利用するIPアドレスを正確に把握・管理しており、その情報を集約したSPFレコードを提供しているため

DKIM（DomainKeys Identified Mail） ​

DKIM(ディーキム)は、RFC 6376により定められた仕様で、ドメインに紐づけられた鍵(DomainKeys)を用いて、メール(Mail)の内容と送信者が正当であると証明する(Identified)。公開鍵暗号を用いた認証仕様で、まずDNSに公開鍵を登録しておく。その上で送信者はメール送信時にメールの内容から電子署名を作成し、メールヘッダに含める。受信者はDNSから公開鍵を取得し、電子署名を検証することで、内容と送信者の正当性を確認できる(検証に失敗した場合、なりすまし、あるいは受信経路での内容の改ざんが考えられる)。

DKIMを導入する場合、まずキーペアを作成し、以下のようなレコードを設定することでDNSに登録する。その上で、メール送信時に電子署名を作成、ヘッダに含めるよう、メールサーバ上で設定する。

selector._domainkey.example.com. IN TXT “v=DKIM1; k=rsa; h=sha256; p=xxxxxxx…;”

サブドメインのselectorは、複数のキーペアを署名に用いる場合の識別子、セレクタとして記載する。値自体は任意であるが、1組のキーペアしか用いない場合も省略できないため、必ず指定する。

DKIMレコードは複数のタグと値の組み合わせで構成される。

※RFC 4871時点ではgタグも定義されていたが、現在は非推奨となっている。

設定値の推奨は以下の通り。

• ESPを利用している場合、サービスからセレクタや公開鍵などの設定値が提示された場合は、その設定を必ず行う

DMARC（Domain-based Message Authentication, Reporting, and Conformance） ​

DMARC(ディーマーク)は、RFC 7489により定められた仕様で、ドメイン認証（Domain-based Message Authentication）の結果を用いて、送信者への認証結果の報告（Reporting）と、受信者へのメールの取り扱いへの準拠（Conformance）を要求する。DMARCはSPFおよびDKIMを前提とした仕組みであり、「SPFおよびSPFアライメント」あるいは「DKIMおよびDKIMアライメント」のいずれかを通過しなかったメールの取り扱い（受信拒否・隔離・受信）をメール送信者が指定できる。

SPF/DKIMアライメントとは、各認証に用いたドメインが、ヘッダFROM（主に受信者に表示されるメールアドレス）のドメインと一致しているかの検証を指す。SPFやDKIMは各ドメインが送信者によって管理されていることを保証する仕組みではあるが、ヘッダFROMとは異なるドメインで認証を行っている場合、SPF/DKIMに通過していたとしても、メール送信者の正当性（ヘッダFROMのドメイン管理者であるか）は全く担保されない。そのような状況を検知するため、ヘッダFROMのドメインと認証に用いられたドメインが一致していることの検証がSPF/DKIMアライメントである。SPF/DKIMアライメントを総称してDMARCアライメントと呼ぶ。

SPF/DKIM同様、設定はDNSに以下のようなレコードを登録することで行う。

_dmarc.example.com IN TXT “v=DMARC1; p=reject; rua=dmarc-report@example.com”

SPFおよびDKIMを前提とした認証の仕組みである以上、必ずSPF/DKIMの設定が完了してからDMARCを設定する。設定伝播には時間がかかることがあるため、SPF/DKIM設定後、48時間以上経過してからDMARCを設定することが、Googleにより推奨されている。

推奨は以下の通り。

• まず、p=noneとした上で、ruaに適切なレポート送信先を設定、日次でレポートを確認、SPF/DKIMの設定が正常に行えていることを確認する
  • rufは設定しても良いが、GmailやMicrosoft 365などの主要サービスがフォレンジックレポートの送信に対応していないため、あまり参考になる情報は得られない可能性が高い
• 次に、p=quarantine、あるいはp=rejectに設定したうえで、pctに10などの小さな値を設定し、引き続きレポートを確認する。加えて受信者（システムのユーザなど）から、「メールが届かなくなった」といった問い合わせが発生するようになっていないか注視する
  • p=quarantineは、認証失敗メールを迷惑メールフォルダなどに隔離するよう受信者に要求する。正当なメールが誤って認証に失敗した場合でも、受信者が救出できる可能性がある
  • p=rejectとすると、認証に失敗したメールが配信されなくなるため、既にドメインのなりすましが行われているなど、認証失敗メールの配信を確実に防ぎたいなどの場合はrejectを設定する
• 徐々にpctの値を大きくしていき、最終的に100（あるいは指定なし）まで引き上げる
  • pctの初期値・増加量は、設定の影響範囲と設定値変更の作業コストを鑑みて決定する

xml version="1.0" encoding="UTF-8"?>
feedback>
  report_metadata>
    org_name>example.comorg_name>
    email>noreply-dmarc-support@example.comemail>
    extra_contact_info>http://example.com/dmarc/supportextra_contact_info>
    report_id>xxxxxxxxxxxxxxxxreport_id>
    date_range>
      begin>UNIX_TIMEbegin>
      end>UNIX_TIMEend>
    date_range>
  report_metadata>
  policy_published>
    domain>example.orgdomain>
    adkim>radkim>
    aspf>raspf>
    p>nonep>
    sp>nonesp>
    pct>100pct>
  policy_published>
  record>
    row>
      source_ip>198.51.100.36source_ip>
      count>2count>
      policy_evaluated>
        disposition>nonedisposition>
        dkim>faildkim>
        spf>passspf>
      policy_evaluated>
    row>
    identifiers>
      header_from>example.orgheader_from>
      envelope_from>example.orgenvelope_from>
    identifiers>
    auth_results>
      dkim>
        domain>example.jpdomain>
        result>passresult>
        human_result>human_result>
      dkim>
      spf>
        domain>example.orgdomain>
        result>passresult>
      spf>
    auth_results>
  record>
feedback>

独自ドメイン利用時の注意 ​

Amazon SESなどのメール送信サービスを利用する場合、SPF/DKIMがメールサービス側で設定されることにより、利用者側は特別な設定を行わずとも、認証を通過するメールが配送されることがある。ただし、それらの認証は、メール送信サービス側のドメインに対して行われるため、独自ドメインを用いてメールを送信する場合、DMARCアライメントが失敗してしまう。この場合、Gmailなど一部のメールクライアントでは「amazonses.com 経由」のような表示がなされたり、場合によっては迷惑メールとして扱われる・受信拒否されてしまう。

推奨は以下の通り。

• 独自ドメイン利用時は、メール送信サービスが提供するドメイン認証設定を必ず利用する。ほとんどのメール送信サービスでは、サービス側が提示するレコードをDNSに登録することで、独自ドメインを用いてドメイン認証が行える（=DMARCアライメントが成功する）仕組みが提供されている

Return-Path: envelope@mail.example.com>
Received-SPF: pass (mx.example.org: domain of envelope@mail.example.com designates 192.0.2.0 as permitted sender) client-ip=192.0.2.0;
Authentication-Results: mx.example.org;
       dkim=pass header.i=@example.com header.s=selector header.b="xxxxxxxx";
       spf=pass (example.org: domain of envelope@mail.example.com designates 192.0.2.0 as permitted sender) smtp.mailfrom=envelope@mail.example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=selector; d=example.com; t=1753843200; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; bh=xxxxxxxx; b=xxxxxxxx
From: "送信者表示名" sender@example.com>

Gmail送信者ガイドライン ​

2024年2月、Gmailがメール送信者向けのガイドラインを公開した。ガイドラインに沿わない場合、Gmailによる受信拒否や、迷惑メールフォルダへの振り分けが発生する可能性があるため、原則として全送信者が準拠するべきである。

推奨は以下の通り。

• 1日あたりのGmail宛のメール送信数が5,000件以上か否かにより、準拠するべき要件は異なるが、1日の送信件数に依らず、すべての要件に準拠する
  • 将来的な送信数の増加に備えるため・Gmail以外への配信率向上・迷惑メール報告率低下に繋がる要件であるため
• No.1、2、3、5は、メール送信サービスを利用する限り、ほとんどの場合サービス側で対応がなされているため、意識する必要はない
• No.4
  • 受信者による迷惑メール報告率が、0.10％未満である状態を維持し、一時的なスパイク時にも0.30％を超えないようにする
  • 手動での迷惑メール報告を防ぐ、直接的なアクションを送信者側で取ることは難しいため、迷惑メールと疑われるような件名・文面を避ける
  • Googleが提供するモニタリングツールであるPostmaster Toolsを活用し、迷惑メール率を継続的に監視しながらメールの内容を調整する。Gmailによる自動的な迷惑メール判定も迷惑メール率に影響するため、前述したドメイン認証の実施、後述するレピュテーションの維持を実施する
• No.6
  • Gmailガイドラインでは、特にGmail（gmail.com）へのなりすましを避ける（GmailのDMARCポリシーがquarantineであるため、DMARCアライメントに失敗した場合、正常に配信されない可能性が高い）よう記述されているが、Gmailに限らず、あらゆるドメインへのなりすましを行わないこと
• No.7
  • メールそのものの送信者ではなく、メール転送サーバやメーリングリストを管理している場合、送信者のドメインに対するドメイン認証の結果は転送時に失われてしまう。転送後も、送信者のドメイン認証結果を確認できるようにするため、各ドメイン認証の結果から作成した値をARCヘッダに設定する
  • メーリングリストを管理している場合は、メーリングリストを経由した配信であることが明らかになるよう、List-idヘッダを設定する
• No.8,9
  • 前述のDMARC設定を行い、DMARCアライメントにも合格するよう、送信ドメインを設定する。2025年7月現在、ポリシーレベルの指定は無いため、十分な検証が行えていない場合はp=noneでも問題ないが、前述の通り、様子を見ながらquarantine/rejectに引き上げることを推奨する
• No.10
  • マーケティングメールを不要であると判断した時点で、即座に配信停止が行える経路をメール内に用意する
  • 本文内に配信停止方法を案内する事に加え、List-Unsubscribeヘッダを付与し、ワンクリックで配信停止できる状況とすることを推奨する。2025年7月現在、本要件を満たしていない場合であっても、自動的に受信拒否や迷惑メール判定が行われるわけではないと案内されている。が、トランザクションメールであっても受信者が不要と判断したときに、配信停止が容易でなければ「迷惑メール報告」ボタンを押す可能性が高くなる。これが繰り返されれば、レピュテーションが損なわれ、全てのメール配信に影響が及ぶため

レピュテーション ​

レピュテーションとは、メール送信者が受信側（ISP: インターネットサービスプロバイダやメールサーバ）から与えられる信頼性の評価のことであり、レピュテーションを高く維持することでユーザーにメールを確実に届けることができる。

主に以下の2種類が存在する。

• IPレピュテーション: メール送信に使用されるIP アドレスの評価
• ドメインレピュテーション: 送信者が利用するドメイン名の評価

レピュテーションは、受信側が迷惑メール（スパム）と正当なメールを区別するためにも用いられる。レピュテーションが低い場合、以下の影響がある。

• 迷惑メール判定: 受信側で自動的に迷惑メールフォルダへ振り分けられる確率が高くなる
• 到達率低下: ISPにより一部またはすべてのメールが受信拒否され、受信者にメールが一切届かなくなる

レピュテーションを高く維持するには、受信者にとって価値のあるメールを継続的に送り、信頼される送信者であり続ける必要がある。

• 安定した送信: 適切な頻度で安定した量のメールを送信（例: 週に1〜2回の定期配信など）
• 質の高いコンテンツ: 受信者の関心に沿ったコンテンツを提供し、高いエンゲージメント（開封やクリックなど）を維持
• リストの健全性: バウンス率や迷惑メール報告を低く抑えるため、常に送信リストをクリーンに保つ

しかし、新しく利用を開始するIPアドレスやドメインには、これまでの送信履歴がないため、ゼロから信頼を築くための特別な対応が必要となる。その対策がウォームアップである。

ウォームアップ ​

ウォームアップとは、新しくメール送信を開始するIP アドレスやドメインのレピュテーションを段階的に構築するプロセスのことである。

• IP ウォームアップ: 新しいIP アドレスでメール送信を始める際に、徐々に送信量を増やしてISP からの信頼を獲得する
• ドメインウォームアップ: 新しいドメインで送信を開始する場合に、そのドメインの信頼性を高めるプロセス

ISP は特にIP アドレス単位での信頼性を重視するため、新規のメール送信環境ではIPウォームアップが重要になる。対応の有無は、専用IPについてはメール送信履歴の有無や、共有IPによって異なる。

推奨は以下の通り。

• トランザクションメールとマーケティングメールのIPは分離し、それぞれ専用IPを利用する
  • マーケティングメールのレピューテーション低下で、トランザクションメールの到達性に影響を受けず、確実な配信が可能であるため
• 小〜中規模配信（月間10万通未満）の場合は、共有IPを利用する
  • ウォームアップ不要で即座に配信開始可能、コスト効率が良いため
• 大規模配信（月間10万通以上）の場合、専用IPを推奨する
  • 完全な制御が可能かつ、長期的な信頼性が高いため
  • 注意として、ウォームアップ期間（1〜2ヶ月）が必要
• ウォームアップ実施の有無は下表に従う

IPプール ​

メール配信する上で、複数のIPアドレスを使い分ける設計も有効である。IPを分散して用いると以下の効果がある。

• リスクの分散: 1つのIPがブロックされても、他のIPで送信を継続可能
• ウォームアップの効率化: 複数のIPを段階的にウォームアップすることで、全体の送信量を早期に拡大
• ISP制限の回避: 各ISPが設定する1IP当たりの送信制限を分散により回避

IPをどのように使い分けるかはいくつかの戦略がある。

• 送信量で分散: 1つのIPに負荷を集中させず、複数のIPで送信量を分散することで、ISPからの信頼を維持
• 用途別: トランザクションメールとマーケティングメールで異なるIPを使用し、リスクを軽減
• ISP別: 特定のISPに特化したIPを用意し、そのISPの特性に合わせて送信する

推奨は以下の通り。

• 以下の条件のいずれかに一致する場合、複数IPを利用する
  • 月間送信量が100万通を超える場合
  • トランザクションメールとマーケティングメールの両方を大量送信する場合
  • 複数のブランドやサービスからメール送信する場合
• 以下の条件に一致する場合は、単一IPを用いる
  • 月間送信量が50万通未満の場合
  • 送信メールの種類が限定的な場合
  • リソースやコストを抑えたい場合

ドメインウォームアップ ​

基本的に、SPF/DKIM/DMARC といった送信ドメイン認証が正しく設定されていれば、ドメインのレピュテーションはIP ウォームアップを進める中で並行して構築されていく。そのため、ドメインのために特別なウォームアップを実施する必要はほとんどない。

サブドメイン戦略 ​

レピュテーション管理として、送信するメールの種類に応じてサブドメインを使い分ける方法がある。これにより、例えばメルマガのスパム報告率が上がっても、認証や注文確認メールの到達性に影響が及ぶリスクを分離できる。

推奨は以下の通り。

• 次のいずれかの条件に一致する場合は、サブドメイン分離する
  • 月間送信量が50万通を超える場合
  • トランザクションメールとマーケティングメールの両方を送信する場合
  • 複数のブランドやサービスを運営している場合
• 次のいずれかの条件に一致する場合は、サブドメイン分離するか “検討” する
  • マーケティングメールの配信頻度が高い場合（週3回以上）
  • 異なる対象オーディエンスにメール送信する場合
• サブドメイン分離は、メール配信開始時点で将来の送信量を見越して設計すること
  • 後からサブドメインを追加・分離する場合、新しいサブドメインは送信履歴がゼロの状態からとなるため、ウォームアップから必要になるため

健全な配信リストを維持するためのリストクレンジング ​

メールの到達力を高め、送信者としての信頼性を維持するために配信リスト全体の品質を向上するためのリストクレンジングが重要となってくる。

リストクレンジングの目的と重要性 ​

古く整理されていないリストにメールを送り続けると、以下のようなリスクが発生する。

• レピュテーションの悪化: 無効なアドレスへの配信を続けると、ISPから迷惑メール送信者と見なされ、評価が低下する。その結果、本来届くはずのメールまでブロックされたり、迷惑メール判定を受けたりするようになる
• コスト浪費: 無駄な配信数分のコストが発生する
• 正確な効果測定の阻害: 反応しないユーザが含まれることで、指標が不正確になる可能性がある

リストクレンジングは、これらのリスクを回避するための重要な対応である。

クレンジングの対象となるリスト ​

リストクレンジングでは、以下の宛先を整理することを推奨とする。

ハード・ソフトバウンスの対応について ​

以下のフローや対応については、あくまでサンプルのため、業務に合わせて対応すること。

メール配信後、以下を対応する。

• ハードバウンスの対応
  • 条件: 配信結果でハードバウンスとなったアドレス
  • 対応: 即時、全件を「配信停止リスト」に登録する
• ソフトバウンスの対応
  • 条件: ソフトバウンスの発生が累計3回以上となったアドレス
  • 対応: 累計”3回”に達した時点で、対象アドレスを「配信停止リスト」に登録

大手ISPごとの特徴 ​

以下は各ISPの大まかな特徴を紹介する。なお、ISPのアルゴリズムや判定基準は頻繁に変更されるため、大まかなこういった傾向があるというような、参考情報として利用する。

サービス選定 ​

メール送信SaaS市場は、国内外で多様なプレイヤーが存在し、それぞれ異なる強みを持っている。日本の市場では、ブラストメール（25,000社以上）、AutoBiz（20,000社以上）、配配メール（10,000社以上）、WEBCAS e-mail（シリーズ10,000社以上）などが導入実績で上位を占めている。ITトレンド年間ランキング2024では、WiLL Mail、配配メール、Account Engagementが人気TOP3に挙げられており、国内企業からの支持を集めていることが示唆される。

一方、グローバル市場では、SendGridが月間1,000億通以上、Mailgunが15万社以上、Amazon SESが年間1兆通以上 の圧倒的な配信実績を誇っている。HubSpotやMailchimpも世界中で広く利用されており、Brazeも大規模エンタープライズ向けの顧客エンゲージメントプラットフォームとして存在感を示している。

推奨は以下の通り。

• 開発者中心でトランザクションメールが主の場合
  • システムからの自動通知メールや、ユーザー行動に即した高速・大量のトランザクションメールの確実な配信を最優先する企業には、Amazon SES、Mailgun、SendGrid
• マーケティング活動が主で非技術者も利用する場合
  • MailchimpやHubSpot Email Marketing
• 高度な顧客ジャーニーとマルチチャネル統合を目指す場合（AI統合等）
  • Braze、Customer.io、またはHubSpot Marketing HubのProfessional/Enterpriseプラン

データ収集ポリシー ​

法令遵守 ​

メールアドレスや電話番号は、それ自体に氏名が含まれる場合や、他の情報と容易に照合できる場合に、個人情報保護法における「個人情報」に該当する。ただし、それ単体で個人を識別できない場合は「個人関連情報」にあたり、法的な定義が異なる。しかし、システムとしては個人情報・個人関連情報に関係なく、常に個人情報として扱われることが多い。その理由は、メールアドレスそのものが個人を特定可能な値に変更されたり、ビジネス要件への対応で属性が追加されることを考えると、最初から厳格な対応を取るほうが将来的な拡張に強く、「個人情報」と「個人関連情報」という2つのデータ保護ポリシーを持ち込まずに済むため設計をシンプルにできるためである。本ガイドラインもそれに賛同し、メールアドレスや電話番号を「個人情報」として厳密に扱う方針とする。

この方針に基づくと、メールアドレスや電話番号を収集・利用する際は、個人情報保護法が定める「適切な同意取得」 「利用目的の明示」 「第三者提供の制限」 「セキュリティ対策」 が必要である。また、広告宣伝目的のメール送信・SMS送信における「特定電子メール法（迷惑メール防止法）」などへの準拠も求められる。加えて、EU（GDPR）やその他海外でも、個人情報として扱われることが一般的であり、それぞれの法規制への対応が求められる。

上記で触れたもの以外も含め、国内の主要な法規制と準拠すべきポイントをまとめる。

各法規制の要点は以下の通り。

• 個人情報保護法
  • 個人の権利利益の保護を目的とし、電話番号を含む個人情報の取得から廃棄まで事業者の責務を定めている
  • 「本人の同意」 「利用目的の特定」 「安全管理措置」などの遵守が求められる
• 特定電子メール法（迷惑メール防止法）
  • 迷惑なマーケティングメールの防止を目的とする
  • 広告宣伝のSMS送信時の 「オプトイン（事前同意）原則」 「送信者情報の表示義務」 「オプトアウト（配信停止）手段の提供」 が求められる
• 特定商取引法
  • 消費者トラブルが生じやすい特定の取引（特に「通信販売」）における消費者保護を目的とする
  • 特電法より厳格な広告ルールが定められ、「契約通知への安易な広告付随の禁止」 「詳細な取引条件の表示義務」 が求められる

推奨は以下の通り。

同意取得:

• 必要最小限のデータのみ収集する
  • そもそも電話番号を収集せず、メール通知等で代替できないかを第一に検討する
  • また、氏名とメールアドレス（電話番号）のみで十分な場合、住所などをそもそも収集しない
• メールアドレスや電話番号の取得時に、利用目的とプライバシーポリシーへのリンクを記載する
  • 利用目的は具体的（例：本人認証、重要通知、広告宣伝、メールマガジン配信）に記載する
• オプトイン同意を確実に取得する
  • 目的ごとに同意を取得する。「本人認証」と「広告宣伝（メールマガジン）」の同意は、登録フォームのチェックボックスを分けて選択可能にする
  • 同意内容には、第三者提供の有無やデータ保存期間も明記する
  • 同意した日時、目的、手段（IPアドレスなど）などを証跡ログとして保存する
• 目的外の利用は、同意を再取得する
  • 利用規約やプライバシーポリシーに反する利用を行う場合は、同意を再取得する
• ユーザーが自身のメールアドレスや電話番号を確認・訂正・削除できるようにする
  • 配信停止、紐づけ解除など

メッセージ本文:

• 誰からのメッセージか分かるよう、サービス名・事業者名を記載する（メールの場合は連絡先や住所など）
• （広告の場合）
  • 「配信停止はこちら」のような、配信停止手段を記載する（GmailのオプトアウトについてはGmail送信者ガイドラインの章を参照）
  • 広告本文からランディングページにリンクし、特商法で定められた価格や返品条件といった法定表示事項を表示する
  • 「必ず儲かる」のような、消費者に誤解を与える断定的な表現や、著しく有利であると見せかける表現は使用しない

開封トラッキング ​

メールの開封トラッキングは、送信したメールが受信者によって開かれたかどうかを測定する技術である。主に以下の目的で行われてきた。

• マーケティング効果測定: メールマガジンなどの開封率を測定し、キャンペーンの効果を評価する。件名のA/Bテストなどに利用
• 営業活動: 重要な提案書などを送付した際、相手がいつ内容を確認したかを把握する

手法としては以下のような方法が取られてきた。

• メール本文にトラッキングピクセル（1×1ピクセルの目に見えない画像）を埋め込み、メールが開かれると画像読み込みのため、特定のURLへのリクエストが送信される。これを持って「開封」とみなす
  • 開封時間やIPアドレス（※大手メールサービスでは取得不可にするようプロキシを導入）が取得可能
  • この仕組み上、メールクライアント設定で画像を非表示設定にしている場合、トラッキング不可となる

しかし、ユーザーの許可なく行動を追跡することへの懸念から、近年プライバシー保護強化の流れがありその信頼性は揺らいでいる。通信キャリア・主要メールサービスごとの状況を下表にまとめる。

このような状況のため、開封トラッキングを継続するかどうか議論になる場合がある。

• 案1: 開封トラッキングを継続
  • 非Appleユーザーに限れば、大まかな傾向を把握できる
  • 全体的に正確性に欠くため、誤った意思決定に繋がる懸念
• 案2: 開封トラッキングを廃止、別の指標に移行
  • メール本文内のリンクのクリック率（CTR）や、その後のコンバージョン率（CVR）を指標に用いる
  • 開封率を元にした件名A/Bテストなどの手法はできなくなるが、ユーザーの能動的なアクションかつ正確な数値を用いることができる

推奨は以下の通り。

• 案2を第一に考える
  • 開封率という指標は不正確であり、それに基づくビジネス上の意思決定はリスクとなるため
  • 開封トラッキングはプライバシー保護の時代的な判断に逆らった手法であるため、コンプライアンス上のリスクとなるため

メールアドレスの管理 ​

有効性 ​

ユーザーが入力したメールアドレスの有効性の検証することで、存在しないアドレスにメールを送信してしまうことで生じるレピュテーションの低下リスクを避け、登録したはずのメールが届かないといった問い合わせを減らし、ユーザー体験を向上させることができる。

メールアドレスの妥当性チェックには、いくつかのレベルが存在する。

形式チェック ​

メールアドレスの妥当性チェックで、最初に行うべきことは、正規表現などを用いた形式チェックである。入力フォームによる登録内容をチェックしフィードバックすることは、以下のメリットもある。

• ユーザー体験の向上
  • user@examplecom のようにピリオドが抜け、@ が無い、 user＠example.com のように全角文字が混入、user @example.com のように半角スペースが混入などの明らかな入力ミスを防ぎ、登録後に「メールが届かない」という状況を軽減できる

一方で、以下のトレードオフ構造がある。

• RFCなどに準拠した厳密な検証にすると…
  • ✅️入力ミスを軽減できるためユーザー体験を向上
  • ✅️誤った宛先にメール送信することで生じる、レピュテーション低下リスクや費用を下げることができる
  • ❌️一部キャリアでは、メールアドレスの公式な仕様（RFC 5322）に則っていないメールアドレスが有効であるため、それらのユーザー登録を阻害してしまい機会損失を生むリスク
• 検証が緩すぎると…
  • ✅️RFC違反だが実際に利用可能なメールアドレスを受付できる
  • ❌️明らかな入力間違いにもユーザーが気付かず、登録後のメールが届かず離脱してしまう懸念。例えば、メールアドレスに 未来太郎 といった氏名を誤入力してしまうのは、メール送信前に検知可能である
  • ❌️バウンスメールが発生し、レピュテーションが低下するリスク
  • ❌️他システム側で、メール送信ができないリスク（例えば、SESでは送信可能だったが、別のESPでは送信不可という状況がありえるため、将来的な切り替え時の課題になりえる）

形式チェックにおける主要な対応案は以下の通り。

推奨は以下の通り。

• 入力時の形式チェック自体は必須で行う
  • ただし、システム目線ではなく、ユーザー入力ミスを防ぐこと（ユーザーの利便性向上）を目的とする
• 形式チェックは、（3）の方針を採用する
  • 「存在するかもしれない」アドレスは通過させ、最終的な存在確認は次のステップである「確認メールの送信」に委ねる
• ユーザー体験向上の施策の導入を検討する
  • 前後の半角スペースは自動でトリムする
  • キャリアメールアドレスで登録した場合、確認メールが届かないかもしれないダイアログの表示を入れるか検討する（GmaiやYahoo!メールなどへの誘導をセットで行うと良い）
  • user@gmal.com のように一般的なドメインの打ち間違いを検知し、「もしかして: Gmail.com？」と提案するライブラリ（例: Mailcheck.js）の導入を検討する

^[A-Z0-9._%+-\\"]+@[A-Z0-9.-]+\.[A-Z]{2,}$

形式チェック以外の検証 ​

フォーマットチェック以降の、ドメイン存在チェック・使い捨てアドレスチェック・確認メール送信は外部のリクエストが発生し、コストが発生するため注意が必要である。

推奨は以下の通り。

• ドメイン存在チェックの実施は、できる限り実施する（優先度は落としても良いが、行ったほうがベター）
  • 少なくてもサーバーサイドでMX/Aレコードの存在を確認することで、ユーザーへのフィードバックを早めること（存在しないドメインです、などの表示）が可能なため
  • 自社サービス側のレピュテーション低下を抑制できるため
  • API利用料の削減が期待できるため
• 不正利用のリスクが高いサービス（無料トライアル、キャンペーン登録など）では、「使い捨てアドレス」チェックするAPIを呼び出しを検討する
  • 対応は必須ではない。リスク評価、費用対効果を見て導入する
• 確認メールの送信は必須で行う
  • ユーザーがメール内の確認リンクをクリックして初めて、そのメールアドレスを「有効」ステータスとして扱う
  • ユーザー登録、メールアドレス変更時など重要な操作時も行うと良い

確認メールの認証方式 ​

確認メール送信を用いた、メールアドレスの有効性確認には以下の2つの方法が考えられる。

推奨は以下の通り。

• マジックリング方式を第一に検討する
  • メールを開ける時点で、リンクのクリックが可能であると考えられるため
  • ユーザー体験が高く、ユーザーの離脱を低くできると考えられるため

エイリアス ​

メールエイリアス（サブアドレス）とは、1つのメールアドレスに複数のバリエーションを持たせることができる機能である。エイリアスにメールを送信すると、元になるメールアドレス（ベースアドレス）にメールが送信される。RFCの仕様上、メールアドレスの@より前のローカルパートに、+記号を含めることが許容されており、Gmailこの仕様を利用し、+以降に任意の文字列を追加することでエイリアスが利用できる。また、Gmailでは、+だけでなく、ローカルパート内のドット（.）でも無視されるため、実質エイリアスのような挙動にできる。

▼例

• ベースアドレス
• エイリアス
• ドットエイリアス
  • miraitaro@example.com
  • m.i.r.a.i.t.a.r.o@example.com

その他のサービスでのエイリアスの扱いをまとめる。

一般的に、エイリアスは以下の目的で使用される。

主な論点として、以下がある。

• エイリアスをサービスとして許容するかどうか
• 許容した場合、エイリアス付きメールアドレスを、ベースアドレスと同一のものとして扱うか、あるいは全くの別物として扱うかどうか

エイリアスに対して、サービスが選択する案をまとめる。

推奨は以下の通り。

• 基本方針は、（3）を選択する
  • 理由
    • 不正利用を防止でき、キャンペーン効果の適切な実施、計測ができるため
    • ユーザーがどのエイリアスを使ったか関係なくサービスを利用でき、ユーザーの混乱を防ぐことができるため
    • ヘルプデスクの、ログイン周りのヘルプ負荷を軽減できるため
    • 顧客データの分散を防ぎ、ユーザー分析の向上に寄与するため
• 正規化は以下の1～3の順番で処理する
  1. 正規化の対象外のアドレスを特定
     • Appleの「メールを非公開」機能で生成されたアドレス、Yahoo!メールの「セーフティアドレス」、そして日本の携帯キャリアのメールアドレスは、全て正規化の対象外とし、それぞれが一意のメールアドレスであるとして扱う
  2. Gmail特有のドットエイリアス (.) の正規化
     • @gmail.com と @googlemail.com のドメインに限り、@より前の部分のドット（.）を無視する正規化を適用する。これ以外のドメイン（独自ドメインなど）には、この正規化は実施しない
  3. その他は、プラスエイリアス (+) の正規化
     • a, b を除いたドメインに対して、+記号以降を無視する正規化を適用する。一部非対応のサービスが存在するリスクよりも、Gmail等の大多数のサービスからの不正利用を防ぐメリットが上回るという、リスクベースでの判断をしたいため
• 開発者体験として、ダミーデータ登録などで複数アドレスを登録したい場合は、設定ファイルなどにホワイトリスト方式で、エイリアスを許容する処理を加える
  1. ホワイトリストに該当するベースアドレスの場合は、正規化をスキップするなどの処理を加える

メールアドレス保存のためのテーブル設計 ​

システム設計の前提として、認証・認可の責務をAuth0やAmazon CognitoといったIDaaSに委任し、自前のログイン機構を作り込まないことを本ガイドラインの前提とする。つまり、ユーザーに関する情報の信頼できる唯一の情報源はIDaaSとなる。自社サービスのデータベースが保持するユーザー情報は、IDaaSが持つ情報の「キャッシュ」か「アプリケーション固有の追加情報」となる。メールアドレスの変更や追加、削除といったライフサイクル管理は、すべてIDaaS側で行われる。

推奨は以下の通り。

• 原則、メールアドレスを自システムで管理せず、必要があればIDaaSに依存した作りとする
• メールアドレスが必要な場合は、usersテーブルにemailカラムを追加し、IDaaSからの情報をキャッシュとして保持することを許容する
• IDaaSが提供するWebhookやイベント通知の仕組みを利用し、プロファイルの変更を自社サービスに同期させる

フェデレーテッドログイン ​

フェデレーテッドログイン（ソーシャルログイン）とは、ユーザーが普段から利用している第三者サービス（Google、Apple、Xなど）のアカウント情報を信頼し、その認証結果を利用して自社サービスにログイン・登録させる仕組みである。

主な論点として、以下がある。

• 既存アカウントとの紐付けをどうするか問題
  • user@example.com が既に会員登録済み。後から同じアドレスのGoogleアカウントで「Googleでログイン」でした場合、どう振る舞うべきか
• メールの再利用による「なりすまし」対策
  • ユーザーAが a@example.com を使って退会後にアドレスが解放、ユーザーBが同じアドレスを取得した場合。Bが「Googleでログイン」して、メールアドレスだけで自動紐付けすると、ユーザーAの購入履歴などがBに参照できてしまい、セキュリティインシデントに繋がる
• プロバイダー側でのアドレス変更によるログイン不可の対策
  • ユーザーがGoogle側でメールアドレスをa@gmail.comからb@gmail.comに変更した場合、Googleログインが不可になる懸念

対応方針としては以下が考えられる。

推奨は以下の通り。

• （3）を採用する
  • ユーザーの混乱を防ぎ、データ整合性を維持可能であるため。また、エイリアス 節の方針とも整合性があるため
  • なりすましリスクを低減でき、ユーザーにとっても意図しないアカウント連携を防ぐことができ親切である
  • 「Googleでログインする」の完了後、メールアドレスで識別するのでは無く、ID トークンの sub クレームから取得できるアカウントの ID をDBに登録して区別する
• （3）を採用した場合は、以下の対応を追加する
  • ユーザーがアカウント設定画面で、特定のソーシャルログインを任意で解除できる機能も提供する（ログイン手段がゼロにならないように、他の有効な認証方法が残っている場合のみ、解除可能にする）
  • Googleでログインせずとも、アカウント設定画面から「Googleアカウント連携」ができる手段も提供する

メール表現 ​

メール形式 ​

メールの形式は、歴史的背景から主に3つの種類が存在する。

1. プレーンテキストメール
   1. RFC 822などで定義された、文字情報のみで構成される形式で、文字の装飾や画像の挿入が不可
   2. 視覚的な訴求力は低いが、あらゆる環境で表示できる強みがある
2. リッチテキストメール
   1. Microsoft社のOutlookなどが独自に採用していた形式
   2. 太字や色付けなどの装飾が可能ですが、特定のメールソフトでしか正しく表示されない制約がある
3. HTMLメール
   1. HTMLとCSSを使って構成される形式
   2. セキュリティにより画像表示をOFFにしている端末や、HTMLメールをサポートしないフィーチャーフォン（ガラケー）などでは、表示崩れなどで可読性が低下するリスクがある

使い分けについては以下の案が考えられる。

推奨は以下の通り。

• 原則、（3）を選択する
  • 大多数のユーザーにはHTMLメールの表現力を利用でき、フィーチャーフォンなどごく一部のユーザーにも最低限の伝達を保証できるため
  • マルチパート配信は、SendGridやAmazon SESといった主要なESPが標準機能としてサポートしており、HTML・プレーンテキストの2つのコンテンツを用意するだけで良いため

HTMLメール ​

HTMLメールは豊かな表現力を持ちエンゲージメントを高めるために有効だが、Webページとは全く異なり、特有の知識と対応が求められる。HTMLメールの代表的な課題として、メールクライアントごとにHTMLとCSSを解釈・表示する「レンダリングエンジン」がバラバラで、しかもその多くが非常に古いことがある。ブラウザの世界では、標準技術への対応が進んでいるが、メールクライアントでは「断片化」がまだまだ残っており、表示崩れや意図しない表示の原因となっている。

近年、HTMLメール開発において最も注目すべき動きは、Microsoft社によるOutlookのレンダリングエンジンの刷新である。

しかし、多くの企業や買い切り版Officeでは、依然としてMicrosoft Wordをベースとした旧来の「クラシックOutlook」が利用され続けている。そのため、2025年現在は新旧のOutlookが混在する移行期であると推測される。Email Client Market Share and Popularity – Litmus によれば、2025年7月時点で、Outlookのシェアは7％である。新旧の比率は不明であるが、相当数が存在するであろうクラシック版のサポートを切り捨てる判断は、難しいと考えられる。

主要サービスのHTML・CSSサポート概況を下表にまとめる。

推奨は以下の通り。

• 原則、レイアウトは保守的なCSSで組み、装飾用のCSSは動かなくても視認性は保つことが可能な、2段階アプローチを採用する
• 1段階目のCSSは、以下の実装ルールに則る