知識マップ: 中小企業向けの一斉メール配信を、特定サービスに縛られず設計する方法

記事「中小企業向けの一斉メール配信を、特定サービスに縛られず設計する方法」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

中小企業が特定のメルマガサービスに頼らず一斉メールを送るには、Bcc一斉送信ではなく、購読者テーブル・抑止テーブル・配信キューからなる配信基盤を自社側に持ち、SMTPリレーという出口だけを差し替えられる構成にするのが現実的です。抑止テーブルは配信停止やバウンスを購読者テーブルより優先させ、配信キューはそこからSMTPリレーへ送信を渡します。送信ドメインはSPF・DKIM・DMARCで認証し、逆引きPTRやList-Unsubscribeを備えることで、GoogleやYahooが求める苦情率の基準を満たせます。特定電子メール法はopt-inの事前同意と送信者の表示義務を課しており、listmonkのようなOSSはこの構造をそのままセルフホストで実装しています。

flowchart LR
    accTitle: 一斉メール配信基盤の知識マップ
    accDescr: Bcc一斉送信の限界、購読者テーブル・抑止テーブル・配信キューからなる自社設計の配信基盤、SMTPリレーの出口選び、SPF・DKIM・DMARCによる送信ドメイン認証、opt-inや表示義務などの法令要件がどう関係するかを示す図
    bulk_email_infrastructure["自社設計の配信基盤(購読者テーブル・抑止テーブル・配信キュー)"]
    individual_send["宛先ごとの個別送信"]
    subscriber_table["購読者テーブル"]
    suppression_table["抑止テーブル"]
    delivery_queue["配信キュー"]
    bcc_mass_send["Bcc一斉送信"]
    smtp_relay["SMTPリレー"]
    m365_smtp_methods["Microsoft 365のSMTP送信方式(4方式)"]
    spf["SPF(Sender Policy Framework)"]
    dmarc["DMARC"]
    dkim["DKIM(DomainKeys Identified Mail)"]
    reverse_dns_ptr["逆引きPTR"]
    list_unsubscribe_header["List-Unsubscribeヘッダ/ワンクリック配信停止"]
    tokutei_email_law["特定電子メール法"]
    opt_in_consent["opt-in(事前同意)"]
    sender_display_obligation["送信者の表示義務"]
    spam_rate["苦情率(spam rate)"]
    listmonk_oss["listmonk"]
    bulk_email_infrastructure -->|"利用する"| subscriber_table
    bulk_email_infrastructure -->|"利用する"| suppression_table
    bulk_email_infrastructure -->|"利用する"| delivery_queue
    bcc_mass_send -->|"用いるのは非推奨"| bulk_email_infrastructure
    individual_send -->|"推奨される対応"| bulk_email_infrastructure
    delivery_queue -->|"前提とする"| subscriber_table
    delivery_queue -->|"前提とする"| suppression_table
    delivery_queue -->|"利用する"| smtp_relay
    smtp_relay -.->|"で構成できる"| m365_smtp_methods
    smtp_relay -.->|"前提とする"| spf
    dmarc -.->|"前提とする"| spf
    dmarc -.->|"前提とする"| dkim
    smtp_relay -.->|"前提とする"| reverse_dns_ptr
    list_unsubscribe_header -->|"推奨される対応"| bulk_email_infrastructure
    tokutei_email_law -.->|"前提とする"| opt_in_consent
    tokutei_email_law -->|"前提とする"| sender_display_obligation
    suppression_table -.->|"軽減する"| spam_rate
    list_unsubscribe_header -.->|"軽減する"| spam_rate
    listmonk_oss -->|"実装を担う"| bulk_email_infrastructure
    individual_send -->|"前提とする"| subscriber_table
    bcc_mass_send -.->|"両立しない"| suppression_table
    opt_in_consent -->|"推奨される対応"| bulk_email_infrastructure

概念間の関係(全22件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• 自社設計の配信基盤(購読者テーブル・抑止テーブル・配信キュー)は購読者テーブルを利用します。配信基盤は、メールアドレス・同意日時・配信停止状態などを持つ購読者テーブルを土台にする。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 自社設計の配信基盤(購読者テーブル・抑止テーブル・配信キュー)は抑止テーブルを利用します。配信基盤は、配信停止・bounce・苦情を記録し購読者テーブルより優先させる抑止テーブルを土台にする。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 自社設計の配信基盤(購読者テーブル・抑止テーブル・配信キュー)は配信キューを利用します。配信基盤の中心は、購読者テーブル・抑止テーブル・配信テンプレートを入力に持つ配信キューである。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Bcc一斉送信を自社設計の配信基盤(購読者テーブル・抑止テーブル・配信キュー)に用いることは推奨されません。Bcc一斉送信は配信停止・バウンス管理・同意記録・送信速度制御を持てないため、外部向け継続配信の配信基盤としては推奨されない。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 宛先ごとの個別送信は自社設計の配信基盤(購読者テーブル・抑止テーブル・配信キュー)に対する本記事の推奨です。宛先ごとの個別送信は、自社設計の配信基盤における本記事の推奨方式である。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 配信キューは購読者テーブルを前提とします。配信キューは誰に送るかを購読者テーブルから得る。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 配信キューは抑止テーブルを前提とします。配信キューは送ってはいけない相手を抑止テーブルで除外する。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 配信キューはSMTPリレーを利用します。配信キューは実際の送信をSMTPリレーへ渡す。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• SMTPリレーはMicrosoft 365のSMTP送信方式(4方式)で構成できます。Microsoft 365を出口にする場合、認証付きClient SMTP submission・SMTP relay・Direct Send・High Volume Emailの4方式のいずれかで構成する。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• SMTPリレーはSPF(Sender Policy Framework)を前提とします。SMTPリレーの送信ドメインは、送ってよい送信元をSPFレコードで宣言している必要がある(GoogleはPTR・TLSに加え全送信者にSPFまたはDKIMのいずれか一方を求めており、SPFはその唯一の選択肢ではない。ただし大量送信者ではSPF・DKIM・DMARCすべてが求められる)。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• DMARCはSPF(Sender Policy Framework)を前提とします。DMARCはSPFの認証結果とFromドメインとの整合を参照する(DMARCはSPFアライメントまたはDKIMアライメントのいずれかが通ればパスするため、DKIM側で整合していればSPF側の整合は必須ではない)。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• DMARCはDKIM(DomainKeys Identified Mail)を前提とします。DMARCはDKIMの認証結果とFromドメインとの整合も参照する(DMARCはSPFアライメントまたはDKIMアライメントのいずれかが通ればパスするため、SPF側で整合していればDKIM側の整合は必須ではない)。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• SMTPリレーは逆引きPTRを前提とします。インターネット宛てに自前の送信サーバーから直接配信する場合、受信側の受け入れ要件として正引き・逆引きが整合する固定的な環境が求められる。社内向けの中継や、出口IPとPTRを提供事業者が持つマネージドリレーでは当てはまらない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• List-Unsubscribeヘッダ/ワンクリック配信停止は自社設計の配信基盤(購読者テーブル・抑止テーブル・配信キュー)に対する本記事の推奨です。本文内の見えるリンクに加え、List-Unsubscribeとワンクリック配信停止の実装が配信基盤に推奨される。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 特定電子メール法はopt-in(事前同意)を前提とします。広告・宣伝メールは、特定電子メール法上、原則として事前同意が必要とされる(ホームページ等で公表されている事業用アドレスへの送信には例外規定があり、この場合は事前同意は必須ではない)。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 特定電子メール法は送信者の表示義務を前提とします。特定電子メール法は、送信者の氏名・住所や受信拒否の通知先などの表示を送信者に義務付ける。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 抑止テーブルは苦情率(spam rate)を軽減します。停止済み・bounce済みへの再送を抑止テーブルで防ぐことで、苦情率の悪化を抑えられる。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• List-Unsubscribeヘッダ/ワンクリック配信停止は苦情率(spam rate)を軽減します。配信停止をしやすくすることは、受信者が迷惑メール報告に頼る前に離脱できる経路を用意することになり、苦情率を抑えることにつながる。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• listmonkは自社設計の配信基盤(購読者テーブル・抑止テーブル・配信キュー)の実装を担います。listmonkは、opt-inの購読者リスト管理・配信実績とバウンスの集計・複数SMTPのキューという、この記事と同じ構造をセルフホストで実装するOSSである。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 宛先ごとの個別送信は購読者テーブルを前提とします。宛先ごとの個別送信を行うには、宛先ごとの状態を持つ購読者テーブルが前提になる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Bcc一斉送信は抑止テーブルと両立しません。Bccでの一括送信は宛先ごとの送信結果を扱わないため、その送信で生じた配信停止・bounceを抑止テーブルへ個別に反映できない。抑止テーブルを送信前のフィルタとして参照するだけなら可能だが、結果を書き戻す双方向の運用としては成立しない。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• opt-in(事前同意)は自社設計の配信基盤(購読者テーブル・抑止テーブル・配信キュー)に対する本記事の推奨です。GoogleもYahooも、購入リストを使わずopt-inのみで集めたリストで配信することを求めている。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

自社設計の配信基盤(購読者テーブル・抑止テーブル・配信キュー)

購読者データ・配信ルール・送信者アイデンティティを自社側で持ち、SMTPリレーという出口だけを差し替えられるようにした一斉メール配信の仕組み。

宛先ごとの個別送信

Bccでまとめて送るのではなく、1通ずつ宛先を分けて送信する方式。

Bcc一斉送信

多数の宛先をBccにまとめて入れて1通で送る、配信停止・バウンス管理・同意記録などの状態管理を持てない送信方法。

配信キュー

購読者テーブル・抑止テーブル・配信テンプレートを入力に、宛先ごとの送信状態と送信結果を管理する配信基盤の中心部分。

SMTPリレー

配信基盤から実際にインターネットへメールを投げてもらう出口。既存メール基盤・自前サーバーなど後から差し替え可能な部分。

DMARC

SPFやDKIMの成否だけでなく、それらの認証済みドメインがFrom:ドメインと整合しているかを見て、受信メールの扱いを判定する仕組み。

List-Unsubscribeヘッダ/ワンクリック配信停止

メールのヘッダに配信停止先を記述し、確認画面なしで購読解除できるようにする仕組み。

特定電子メール法

広告・宣伝メールの送信について、事前同意や表示義務などを定める日本の法律。

抑止テーブル

配信停止・hard bounce・苦情など、送ってはいけない宛先を記録し、購読者テーブルより優先して参照されるテーブル。

listmonk

AGPLv3のセルフホスト型ニュースレター配信ソフト。opt-inの購読者リスト管理、配信実績・バウンスの集計、複数SMTPを使うキューを備える。

opt-in(事前同意)

受信者が自分の意思で購読を申し込んでいる状態。名刺やリスト購入で集めただけの宛先は含まれない。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。