大東 信仁（ものくろ） 
「さくらインターネットでメール転送の設定をしたのに、Gmailから送ったメールだけが転送先に届かない」ということ、ありませんか？
クライアントさんのメール転送設定をしていて、まさにこの問題にぶつかりました。
2024年2月のGoogleによるDMARCポリシー変更と、さくらインターネットのメール転送の仕様が組み合わさって起きている構造的な問題でした。
同じ問題でハマっている方のために、原因の特定から解決までの流れを共有します。
起きていたこと
構成はこんな感じです。
Aさん（Gmail）
↓ メール送信
独自ドメインメール（[email protected]）← さくらインターネット スタンダード
↓ 全転送設定
Bさん（Gmail）[email protected] のメールボックスにはちゃんと届いています。でも、転送先のGmailには届かない。
迷惑メールフォルダにも入っていません。完全に消えているんです。
ところが、Gmail以外から送信されたメールは、同じ転送設定で問題なく届きます。
Gmailからのメールだけが転送に失敗する。
これは困りました。
なぜGmailだけ？──3段階の認証の仕組み
メールの世界には、なりすまし対策として3つの認証技術が動いています。
- SPF──「このメールは正規のサーバーから送られたか？」をIPアドレスで確認する仕組み
- DKIM──「このメールは途中で改ざんされていないか？」を電子署名で確認する仕組み
- DMARC──「SPFかDKIMのどちらかが通ったか？通らなかった場合どうするか？」を定めるポリシー
ポイントは、DMARCはSPFかDKIMのどちらか一方が通ればOKということです。両方失敗して初めて、DMARCポリシーに従ったアクション（破棄・隔離など）が発動します。
転送すると何が起きるか
メールが転送されると、この認証の仕組みが壊れます。
SPFは確実に失敗する
SPFは「送信元のIPアドレス」で正当性を判断します。GmailのサーバーIPはgmail.comのSPFレコードに載っているから認証が通ります。
しかし、さくらのサーバーが転送する時、送信元IPはさくらのサーバーに変わります。gmail.comのSPFレコードには載っていません。
→ SPF: FAIL（確定）
DKIMは「壊れるかどうか」がサーバー次第
DKIMの電子署名は、メール本文のハッシュ値に基づいています。転送時にメール本文が1バイトでも変わると、署名が無効になります。
ここがさくらインターネットの仕様がこうなっている様子。
さくらのMTA（メール転送エージェント）である maildrop は、テキスト形式のメール本文を転送時にデコード→再エンコードする処理を行います。この過程で本文のバイト列が変わり、Gmailが付与した元のDKIM署名が無効になります。
→ DKIM: FAIL（さくらの場合）
DMARCの結果
SPFもDKIMも失敗。DMARCは両方失敗した場合にポリシーを参照します。
2024年2月以前、gmail.com のDMARCポリシーは p=none（何もしない）でした。認証に失敗しても、受信側は普通に配信していました。
2024年2月、Googleはgmail.comのDMARCポリシーを p=quarantine（隔離）に変更しました。
この変更により、Gmail発のメールがDMARC認証に失敗すると、受信サーバーはそのメールを迷惑メールに振り分けるか、サイレントに破棄するようになりました。
なぜそれ以外のメールは届くのか
DMARCポリシーを p=none に設定していたり、DMARCレコード自体の設定がない場合は、届くわけです。
p=none の場合、SPFもDKIMも失敗してDMARC認証に落ちたとしても、受信側は何もアクションを取りません。普通に配信されます。
つまり、Gmailだけが届かないのではなく、DMARCポリシーが厳しいドメインからのメールだけが届かないんです。大手銀行など p=reject を設定しているドメインからの転送メールも同様に失敗する可能性があります。
さくらの設定で解決できないか
さくらインターネットは2024年1月31日にDKIM・DMARC・ARC機能を全プランに提供開始しています。サーバーコントロールパネルからDKIMを有効にすると、ARC署名も自動的に付与されるようになります。
ARCは「転送前にDKIM/SPFが通っていた」ことを記録する仕組みです。
でも解決しない
さくらのmaildropが本文を再エンコードしてDKIM署名を壊すという根本原因は、DKIM/ARC設定では解決できません。
ARC署名は「転送前は認証が通っていた」ことを伝えますが、受信側のGmailがその情報をどこまで信頼するかはGoogleの裁量です。
さらに、さくらはSRS（Sender Rewriting Scheme）に非対応です。SRSはエンベロープFromを転送サーバーのドメインに書き換えることでSPF認証を通す仕組みですが、さくらはこの書き換えを行いません。
Xserverなら届く理由
実際に検証したところ、同じ構成でもXserverでは転送メールが届くことを確認しています。
違いは、転送時にDKIM署名が壊れるかどうかです。
| さくら（maildrop） | Xserver（Postfix） | |
|---|---|---|
| 転送時のSPF | FAIL | FAIL |
| 転送時のDKIM | 壊れる | 残る |
| DMARC結果 | FAIL | PASS |
XserverのPostfixはメッセージ本文をそのまま転送するため、Gmailが付与した元のDKIM署名が保持されます。SPFは失敗しますが、DKIMが通るのでDMARCはPASS。
MTAの転送時の挙動の違いが明暗を分けています。
解決策
方法1：Cloudflare Email Routing（無料・おすすめ）
ドメインのDNSをCloudflareに移管し、Cloudflare Email Routingで転送する方法です。
Aさん（Gmail）
↓ メール送信
[email protected] → Cloudflare Email Routing（SRS対応・DKIM保持・ARC署名付与）
↓ 転送
Bさん（Gmail）← 正常に届く完全無料です。
SRS対応でエンベロープFromを書き換え、元のDKIM署名も保持するため、大半のメールが正常に転送されます。
設定の流れはこんな感じです。
- Cloudflare無料プランに登録
- ドメインのネームサーバーをCloudflareに変更
- Cloudflareダッシュボードで転送ルールを作成
- 必要なMX・TXTレコードはCloudflareが自動生成
所要時間は30分〜1時間程度。ネームサーバー変更の反映待ちで最大48時間かかる場合があります。
ネームサーバーを変えるとAレコードなどもCloudflare側で再設定が必要なので、サイトリニューアルなどのタイミングと合わせると効率的です。
Gmailの「別のアドレスから送信」機能はそのまま使えます。
方法2：Google Workspace（月額約1,100円〜・最も確実）
独自ドメインのメールをGoogleのサーバーで直接運用する方法です。MXレコードをGoogleに向けるため、そもそも転送が発生せず、認証問題は原理的に消滅します。
コストはかかりますが、メールの到達性という観点では最も確実な選択肢です。
方法3：サーバーをXserverに移行
ホームページもメールもXserverに移す方法です。XserverのPostfixは転送時にDKIM署名を保持するため、同じ転送設定でもGmailに届きます。
ホームページのリニューアルやサーバー統合を検討しているなら一石二鳥です。
方法4：メールクライアントで直接受信
ThunderbirdなどのメールクライアントでさくらのIMAPを直接参照し、Gmailと並行して確認する方法です。転送を使わないので問題は発生しません。ただしWeb版Gmailだけで完結しなくなります。
まとめ
この問題はさくらインターネットのバグではなく、メール転送とDMARC認証の構造的な相性問題です。
主要メールプロバイダがDMARCポリシーを厳格化する流れは今後も続きます。「転送すれば届く」という前提が成り立たなくなってきている時代です。
ちなみに、AIにメールヘッダーを丸ごと渡して分析してもらったら、原因特定が一瞬でできました。人間が読むには辛いヘッダー情報も、AIの得意分野です。
根本的には、転送に依存しないメール運用への移行が最も合理的です。
Cloudflare Email Routingは無料で使えて設定も簡単なので、同じ問題でお困りの方はぜひお試しください。
