キャリアメール向けドメインウォームアップガイド｜docomo・au・SoftBank対応

2026.10.28

株式会社プリモポスト取締役

日吉浩之メール到達エバンジェリスト

新しいドメインや新しい送信IPで配信を始めたとき、docomo.ne.jp や ezweb.ne.jp 宛だけ届かない、またはキューに溜まり続ける。メール配信の運用を担当するエンジニアなら、一度は経験があるのではないでしょうか。

この記事では、国内3キャリア（NTTドコモ、KDDI/au、ソフトバンク）宛の配信に絞って、次の3点を公開情報をもとに整理します。

キャリアの受信側で、何がメールを止めているのか
2024から2026年に何が変わったか
送信者が自社で立ち上げをどう設計し、何を見て判断するか

この記事の前提：キャリアはブロックの閾値（しきい値）を公開していません。本文中の「公式情報」と「筆者の運用経験」は分けて書いています。運用ルールは公開できる範囲で示しており、あくまで出発点として使ってください。

キャリア宛の到達率は、送信者が自分で守る

送信者向けの窓口は、ほぼ存在しない

キャリアメールの受信側では、キャリア自身のメールサーバーによる流量制御と、裏側で動くアンチスパムエンジンによる迷惑メール判定の2つがメールを止めています。

どちらについても、送信者が評価を確認するツールや、ブロックの解除を申請する窓口は公開されていません。

Gmail の Postmaster Tools に相当するものはなく、au は「特定の送信者からのメールを優先して扱うことはできない」と明言しています。

唯一の例外は、ドコモが法人向けに提供している「ドコモメール公式アカウント」ですが、これは送信元の正当性を示す制度であって、流量制限や迷惑メール判定を免除するものではありません。

つまり、キャリア宛の到達率は、送信者が自分の配信の仕方で守るしかありません。

流量制御にかからない速度で送ること、そしてアンチスパムエンジンに「正規の送信者」と判断され続ける送り方を積み重ねることです。

事前の「ウォームアップ」という工程は、キャリア宛には作れない

Gmail や Outlook 向けには、本番の前に少量の送信を積み重ねて評価を作る「ウォームアップ」の工程を置くのが一般的です。

しかしキャリア宛では、この工程を本番と切り離して作ることができません。

ウォームアップの送信先になる本物のキャリア宛受信者を、本番前に用意する手段がない。
受信確認用のシードアドレスは、キャリア回線の契約が要るうえに数アドレスしか作れず、量を積む役には立たない
キャリア宛の評価を積めるのは、本物のオプトイン受信者への本番配信だけ

今回お伝えする

「キャリア宛のウォームアップ」

とは、本番の初期運用そのものを、キャリア宛だけ別枠で管理し、段階的に立ち上げることを指します。

宛先がキャリアのメールを別の配信経路・別の流量で扱い、最初は絞って、反応を見ながら上げていく。

これがキャリア宛で取れる唯一の方法であり、この記事はそれを自社で進めるための手順書として書いています。

Gmail との違い

Gmail と比べると、送信者に見える情報の少なさがよくわかります。

観点	Gmail	携帯キャリア（docomo / au / SoftBank）
ルールの公開	送信者ガイドラインで数値基準を公開	注意事項のみ。閾値は非公開（au は「明確な基準や閾値は提示できない」と明言）
評価の可視化	Postmaster Tools あり	送信者向けのツールなし
迷惑メール判定	Google 自身が判定	裏側のアンチスパムエンジン（docomo・au は Hornetsecurity の判定情報）と、キャリア独自の基準
受信者側の設定	ほぼ Google 側の判定に依存	受信者自身がドメイン指定受信・URL付きメール拒否・大量送信者拒否などを細かく設定できる
流量制御	主に一時エラー（4xx）で通知	TCP の RST や無応答など、SMTP の応答が返らない形で制限されることがある
事前ウォームアップ	受信箱網を使ったサービスや、少量の本番前送信で可能	本番配信の中で段階的に立ち上げるしかない

キャリアの受信防御は2層構造

公開情報から見ると、キャリアの受信側の防御は大きく2つの層に分けて考えるとわかりやすくなります。判定の単位が違うことにも注意してください。レイヤー1は主に送信元IPを単位に、レイヤー2は送信ドメインとメールの内容を単位に見ています。

レイヤー1：MTA層の流量制御（接続とトラフィックの制限）

au は送信者向け FAQ で、メールサーバーが混雑している、または混雑しそうなときに「受信ブロック」を行うと説明しており、対象になる行為として次を挙げています。

一度に大量のメールを送る、短時間に送信を繰り返す
メールサーバーへ大量に接続する
SMTP セッションを占有する
EHLO / HELO が不正、または送っていない
送信元 IP の DNS 逆引きができない
3MB を超える大容量メール

設備が過負荷のときの応答は「無応答」または「TCP の RESET」とされています。つまり、SMTP の 4xx コードが返ってくるとは限りません。

現場では「キャリアブロック」と呼ばれることもあり、ポート25への SYN に RST が返され、送信側 MTA では接続拒否（Postfix のログでは Connection refused）として一時エラー扱いになる、という報告があります。

ブロックは送信元IP単位でかかり、解除までの時間は数十分から24時間以上までばらつくようです。

ソフトバンクも、送信者向けの注意事項として次を案内しています。

宛先不明のアドレスが大量に含まれると、システムが迷惑メールと判断する
一度に集中して送らず、時間を分散する
毎正時（〜時00分）前後の集中配信を避ける
ドメイン別に並べ替えた一括送信を避ける

au も同じく、毎正時を避けることと、使われていないアドレスを多く含むリストへの送信で受信ブロックされる可能性があることを案内しています。

レイヤー2：内容と評判による判定（迷惑メールフィルタ・なりすまし判定）

MTA 層を通過したメールは、迷惑メールかどうか、なりすましかどうかの判定を受けます。

キャリア	迷惑メールの自動判定	判定エンジンについての公式記載
NTTドコモ	迷惑メールおまかせブロック	「Hornetsecurity株式会社の判定基準により判定」。誤判定の報告などはメール原文を添付して Hornetsecurity 社へ送付
au（KDDI）	迷惑メールおまかせ規制	「Hornetsecurity株式会社の判定情報などに基づき提供」
ソフトバンク	迷惑メールフィルター	「蓄積されたスパムデータベースをもとにメールの内容を機械的に判断」。提供会社名は非公開

Hornetsecurity は、2024年に仏 Vade（通信事業者向けのメールフィルタ技術を持つ企業）を統合したドイツのメールセキュリティ企業で、2025年12月に米 Proofpoint による買収（18億ドル）が完了しています。

docomo と au の2キャリアは、同じベンダーの判定情報を使っていることになります。

片方で「迷惑メールらしい」と学習されたパターンがもう片方にも影響するかどうかは公開されていませんが（私の推測です）、両キャリアを同じ基準で扱っておくのが安全です。

このレイヤーには、DMARC を中心とする送信ドメイン認証の判定も含まれます。

2024〜2026年の主な変更点

ここ2年ほどで、キャリアの受信側の仕様は大きく変わりました。古いノウハウのままだと判断を誤るので、まず頭の中を整理します。

時期	キャリア	変更内容	送信側への影響
2023年12月〜	KDDI	DMARC・BIMI を導入。2024年2月に自社の主要ドメインで p=reject を完了	au 宛でも DMARC の結果が重視されるようになった
2024年4月〜	ソフトバンク	DMARC によるなりすまし対策を順次導入（S!メール、Eメール(i)、Y!mobile の MMS）	DMARC-SPF か DMARC-DKIM のどちらかで Pass することを送信者に求めている
2024年10月〜（Android） 2025年1月〜（iPhone ほか）	NTTドコモ	DMARC 認証に失敗した、または DMARC 未導入のメールに「なりすまし」の警告を表示	DMARC 未設定のドメインは、正規のメールでも警告付きで表示される
2025年2月13日〜（3月12日に全面移行）	NTTドコモ	迷惑メールフォルダを追加。これまで受信拒否していたメール（ドメイン指定拒否、詐欺／ウイルスメール拒否など）が迷惑メールフォルダに入るように。DMARC の quarantine 判定もここへ振り分け	バウンスが返らなくなった。「エラーが出ていない = 受信箱に届いた」とは言えなくなった
2026年7月〜	au	ヘッダ情報・件名・本文から判定に役立つ特徴データを Hornetsecurity 社に提供し、判定情報に自動で反映	迷惑メールらしいパターンの学習と反映が速くなる。テンプレートの使い回しや急な大量送信の影響が出やすくなると考えられる

エンジニアにとって特に大きいのは、docomo の迷惑メールフォルダ導入です。

以前は、ドメイン指定拒否は DATA コマンドの後に 550 が返るため、RCPT TO の段階で返る「宛先不明」の 550 と区別できました。

現在は迷惑メールフォルダに入るだけでバウンスは返りません。バウンス率だけ見ていると、迷惑メールフォルダに入っていることに気づけないという状態になります。

立ち上げ前の前提条件チェックリスト

流量をどう調整しても、土台ができていなければ効果は出ません。本番配信を始める前に、次の項目をすべて確認してください。

1. 送信ドメイン認証（SPF / DKIM / DMARC）とアライメント

# SPF（ヘッダFromのドメインと、エンベロープFromのドメインの両方を確認）
dig +short TXT example.com
dig +short TXT bounce.example.com

# DKIM（セレクタは配信基盤に合わせて置き換える）
dig +short TXT s1._domainkey.example.com

# DMARC
dig +short TXT _dmarc.example.com

DMARC アライメントを成立させる：ヘッダFrom のドメインと、SPF（Return-Path）または DKIM（d=）のどちらかのドメインが一致している必要があります。外部の配信サービスを使う場合、初期設定のままだと Return-Path や DKIM の d= が配信サービス側のドメインになっていて、SPF も DKIM も Pass なのに DMARC は Fail というケースがよくあります。
SPF の DNS ルックアップは10回まで：配信サービスを増やすたびに include: が増え、上限を超えると PermError になります。
DMARC ポリシー：docomo の警告表示は「DMARC 認証に失敗、または未導入」のメールに出ます。p=none でも認証が Pass していれば警告は出ませんが、Fail すれば p=none でも警告が出ます。3キャリアとも quarantine / reject への移行を呼びかけており（JPAAWG 2024 の講演資料）、まず rua でレポートを集め、正規の送信元をすべて把握してから段階的に引き上げます。
ソフトバンクは、転送メールでの認証失敗対策として ARC 署名への対応も推奨しています。

2. PTR（逆引き）と HELO の整合

au は、逆引きできない送信元と不正な HELO を受信ブロックの対象として明記しています。

# 送信IPの逆引き
dig +short -x 203.0.113.10
# => mail01.example.com.

# 逆引きで得たホスト名の正引きが、同じIPに戻るか（FCrDNS）
dig +short A mail01.example.com
# => 203.0.113.10

PTR がホスト名を返し、そのホスト名の正引きが同じ IP を返すこと（FCrDNS）
MTA の EHLO で名乗るホスト名が、その PTR と一致していること（Postfix なら myhostname、または smtp_helo_name）

3. リストの整理（宛先不明アドレスの除去）

au とソフトバンクは、宛先不明のアドレスが多いことを受信ブロック・迷惑メール判定の要因として明記しています。

ドコモも、送信できなかったアドレスの確認・除去などリストの定期的なメンテナンスを推奨しています。キャリアメールは解約や MNP でアドレスが使われなくなることが多く、古いリストほど危険です。

過去のバウンスで宛先不明と判定されたアドレスは、配信停止リストに入れる
長期間送っていないリストは、本番配信の前に検証ツールで整理しておく
取得経緯が確認できないアドレスには送らない（特定電子メール法のオプトイン要件もあります）

4. 受信者側の設定と、送信者側でできる唯一の申請

キャリアメールの利用者は、ドメイン指定受信や「URL付きメールの拒否」などを自分で設定していることがあります。

ドコモには「大量送信者からのメール拒否設定」という項目もあり、一斉配信を行う送信元は受信者の設定次第で拒否されることがあります。

これらは送信者側では制御できないので、会員登録の画面やサンクスメールで、受信を許可してほしい送信ドメインを明記するのが確実です。

送信者側から申請できる制度としては、ドコモの「ドコモメール公式アカウント」があります。

法人向けに無料で提供されており、ドコモは DMARC 警告表示の導入にあわせて申し込みを推奨しています。

流量制限や迷惑メール判定を免除するものではありませんが、正規の送信元であることを示す手段として、立ち上げ前に申し込んでおく価値があります。

本番初期運用でのキャリア宛の立ち上げ設計

1. キャリアのドメインごとに流量を絞る（Postfix の例）

キャリア宛の配信を一般宛と同じキュー・同じ並列数で流すと、レイヤー1の制限にすぐかかります。

キャリアのドメインだけ別の transport に分け、並列数と送信間隔を個別に制御するのが定番の構成です。この設定は本番配信の初日から入れておきます。

/etc/postfix/transport

docomo.ne.jp        slow_carrier:
ezweb.ne.jp         slow_carrier:
au.com              slow_carrier:
uqmobile.jp         slow_carrier:
softbank.ne.jp      slow_carrier:
i.softbank.jp       slow_carrier:
ymobile.ne.jp       slow_carrier:
yahoo.ne.jp         slow_carrier:

/etc/postfix/master.cf

slow_carrier unix  -       -       n       -       -       smtp
    -o syslog_name=postfix/slow_carrier

/etc/postfix/main.cf（立ち上げ初期の設定例）

transport_maps = hash:/etc/postfix/transport

# キャリア宛の transport だけ、宛先ごとの送信間隔と1接続あたりの宛先数を個別に指定
slow_carrier_destination_rate_delay = 1s
slow_carrier_destination_recipient_limit = 10

# rate_delay を 0s に戻した後に効く並列数の上限
slow_carrier_destination_concurrency_limit = 2

# 一時エラー時の再送間隔（短すぎると再接続の嵐になる）
minimal_backoff_time = 600s
maximal_backoff_time = 3600s

postmap /etc/postfix/transport
postfix reload

調整のポイント

*_destination_rate_delay（Postfix 2.5以降）に0より大きい値を入れると、同じ宛先への配信の間に指定した間隔が挟まり、その宛先への並列数は実質1になります。concurrency_limit の値は、rate_delay を 0s に戻してから効きます。立ち上げ初期やブロック後の復旧期は rate_delay で間隔を空け、安定してから rate_delay を 0s にして並列数を1〜2から少しずつ上げる、という順で進めます。
recipient_limit が1だと「宛先」が受信者アドレス単位になり、ドメイン単位の間隔制御にならない点に注意してください。逆に大きくすると、セッションを占有しているとみなされるおそれがあります。小さめにしておきます。
外部の配信サービス（ESP）を使う場合も考え方は同じです。配信ドメイン別の流量設定があるか、ない場合は時間帯を分けて送れるかを確認します。

2. 送信リストの並び順と送信時刻

ドメイン順にソートしない：ソフトバンクが明示的に避けるよう案内しています。リストをシャッフルしてから投入するか、宛先ドメインをラウンドロビンで回すように組み立てます。
毎正時を避ける：au・ソフトバンクとも、毎正時前後に送信要求が集中していると案内しています。cron で配信するなら 0 * * * * ではなく、7,37 * * * * のように分をずらします。
反応の良い宛先から送る：直近でログインや購入があるユーザーなど、迷惑メール報告や宛先不明になりにくい層から始めます。

3. 送信量の増やし方（当社の運用ルール）

以下は、キャリアが公開している基準ではなく、当社が本番の立ち上げで用いている運用ルールを、公開できる範囲で示したものです。業種、リストの質、コンテンツによって適切な値は変わります。

キャリア宛は「週ごとに何通」という固定の予定表ではなく、前日の結果で翌日の量を決めるルール型で運用します。

初期の量：キャリア宛の枠を、一般宛とは別に小さく設定します。本番リストのうち、反応の良い受信者から順に、キャリア別に少量ずつ送ります。
上げる条件：一時エラー・接続拒否がほぼゼロ、宛先不明が極めて少なく、シードアドレスが受信箱に入っている日が続いたときだけ上げます。
上げ幅：一度に上げる量は、直前の段階の最大1.5倍までに抑えます。倍増はしません。
戻す条件：接続拒否が続く、シードアドレスが迷惑メールフォルダに入る、宛先不明が増える、のいずれかが出たら、1つ前の段階に戻し、原因を確認してから再開します。
期間：本番の送信量によりますが、1〜2か月以上かかることを見込んでおきます。キャンペーンの日程から逆算して、余裕を持って始めてください。

増やすのは1日の総量だけでなく、単位時間あたりの流量も含めてです。1日の総量が同じでも、30分に集中させればレイヤー1の流量制御にかかります。

また、本文やテンプレートを急に変えないことも大切です。レイヤー2の判定は内容の特徴も学習するので、立ち上げ中は内容を比較的安定させておくのが無難です。

観測と判断

1. ログからキャリア別の状況を読む

Postfix なら、宛先ドメイン別に配信結果を集計するだけでも、かなりのことがわかります（ログの場所は RHEL 系なら /var/log/maillog、Debian 系なら /var/log/mail.log）。

# docomo 宛の配信結果の内訳
grep -E 'to=<[^>]+@docomo\.ne\.jp>' /var/log/maillog \
  | grep -oE 'status=[a-z]+' | sort | uniq -c

# 一時エラー（deferred）の理由の上位
grep 'postfix/slow_carrier' /var/log/maillog \
  | grep 'status=deferred' \
  | grep -oE '\(.*\)$' | sort | uniq -c | sort -rn | head

ログの症状	考えられる状態	対応
`Connection refused`、`lost connection`、接続タイムアウトが急に増える	レイヤー1の流量制御（いわゆるキャリアブロック）。SYN に RST が返っている	すぐに流量を落とす。rate_delay を入れて並列数を1に。再送間隔を長めにして、再接続を繰り返さない
4xx の一時エラーが続く	混雑、または一時的な制限	再送は MTA に任せ、新しいメールの投入を抑える
RCPT TO の段階で 550（宛先不明）が多い	リストの質の問題	該当アドレスを即時に配信停止リストへ。キャリアの評価にも直結する
バウンスは少ないのに反応率（開封・クリック）だけ落ちる	迷惑メールフォルダに入っている可能性（特に docomo）	シードアドレスで振り分け先を確認。認証とコンテンツを見直す

2. 「バウンスがない = 届いている」ではない

3章で書いたとおり、docomo はドメイン指定拒否などをバウンスではなく迷惑メールフォルダで処理するようになりました。

キャリアには Postmaster Tools に相当する仕組みもないため、実際のキャリアアドレスを受信確認用に用意し、どのフォルダに入ったかを定期的に確認する以外に、確実に知る方法はほとんどありません。

見るべき指標は次の3つです。

キャリア別の配信結果：sent / deferred / bounced の比率とその推移
キャリア別の反応率：Gmail 宛と比べて極端に低くないか
シードアドレスでの振り分け結果：受信箱か、迷惑メールフォルダか

3. ブロックされた後の復旧

流量を大きく下げ、立ち上げの序盤の段階に戻して送り直します。
一時エラーで溜まったキューを一度に流すと、再びブロックされる原因になります。キャリア宛の transport だけ止めて（例：postsuper -h で保留）、少しずつ解放します。
解除までの時間は公開されていません。再接続を繰り返すほど長引くと考えて、待つ判断も大切です。

Gmail とキャリア、フィルタエンジンの違い早見表

最後に、送信者から見た違いを整理します。

Cloudmark は、公開情報の範囲ではキャリアでの採用は確認できず、エックスサーバーなどのレンタルサーバーで受信側のスパムフィルタとして使われているエンジンです。

企業宛の B2B 配信では、こちらの影響を受けることもあるため、参考として並べています。

観点	Gmail	docomo / au（Hornetsecurity の判定情報）	Cloudmark（レンタルサーバーなど）
立場	メールボックス事業者	通信キャリア（判定情報はベンダーから提供）	MTA に組み込む判定エンジン
公開されているルール	送信者ガイドライン（DMARC、ワンクリック配信停止、苦情率0.3%未満など）	送信時の注意事項のみ。閾値は非公開	非公開
送信者向けの可視化	Postmaster Tools	なし（ドコモの公式アカウント申請のみ）	なし（ブロックリストからの削除申請窓口あり）
判定の特徴	認証、ユーザーの反応、苦情率	流量制御、DMARC、利用者からの報告や特徴データの学習にもとづく内容判定	コンテンツの特徴（フィンガープリント）照合と、送信元の評判スコア
拒否のされ方	主に 4xx / 5xx の応答で通知	TCP の RST・無応答、550、迷惑メールフォルダへの振り分け	550 による拒否など

自社で進めるための実行プラン

キャリア宛の立ち上げは、送信する側が自分で進めるしかありません。公開情報の範囲では、送信者向けの評価確認ツールや、ブロック解除の申請窓口は見当たりません。

外部に「任せて解決」できる領域ではないという前提で、社内で次の順に進めてください。

ステップ0：体制と期間を決める

担当を決める：MTA（または配信サービス）の設定変更、ログの確認、配信リストの管理を、誰が担当するか決めます。立ち上げ中は毎日ログを見る必要があります。
期間を確保する：本番の送信量に届くまで1〜2か月以上。キャンペーンや大型告知の日から逆算します。
旧ドメイン・旧IPを並行して使えるか確認する：移行の場合、新しい環境の送信量を増やしながら、残りを旧環境で送れると安全です。

ステップ1：受信確認用のキャリアアドレスを用意する

docomo・au・SoftBank の回線を各1回線以上用意し、キャリアメールのアドレス（シードアドレス）を作ります。キャリアメールは MVNO（格安SIM）では使えません。docomo メールは docomo・ahamo・irumo、au メールは au・UQ mobile、SoftBank メールは SoftBank・Y!mobile の回線が必要です（povo にはキャリアメールがありません）。
迷惑メールフィルタは初期設定のままにします（受信許可リストに自社ドメインを入れると、一般の利用者と同じ条件で確認できなくなります）。
配信のたびにシードアドレスを宛先に混ぜ、受信箱に届いたか、迷惑メールフォルダに入ったか、なりすまし警告が出ていないかを記録します。
シードアドレスはあくまで監視用です。数アドレスに送っても評価は積み上がらないので、量の代わりにはなりません。

ステップ2：前提条件を整える

SPF / DKIM / DMARC のアライメント、PTR と HELO の整合を確認し、DMARC の rua レポートの受信を始めます。
過去の宛先不明アドレスを配信停止リストに入れ、長く送っていないリストは検証ツールで整理します。
会員登録画面やサンクスメールで、受信を許可してほしいドメインを案内します。
ドコモメール公式アカウントを申し込みます。

ステップ3：配信基盤の流量制御を設定する

自社で MTA を運用している場合：5-1 の例のように、キャリアのドメインを専用の transport に分け、送信間隔と並列数を絞ります。
配信サービス（ESP）を使っている場合：宛先ドメイン別に流量を制御する機能があるかを確認します。機能がない場合は、キャリアのアドレスだけを別のリストに分け、時間帯を分けて送ります。
リストのシャッフル、毎正時を避けるスケジュールもこの段階で組み込みます。

ステップ4：本番配信をキャリア宛だけ少量から始め、毎日判定する

毎日の確認項目を決めておき、次のルールで判断します。

その日の結果	次の日の判断
一時エラー・接続拒否がほぼゼロ、宛先不明も少なく、シードアドレスは受信箱	送信量を上げる（最大でも1.5倍まで）
一時エラーや接続拒否が少し出た	送信量を据え置き、送信間隔を広げる
接続拒否が続く、シードアドレスが迷惑メールフォルダに入った	1つ前の段階に戻す。原因（リスト、内容、認証）を確認してから再開

ステップ5：本番の送信量に達した後も監視を続ける

キャリア別の配信結果、反応率、シードアドレスでの確認は、立ち上げが終わっても続けます。
送信量を急に増やす施策（セール、一斉告知など）の前は、数日かけて少しずつ流量を上げておきます。

最後に

携帯キャリア宛の配信では、流量制御（レイヤー1、IP単位）と内容・評判の判定（レイヤー2、ドメインと内容単位）の両方を意識する必要があります。
docomo と au は、どちらも Hornetsecurity の判定情報を使っています。au は2026年7月から特徴データの自動反映も始めました。
docomo の迷惑メールフォルダ導入以降、バウンスだけでは届いたかどうかを判断できません。シードアドレスでの確認が欠かせません。
キャリア宛には、本番と切り離した事前ウォームアップの工程は作れません。本番の初期運用でキャリア宛を別枠に分け、少量から段階的に上げるのが唯一の方法です。
始める前に、DMARC のアライメント、PTR と HELO の整合、リストの整理、ドコモメール公式アカウントの申請を済ませておきます。
立ち上げ中は、キャリア別に流量を絞る、毎正時とドメイン順ソートを避ける、反応の良い宛先から送る、上げ幅は最大1.5倍、を徹底し、異常が出たらすぐ前の段階に戻します。

閾値が公開されていない相手なので、慎重に始めて、ログを見ながら少しずつ増やす以外に近道はありません。

前提条件づくりはプリモポストがお手伝いします

株式会社プリモポストでは、キャリア宛のウォームアップの代行は行っていません。一方で、この記事で挙げた前提条件は、キャリア宛・Gmail宛を問わず到達率を左右します。

次のサービスで、社内で立ち上げを進めるための土台づくりを支援しています。

送信ドメイン認証と配信環境の確認：迷惑メール診断サービスで、SPF / DKIM / DMARC の設定、ブラックリストへの掲載、スパムトラップの混入などを診断します。
宛先不明アドレスの除去：メールクリーニングサービスで、本番配信の前に配信リストを整理できます。
SPF の10回制限への対応：AutoSPFで、配信サービスが増えても SPF の PermError を防ぎます。
Gmail・Outlook など向けのウォームアップ：ドメインウォームアップサービスをご利用いただけます（キャリア宛は対象外です）。

気軽にお問い合わせください。