WordPressのお問い合わせ通知がGmailに届かない。ニュースレターが迷惑メールに入る。原因を調べると「Gmail送信者ガイドライン」が出てくるが、サーバーの設定と配信の運用が並んでいて、どこから確認するか迷いやすい。
この記事では、独自ドメインから個人用Gmailへ送るWordPressのメールを中心に、要件と確認先を整理する。自分で全部を設定する必要はないが、「レンタルサーバーだから任せておけばよい」とも限らない。実際の送信経路を確かめ、運営者とメール送信事業者の担当を分けて確認しよう。
個人運営でも、送信量によって要件は変わる
Googleのメール送信者ガイドラインが対象にするのは、末尾が@gmail.comまたは@googlemail.comの個人用Gmailアカウントへの送信だ。「個人用」は受信先の区分であり、送信者が個人か法人かを分ける言葉ではない。
基本となるのは、すべての送信者の要件。そのうえで、一括送信者には追加要件がある。公式の送信者ガイドラインFAQは、24時間以内に個人用Gmailへ約5,000件以上送る送信者を一括送信者として説明している。5,000件ちょうどなら対象外、とは考えない。
件数は同じプライマリドメインで合算され、サブドメインからの送信も含む。たとえばexample.comとnews.example.comで分けていても、別枠にはならない。WordPress以外の配信サービスも含めて把握する必要がある。一度一括送信者に分類されると、その後に送信量を減らしても分類は解除されない。
購読者が数百人のサイトでも、その人数だけで判定はできない。同じドメインの別サービスや過去の配信も確認し、該当しない場合は基本要件から整える。境界に近いなら、追加要件を後回しにしないほうがよい。
基本の6要件を、確認する場所で分ける
すべての送信者に示されている基本要件は次の6つ。右欄はWordPress運営で確認先を探すための整理で、サービスを契約すれば自動的に完了するという意味ではない。
| 基本要件 | 主な確認先 |
|---|---|
| SPFまたはDKIMで認証する | 送信サービスの認証設定と、利用中のDNS |
| 送信IPと正引き・逆引きDNSを対応させる | 実際にメールを送る事業者 |
| メール送信にTLSを使う | 送信事業者の配送設定。WordPressの接続設定も別に確認 |
| Postmaster Toolsの迷惑メール率を0.3%未満に保つ | 配信先・内容・頻度と、送信後の指標 |
| RFC 5322に沿ったメール形式にする | 配信ツールと、実際に送られたヘッダー |
| GmailのFromを詐称しない | フォームやニュースレターの差出人設定 |
最初に、フォーム通知、ニュースレター、自動返信を分けて、どのSMTPサーバーや配信サービスを使っているかを書き出す。WordPressを置くサーバーと、メールを送るサービスが別なら、確認する管理画面も変わる。
WordPressでは、Fromと認証するドメインをそろえる
フォームの通知メールをレンタルサーバーから直接送っているのに、Fromを自分の@gmail.comにしていないか。Google以外の送信元からGmailのアドレスを名乗る設定は避けたい。Googleの正規の認証済み送信経路を使う場合とは分けて考える。
独自ドメインから送る構成では、Fromに、その送信サービスで利用を認められ認証したドメインのアドレスを設定する。フォームに入力された訪問者のアドレスを、そのままFromに使うことも避ける。返信先を変える場合は、利用する送信サービスの制限や推奨を確認したうえでReply-Toを設定し、返信先と配信への影響を確かめる。
Fromの文字列を変えるだけで認証が完成するわけではない。SPFは実際の送信元を含め、DKIMは利用サービスの署名設定と公開鍵を確認する。DNSの登録先は、ドメインの購入先ではなく、現在そのDNSを管理している事業者だ。複数の送信サービスを併用しているなら、既存の設定を消さず、各サービスの案内を照合する。
基本の最低要件はSPFまたはDKIMだが、GoogleはSPF・DKIM・DMARCをそろえることを推奨している。DKIMを使う場合、鍵は1,024ビット以上が必要で、対応していれば2,048ビットが推奨される。自分で鍵を作り直す前に、利用中の事業者が提供する設定を確認しよう。
Contact Form 7の通知メールを設定する場合は、Contact Form 7の通知がGmailに届かないときの設定手順も参照してください。メールタブの送信元・返信先、採用する送信サービスへの接続、実際のフォームでの確認を扱っています。
PTR・TLS・メール形式は、任せる部分も確認する
PTRは送信IPからホスト名を引く逆引きDNSだ。そのホスト名のAまたはAAAAレコードが、元の送信IPへ戻る対応も必要になる。共用のメール送信サービスでは通常、IPを管理する事業者に確認する部分だ。自分のドメインのTXTを変更して直す項目とは限らない。
TLSも、接続を分けて見る。WordPressからSMTPサーバーへの接続は、利用者がプラグインで暗号化方式やポートを設定する場合がある。一方、そのSMTPサーバーからGmailへ配送するときのTLSは送信事業者側の担当だ。前者でTLSを選んだだけで、後者まで確認できたことにはならない。各サービスの接続手順に従い、配送側は事業者の案内や送信結果で確かめる。
「一般的なプラグインならメール形式に問題はない」とも言い切れない。Googleは、有効なMessage-ID、Fromにメールアドレス1つ、From・To・Subjectなどを重複させない形式を求めている。プラグイン同士の併用や独自のヘッダー追加があるときは、設定画面だけでなく実際のメールも見る。
形式エラーは、Postmaster Toolsと送信者要件のFAQでも、配信エラーと拒否メッセージを確認するよう案内されている。問題が出たら、日時・送信方法・エラーコードをそろえて、送信サービスやプラグインの担当へ相談すると切り分けやすい。
一括送信者はDMARCと登録解除も確認する
一括送信者には、SPFとDKIMの両方、DMARC、直接送るメールのFromドメインと認証ドメインの整合が求められる。両方の認証を整える要件と、DMARCが合格する条件は別だ。DMARCは、SPFまたはDKIMの少なくとも一方が成功し、その認証ドメインがFromと整合すれば合格する。
DMARCのポリシーはp=noneでも要件を満たせるが、既存のquarantineやrejectをnoneへ戻す案内ではない。新しく導入するなら、正当な送信元を洗い出し、レポートなどで認証を確認しながら方針を決める。noneは認証失敗メールの隔離・拒否を求めない方針であり、なりすまし対策や配送成功をそれだけで完成させるものではない。
マーケティングや購読メールでは、ワンクリック登録解除と、本文中の分かりやすい解除リンクも確認する。本文に解除ページへのリンクを置くだけでは、ワンクリック要件の代わりにならない。配信ツールがList-Unsubscribe-Postと、HTTPSの解除先を持つList-Unsubscribeに対応し、実際に解除処理を受け付けることが必要だ。
パスワード再設定や購入確認などの取引通知は、FAQではこのワンクリック要件の対象外とされている。ニュースレターと通知メールを同じものとして扱わず、本文に販促を混ぜていないかも見ておく。
Googleの購読メール向けガイドラインは、規模で限定せず、ワンクリック解除、48時間以内の解除処理、登録時のアドレス確認を案内している。少量配信でも、受け取りたい人が申し込み、やめたい人が無理なくやめられる運用を先に整えたい。
迷惑メール率は「送ったうちの迷惑メール入り率」ではない
基本要件はPostmaster Toolsの迷惑メール率を0.3%未満に維持すること。Googleは運用上、0.1%未満を保つことを推奨し、0.3%以上に達しないよう案内している。0.3%ぎりぎりを目標に送る、という意味ではない。
Postmaster Toolsのダッシュボード説明でいう迷惑メール率は、受信トレイへ配信されたメールのうち、受信者が迷惑メールとして報告した割合だ。対象にはDKIM認証済みメールという条件もある。全送信数を分母にした割合でも、Gmailが自動で迷惑メールに振り分けた割合でもない。
多くのメールが最初から迷惑メールへ入ると、この率が低く見えることもある。数字が低いだけで配送が良好とは判断せず、配信エラーや認証結果も合わせて見る。送信量の少ない日はデータが表示されないことがあり、空欄を0%と読み替えてはいけない。
運用では、同意のある宛先だけへ送り、ニュースレターと事務連絡を分け、急に大量送信しないことから始める。設定を直した後も、宛先リストや頻度がそのままなら問題が続く場合がある。返信・解除・エラーも、配信後に確認する仕事の一部だ。
1通の結果と、ドメイン全体の状態を分けて確かめる
まずは、問題が出ているのと同じフォームや配信ツールから確認する。受信トレイか迷惑メールに届いたら、パソコン版Gmailで「メッセージのソースを表示」を開き、SPF・DKIM・DMARCと、Gmail側が付けたAuthentication-Resultsを確認する。認証対象のドメインも見よう。
passはそのメールの認証結果であり、送信した個人の本人確認や本文の安全性、今後の受信トレイへの到達を保証しない。未着ならメールのソースは開けないので、送信元へ戻ったエラーや配信ログを先に確認する。
転送を挟む場合は、直接送信と分けて調べる。転送でSPFが失敗したり、本文・件名の変更でDKIMが壊れたりすることがあるため、Googleの転送メール向け案内に沿って、転送事業者の認証対応も確認する。通常のフォーム送信と同じDNS修正だけで解決するとは限らない。
継続的な確認にはPostmaster Toolsのセットアップ案内を参照し、認証に使うドメインを追加して所有権を確認する。登録しただけで直ちに全指標が見えるわけではない。データはリアルタイムではなく、送信量によって表示されない項目もある。1通のテストと、ドメイン全体の傾向を補い合わせて判断したい。
Opsoryの見解：担当を分けても、確認はつなげる
ガイドラインを満たす作業は、設定を二つ変えて終わるものではない。それでも、送信経路を特定すれば、自分で直す項目と、事業者へ確認する項目を絞れる。Fromと認証、送信サーバー、購読と解除、送信後の結果を一つずつつなげて確認するほうが、原因を決めつけて設定を動かすより進めやすい。
設定場所の具体例は、エックスサーバーのメールがGmailに届かないときの確認手順、ConoHa WINGのメールがGmailに届かないときの確認手順、ロリポップのメールがGmailに届かないときの確認手順にまとめた。仕組みから整理したい場合はメール到達率の基本、WordPressのニュースレターを切り分ける場合はMailPoetが届かない原因まとめも参照してほしい。
さくらのレンタルサーバのメールサーバーから送っている場合は、さくらのレンタルサーバからGmailに届かないときの確認手順も参照してください。実際の送信経路とDNSの管理先を確認し、利用するサーバーに合わせて設定を調べます。
mixhostのメールサーバーから送っている場合は、mixhostからGmailに届かないときの確認手順も参照してください。実際の送信経路とDNSの管理先を確かめ、現在の認証設定を確認するための案内です。
コメント