これまでに、いくつかの企業サイトのお問い合わせフォームから、実際に問い合わせを送ってみたことがあります。

何件かで、送信直後に届くはずの確認メール（自動返信）が、迷惑メールフォルダに入っていました。 届けていると思っていたものが、実は届いてなかった。そもそも受信すらされていなかった。

原因を調べると、案の定でした。ドメイン側のメール認証、SPF・DKIM・DMARCが、いずれも未設定だったのです。

1. 何が起きているのか

フォームの不具合ではありません

このトラブルが厄介なのは、サイト側には何の異常も現れない点です。

フォームは正常に表示され、入力もでき、「送信が完了しました」と表示されます。管理者宛のメールが届いていることもあります。それでも、お客様の手元にある確認メールは迷惑メールフォルダの中にある。

送信側で確認できるのは「送った」という事実までで、届いたかどうかを判断するのは受信側のサーバーです。この非対称性が、問題の発見を遅らせます。

とくに影響が出やすいのが、フォームにGmailのアドレスを入力された場合です。

判定の基準は、すでに変わっています

2024年2月以降、Gmailのアドレス宛にメールを送るすべての送信者に対して、次の条件が求められるようになりました。

  • 送信元ドメインに SPFまたはDKIM のメール認証が設定されていること
  • 送信元のIPアドレスに、有効な逆引きDNSレコードがあること
  • 送信に TLS接続 を使用していること
  • 迷惑メールとして報告される割合を 0.3%未満 に保つこと

さらに2025年11月以降は、条件を満たしていない送信元に対する措置が強化され、配信の一時的な拒否や永続的な拒否が行われる場合があると明記されています。

つまり、「これまでは届いていた」ことは、今日届く根拠になりません。 サイト側は何も変更していないのに、ある時期から通らなくなる。この点が、原因の特定を難しくしています。

呪文のように見える、4つの用語

SPF、DKIM、DMARC、SMTP。並べられると暗号のようですが、役割は明確に分かれています。

  • SMTP — メールを送るための正式な通り道です。この経路を通して送ることが前提になります。
  • SPF — 「このドメインのメールは、このサーバーから送られます」という宣言を、ドメインのDNSに登録するものです。
  • DKIM — 送信時にメールへ電子署名を付け、送信元が本物であることと、途中で改ざんされていないことを示します。
  • DMARC — SPFやDKIMの照合に失敗したメールをどう扱うか、という方針をドメイン所有者が示すものです。

まとめると、ドメインに認証情報を付与し、受信側がそれを照合して正規の送信元かどうかを判断できるようにする仕組みです。

専門用語が多く、DNSという普段は触らない領域を扱うため、Web制作の現場でも後回しにされやすい設定です。サイトの表示には一切影響しないため、問題が起きるまで誰も気づきません。

WordPressのフォームで起きやすい理由

もう少し具体的に、何が起きているのかをご説明します。

WordPressは、標準の状態ではサーバーに送信を任せる形でメールを出します。このとき、メールの名乗り（From）はサイトのドメインである一方、実際に送信を行った主体はサーバーになります。受信側から見ると、そのドメインとは関係のない場所から、そのドメインを名乗るメールが届いたという形になり、認証が通りません。

もう一つ、実務でよく見かけるのがフォームの送信者アドレスの設定です。

お問い合わせフォームの「送信者」欄に、入力されたお客様のメールアドレスをそのまま設定しているケースがあります。お客様がGmailのアドレスを入力した場合、自社のサーバーが gmail.com を名乗って送信することになります。これは、なりすましと判定されて当然の形です。

正しくは、名乗りは自社ドメインのアドレス、お客様のアドレスは返信先（Reply-To）に設定します。この一点の修正だけで改善する場合もあります。

2. 対応でできること、できないこと

先にお伝えしておきたい点があります。

「設定すれば必ず届く」と保証することはできません。 迷惑メールの判定は、認証の可否だけでなく、本文の内容、送信元の評判、受信者の操作履歴など、受信側の総合的な判断で決まります。100%の到達を約束できるサービスは存在しません。

弊社が行えるのは、受信側が正しく判断するための材料を、送信側で正しく整えることです。認証を通し、なりすましと誤解される形をなくし、迷惑メールに振り分けられにくい状態にします。実際、この対応だけで改善するケースが大半です。

対応の対象は、WordPressのプラグインを使用したお問い合わせフォームです。

3. 対応の進め方

STEP 1｜現状の調査

実際にフォームから送信し、届いたメールのヘッダー情報を確認します。SPF・DKIM・DMARCそれぞれの判定結果を実測し、どこで失敗しているのかを特定します。推測でDNSを変更することはしません。

STEP 2｜送信経路の整理

送信者アドレスを自社ドメインの実在するアドレスへ変更し、お客様のアドレスは返信先へ移します。あわせて、メールがSMTP経由で正しく送信される構成へ調整します。

STEP 3｜ドメイン（DNS）への認証設定

SPFレコードを、実際の送信経路に合わせて設定します。SPFは1ドメインにつき1本にまとめる必要があるため、既存の設定がある場合は統合します。続いてDKIMの署名を有効化し、DMARCはまず監視のみの状態から開始します。

STEP 4｜検証

Gmailを含む主要なメールサービス宛に実際に送信し、ヘッダー上で認証が成功していることを確認します。管理者宛メールと自動返信メールの両方を検証します。

STEP 5｜運用開始

DMARCのレポートを確認し、問題がなければ段階的に運用方針を強化します。運用開始後の確認方法もあわせてご案内します。

期間の目安

DNSの変更は反映までに時間がかかるため、調査から検証完了までおおむね数日〜1週間を見込んでいただいています。フォームの本数やドメインの構成によって前後します。

4. よくあるご質問

Q. DNSを変更して、サイトやメールが止まることはありませんか。

A. 既存のレコードは事前にすべて記録し、追加と修正のみを行います。とくにメールの受信に関わる設定（MXレコード）は変更しません。作業前に、現在の設定内容をご確認いただいたうえで進めます。

Q. 独自ドメインのメールを、別のサービスで利用しています。

A. Google WorkspaceやMicrosoft 365などでメールを運用されている場合でも対応可能です。その場合はSPFレコードを1本に統合し、双方の送信元を含める形に整理します。

Q. フォームのプラグインを入れ替える必要はありますか。

A. 原則として必要ありません。現在お使いのプラグインの設定と、ドメイン側の設定で対応します。ただし、開発が終了しているプラグインをお使いの場合は、あわせてご相談ください。

Q. 事前に準備するものはありますか。

A. サーバーのコントロールパネルと、ドメインを管理しているサービスのアカウントが必要になります。どちらが管理会社側にある場合でも、依頼の進め方をご案内します。

Q. 費用はどのくらいかかりますか。

A. ドメインの構成、フォームの本数、現在の設定状況によって変動しますので、調査結果をもとにお見積りします。まずは現状の確認だけでも承ります。

Q. 対応後、確実に届くようになりますか。

A. 前述のとおり、100%の到達を保証することはできません。迷惑メールに振り分けられにくい状態に整えることが目的であり、その効果はヘッダーの認証結果という形で確認できます。

5. メール認証の設定を代行いたします

「SPF・DKIM・DMARC・SMTP」は、それだけ見ると暗号のような言葉です。内容を理解していただく必要はありません。

  • 現在の設定状況の調査（実際に送信して、認証結果を実測します）
  • 送信経路とフォーム設定の見直し
  • ドメインへのSPF・DKIM・DMARCの設定
  • Gmailを含む主要サービス宛での到達確認

迷惑メールに入りにくくし、Gmail宛にも届くよう調整いたします。（前述のとおり、100%の保証はいたしかねます）

「うちのフォームは大丈夫だろうか」「そもそも設定されているのか分からない」という段階でも構いません。現状の確認からご相談を承ります。

ご相談はお問い合わせフォーム、またはサービス詳細はサーバー・サイト移管やWordPressサイト簡易セキュリティチェック、WordPress制作のページをご覧ください。

まとめ

お問い合わせフォームは、企業サイトにおいてお客様との最初の接点になる場所です。

そこで送られる確認メールが届いていないという状態は、機会そのものを失っていることを意味します。しかも、サイト側には何の異常も現れないため、失っていること自体に気づけません。

一度、ご自身のサイトのフォームから、Gmailのアドレス宛に問い合わせを送ってみてください。迷惑メールフォルダに入っていたなら、それが確認の合図です。

この記事は人間による下書きからAIのサポートを経て、最後に人間がチェックして投稿しております。