メール配信システムの自作・構築とは？SMTP基盤設計と到達率確保の実装手順

メール配信システムの自作・構築とは、PostfixなどのMTA（メール転送エージェント）と配信管理プログラムを自社で組み上げ、大量配信の基盤を自前で運用することを指します。2024年2月に適用が始まったGmailの送信者ガイドライン以降、SPF・DKIM・DMARCの送信ドメイン認証を整えなければ大量配信のメールはそもそも届かなくなりました。本記事は実装者向けに、MTAと配信キューの基本構成、認証設定の具体的な手順、IPレピュテーションを含む大量配信基盤の設計要件を解説します。あわせてフルスクラッチ・AWS SESリレー併用・SaaS利用の3方式を比較し、自社構築を採用してよい条件と見送るべき場面を条件付きで示します。

まとめ：メール配信システム自作の採否と構築方式の結論

結論から言うと、メール配信基盤のフルスクラッチ自作を採用してよいのは「月間数百万通超の配信量」「顧客データを外部SaaSへ出せない規制」「送信ログの長期保持要件」のいずれかを満たし、かつ到達率を監視する運用体制を確保できる場合に限られます。この条件に届かない多くのケースでは、配信部分をAmazon SESなどのSMTPリレーに委ねた準自作構成が現実解になります。送信1,000通あたり0.10USD（2026年7月時点の公式料金）という従量費用で、IPレピュテーションの育成という自作最大の難所を回避できるためです。

どの方式を選んでも、SPF・DKIM・DMARCの3点セットアップとワンクリック登録解除への対応は避けられません。個人用Gmail宛に1日5,000通以上を送る送信者への必須要件だからです。本文では、この認証設定とバウンス処理・迷惑メール率0.3%未満の維持という到達率設計を、DNSレコードの具体値まで落として説明します。

メール配信システムを自作する場合の基本構成とMTA・配信キューの設計

自作する配信システムは「配信管理アプリケーション」「MTA」「計測基盤」の3層で構成します。メール配信システムという製品分類そのものの整理や、メルマガ配信ツール・MAツールとの違いはメール配信システムとは？仕組み・メルマガ配信ツールとの違いと導入判断の解説記事に譲り、本記事は実装の内側だけを扱います。

MTA（Postfix等）による送信サーバー構成と配信キュー管理の要点

送信の中核となるMTAには、Linux環境ではPostfixを選ぶのが定石です。設定ファイルが宣言的で、流量制御のパラメータが豊富にそろっています。自作で最初に設計すべきはキューの挙動で、宛先サーバーが一時エラー（4xx応答）を返したメールはdeferredキューに積まれ、再送間隔を空けながら配送が繰り返される仕組みです。この再送設計を放置すると、障害時にキューが数十万通単位で滞留し、復旧後の一斉再送でスパム判定を誘発します。

配信管理アプリケーション側では、宛先リストをMTAへ流し込む速度の制御と、エンベロープFrom（Return-Path）の設計が要になります。エンベロープFromを配信ごとに識別可能なアドレスにしておくと、バウンスメールの突き合わせがログ解析なしで済みます。

配信リスト管理・開封計測・バウンス処理など自作で必要になる機能一覧

SMTPで送るだけなら数日で書けますが、配信「システム」として成立させるには周辺機能の作り込みが本体より重くなります。最低限、次の機能が必要です。

• 購読管理：登録・解除・サプレッションリスト（送ってはいけない宛先の恒久管理）
• 登録解除：RFC 8058準拠のワンクリック解除（List-Unsubscribeヘッダー）
• 開封計測：トラッキングピクセルの埋め込みと集計
• クリック計測：リダイレクタによるURL置換と集計
• バウンス処理：ハードバウンスの自動除外とソフトバウンスの閾値管理
• テンプレート管理：差し込み変数とHTMLメール・テキストメールの同時生成

このうち購読管理とバウンス処理は到達率に直結するため、後回しにできません。解除済みの宛先への誤配信は苦情率を直接押し上げ、存在しないアドレスへの再送はIPの評価を下げ続けます。

OP25Bとサブミッションポート587への対応など送信経路の前提条件

国内ISPの多くはOP25B（Outbound Port 25 Blocking）を実施しており、動的IPから外部の25番ポートへの直接送信は遮断されます。自作基盤は固定IPを持つデータセンターやクラウド上に置き、社内やクライアントアプリからの投稿はサブミッションポート587とSMTP認証で受ける構成にします。加えて、送信IPの逆引きDNS（PTRレコード）が送信ドメインと整合していることは、大手ISPが受信可否を判断する際の基礎条件です。クラウド事業者によっては25番ポートの送信自体に解除申請が必要で、AWSのEC2も申請なしでは25番ポートの流量が制限されます。

SPF・DKIM・DMARCの設定手順と到達率を確保する認証設計

送信ドメイン認証は到達率設計の土台です。3つの仕組みはそれぞれ役割が異なり、どれか1つで代替はできません。設定はすべてDNSレコードの追加が起点になります。

SPFレコードとDKIM署名の設定手順：DNSに登録する具体的な値

SPFは「このドメインのメールを送ってよいIPアドレス」をDNSのTXTレコードで宣言する仕組みです。自作基盤なら送信IPを直接記述し、たとえばv=spf1 ip4:203.0.113.10 -allのように登録します。リレーサービス併用時は事業者指定のincludeを追加します。SPFのDNS参照回数は10回までという制限があり、includeを重ねすぎると認証自体が失敗する点に注意してください。

DKIMは送信サーバーが電子署名を付与し、受信側が公開鍵で検証する仕組みです。PostfixではOpenDKIMを連携させ、生成した公開鍵をセレクタ名付きのTXTレコード（例：selector1._domainkey.example.jp）に登録します。鍵長は2048ビットを選びます。1024ビット鍵は仕様上は有効でも、Gmailなど主要受信側の評価で不利になるためです。

DMARCポリシーの段階的な強化手順とレポート監視の運用方法

DMARCはSPF・DKIMの認証結果と表示上のFromドメインの一致（アライメント）を検証し、不一致時の処理方針を受信側へ指示します。導入は監視のみのv=DMARC1; p=none; rua=mailto:[email protected]から始め、ruaで届く集計レポートで正規メールの認証失敗がないことを数週間確認してから、p=quarantine、p=rejectへ段階的に引き上げます。いきなりrejectにすると、転送経由の正規メールが破棄される事故が起きがちです。DMARCの仕組みとレコード構文の詳細はDMARCとは？その仕組みと設定方法、SPFやDKIMとの関係で解説しています。

Gmail送信者ガイドライン（2024年2月適用）が定める必須要件

Googleは2024年2月1日以降、個人用Gmailアカウント宛に1日5,000通以上を送る送信者へ次の要件を課しています。SPFとDKIMの両方の設定、送信元ドメインへのDMARC設定（ポリシーはnoneでも可）、RFC 8058準拠のワンクリック登録解除、そしてPostmaster Toolsで計測される迷惑メール率を0.3%未満に保つことです。5,000通未満の送信者にもSPFまたはDKIMいずれかの設定は求められています。自作基盤はこの要件への適合を誰も肩代わりしてくれないため、リリース前のチェックリストに認証・解除ヘッダー・苦情率監視の3項目を必ず入れてください。

大量配信基盤の設計要件：IPレピュテーション管理とバウンス処理

認証を整えても、送信IPとドメインの「評判」が育っていなければ受信トレイには届きません。大量配信基盤の設計は、この評価をいかに落とさず育てるかに集約されます。

送信IPのウォームアップと配信速度制御（スロットリング）の設計

新規に取得した送信IPは実績がないため、大手ISPは大量送信を即座に疑います。初日から数十万通を送るのではなく、少量から始めて週単位で段階的に配信量を増やすウォームアップ期間が必要です。エンゲージメントの高い宛先（直近に開封実績のある読者）から送り始めると評価が育ちやすくなります。あわせて必要になるのが、宛先ドメインごとの同時接続数と単位時間あたりの送信数を制御するスロットリングと、受信側から4xx応答（一時的な流量制限）が返ったらそのドメイン向けの送出を自動で絞る仕組みです。Postfixでは宛先別トランスポートと流量パラメータの組み合わせで実現できます。

バウンスメール・苦情処理の自動化と迷惑メール率0.3%未満の維持

バウンスは種別ごとに処理を分けます。宛先不存在などのハードバウンスは1回で配信リストから恒久除外し、メールボックス容量超過などのソフトバウンスは連続回数の閾値（たとえば3回）で除外する設計です。この自動化を怠り無効アドレスへ送り続けることが、IP評価を最も早く毀損します。苦情側では、Postmaster Toolsで迷惑メール率を常時監視し、0.3%の上限に対して0.1%未満が平常時の目標です。Microsoft系にはSNDS・JMRPといったフィードバックループがあり、苦情を申告した宛先を自動でサプレッションリストへ回す連携まで作って初めて、大量配信の運用が回ります。

フルスクラッチ・SMTPリレー併用・SaaS利用の構成比較と費用目安

「自作」と一口に言っても、どこまでを自前で持つかで難易度と費用は大きく変わります。実装範囲の異なる3方式を比較します。

3方式の比較表：構築コスト・運用負荷・拡張性・到達率設計の自由度

フルスクラッチはMTAから自前、リレー併用は配信管理を自作して送信だけ委譲、SaaSは全部を借りる方式です。

表の通り、フルスクラッチが費用面で逆転するのは配信量が月間数百万通を超え、従量課金の累積が固定費と専任運用の人件費を上回ってからです。それ以前の規模では、到達率対策を自力で背負うリスクに見合う回収がありません。

AWS SESをSMTPリレーに使う準自作構成の実装ポイント

準自作構成では、配信管理・リスト管理・計測を自社アプリケーションで実装し、送信はAmazon SESのSMTPエンドポイントまたは送信APIへ委ねます。新規アカウントはサンドボックス状態で検証済み宛先にしか送れないため、本番前に解除申請が必要です。バウンスと苦情はAmazon SNS経由で通知を受け取り、自社のサプレッションリスト更新に接続します。SESを含むAWSのメッセージングサービスの位置づけは、AWS SQS・SNS・SESの違いと使い分けの比較記事で整理した通りです。共有IPで苦情率の高い他者の影響を受けたくない場合は、専用IPのオプションを追加し、自前のウォームアップを行う判断になります。この構成なら、フルスクラッチで最も苦しいIP評価の育成をSESの基盤に預けたまま、配信ロジックとデータは自社側で握れます。

自社構築を採用する条件と見送るべき場面：受託開発での実務判断

受託開発の現場でメール配信基盤の相談を受ける際の判断基準を、条件付きで言い切ります。迷ったらこの章の条件に当てはめてください。

自作を採用してよい3条件：件数規模・要件特殊性・運用体制の有無

フルスクラッチの自作を採用してよいのは次の3条件のうち1つ以上を満たす場合です。第一に、月間数百万通超の配信があり従量課金の累積が構築・運用費を上回り続ける場合。第二に、金融・医療など顧客データを外部SaaSへ持ち出せない規制やセキュリティ要件がある場合。第三に、送信ログやアーカイブの保持形式に監査上の要件があり、外部サービスの仕様では満たせない場合です。ただしいずれの場合も、Postmaster Toolsとバウンス指標を監視し続ける運用担当を確保できることが前提条件になります。基盤は作った日ではなく、送り続けた月日で評価されるためです。

自作を見送るべき典型場面と代替構成：SaaS移行・リレー併用の選び方

月間数万通程度のメルマガ・お知らせ配信のためにMTAから作るのは過剰投資であり、見送るべきです。この規模はSaaSの月額課金で十分に収まり、自作しても到達率はSaaSに勝てません。会員基盤や基幹システムとの連携要件があってSaaSの標準機能からはみ出す場合が、準自作（リレー併用）の出番です。配信ロジックだけを開発し、送信はSESに委ねれば、開発範囲は配信管理アプリケーションに限定されます。ウォームアップと評価監視を担う人員を置けない組織がフルスクラッチへ進むのは、方式選定として誤りです。この場合は要件が特殊でも専用IP付きのリレー構成までに留めます。

構築を外部委託する場合の進め方と開発会社への依頼範囲の切り分け

外部委託する場合は、依頼範囲を「配信管理アプリケーションの開発」「SES等クラウド基盤の設計・構築」「認証・到達率設計の初期セットアップ」の3つに分けて見積もりを取ると、比較がしやすくなります。とくにクラウド側の設計は、配信基盤単体ではなくVPC・監視・通知連携を含むインフラ全体の構成に影響する部分です。当社でもAWS上のインフラ設計から構築・運用までをAWSインフラ構築サービスとして請け負っており、SESを核にした配信基盤の設計もこの範囲で対応しています。既存システムとの連携を含む要件定義から相談できる委託先を選ぶと、配信基盤だけが孤立する構成を避けられます。

よくある質問

メール配信システムの自作・構築を検討する実装者から繰り返し出る疑問に答えます。

メール配信システムの自作にはどのくらいの期間がかかりますか？

SMTPリレー併用の準自作なら、配信管理・購読管理・計測の開発とSESのサンドボックス解除を含めて、小規模構成で数週間から数か月が目安です。フルスクラッチはMTA構築後に送信IPのウォームアップ期間が必要で、少量送信から段階的に増やすため、本番の配信量に到達するまで構築期間とは別に週単位の時間がかかります。この立ち上げ期間を計画に入れていない案件は、リリース直後の大量送信でスパム判定を受けやすくなります。

OP25Bとは何ですか？自作サーバーからの送信にどう影響しますか？

OP25B（Outbound Port 25 Blocking）は、ISPが動的IPアドレスから外部への25番ポート通信を遮断する迷惑メール対策です。オフィスや家庭の回線に置いたサーバーからは外部のメールサーバーへ直接送信できないため、自作基盤は固定IPを持つデータセンターまたはクラウドに配置します。送信者側のアプリケーションからはサブミッションポート587とSMTP認証を使って基盤へ投稿する構成が標準です。

SPF・DKIM・DMARCはすべて設定しないとメールが届きませんか？

個人用Gmail宛に1日5,000通以上を送るなら、SPF・DKIM両方とDMARCの設定はGoogleの送信者ガイドライン上の必須要件です（2024年2月1日以降適用）。5,000通未満でもSPFまたはDKIMのいずれかは求められ、未設定の送信は拒否や迷惑メール判定の対象になります。大量配信を前提に基盤を作るなら、3つすべてを初期構築の範囲に含めるのが実務上の答えです。

AWS SESを使った構成でも「自作」と言えますか？

配信リストの管理・セグメント抽出・テンプレート生成・計測といった配信ロジックを自社で実装していれば、送信だけをSESへ委ねても配信システムの中身は自社の設計です。本記事ではこれを準自作構成と呼んでいます。データの持ち方と配信条件を自社で握れる点はフルスクラッチと変わらず、違いは送信IPの評価管理をSESの基盤に預けるかどうかにあります。

到達率が急に下がったときは何から確認すればよいですか？

最初にPostmaster Toolsで迷惑メール率とドメイン評価を確認します。0.3%に近づいていれば苦情起因です。次にバウンスログを種別ごとに集計し、ハードバウンスの急増（リストの劣化）か4xx応答の増加（流量制限）かを切り分けます。あわせてDMARCの集計レポートで認証失敗率を確認し、送信IPが公開ブラックリストに載っていないかの照合まで行えば、原因の大半はこの4点のどれかに現れます。

関連記事

• メール配信システムとは？仕組み・メルマガ配信ツールとの違いと導入判断を解説：本記事の親にあたる判断ハブで、製品分類と導入判断を整理しています。
• メール配信システムのおすすめ比較と選び方｜到達率・機能・料金の選定軸を解説：自作せずSaaSを選ぶ場合の製品選定軸をまとめています。
• DMARCとは？その仕組みと設定方法、SPFやDKIMとの関係：本記事の認証設計の章を、DMARCに絞って掘り下げた解説です。
• AWS SQS・SNS・SESの違いと使い分け｜3サービスの選定基準を比較：準自作構成で使うSESの、AWS内での位置づけが分かります。
• メールマーケティングとは何か？基本的な定義とメリットを解説：配信基盤の上で行う施策側の基礎を扱っています。