【設計者向け】迷惑メール判定されないお問い合わせフォーム設計
― Rspamdのシンボルから逆算する実装チェックポイント ―
はじめに
お問い合わせフォームから送信したメールが、
一部のキャリアメールに届かない
迷惑メールに振り分けられる
という問題に遭遇したことはありませんか？
私の場合、下の環境で確認しました。
大手国内SaaS・メールサービスプロバイダ
国内キャリアメール
本記事では、
受信側がRspamd系ロジックで判定している想定で、
スパム判定されないWebフォーム設計を設計者視点で解説します。
なぜフォームメールは疑われるのか
フォームメールは構造的に：
送信者と実際の送信元がズレる(調整不足)
テンプレート文面(スパムパターン/シグネチャに合致しやすい)
URLを含む
一方向通信
簡単に言うと、スパムと特徴が似ているってことです。
💡 結論
フォームメールは「普通に作るとスパム寄りになる」
むしろスパムのほうがまともに見える
✔ チェックポイント①
From と Envelope From の整合性
❌ NG例
Header From: user@gmail.com
Envelope From: www-data@server.local
🔥発生しやすいシンボル(Rspamdの標準シンボル)
FORGED_SENDER
FROM_NEQ_ENVFROM
👉 なりすまし扱い
🆗 正しい設計
From: no-reply@example.com
Envelope From: no-reply@example.com
Reply-To: user@gmail.com
✔️ ポイント
Fromは自ドメイン固定
ユーザー入力はReply-Toへ
✔ チェックポイント②
Message-ID の整合性
❌ NG例
Message-ID: <12345>
🔥 発生しやすいシンボル
MISSING_MID
INVALID_MSGID
MID_RHS_NOT_FQDN
🆗 正しい例
Message-ID: 20260421.123456.abcdef@example.com
✔️ ポイント
FQDN必須
Fromと同一ドメイン
一意性確保（時刻＋ランダム）
ちゃんとRFC 5322に目を通したほうがいい
💡 Message-IDは“身元証明”です。正しく設定しましょう。
✔ チェックポイント③
逆引き（rDNS）と直接配送
❌ NG構成
(DNS設定に問題がある)Webサーバ → 相手MXへ直接送信した場合はとくに注意
🔥 発生しやすいシンボル
RDNS_NONE
HFILTER_HOSTNAME_UNKNOWN
DIRECT_TO_MX
🆗 正しい構成
Web → SMTPサーバ → 外部
ほとんどのホスティングサービスではsendmailを使うことで対策OK
✔️ rDNSの正しい状態
IP → mail.example.com
mail.example.com → 同IP
💡 クラウドインスタンス やVPS はデフォルトNGもあるので、DNS周りはチェックしましょう
✔ チェックポイント④
MIME構造の不整合
❌ NG
HTMLのみ
boundary不正
Content-Type不一致
🔥 発生しやすいシンボル
MIME_HTML_ONLY
MIME_BAD
🆗 正しい構造
multipart/alternative
├ text/plain
└ text/html
✔️ ポイント
text/plain必須
自前生成は避ける
→ 信頼できるライブラリを使いましょう
✔ チェックポイント⑤
本文内URLの扱い
❌ NG
短縮URL
表示URLとリンク先不一致
IP直リンク
🔥 発生シンボル
PHISHING
R_SUSPICIOUS_URL
SURBL_*
🧑🔧設計指針
URLは最小限
Fromドメインと一致
短縮URL禁止
💡正規のDMなどもけっこう短縮URLで引っかかっています。
短縮URLが本当に必要かどうかを含めて検討の余地がありますね。
✔ チェックポイント⑥
解除導線（Unsubscribe）の有無
❌ NG
配信停止手段がない
一方通行メール
🤔 なぜ重要か
メールフィルタはスコアだけでなく、ユーザー行動（迷惑メール報告）を誘発してしまいます。
解除手段がない場合：
👉 ユーザーは「迷惑メール報告」するしかない
👉 送信者のレピュテーションが低下
👉 結果的に到達率が悪化
📖 公式ガイドライン（Google）
マーケティングメールはワンクリックで配信停止できる必要があります。
https://support.google.com/mail/answer/81126?hl=ja
📧 推奨実装（ヘッダ）
List-Unsubscribe: https://example.com/unsubscribe, mailto:unsubscribe@example.com
List-Unsubscribe-Post: List-Unsubscribe=One-Click
📧 本文での補助導線
配信停止をご希望の場合はこちらからお手続きください。
または
このメールに返信いただくことで配信停止のご連絡を承ります。
✔️ ポイント
Rspamd単体では強い加点要素ではない
しかし「reputation（信頼性）」に影響する
苦情率を下げる重要な要素
フォームメールであっても、
自動返信メール
継続的な通知メール
などの場合は、解除導線を用意することで迷惑メール判定のリスクを下げることができます。
💣 よくある“落ちるヘッダ構成”
Envelope-From www-data@server.local
From: user@gmail.com
Message-ID: <12345>
HTMLのみ
直接配送
URL多数
🔥 発生シンボル(典型的なコンボ)
FORGED_SENDER
MISSING_MID
MIME_HTML_ONLY
DIRECT_TO_MX
✅ 実務チェックリスト
🚀 必須
✅FromとEnvelope From一致
✅ Message-ID正常
✅ SMTPリレー使用
✅ rDNS正しい
✅ MIME正規構造
👍 推奨
[ ] text/plain併用
[ ] URL最小化
[ ] Reply-To適切
🎯 まとめ
✉️ フォームメールは“メールとして正しいか”がすべて
💡 最後に
ここまで「Webフォームからのメールをいかに落とされずに届けるか」という話をしてきました。
ただ正直なところ、今の時代においては「がんばってフォームを自作すること自体が適切なのか？」という視点も必要だと思います。
UIは Googleフォームなどで簡単に構築できますし、取得したデータはAIエージェントに渡せば柔軟に処理できます。
それに対して従来型のWebフォームは、
CAPTCHA実装の不備
スパム対策の甘さ
メール送信まわりの設計不備
といったリスクを抱えがちです。
つまり
「メールが届かない問題」以前に、
フォームそのものがリスクになっているケースもある
と思うのです。
もちろん、要件によっては自前フォームが必要なケースもあるでしょう。
その場合は本記事のチェックポイントが参考になれば幸いですが、一度立ち止まって、
“安全に作る”だけでなく“作るべきか”も含めて設計する🤔
という視点が重要なのかなと思います。
