自社設計の配信基盤(購読者テーブル・抑止テーブル・配信キュー)
購読者データ・配信ルール・送信者アイデンティティを自社側で持ち、SMTPリレーという出口だけを差し替えられるようにした一斉メール配信の仕組み。
一斉メール配信基盤
配信基盤
宛先ごとの個別送信
Bccでまとめて送るのではなく、1通ずつ宛先を分けて送信する方式。
購読者テーブル
メールアドレス・同意日時・同意取得元・配信カテゴリ・配信停止状態などを持つ、送信対象の状態管理テーブル。
抑止テーブル
配信停止・hard bounce・苦情など、送ってはいけない宛先を記録し、購読者テーブルより優先して参照されるテーブル。
抑止リスト
配信キュー
購読者テーブル・抑止テーブル・配信テンプレートを入力に、宛先ごとの送信状態と送信結果を管理する配信基盤の中心部分。
Bcc一斉送信
多数の宛先をBccにまとめて入れて1通で送る、配信停止・バウンス管理・同意記録などの状態管理を持てない送信方法。
Bcc一発送信
SMTPリレー
配信基盤から実際にインターネットへメールを投げてもらう出口。既存メール基盤・自前サーバーなど後から差し替え可能な部分。
送信の出口
Microsoft 365のSMTP送信方式(4方式)
メールボックスを持たない装置・アプリからMicrosoft 365経由で送信するための、認証付きClient SMTP submission・コネクタ利用のSMTP relay・認証なしDirect Send・High Volume Emailの4方式。
SPF(Sender Policy Framework)
SMTPセッション中のMAIL FROM(エンベロープ送信者)が、そのドメインの送信元として許可されたIPかをDNSのTXTレコードで検証する仕組み。
DMARC
SPFやDKIMの成否だけでなく、それらの認証済みドメインがFrom:ドメインと整合しているかを見て、受信メールの扱いを判定する仕組み。
Domain-based Message Authentication, Reporting, and Conformance
DKIM(DomainKeys Identified Mail)
メッセージの一部ヘッダと本文に署名を付け、受信側がDNSの公開鍵で検証する認証方式。署名ドメインはDKIM-Signatureのd=で表される。
逆引きPTR
送信元IPアドレスからホスト名を引ける状態にする逆引きDNSレコード。主要な受信側が送信者の信頼性の判断材料にする。
PTRレコード
List-Unsubscribeヘッダ/ワンクリック配信停止
メールのヘッダに配信停止先を記述し、確認画面なしで購読解除できるようにする仕組み。
特定電子メール法
広告・宣伝メールの送信について、事前同意や表示義務などを定める日本の法律。
特定電子メールの送信の適正化等に関する法律
opt-in(事前同意)
受信者が自分の意思で購読を申し込んでいる状態。名刺やリスト購入で集めただけの宛先は含まれない。
送信者の表示義務
送信者などの氏名・住所、受信拒否を受けるアドレスやURL、受信拒否できる旨、苦情・問い合わせ先などをメールに表示する法律上の義務。
苦情率(spam rate)
受信者が「迷惑メール」ボタンを押した割合。主要な受信側が送信者の評判を判断する指標。
listmonk
AGPLv3のセルフホスト型ニュースレター配信ソフト。opt-inの購読者リスト管理、配信実績・バウンスの集計、複数SMTPを使うキューを備える。
配信基盤は、メールアドレス・同意日時・配信停止状態などを持つ購読者テーブルを土台にする。
配信基盤は、配信停止・bounce・苦情を記録し購読者テーブルより優先させる抑止テーブルを土台にする。
配信基盤の中心は、購読者テーブル・抑止テーブル・配信テンプレートを入力に持つ配信キューである。
Bcc一斉送信は配信停止・バウンス管理・同意記録・送信速度制御を持てないため、外部向け継続配信の配信基盤としては推奨されない。
宛先ごとの個別送信は、自社設計の配信基盤における本記事の推奨方式である。
配信キューは誰に送るかを購読者テーブルから得る。
配信キューは送ってはいけない相手を抑止テーブルで除外する。
配信キューは実際の送信をSMTPリレーへ渡す。
Microsoft 365を出口にする場合、認証付きClient SMTP submission・SMTP relay・Direct Send・High Volume Emailの4方式のいずれかで構成する。
SMTPリレーの送信ドメインは、送ってよい送信元をSPFレコードで宣言している必要がある(GoogleはPTR・TLSに加え全送信者にSPFまたはDKIMのいずれか一方を求めており、SPFはその唯一の選択肢ではない。ただし大量送信者ではSPF・DKIM・DMARCすべてが求められる)。
DMARCはSPFの認証結果とFromドメインとの整合を参照する(DMARCはSPFアライメントまたはDKIMアライメントのいずれかが通ればパスするため、DKIM側で整合していればSPF側の整合は必須ではない)。
DMARCはDKIMの認証結果とFromドメインとの整合も参照する(DMARCはSPFアライメントまたはDKIMアライメントのいずれかが通ればパスするため、SPF側で整合していればDKIM側の整合は必須ではない)。
インターネット宛てに自前の送信サーバーから直接配信する場合、受信側の受け入れ要件として正引き・逆引きが整合する固定的な環境が求められる。社内向けの中継や、出口IPとPTRを提供事業者が持つマネージドリレーでは当てはまらない
本文内の見えるリンクに加え、List-Unsubscribeとワンクリック配信停止の実装が配信基盤に推奨される。
広告・宣伝メールは、特定電子メール法上、原則として事前同意が必要とされる(ホームページ等で公表されている事業用アドレスへの送信には例外規定があり、この場合は事前同意は必須ではない)。
特定電子メール法は、送信者の氏名・住所や受信拒否の通知先などの表示を送信者に義務付ける。
停止済み・bounce済みへの再送を抑止テーブルで防ぐことで、苦情率の悪化を抑えられる。
配信停止をしやすくすることは、受信者が迷惑メール報告に頼る前に離脱できる経路を用意することになり、苦情率を抑えることにつながる。
listmonkは、opt-inの購読者リスト管理・配信実績とバウンスの集計・複数SMTPのキューという、この記事と同じ構造をセルフホストで実装するOSSである。
宛先ごとの個別送信を行うには、宛先ごとの状態を持つ購読者テーブルが前提になる。
Bccでの一括送信は宛先ごとの送信結果を扱わないため、その送信で生じた配信停止・bounceを抑止テーブルへ個別に反映できない。抑止テーブルを送信前のフィルタとして参照するだけなら可能だが、結果を書き戻す双方向の運用としては成立しない。
GoogleもYahooも、購入リストを使わずopt-inのみで集めたリストで配信することを求めている。