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

「専用のメルマガ配信サービスを新しく増やさずに、既存のドメインやサイトを使って数十〜数百件の案内メールを送りたい」。 この相談に対する現実的な答えは、Bcc 一発 ではなく、宛先ごとの個別送信、購読管理、配信停止、SPF / DKIM / DMARC を揃えた小さな配信基盤にすることです。

ここでいう「特定のサービスを使わない」は、「何も使わない」ではありません。 SMTP という標準、購読者リスト、テンプレート、配信停止導線を自社側で持ち、送信手段だけは後から差し替えられる構成にする、という意味です。

また、この記事では 既存顧客、会員、資料請求者、ニュースレター購読者のように、何らかの関係や同意がある相手へ送るメール を前提にします。 公開アドレスを集めて無差別に送る話ではありません。広告・宣伝メールには法的な前提がありますし、配信品質の面でもそのやり方は長く持ちません。¹²

以下は、2026 年 4 月時点で確認できる日本の特定電子メール法まわりの公的情報と、Google / Yahoo / Outlook の送信者ガイドラインを前提にした整理です。¹²³⁴⁵

この記事の対象読者と前提

この記事で使う略語

第 2 章以降で説明なしに出てくる言葉を、先にまとめておきます。

1. まず結論

中小企業が外部向けの一斉メールで現実的に取るべき形は、だいたい次の 4 点です。

1. 宛先ごとに個別送信する Bcc にまとめて入れるのではなく、1 通ずつ送る前提でキューを切ります。
2. 購読状態を自社で持つ active、unsubscribed、bounced のような状態管理を、自社の DB や CSV ではっきり持ちます。
3. 配信停止を自動で受け付ける 「もう送らないでください」を手作業で処理する運用にしません。本文内の見えるリンクと、可能なら List-Unsubscribe を入れます。³⁴⁵
4. 送信ドメインを認証する SPF / DKIM / DMARC、逆引き PTR、TLS を揃えます。送れたとしても、これがないと届きにくくなります。³⁴⁵

要するに、メールソフトの操作の問題ではなく、配信基盤の問題 です。

「一斉に送りたい」という要件を、To / Cc / Bcc にたくさん並べること だと考えると崩れます。 実際に必要になるのは、こういう仕組みです。

• 誰に送ってよいか
• もう送ってはいけない相手は誰か
• 何の目的で同意を取ったか
• 配信停止をどう受けるか
• 送信元として信用される設定になっているか

この記事の知識マップ

中小企業が特定のメルマガサービスに頼らず一斉メールを送るには、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件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. なぜ Bcc 一発送信 では足りないのか

外部向けの一斉送信で Bcc がつらいのは、見た目が簡単なわりに、運用上の本体を何も持てないからです。

特に危ないのは、「送ること」はできるので、仕組みとして成立しているように見える ことです。 でも実際には、送信停止、バウンス抑止、同意記録、送信ログがない状態なので、人数が少し増えた瞬間に人手運用が破綻します。

Bcc が完全に悪いわけではありません。 社内連絡、閉じた会員へのごく小規模な案内、単発の関係者連絡なら成立することもあります。 ただし、外部の顧客や見込み客へ継続的に送る仕組みの土台 としては弱い、という話です。

3. 「特定のサービスを使わない」の現実的な意味

ここで誤解しやすいのは、「特定のサービスを使わない」=「全部手でやる」ではないことです。

実務では、この 3 つを自社側で持てていれば、かなりベンダーロックインを避けられます。

3.1 自社が持つべきもの

• 購読者データ
  • メールアドレス
  • 同意日時
  • 同意取得元
  • 配信カテゴリ
  • 配信停止状態
• 配信ルール
  • 何を誰に送るか
  • どの速度で送るか
  • バウンスや配信停止をどう反映するか
• 送信者アイデンティティ
  • 送信ドメイン
  • SPF / DKIM / DMARC
  • 返信を受けるメールアドレス
  • 配信停止 URL

3.2 差し替えてよいもの

• 実際に投げる SMTP リレー
• 管理画面の実装方法
• 送信キューの実装場所
• ログの保管先

つまり、「サービスを使わない」ことの本質は、送信のルールと状態を相手側に預け切らないこと です。

• 宛先リストは自社 DB にある
• 配信停止 URL は自社ドメイン配下にある
• 件名と本文テンプレートは自社で持つ
• SMTP の出口だけは後から差し替えられる

この形なら、最初は既存のメール基盤を使い、後から別の送信手段へ移ることもできます。

4. 中小企業向けの現実的な構成

4.1 最低限の部品

数十〜数百件/回くらいなら、最初から大げさな仕組みは不要です。 ただし、最低限このくらいは分けて持つほうが安定します。

1. 購読者テーブル
2. 抑止テーブル
   • 配信停止
   • hard bounce
   • 苦情
3. 配信テンプレート
   • 件名
   • 本文（HTML / text）
   • 配信カテゴリ
4. 配信キュー
   • 宛先ごとの状態
   • 送信結果
   • 再試行回数
5. SMTP リレー
   • 既存メール基盤を使うか
   • 自前サーバーを使うか
6. ログ
   • いつ誰に投げたか
   • 成功 / 失敗
   • 停止 / bounce 反映

開封率やクリック率の高度な計測は、最初から必須ではありません。 まず必要なのは、安全に送り、止められ、説明できること です。

4.2 配信対象テーブルで持つ項目

最低限の項目はこのあたりです。

もし最初のマスタが Excel や既存顧客台帳でも、ここまでは分けて持ったほうがよいです。 特に重要なのは、抑止情報が常に優先されること です。

たとえば、営業台帳にその人のアドレスが残っていても、抑止テーブルで unsubscribed なら送らない。 このルールがないと、配信停止後に別経路から再混入して事故ります。

4.3 構成図

flowchart LR
    A[ホームページ / 購読フォーム] --> B[購読者テーブル]
    A2[既存顧客台帳 / 会員台帳] --> B

    C[配信テンプレート<br/>件名 / HTML / text] --> D[配信キュー]
    B --> D
    E[抑止テーブル<br/>配信停止 / bounce / complaint] --> D

    D --> F[SMTP リレー<br/>既存メール基盤 or 自前リレー]
    F --> G[受信者]

    G --> H[配信停止 URL]
    G --> I[返信]
    G --> J[バウンス / 苦情]

    H --> E
    J --> E
    I --> K[運用窓口]

    L[SPF / DKIM / DMARC / PTR / TLS] --> F

図が表示されない環境のために、同じ内容を文章でも書いておきます。

• 入口: ホームページの購読フォームと、既存顧客台帳・会員台帳。どちらも 購読者テーブル に集めます。
• 中心: 配信キュー に、購読者テーブル（誰に送るか）、抑止テーブル（送ってはいけない相手）、配信テンプレート（件名・HTML・text）の 3 つが入ります。
• 出口: 配信キューから SMTP リレー（既存メール基盤か自前リレー）へ渡し、そこから受信者へ届きます。SMTP リレーには SPF / DKIM / DMARC / PTR / TLS の設定がぶら下がります。
• 戻り: 受信者からは 3 方向の反応が返ります。配信停止 URL とバウンス・苦情は 抑止テーブル へ戻し、返信は運用窓口の人が受けます。

この図のポイントは、送信手段が中心ではない ことです。 中心は 購読者テーブル と 抑止テーブル と 配信キュー です。

SMTP リレーは出口にすぎません。 ここが分かれていると、将来送信手段を切り替えても、過去の配信停止や同意履歴を失わずに済みます。

4.4 出口と配信エンジンの選び方

「自社で持つもの」と「差し替えてよいもの」を分けたあと、実際に手を動かす段になると、次に調べるのはこの 2 つです。

1. 出口（SMTP リレー）をどれにするか

すでに使っているメール基盤をそのまま出口にできることが多いです。たとえば Microsoft 365 の場合、メールボックスを持たない装置やアプリから送るための方式が公式に整理されており、認証付きの Client SMTP submission、コネクタを使う SMTP relay、認証なしの Direct Send、社内宛て大量送信向けの High Volume Email の 4 つが、送信上限や必要な TLS・ポートとあわせて比較されています。¹⁰ オンプレのメールサーバー（Exchange Server など）がある場合は、そちらでリレーを受けるほうが構成しやすい、とも案内されています。¹⁰

選ぶときに見るのは、だいたいこの 4 点です。

2. 配信エンジンを作るか、既存の OSS に載せるか

購読者テーブル、抑止テーブル、配信キュー、配信停止ページを全部自作するのは、意外と手間です。同じ構造を持つセルフホスト型の OSS があるので、まずそれで足りるかを見るのが早道です。 たとえば listmonk は、AGPLv3 のセルフホスト型ニュースレター配信ソフトで、シングル / ダブル opt-in の購読者リスト管理、キャンペーンの配信実績とバウンスの集計、複数 SMTP を使うキューを備えています。¹¹

判断の目安はこうなります。

いずれの場合も、購読者データ・抑止データ・配信停止 URL を自社側に残すという原則は変わりません。ここさえ守れていれば、出口も配信エンジンも後から入れ替えられます。

5. 規模別にどこまで作るか

5.1 月 1 回・数十件

この規模なら、最小構成で十分なことが多いです。

• 送信専用の差し込みテンプレート
• 宛先ごとの個別送信
• 配信停止 URL
• 送信ログの保存
• SPF / DKIM / DMARC の整備

ここでのポイントは、人数が少なくても Bcc に戻らないこと です。 50 件以下でも、外部向けの継続配信なら、もう 個別送信 + 状態管理 の形にしておいたほうが後で楽です。

5.2 月数回・数百件

この段階に来たら、いくつか足したほうが安定します。

• 配信キュー
• 配信速度の制御
• バウンス反映
• 配信停止の即時反映
• 送信専用サブドメイン
• 承認フロー
  • テスト送信
  • 本番送信
  • 結果確認

また、日常の人間メールと販促・案内メールを分ける のが大切です。 Google はメッセージ種別ごとに From アドレスや IP を分ける考え方を示しており、Yahoo も bulk / marketing と transactional / alerts を同じ IP や DKIM ドメインに混ぜないことを案内しています。³⁴

たとえば、用途ごとにアドレスを分けるだけでも運用がかなり整理されます。³⁴⁵

• 受注確認・請求系: billing@example.com
• 障害通知・メンテ情報: notice@example.com
• ニュースレター・案内: news@example.com

5.3 1 日数千件に近づくなら

ここまで来ると、「特定のサービスを使わない」こと自体が目的化しやすくなります。

Google は Gmail 向けに 1 日 5,000 通超 の送信者へ、SPF / DKIM / DMARC、From ドメインの整合、ワンクリック配信停止などの要件を明示しています。 Outlook も 1 日 5,000 通超 のドメインに SPF / DKIM / DMARC を要求し、要件を満たさないメッセージは迷惑メール送りや拒否対象になり得ると案内しています。³⁵

この規模になると、運用の主題も変わってきます。

• IP 評判
• 苦情率
• バウンス率
• 配信停止処理
• ボリュームの増やし方
• 監視

この段階なら、専用サービスを使うほうが安い 場面も多いです。

つまり、この記事の結論は「どれだけの規模でも全部自前にするべき」ではなく、 数十〜数百件規模なら、状態とルールを自社で持った小さな配信基盤がちょうどよい です。

6. 法務と配信品質で最低限外せないこと

6.1 同意

広告・宣伝メールは、原則として事前同意が必要です。 迷惑メール相談センターの整理でも、事前承諾なしに広告宣伝メールを送ることは原則不可とされています。²

また、Google も Yahoo も、受信者が明示的に望んだメールだけを送ること、購入リストを使わないこと、自動チェック済みの opt-in を避けることを求めています。³⁴

実務で最低限残したいのは、このあたりです。

• 同意日時
• 同意取得元
• 何の配信か
• 説明文面
• 同意を取った画面または文面

なお、法律上は、ホームページで公表されている事業用アドレスへの送信に例外規定があります。 ただし、その例外に頼って配信基盤を作るのはおすすめしません。 クレーム、到達率、評判、実際の反応率のどれを見ても、長く持ちにくいからです。²

6.2 表示義務と配信停止

同意がある相手へ送る場合でも、送信者には表示義務があります。 迷惑メール相談センターの整理では、少なくとも次の情報が必要です。²

• 送信者などの氏名または名称
• 受信拒否通知を受けるメールアドレスまたは URL
• 受信拒否できる旨
• 送信者などの住所
• 苦情・問い合わせ先

つまり、フッターに最低限これが必要です。

送信者: 株式会社○○
配信停止: https://example.com/unsubscribe/xxxxx
受信停止をご希望の場合は、上記 URL からお手続きください。
住所: 東京都...
お問い合わせ: support@example.com

さらに、主要な受信側は配信停止のしやすさをかなり重視しています。

• Google: 大量送信者ではワンクリック unsubscribe を要求³
• Yahoo: List-Unsubscribe と本文内リンク、2 日以内の反映を要求 / 推奨⁴
• Outlook: 見つけやすく機能する unsubscribe を推奨⁵

なので、最低でも本文内に見えるリンク、可能なら次のヘッダを入れるのが自然です。³⁴

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/xxxxx>

6.3 認証と到達率

主要な受信側は、すでに「送れること」ではなく「認証されていること」を前提にしています。

Google の公開ガイドラインでは、次が求められています。³

• 全送信者: SPF または DKIM、PTR（正引き / 逆引き整合）、TLS
• 大量送信者: SPF + DKIM + DMARC、From ドメインの整合
• 低い spam rate
• 大量送信者では one-click unsubscribe

Yahoo の要件はこうです。⁴

• SPF / DKIM / DMARC
• DMARC alignment
• valid forward / reverse DNS
• unsubscribe
• spam rate 0.3% 未満
• opt-in
• bulk と transactional の分離

Outlook も高ボリューム送信者向けの要件を出しています。⁵

• SPF pass
• DKIM pass
• DMARC（少なくとも p=none、SPF または DKIM と整合）
• 本物の From / Reply-To
• unsubscribe
• list hygiene

最低限の運用チェックを表にするとこうなります。

Google は、送信量を増やすときは 低いボリュームから、反応の良い相手に、一定ペースで 始めることを勧めています。 突然のスパイクや一気に倍増する送り方は、制限や reputation 低下の原因になりやすいです。³

7. 実装の進め方

最小で始めるなら、順番はこのくらいが現実的です。

1. 送るメールの種類を分ける
   • 通知メール
   • ニュースレター
   • セミナー案内
   • 既存顧客向け案内
2. 購読フォームか同意取得フローを作る ホームページ上で説明文と一緒に取得できるようにします。 「何が、どの頻度で届くか」が分かる文面にするのが大切です。⁴
3. 購読者テーブルと抑止テーブルを分ける ここを最初に分けておくと、後から何に乗り換えても運用が崩れません。
4. 送信専用のドメイン / サブドメインを決める たとえば news.example.com や mail.example.com です。 少なくとも、日常の受発注や個人メールボックスと責務を混ぜないことです。³⁴
5. SPF / DKIM / DMARC / PTR / TLS を整える 自前送信ならここが最優先です。 逆引きが取れない環境を、送信基盤にしないことです。³⁴
6. 管理画面は小さくてよいので作る 必要なのは豪華な UI ではなく、次の機能です。
   • 件名編集
   • 本文編集
   • テスト送信
   • 本番送信
   • 配信対象プレビュー
   • バッチサイズ設定
   • 結果確認
7. 最初は少量から送る 既存顧客や反応の良い購読者に絞り、一定ペースで出します。 問題がなければ対象を広げます。³
8. 配信停止と bounce を最優先で反映する 開封率より前に、ここが動くことを確認します。

この順番にすると、「とりあえず送れる」ではなく「事故らずに続けられる」 形に持っていけます。

7.1 次に調べるべきキーワード

社内で調べたり、業者に相談したりするときに、そのまま検索語として使える言葉を段階別に並べておきます。

このうち最初に手を付けるのは認証の設定です。ここが済んでいないと、以降の作業をどれだけ丁寧にやっても届きません。

購読フォーム、同意文面、配信停止ページの設計まで含めて見直すなら、ホームページ制作 と一緒に整理すると進めやすいです。 一方で、既存顧客台帳や社内システム、Windows ツールとつなぐ前提なら、技術相談・設計レビュー で責務分割から詰めるほうが安全です。

8. よくある失敗

ありがちなのは、このあたりです。

• 人間の通常メールと販促・案内メールを同じ送信元で回す
• 同意を free text のメモだけで管理する
• 配信停止をメール返信の手作業にする
• 古い名刺リストをまとめて流し込む
• 突然、過去最大ボリュームで送り始める
• 通知メールに販促文面を混ぜる
• 送信結果を「送信 API が成功した」で止める
• 既存顧客台帳より抑止テーブルが弱い

特に最後は本当に事故りやすいです。

営業側の Excel にアドレスが残っている。 でも、その人はニュースレターを停止済み。 このとき、停止情報が常に勝つ ルールにしていないと、別経路から何度でも再送されます。

9. まとめ

中小企業が、特定のサービスを使わずにそこそこ多い人数へメールを送りたいなら、考えるべきは「どのボタンを押すか」ではありません。

本当に必要なのは、次の 5 点です。

• Bcc 一発 ではなく 宛先ごとの個別送信
• 購読者テーブル と 抑止テーブル
• 配信停止を自動で受ける導線
• SPF / DKIM / DMARC / PTR / TLS
• 通知系と販促系を分ける運用

結局のところ、送信手段を持つことより、送信ルールを持つことが先 です。

数十〜数百件/回くらいなら、専用サービスなしでも十分回せます。 ただしその場合でも、「メールソフトでまとめて送る」のではなく、小さな配信基盤として設計する のが近道です。

関連記事

• 問い合わせが来ないサイトで、先に直すべき3つの場所
• 記事とサービスページをどうつなぐか - 内部リンク設計の基本

参考資料

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

案内メールをBccでまとめて一斉送信してはいけないのですか？

外部の顧客や見込み客へ継続的に送る仕組みの土台としては弱いです。Bccは送ること自体はできますが、配信停止が追えない、バウンス管理がない、同意の記録がない、送信速度を制御できない、担当者依存になる、という運用上の本体を何も持てません。人数が少し増えた瞬間に人手運用が破綻します。社内連絡や単発の関係者連絡なら成立することもありますが、外部向けの継続配信なら宛先ごとの個別送信と状態管理の形にすべきです。

広告・案内メールを送るのに同意は必要ですか？

広告・宣伝メールは原則として事前同意が必要です。迷惑メール相談センターの整理でも、事前承諾なしに広告宣伝メールを送ることは原則不可とされています。GoogleもYahooも、受信者が明示的に望んだメールだけを送ること、購入リストを使わないことを求めています。実務では、同意日時、同意取得元、何の配信か、説明文面を記録として残すべきです。ホームページで公表されている事業用アドレスへの例外規定はありますが、それに頼った配信基盤はおすすめしません。

メールが迷惑メール判定されないために最低限何が必要ですか？

送信ドメインの認証です。具体的には、SPF/DKIM/DMARCの設定、逆引きPTRが取れる送信環境、TLS、実在して返信を受けられるFrom/Reply-To、本文内の配信停止リンクとList-Unsubscribeヘッダ、opt-inのみのリスト品質です。GoogleはGmail向けに1日5,000通超の送信者へSPF+DKIM+DMARCとワンクリック配信停止を要求し、Yahooはspam rate 0.3%未満などを求めています。また、送信量を増やすときは低いボリュームから一定ペースで始めるべきです。

メルマガ配信サービスを使わずに自社で配信基盤を作れますか？

数十〜数百件/回の規模なら十分可能です。ポイントは、購読者データ、配信ルール、送信者アイデンティティ(ドメイン・認証・配信停止URL)を自社側で持ち、SMTPリレーという出口だけを後から差し替えられる構成にすることです。中心はSMTPではなく、購読者テーブル・抑止テーブル・配信キューです。ただし1日数千件に近づくと、IP評判や苦情率の管理が主題になるため、専用サービスを使うほうが安い場面も多くなります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。