2026年6月22日

[メール] SPF/DKIM/DMARCを設定したのに届かない

SPFやDKIM、DMARCといったメール認証は、最近では広く認知されるようになりました。これらを設定すればメールは正しく届く、と理解されている方もいらっしゃると思います。

ところが、認証設定が完璧でも、メールが届かない事例が複数報告されています。背景には「レピュテーション」と呼ばれる、もう一つの評価軸があります。

認証は「届くこと」を保証しない

SPF・DKIM・DMARC というメール認証の仕組みは、なりすましでないことや、中身が改ざんされていないことを証明するための仕組みです。これらが整っていれば、受信側は「このメールは確かに、名乗っている送信元から送られている」と判断できます。

ただし、それは「本人である」ことの証明で、「届けてよい相手だ」と認められたわけではありません。受信側には、送信元の信頼度を測る「レピュテーション」という、もう一つの評価軸があることがあります。

認証設定が完璧でも、レピュテーションが整っていない送信元から大量にメールを送れば、受信側はそれを「怪しい挙動」とみなし、迷惑メールフォルダへの振り分けや、配信そのもののブロックといった結果を引き起こすことがあります。

2つの軸はそれぞれ性質が違います。認証は技術的な設定で、一度正しくしてしまえば即時に効力を持ち、変更がなければ状態が維持される静的な仕組みです。一方のレピュテーションは、日々の送信行動の積み重ねで決まる動的な評価で、受信者の反応や苦情、配信量の急な変化によって継続的に変動します。

どちらか一方だけでは、メールは安定して届きません。

実例:認証は整っていたのに届かなかった

2024年から2025年にかけて、メール配信に関わる事象が複数公表されました。いずれも、認証設定そのものは適切だったにもかかわらず、特定の受信プロバイダにメールが届かなかったケースです。

事例1:新サービス開始時の認証メール不達

2025年10月、公共放送の新サービスが開始された際、利用者登録時の認証コードがGmailなどの一部メールに届かない事象が発生しました¹。

発信元の認証設定そのものは適切でした。事業者は、原因について「短時間に大量のメールを送ったことで、スパムと自動判別された可能性」を会見で説明しています²。後に、新規ドメインの送信実績が乏しい状態で大量送信を行ったことが背景にあったと発表されています³。事業者側は配信量を調整するなどの対応を行い、翌日までに事象は解消しました。

事例2:オンライン出願システムでの配信失敗

2024年1月、ある自治体の教育委員会が運用する高校入試のオンライン出願システムで、Gmailのアドレスを使った受験生のもとに案内メールが届かない事象が起きました⁴。

メール配信品質の自動診断ツールでは大きな不備が指摘されない状態でしたが、出願期間中に問題が継続し、最終的な解消までおよそ1か月を要しました。教育委員会の発表によれば、当初は「Gmail側で制限がかかったこと」が原因と考えられていました。その後、システム障害報告書をもとにした第三者の分析では、バウンスメールの受信設定や、送信ドメイン認証の運用面において複数の課題があったと整理されています。

二つの事例に共通すること

これら二つの事例は、いずれも次のような状況下で起きています。

認証設定そのものは大きな問題が指摘されない状態だった
にもかかわらず、特定の受信プロバイダ(主にGmail)に配信が届かなかった
いずれも新規のサービス開始や大規模な配信開始のタイミングで起きた

単純な設定ミスや技術的な不備として片付けられるものではなく、別の要因が働いていたことがわかります。

認証とレピュテーションは別の話

認証(Authentication)が証明すること

SPF・DKIM・DMARC は、メールの送信者が正当な相手であることを証明したり、中身が改ざんされていないことを証明したりするための仕組みです。これらの設定が正しければ、受信側は「このメールは確かに、名乗っている送信元から送られている」と判断できます。

ここで止まれば、それは「送信者の本人確認ができた」という意味にとどまり、「届けてもよい相手だ」とは別の話です。

レピュテーション(Reputation)が決めること

レピュテーションは、Gmail や Yahoo、各キャリアといった受信側の事業者が、それぞれの送信元(IPアドレスやドメイン)に対して内部的に付けている信頼度スコアです。

評価の材料は、過去の配信実績にあります。Google公式ドキュメントによれば、評価は送信動作によって決まり、ISPや受信メールプロバイダによって監視されるとされています⁵。具体的には、メールの開封率やクリック率といった受信者のエンゲージメント、スパム報告の頻度、存在しないアドレスへの送信を表すバウンス率、そして時系列で見た送信量のパターン、こうしたものの組み合わせで評価されます。

ここで難しいのは、新しく使い始めたIPアドレスやドメインには、評価の元となる実績がないという点です。受信側のシステムは、実績ゼロの送信元を疑わしいものとして扱う傾向にあります。実績のない相手から、ある日突然大量のメールが送られてくれば、それは「スパム業者の典型的なパターン」と見なされます。先述の事例で起きていたのは、まさにこの現象です。

メールサーバーの実装は各社で異なりますが、概ねこのような評価プロセスをたどります。認証は最初の関門にあたり、これを通過しなければ、そもそも入場できません。通過したからといって受信箱に届くわけではなく、その後にレピュテーションの評価が待っています。スコアが芳しくなければ迷惑メールフォルダ行き、疑わしい挙動と判断されればブロックです⁶。

認証が「通行証」だとすれば、レピュテーションは「滞在中の素行」のようなものです。チケットを持っているだけでは、目的地までたどり着けません。

2024年以降、認証はもはや必須化された

さらに、最近では「認証なしでは入場すらできない」という方向に環境が動いています。

2024年2月、GoogleとYahooは送信者ガイドラインを大きく改定しました⁷。1日に5,000通以上をGmailアドレスへ送信する送信者には、SPF・DKIM・DMARC のすべての設定、簡単に解除できる退会機能(ワンクリック退会)、そしてスパム報告率を一定値以下に保つこと、こうした要件が課されました。基準として明記されているスパム率の上限は0.3%、推奨値は0.1%以下です。

2025年4月にはMicrosoftも同等の要件を発表し、Outlook.comドメイン宛の配信に同様のルールが適用されました。そして2025年11月、Googleは要件未達のメールを段階的に拒否する運用を本格化させています。これまで迷惑メールフォルダへの振り分け程度で済んでいたものが、サーバーレベルでの拒否(永続エラー)に変わってきました。

認証はもはや「やっておくと安心」ではなく、「整っていなければ届かない」という前提条件になりました。その上で、レピュテーションが、届く・届かないを実際に決めます。本記事の主題である「認証だけでは不十分」という構図は、近年さらに強まっています。

IPウォーミングという考え方

では、新規のIPアドレスやドメインから配信を始めるとき、どうすればレピュテーションを正しく育てられるのでしょうか。

メール配信の専門事業者では定着している考え方が、「IPウォーミング」です。新しいIPアドレスやドメインから配信を始める際に、送信量を段階的に増やしていくプロセスを指します。受信側に「このIPは、急に大量に送ってくる怪しい送信元ではなく、正常な配信元である」と理解してもらうための慣らし運転にあたります。

ウォーミング期間の感覚値

一般的なメール配信プラットフォームのドキュメントでは、ウォーミング期間として最低でも14日、長い場合で30日から60日が示されています⁸。具体的な日数や送信量はリストの規模、エンゲージメントの質、配信内容によって変わるため、汎用的な「正解」はありません。

ただし、原則は明確です。最初は少量から始め、毎日継続的に送り、徐々に量を増やす。ある日に突然多く送るような事は避けます。

基本となる原則

最初はエンゲージメントが期待できる相手(既存の関係性がある利用者など)から送る
毎日継続的に送り、間隔を空けない。間隔を空けると評価がリセットされる場合がある
急激な送信量の増加(例えば前日比で2倍以上)は避ける
バウンス率や苦情率を監視し、異常があれば送信量の伸びを止める

Googleの公式ドキュメントにも、過去に大量送信したことがない場合は送信量を急に増やすことを避けるよう、また、以前の送信量から急に2倍に増えると、レート制限や評価の低下につながる可能性があると記載されています。受信側にとっても、急な変化は警戒すべき信号として扱われていることが伺えます。

気をつけるべき場面

IPウォーミングが必要になるのは、次のような場面です。

新しいドメインから本格的にメール配信を始めるとき
新しいIPアドレスを使った配信に切り替えるとき
月間の送信量を大幅に増やすとき(例えば1万通から10万通へ)
1ヶ月以上、ほとんど送信がなかった状態から再開するとき

送信量別の対応の目安

1日の送信量	ウォーミングの必要性
100通以下	基本的に不要。少量配信のためレピュテーションへの影響は限定的
500通以上	実施を推奨。新規ドメイン・IPであれば段階的に増やす
5,000通以上	必須。Gmailでの大量送信者扱いの閾値でもあり、認証要件も厳格化される

運用中の監視

配信を開始してからも、レピュテーションの状態を継続的に確認することが望ましい運用です。Gmail宛の配信については、Google が提供する Postmaster Tools を利用することで、自社ドメインのスパム率や評価状態を把握できます⁹。一般には、スパム報告率は0.1%以下を維持することが望ましいとされており、0.3%を超えると配信品質の悪化が顕在化しやすくなります。

まとめ

メールの大量配信においては、下記の点を意識して進めましょう。

認証(SPF/DKIM/DMARC)はもはや必須。設定がなければ届かない時代になっている
認証だけで届くことが保証されるわけではない。レピュテーションも届く・届かないを決める要素
新規ドメイン・新規IPには、レピュテーションを育てる時間(最低でも14日程度)が必要
配信開始のスケジュールには、IPウォーミング期間をあらかじめ組み込んでおく
運用開始後もスパム率や評価状態の監視を続け、異常があれば早めに対処する

新しいシステムの導入や大規模な配信などを始める前に、関係者の間でこれらを共有しておくことで、トラブル予防の一助となりましたら幸いです。

本記事の内容につきまして、可能なかぎりの確認を実施しておりますが、それぞれの環境や受信プロバイダの運用方針の変化などにより、結果が異なる可能性があります。重要な配信を計画される際は、事前のテスト送信と段階的な配信開始をお勧めします。判断に迷われる場合は、専門家にご相談ください。

ご紹介:

まるっと (IT総合支援サービス)

「止めない」「守る」「活かす」の3つの柱で、お客さまのIT基盤をトータルに支えます。専任の情報システム担当がいらっしゃらない企業さまも、お気軽にご相談ください。
▸ サービス詳細: https://www.distant-view.co.jp/service/marutto.html
▸ お問い合わせ: https://www.distant-view.co.jp/contact/

出典・参考リンク

出典・参考リンクは2026年6月時点で内容を確認しています。リンク先は予告なく変更・削除される場合がありますので、最新の公式情報をあわせてご確認ください。

事象の事実関係について。日経電子版「10月開始『NHK ONE』、アカウント登録で不具合」(2025年10月1日):
https://www.nikkei.com/article/DGXZQOUC011480R01C25A0000000/ ↩︎
事業者会見の内容について。AV Watch「NHK ONE、認証コード送信されない不具合は『大量発信によるスパム判定の可能性』」(2025年10月1日):
https://av.watch.impress.co.jp/docs/news/2051729.html ↩︎
解消の経緯と原因について。ITmedia NEWS「『NHK ONE』登録不具合が解消原因は『新規ドメインからの大量送信』」(2025年10月2日):
https://www.itmedia.co.jp/news/articles/2510/02/news085.html ↩︎
事象の事実関係について。日経クロステック「神奈川県公立高校入試のインターネット出願で障害1週間、Gmailにメール届かず」(2024年1月16日):
https://xtech.nikkei.com/atcl/nxt/news/24/00055/ ↩︎
送信元の評価の仕組みについて。Google Workspace 管理者ヘルプ「Postmaster Tools ダッシュボード」: https://support.google.com/a/answer/14668346 ↩︎
受信側の評価プロセスについて。Google Workspace 管理者ヘルプ「メール送信者のガイドライン」(送信者の評価が高ければ受信トレイに、低ければ迷惑メールフォルダに分類される旨の記載): https://support.google.com/a/answer/81126 ↩︎
GoogleとYahoo!の送信者要件(2024年導入)について。Google Workspace 管理者ヘルプ「メール送信者のガイドラインに関するよくある質問」:
https://support.google.com/a/answer/14229414 ↩︎
ウォーミング期間の標準値について。Twilio SendGrid「Email Guide to IP Warm Up」(平均30日、長い場合60日、短い場合1〜2週間):
https://www.twilio.com/en-us/resource-center/email-guide-ip-warm-up ↩︎
Postmaster Tools （※利用には送信ドメインの所有権確認(DNSレコード設定)が必要）
Google公式: https://postmaster.google.com/ ↩︎