フォームに送信があったはずなのに通知が担当者に届かない。自動返信がお客様の迷惑メールフォルダに入る。この2つは、SPF・DKIM・DMARC という送信ドメイン認証の設定か、通知メールの差出人の決め方が原因であることがほとんどです。
自社サイトの問い合わせフォームを運用していて、通知の取りこぼしを止めたい Web 担当・情シスの方向けです。仕様は RFC の原文で確認しました。
通知が消えるかどうかは「差出人を誰にしているか」でほぼ決まる
いちばん多い原因は、通知メールの From ヘッダに問い合わせ送信者のアドレスを入れている設計です。
MAIL FROM は封筒(エンベロープ)上の差出人で画面には出ません。From ヘッダはメールソフトが表示する差出人の行で、RFC では RFC5322.From と呼びます。
フォームの通知を送るのは自社サイトのサーバーや配信サービスです。ここで From に「お客様が入力したアドレス」を入れると、受信側から見れば「そのドメインが許可していないサーバーから、その名義で届いたメール」になります。SPF は fail し、そのドメインの DKIM 署名もありません。送信者側が DMARC で p=quarantine や p=reject を掲げていれば、通知は迷惑メール送りになるか、受け取ってもらえません。
直し方は単純で、From は自社ドメインに固定し、お客様のアドレスは Reply-To に入れる。
お客様宛の自動返信は自社ドメイン名義なので、自社の送信経路が SPF・DKIM に登録されているかがそのまま到達率になります。Gmail のメール送信者のガイドラインは 2024 年 2 月以降、送信量にかかわらずすべての送信者に SPF または DKIM の設定・有効な正引きと逆引き DNS・TLS 接続での送信を求めています(1 日 5,000 件以上を送る場合はさらに SPF と DKIM の両方、DMARC、From のドメイン一致)。フォーム通知は通数が少なくても前者の対象です。
症状から当たりをつけてください。
| よくある症状 | まず見るところ | ありがちな原因 |
|---|---|---|
| 担当者に通知が来ない | 通知メールの From ヘッダ | 送信者のアドレスを From に入れている |
| 通知が迷惑メールに入る | 自社ドメインの SPF・DKIM | フォームを動かすサーバーや配信サービスが未登録 |
| ある日から急に届かない | v=spf1 の TXT が 1 本か | サービス追加時に SPF を 2 本目として足した |
| 社内で転送した先で消える | 転送設定 | 転送で SPF が壊れる(仕様上の限界) |
3つの違いは「どのドメインを検証しているか」
SPF は封筒の差出人、DKIM は署名した組織、DMARC は画面に表示される差出人を見ています。
| SPF | DKIM | DMARC | |
|---|---|---|---|
| 規格 | RFC 7208 | RFC 6376 | RFC 9989 |
| 検証していること | 送信元 IP が MAIL FROM ドメインから送る許可を得ているか | 電子署名が署名ドメインの公開鍵で検証できるか | SPF/DKIM の結果が From と揃っているか |
| 見ているドメイン | MAIL FROM(封筒の差出人) | 署名の d= タグ(SDID) | RFC5322.From(画面に出る差出人) |
| DNS の置き場所 | ドメインの TXT | セレクタ._domainkey.ドメイン | _dmarc.ドメイン |
| 失敗したとき | 結果を返すだけ | 結果を返すだけ | p= で扱いを指示 |
SPF も DKIM も、単体では From ヘッダについて何も言っていません。 RFC 6376 は、SDID や AUID の値が他のヘッダフィールドの識別子と一致することは要求しない、と明記しています。両方を通しても画面の差出人が偽物である可能性は残り、ここを埋めるのが DMARC です。なお RFC 9989 は 2026 年 5 月公開で RFC 7489 を廃止しており、7489 前提の解説は古い記述を含みます。
設定の順番は SPF → DKIM → DMARC。DMARC は必ず p=none から
DMARC は SPF か DKIM のどちらかが揃っていないと意味を持ちません。逆順に入れると自社のメールが消えます。
| 手順 | やること | 確認の仕方 |
|---|---|---|
| 1 | 送信経路の棚卸し | 自社名義で送る経路をすべて書き出す |
| 2 | SPF を 1 本にまとめる | v=spf1 が 1 本か、DNS 参照が 10 個以内か |
| 3 | DKIM 署名を有効化 | サービスごとにセレクタを分け dkim=pass を確認 |
| 4 | DMARC を公開 | v=DMARC1; p=none; rua=mailto:... から |
| 5 | 潰してから強める | p=quarantine → p=reject。急がない |
手順1で最も抜けやすいのがフォームの通知と自動返信の経路です。私たちが実サイトのフォームを見てきた範囲でも、制作会社が設定したまま誰も把握していない、レンタルサーバーから直接送っている、という状態がよくありました。ここを書き出さずに DMARC を強めると、真っ先に落ちるのが問い合わせの通知です。
p= は none(表明しない)、quarantine(疑わしい扱い)、reject(不正扱い)の 3 つ。アライメント(From と SPF/DKIM のドメインの揃い方)を決める aspf adkim は既定がどちらも緩和(r)で、サブドメインから通知を送っているならこのままが安全です。RFC 9989 では旧仕様の pct が削除され、テスト中を示す t=y に置き換わりました。
フォーム運用でつまずく失敗と、その戻し方
多くはメール送信サービスを足したときに起きます。
SPF レコードを 2 本書いてしまう。 フォーム用の配信サービス追加時に v=spf1 の TXT をもう 1 本足すのが典型です。RFC 7208 は、該当するレコードが複数見つかった場合は permerror を返すと定めています。必ず 1 本に統合します。
include を足しすぎて 10 個を超える。 RFC 7208 は、DNS 参照を伴う項目(include a mx など)の合計を 10 個に制限しなければならない(MUST)としています。配信サービス・CRM・フォーム通知と足すと簡単に超え、超えれば permerror で SPF は評価されません。使っていない include を消すか、サブドメインで経路を分けます。
転送の fail で慌てる。 通知を個人アドレスへ自動転送すると送信 IP が変わるため、元ドメインの SPF は fail します。仕様上の限界で、fail 件数だけで p=reject を判断しないでください。
p=reject を急いで通知が届かなくなる。 RFC 9989 も、正当な利用のメッセージが検証に失敗しうること、ポリシー公表の前にその不備を解消しなければならない(MUST)ことを述べています。p=none でレポートを数週間〜数か月見て、fail を説明できてから上げます。
DMARC レポートは「知らない送信元」を探すために読む
rua に届く集計レポートは、手順1の棚卸し一覧と突き合わせて読みます(ruf は個人情報の扱いが重く後回しで構いません)。
- 知っている送信元が fail → 自社の設定漏れ。たいてい最初に見つかる
- 知らない送信元が fail → なりすましか、部署が個別に契約したサービス。まず後者を疑う
- 知らない送信元が pass → 棚卸し漏れ。フォームの通知経路がよくここに出る
ここまでは「自社が送るメール」の話。フォームに届く中身は別問題
認証を整えると通知は届くようになりますが、フォームに外部から投稿される内容には構造上まったく効きません。
経路が違うからです。フォームからの送信はブラウザから自社サイトへの HTTPS リクエストで、SMTP を通らないため MAIL FROM も DKIM 署名もありません。その後に飛ぶ通知の差出人は自社ドメインです。DMARC から見れば、営業も本物の問い合わせも等しく「自社が自社に送った正規のメール」として pass します。認証を整えるほど、営業メールもきれいに届きます。
私たちが分析した、美容商社(国内最大手・上場)の実フォームデータ(3 種類・合計 1,894 件・約 20 か月分)では、汎用フォームの 56.2%、中途採用フォームの 73.1% が営業目的の送信でした(文面の特徴による簡易な分類)。業種・規模・フォームの性格で比率は大きく変わる一社・一時点のサンプルですが、ドメイン認証を整えてもこの層は 1 件も減りません。しかも通知が正しく届くようになった分、担当者の受信箱に並ぶ件数はむしろ増えます。
フォーム側に必要なのは、送信元の認証ではなく内容による選別です。私たちは自社サイトを含む複数の実サイトにこの選別を設置して運用しており、いまは 99%+ を自動で遮断し、残り約 1% を人が判断する形に落ち着いています(実装はセキュリティ)。通知の設計は問い合わせフォームの作り方、取引先を名乗る内容の見抜き方はなりすましメールの対策、入口別の手当ては会社の迷惑メール対策にまとめています。
よくある質問
通知メールの差出人をお客様のアドレスにしたいのですが
From には自社ドメインを入れ、お客様のアドレスは Reply-To へ。返信の宛先は Reply-To が優先されるため運用は変わらず、認証だけが通ります。
SPF と DKIM は両方必要ですか
DMARC は一方が揃えば pass しますが、両方が推奨です。転送で SPF が壊れても DKIM が残る冗長性が効きます。
DMARC を設定すると迷惑メールは減りますか
自社ドメインを騙るなりすましは減らせますが、自社に届くものは減りません。DMARC は「自社の名前を守る」仕組みで、「届くものを選別する」仕組みではありません。
設定したのに反映されません
DNS の TTL 分は待ちます。SPF は DNS TXT レコードとしてのみ公開すると RFC 7208 が定めており、かつての専用レコード型は使いません。DMARC は _dmarc. が付いたホスト名かを確認します。
明日やること
- フォームの通知を1通開き、From が自社ドメインかを見る。違えば Reply-To へ移す
- 自社名義で送る経路を書き出す(フォーム通知・自動返信・配信サービス・CRM・複合機も)
- 自社ドメインの TXT を引き、
v=spf1が 1 本か、DNS 参照が 10 個以内かを数える _dmarcにv=DMARC1; p=none; rua=mailto:<受信用アドレス>を公開し、レポートで漏れを潰す- 届くようになった後の「中身の仕分け」は別問題として切り分ける。進め方は問い合わせフォームの営業メール対策に
自社のフォームにどれだけ営業が混じるかは無料診断で確認できます。選別を試すなら14 日間の無料トライアルをご利用ください。