イクバル・アバドゥラ
転送メールがスパムに入る理由と、ARCがそれをどう防ぐか
DMARC強化で転送メールがスパムに落ちる問題。ARC署名は認証連鎖を保ち、GmailやYahooが信頼できるようにする。仕組みと確認方法を説明する。
新しく手に入れたドメインでサイドプロジェクトを始めて、そこにメール転送を設定したとしよう。MXレコードを向け、エイリアスを作り、テストメールを送った。Gmailの受信トレイに届いた。完了だと思った。
3ヶ月後、ドメイン更新の通知が来なかった。送信側のログを確認した。メールは送信されている。バウンスもしていない。ただ、受信トレイに届いていないだけだった。Gmailを検索し、スパムフォルダを確認した。そこにあった。他にも、数週間の間に静かに沈んでいた転送メールが十数通あった。
これは設定ミスではない。MXレコードの破損でもない。メール転送と現代の認証システムの相互作用に生じる構造的な問題だ。そして、これは悪化している。
問題の核心：転送が認証を破壊する
誰かが独自ドメインにメールを送ると、そのメールは受信トレイに届くまでに2つのメールサーバを経由する。送信者のサーバが送る。転送サービスが受信する。転送サービスが再び送る。今度はGmail、Yahoo、Outlookの宛先へ。
2回目の送信が問題だ。現代のメール認証には3つの柱がある。SPF、DKIM、DMARCだ。
- SPFは、メールを送信するサーバがドメイン所有者に認証されているかを確認する。送信者のSPFレコードは自分のサーバをリストする。転送サービスがメールを再送信すると、送信IPが変わる。SPFは失敗する。
- DKIMは暗号署名だ。送信者がメールに署名していれば、転送サービスが本文やヘッダを変更しなければ署名は生き残る。しかし、転送はしばしばヘッダを変更する。そして多くの送信者はそもそも署名していない。
- DMARCは政策層だ。SPFやDKIMが失敗した場合、受信サーバにどう対処するかを指示する。GmailとYahooは2024年からDMARCの執行を強化している。SPFに失敗し、DKIM署名も残っていない転送メールは、次第に疑わしいものとして扱われる。
結果：転送サービスに何の過ちもないのに、受信サーバは認証されていないIPから来た、認証の破損したメールを見て、それをスパムとする。
最近なぜ悪化したか
2023年10月、GoogleとYahooは大量送信者に対する新しい要件を発表した。執行は2024年2月に始まり、Gmailは2月に一時的エラーを導入し、4月から段階的に拒否率を上げ、6月からはDMARCレコードの最低政策p=noneを義務化した（M3AAWG, 2023; dmarcian, 2024）。Googleはgmail.com自身のDMARCレコードもp=quarantineに更新し、Gmailのドメインを名乗るがGoogleのプラットフォーム外から送られるメールは、次第にスパムに振り分けられるようになった。
Yahoo Japanは2024年12月に追随した。2025年に入り、DMARCとSPFとDKIMをユーザーの義務化とした（Security Boulevard, 2025）。
影響は全員に即座に及んだわけではない。しかし、その後の数ヶ月で、転送メールがスパムに入る頻度が増えた。理由は、これらのDMARC執行変更が大量送信者だけでなく、転送メールも含むすべてのメールに対して適用される受信サーバの厳格さの基準を引き上げたからだ。
聞いた話ではあるが、2024年初頭は、転送メールは安定して届いていたが、2025年半ばには、正当な転送メールの10通に1通がスパムに落ちていたらしい。2025年末には、特定の送信者からでは5通に1通の割合になっていた。変化は徐々だった。だから多くの人は、重要なメールが消えるまで気づかない。
やっぱり何かが変わっていた。MailRouteは2026年半ばに「何年も問題なく動いていた転送が、突然バウンスしたり、静かにすべての転送メールを受信者のスパムフォルダに送り込んだりし始める」と記録している（MailRoute, 2026）。DMARCguardは、Gmailが正当な送信者からの転送メールに対して「421 4.7.26 Your email has been blocked because the sender is unauthenticated」と返すことを報告している（DMARCguard, 2026）。TrekMailも同じパターンを述べている。「メッセージが消える。送信者にバウンスは来ない...受信メールサーバにとって、転送メールはスプーフィングされたメールと見分けがつかない」（TrekMail, 2026）。
ARCとは何か、何をするか
ARCはAuthenticated Received Chain（認証受信連鎖）の略だ。中継メールサーバ——転送サービス、メーリングリスト、ゲートウェイ——が、認証結果をホップを越えて保存するために設計されたプロトコルだ。
実際にどう動くか説明する。転送サービスが送信者からメールを受信すると、SPFとDKIMをその時点で確認する。そして結果を記録する。「このホップでSPFは通過した。このドメインのDKIMは通過した。」自分の鍵でこの記録を暗号署名する。Gmailに転送するとき、この署名付きのARC結果をヘッダに含める。
Gmailは転送メールを受信する。SPFは失敗する。転送サービスのIPになり、送信者のIPではなくなったからだ。DKIMは生き残るかもしれないし、そうでないかもしれない。しかしGmailはARC署名を確認する。転送サービスが前のホップでの認証結果を保証したことを見る。転送サービスが信頼されていれば、GmailはARC結果をDMARC評価に反映する。転送メールは正当なものとして扱われ、疑わしいものではなくなる。
ARCは直接SPFやDKIMを修正しない。受信サーバが中間で何が起きたかを理解するための信頼の連鎖を追加する。封印の壊れた荷物が届くのと、配達人から「受取時は封印が intact だった」という説明書きが付いた荷物が届くのとの違いだ。
なぜ多くの転送サービスがARCを実装しないか
ARCは新しいプロトコルではない。2019年に標準化された。多くの転送サービスがこれを欠いている理由は単純だ。正しく実装する技術的難度が高く、DMARCの執行が広まるまでは必須ではなかったからだ。
実装には以下が必要だ：
- 受信メールのSPFとDKIM結果を確認し、保存すること。
- メールヘッダに正しい形式と順序でARC連鎖を構築すること。
- 鍵ペアでARC結果に署名し、公開鍵をDNSに公開し、鍵のローテーションを管理すること。
- エッジケースを処理すること。上流からの破損したARC連鎖、不正な署名、ループなど。
多くの転送サービスは、DMARCの執行が実務的な懸念となる前に構築された。彼らの設計は、「メールが届けば転送でき、受信サーバはそれを受け入れる」という前提に立っている。その前提は何十年も成り立っていた。もう成り立たない。
私はKaiMailをARCから構築した。この問題に既に苦しめられていたからだ。転送メールが静かに消えるのは避けたかった。しかし、私は少数派だと承知している。一部の最大手サービスを含め、多くのサービスはまだARCを実装していない。彼らのユーザーは、理由を理解しないまま、その結果を体験している。
自分でできること
メール転送を使っているなら、2つの確認が有効だ。
1つ目。自分の転送サービスがARCをサポートしているか確認する。最も簡単な方法は、転送アドレスを通じてGmailにメールを送り、Gmailで元のメッセージヘッダを表示することだ。ARC-Seal:で始まるヘッダを探す。あれば、そのサービスはARCを実装している。なければ、実装していない。ないからといって必ずスパムに入るわけではない。しかし、DMARCの執行が強まるにつれ、スパムに入るリスクが高まることを意味する。
2つ目。送信元ドメインを管理しているなら、SPFとDKIMの両方が設定されていることを確認する。ARCを実装した転送サービスでも、観測したものを保証できるだけだ。送信者がSPFレコードもDKIM署名も持っていなければ、保存するものがない。ARCは元のメールが正当だった場合に助ける。認証を持たなかったメールに魔法のように認証を加えるわけではない。
転送サービスを選ぶ際、ARCはチェックリストに入れるべき項目だ。唯一の要素ではない。価格、設定の容易さ、Webhook、送信機能もすべて重要だ。しかし、配達性はメール転送の核心の約束だ。転送メールを確実に受信トレイに届けられないサービスは、どんなに安く、どんなに簡単でも、その約束を果たしていない。
長期的な視点
メールは、これまで構築された最も信頼性の高いメッセージングシステムだ。ウェブより先にあり、すべてのソーシャルネットワークを生き延び、身元確認、アカウント回復、ビジネスコミュニケーションの普遍的な識別子であり続けている。しかし、その信頼性は、より単純なトポロジー——送信者1人、受信者1人、中間者なし——向けに設計された信頼メカニズムに依存している。
転送サービスは中間者だ。私たちは送信者と受信者の間に座り、プロトコルは元来私たちのために設計されていなかった。ARCはこの隙間を埋めるパッチだ。これは理論的なおまけではない。メールを誤ってスパムと分類するのを防ぐメカニズムだ。アーキテクチャがその下で変化したからだ。
ARCがメール転送を完全にするわけではないと主張しているわけではない。スパマーはARC連鎖を悪用しようとする。だから受信サーバは、確立された評価を持つサービスからのARC結果だけを信頼する。鍵のローテーション、署名検証、連鎖の検証はすべて運用オーバーヘッドを増やす。しかし、ユーザーが受信を期待したメールを静かに失うという代替案は、より悪い。
転送サービスを運営し、まだARCを持っていないなら、それは必要だ。転送サービスを利用し、自分のサービスにそれがないなら、何を引き換えにしているか知るべきだ。そして、転送メールの一部がなぜ消えるのか理解せずに転送しているなら、今は知っている。メールは壊れていない。信頼の連鎖が壊れている。