FreeBSDに限定した話ではないですが
はじめに
2026年1月からGmailがPOP機能を廃止することが発表され、多くの記事が「転送に
切り替えろ」と推奨しています。
しかし、これは間違いです。転送は基本的に機能しません。
FreeBSD環境でメールサーバを運用している経験から、転送が抱える技術的な問題
と、その回避方法について解説します。
なぜ転送はダメなのか
SPFの仕組み上の問題
転送の基本的な問題は、SPF（Sender Policy
Framework）という仕組みと根本的に相性が悪いことです。
送信元ドメイン → 転送サーバ → Gmail
(example.com) (your-server) (受信拒否)
転送されたメールは、送信元IPアドレスが転送サーバのものになります。しかし、
From: ヘッダーは元のドメイン（example.com）のまま。
Gmailが見るもの：
From: user@example.com- 送信IP: your-server のIP
- SPF検証: example.com のSPFレコードに your-server のIPは含まれていない
- 結果: SPF fail
厳密には、SPFの仕組み上、転送は元々不可能なのです。
Gmailの実際の挙動（経験則）
しかし、実際にはGmailへの転送が一部成功しているケースがあります。これは、G
mailが独自のルールを適用しているためです。
Gmailが転送メールを受け取る条件
私の運用経験から、Gmailは以下の条件で転送メールを受け取ります：
パターン1: DKIMが有効
- 元のメールにDKIM署名がある
- 転送後もDKIM検証が通る
-
かつ DMARC が
p=none
パターン2: Envelope Fromの一致
-
From:ヘッダー = Envelope From - SPFが通る
- DMARC が
p=noneまたは未設定
重要： DMARC が p=reject の場合、SPF/DKIM が fail
すると確実に拒否されます。
実際の運用データ
私のメールサーバで、Gmail転送の成功率を調べた結果：
転送成功: 130件 (58%)
転送失敗: 94件 (42%)
約6割は転送が成功していますが、4割は失敗しています。
転送失敗の主な原因
-
認証なし（94%以上）
- 送信元がDKIM署名していない
- かつ SPF も fail
- Gmail の「認証必須」ポリシーで拒否
-
DMARC p=reject（数%）
- みずほ銀行（mizuhobank.co.jp）
- 任天堂（nintendo.com）
- など、一部の大企業のみ
みずほ銀行の転送失敗ログ
Dec 20 10:38:04 mail postfix/smtp[xxxxx]: XXXXXXXXXX:
to=@gmail.com, orig_to=@example.jp,
relay=gmail-smtp-in.l.google.com[xx.xxx.xxx.xx]:25,
delay=1.7, delays=0/0/0.72/0.98, dsn=5.7.26,
status=bounced (host gmail-smtp-in.l.google.com said:
550-5.7.26 Unauthenticated email from mizuhobank.co.jp is not accepted
due to
550-5.7.26 domain's DMARC policy. Please contact the administrator of
550-5.7.26 mizuhobank.co.jp domain if this was a legitimate mail.
To learn about the DMARC initiative, go to
550 5.7.26 https://support.google.com/mail/?p=DmarcRejection
みずほ銀行は DMARC p=reject
を設定しているため、転送されたメールは確実に拒否されます。
主要銀行のDMARC設定（2025年12月調査）
主要銀行のDMARC設定を調査しました。p=reject
を設定している銀行のメールは、転送すると確実に失敗します。
| 銀行名 | ドメイン | DMARC ポリシー | 転送可否 |
|---|---|---|---|
| みずほ銀行 | mizuhobank.co.jp | p=reject | ❌ 不可 |
| 三井住友銀行 | smbc.co.jp | p=reject | ❌ 不可 |
| りそな銀行 | resonabank.co.jp | p=reject | ❌ 不可 |
| ゆうちょ銀行 | japanpost.jp | p=reject | ❌ 不可 |
| 三菱UFJ銀行 | bk.mufg.jp | p=none | ✅ 可能 |
| SBIグループ | sbigroup.co.jp | p=none | ✅ 可能 |
| 楽天銀行 | rakuten-bank.co.jp | p=quarantine | △ 隔離 |
| イオン | aeon.co.jp | p=quarantine | △ 隔離 |
DMARC ポリシーの意味
- p=reject: 認証失敗時に即座に拒否 → 転送不可
-
p=quarantine: 認証失敗時に隔離（迷惑メールフォルダ） →
届くが迷惑メール扱い - p=none: 認証失敗でも受信 → 転送可能
調査結果の詳細
みずほ銀行
$ host -t TXT _dmarc.mizuhobank.co.jp
v=DMARC1; p=reject; sp=reject; pct=100;
三井住友銀行
$ host -t TXT _dmarc.smbc.co.jp
v=DMARC1;p=reject;pct=100;
りそな銀行
$ host -t TXT _dmarc.resonabank.co.jp
v=DMARC1; p=reject; fo=1;
ゆうちょ銀行
$ host -t TXT _dmarc.japanpost.jp
v=DMARC1; p=reject; pct=100;
三菱UFJ銀行（転送可能）
$ host -t TXT _dmarc.bk.mufg.jp
v=DMARC1; p=none;
SBIグループ（転送可能）
$ host -t TXT _dmarc.sbigroup.co.jp
v=DMARC1; p=none; fo=1;
主要銀行の半数が p=reject
を設定しており、これらからのメールは転送できません。
Gmail to Gmail の転送は大丈夫
興味深いことに、Gmail自身は p=none を設定しています。
$ host -t TXT _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; ..."
そのため、GmailからGmailへの転送は問題なく動作します。
過去の問題：2024年のSPF厳格化
実は、2024年末にもGmailのポリシー変更がありました。
当時は、GmailをGmailへの転送は拒否されるという状況でした。これは、Gmai
lが「Envelope From と Header From の一致 + SPF
pass」を厳格に要求し始めたためです。
このとき、私は10年以上使っていた「Gmailに転送してスパムフィルタとして利用
」という運用を諦め、POP受信に切り替えました。
そして今回、そのPOP機能が廃止されるわけです。
p=reject を設定する企業の問題
p=reject を設定している企業は、フィッシング対策を重視しているのでしょうが
、正当なメール転送も殺してしまうという副作用に気づいていないか、気にしてい
ないようです。
p=reject を設定している主な企業・組織
運用ログおよびDNS調査から判明：
銀行：
- みずほ銀行（mizuhobank.co.jp）
- 三井住友銀行（smbc.co.jp）
- りそな銀行（resonabank.co.jp）
- ゆうちょ銀行（japanpost.jp）
その他：
- 任天堂（nintendo.com）
週に数件程度の転送失敗が発生していますが、幸いにも p=reject
を設定している企業は全体から見れば少数です。
多くの企業は p=none または DMARC
未設定のため、転送がある程度機能しています。
DMARCの設計上の欠陥
DMARC
は、転送というメールの基本的な使い方を完全に壊してしまったと言えます。
転送が壊れる仕組み
送信元ドメイン → 転送サーバ → Gmail
(example.com) (転送)
Gmailが検証：
- From: user@example.com ← 変わらない
- 送信IP: 転送サーバのIP ← 変わる
- SPF検証: example.com のSPFに転送サーバは含まれない → fail
- DKIM: 元の署名が転送で破損/検証失敗 → fail
- 両方 fail → DMARC の判定によって拒否
皮肉な状況
DMARC による認証強化の結果、スパマーが適応しました：
- typosquatting ドメインを取得（gmail.com → grnail.com）
- DKIM/SPF を正しく設定
- 技術的には「正しく認証されたメール」
- Gmail は受け取ってしまう
一方で、正当なメール転送は拒否されるという本末転倒な状況です。
根本的な問題：メールクライアントのUI
実は、技術だけでなくUIにも問題があります。
メールアドレスが見えない
iPhone/Android/Mac/Windows
のメールソフトは、デフォルトでメールアドレスを表示しません。
表示: "Apple Support"
実際: "Apple Support" no-reply@appIe-support.com
（Apple の l が大文字 I）
ユーザには「Apple Support」としか見えないため、grnail.com でも gmail.com
でも区別できません。
「ユーザフレンドリー」の弊害
- 技術的な情報は隠すというデザイン哲学
- メールアドレスを確認する習慣がなくなる
- フィッシングメールを見分けられない
技術で解決しようとした結果
- DKIM/SPF/DMARC で送信元ドメインを認証
- でもユーザはドメインを見ない
- スパマーは似たドメインを使う
- 認証は通るがフィッシングは防げない
- 一方で正当な転送は死ぬ
解決策はあるのか
現実的な選択肢
- 転送を諦める
- 58%は届くが、42%は失敗する
- 重要なメール（銀行など）が届かないリスク - メールクライアントで直接受信
- Thunderbird などで IMAP/POP3
- でも Gmail のスパムフィルタが使えない - Gmailの「他のアカウントからメールを確認」機能
- ← 2026年1月に廃止される - メールを読まない
- 究極の解決策（冗談です）
将来の可能性：SLM (Small Language Model)
Gmail
のスパムフィルタの代替として、ローカルで動くSLMを使う方法が考えられます：
- Llama 3.2 や Phi-3 など
- メールを読んで重要度を判定
- スパム確率を計算
- プライバシー保護（ローカル処理）
- API コストなし
これはまだ実験段階ですが、将来的な解決策になる可能性があります。
まとめ
- 転送は基本的に機能しません（約4割が失敗）
- 主要銀行の半数が p=reject を設定しており、これらのメールは転送不可
- Gmail の POP 廃止で、代替手段がなくなる
- メールエコシステムは、認証強化により徐々に壊れている
「転送に切り替えろ」という記事は、技術的な背景を理解していない誤った情報で
す。
残念ながら、現時点では完全な解決策はありません。
参考：FreeBSD でのメールサーバ運用環境
- Postfix + Dovecot
- OpenDKIM による DKIM 署名
- 逆引き DNS の重要性（動的IPパターンは拒否される）
- RBL (Realtime Blackhole List) の影響
FreeBSD でメールサーバを運用している方は、これらの設定も確認してください。
主要銀行のDMARC設定を表形式で追加し、転送可否を明確にしました。みずほ、三
井住友、りそな、ゆうちょの4大銀行が全て p=reject
という衝撃的な結果です。