2024年最新版:Gmail送信者向け新ガイドライン対応マニュアル
Gmailでは、2024年2月以降から「メール送信者のガイドライン」が適用されます。このガイドラインに則って送信が行われていない場合、迷惑メールなどと自動判定されて送信拒否や迷惑メールフォルダへの振り分けが行われる可能性があります。業務で使用している送信メールが該当しないか確認し、必要に合わせて対応を取りましょう。
新ガイドラインの概要
Googleは、2024年2月以降にメール送信者に対するガイドラインの一部を変更しました。
従来の要件に加えて、1日5,000件以上メールを送信し、かつ個人用Gmailアカウント宛てに送信する個人・団体に、追加認証等を義務付けています。
これらはスパムメールや迷惑メールに対応するためのものです。
また、マーケターにとっては必要なメールでも、受信者にとっては不要なメーリングリストからのメールなどへの対応も含まれています。
なお、Google Workspaceを利用した別ドメイン宛のメールは新ガイドラインの対象外となっています。
ただし、今後同様のガイドライン変更が行われる可能性もあるので、早い段階で対応しておくことをおすすめします。
すべての送信者の要件
まずは、変更前・変更後で共通しているガイドラインを確認します。
ドメインにメール認証を設定する
ドメイン にSPF、またはDKIMの設定を行います。
ドメインは、インターネット上から発信者・受信者を特定してメールの送受信をできるようにするためのものであり、インターネット上の住所に相当します。
SPFはSender Policy Framework、DKIMはDomainKeys Identified Mailの略で、いずれも送信元が異なるなりすましメールを判定するために使われるドメイン認証の方法です。それぞれ異なる方式でチェックしているので、両方とも対応しておくと、メールの安全性がより高まります。
ドメインの管理サービスによってこれらのメール認証の設定方法は異なるので、各管理サービスのヘルプページなどから確認してください。
DNSレコード・PTRレコードがあることを確認する
ドメインから送信元IPアドレスを調べる「正引き」を可能にするのがDNSレコードです。逆に、送信元IPアドレスからドメインを調べる「逆引き」を可能にするのがPTRレコードです。
これらが一致することで、ネットワーク上でコンピューターを識別するための送信元ホスト名 が、送信元IPアドレスと関連付けられていることを検証できます。
PTRレコードの対応は、いくつかのドメイン管理サービスでは対応していないケースもあるようなので、実際に使用しているサービスのヘルプページ等で一度確認してみましょう。
メールの送信にTLS接続を使用する
TLS(Transport Layer Security)は、メールを暗号化するインターネットプロトコル(IP)の一種です。IPは、ネットワークを経由してデータを送信する際に、正しい送り先に正しい内容が送信できるようにするための情報暗号化・解読法などを定めた通信規則を指します。
TLSは暗号化することでメールへの不正アクセスを防ぎ、内容の改変を避けたり、個人情報を保護したりするのに役立っています。
以前はSSL(Secure Sockets layer)というシステムで同様に暗号化していましたが、TLSはより強固に情報を保護してくれます。
TLSの設定方法も各ドメイン管理サービスによって異なりますが、設定内に『TLSを設定する』等の項目がある場合は『利用する』に設定変更すればいいものが多いようです。確認して対応してみてください。
迷惑メール率を一定水準未満に保つ
Gmail宛てに送られたメールのうち、受信者に迷惑メールとして報告されてしまった割合を0.10%未満に維持する必要があります。
迷惑メールとして報告された割合が高いドメインは、今後も迷惑メールとして分類されてしまう可能性が高まります。逆に、迷惑メール率が低ければ、今後も迷惑メールとして扱うかチェックされる可能性が低くなります。
メールの内容や送信頻度をコントロールして、迷惑メールとして報告を受けないよう気を付けましょう。
その他留意事項
これら以外にも、
- Internet Message Format標準(RFC 5322)に適合したメール
- Fromヘッダーのなりすましの禁止
- メーリングリストなどを使用する場合はヘッダーにARCの追加を行う
などが求められます。
RFC 5322については非常にルールが細かく、かつイレギュラーが起こりにくい内容なので、補足的に後述します。
ヘッダーでのなりすまし行為は、送信元を誤認させるような意図的な修正を行うことを指します。
ARCは、メールが複数のサーバーを経由する際にそれぞれの認証結果を記録・保持する仕組みです。
メーリングリストなどの場合、送信依頼元から別サーバーを経由してメールが送信されるため、ARC非対応の場合はなりすましメールと誤認されてしまうリスクがあります。
1日5,000件以上送信する場合の義務
新ガイドラインでは「1日5,000件以上を送信する場合」について、義務が追加されました。
『すべての送信者の要件』を満たしている
まず、上記で解説した『すべての送信者の要件』は従来同様満たす必要があります。
これまでトラブルなくメールを送信できていた場合は特に問題ないでしょう。
下記項目を達成しているにもかかわらず迷惑メールとして処理されているようなケースでは、念のため再確認してみてください。
送信ドメインにDMARCメール認証を設定する
DMARCはSPFやDKIMを技術的基礎として利用した、なりすまし防止技術のひとつです。これを設定することにより、SPF、DKIMだけでは防ぎきれなかったなりすましメールも検知できるケースがあります。
DMARCの具体的な設定方法は各ドメイン管理サービスによって異なります。
基本的には
- SPFの設定
- DKIMの設定
- 電子署名の作成
- DMARCの設定
の4ステップで完了します。
マーケティング目的のメールはワンクリックで登録解除可能な状態にする
メーリングリストを利用しての送信など、マーケティングを目的としたメールの場合は、ワンクリックでメール配信登録を解除できるように設計する必要があります。
具体的には、送信メールに次の両方のヘッダーを含めることで対応可能です。
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe:※Google『メール送信者のガイドライン』より抜粋
なお、上記のURLはサンプルです。
また、何回もメールが返送されている(既にメールアドレスが無効になっていると思われる)ユーザーを手動で登録解除したり、メール開封率の低いユーザーに継続購読の意思があるか確認したりといった方法も推奨されています。
迷惑メールに分類されにくいメールの送信方法
上記に解説した方法を守ることでGmailによって自動で迷惑メールに振り分けられるリスクは低減します。
さらに、以下のような内容が推奨/非推奨として公開されています。
Googleが推奨する方法
1日の送信件数が5,000件未満の場合は、SPFもしくはDKIMのどちらかだけでもいいとされていますが、両方に対応することを推奨しています。
特定ドメインのメールは、同じIPアドレスから送信されていることが理想です。
もし複数のIPアドレスから送信しなくてはいけない場合は、メールの種類ごとに分け、異なるメールアドレスを指定するといいでしょう。
例えば、同一ドメインのメールを2つのIPアドレスを使用して送信する場合、セールスメールと告知メールなど、メールの内容に則して@の前の文字列を変え、それぞれ異なるIPアドレスに発信元を振り分けたうえで送信する、というような考え方です。
また、受信者の連絡先として登録されているアドレスからのメールは、迷惑メールに分類されにくくなります。
Googleが推奨しない方法
一方で、前述したような各種認証等を行っていても迷惑メールと判定されやすくなるケースもあります。
ある特定の内容を示したメールに異なる内容を盛り込むことは、避けた方がいいでしょう。顧客に送る領収書メールにプロモーションに関する内容を含めてはいけない、と例示されています。
社内など、内部で送信し合うようなメールを迷惑メールとして処理してしまうと、ドメインの評価が下がってしまいます。メールを受信するように登録していないユーザーに対するプロモーションメールの送信も、迷惑メールとして処理されてしまうリスクが高いです。
これらの行為は、他の顧客に対するメールもまとめて迷惑メールとして処理されやすくなります。
また、他者になりすましたメールや、ユーザーを自動的にメーリングリストに追加するようなフォームを使用したメールも避けましょう。
送信量を増やす際の注意点と対処法
メールを一斉送信する件数を急激に増やすと、メール監視ツールが反応して問題が生じるかもしれません。
具体的には、以前の送信量から2倍に増えると、送信レートの制限や、評価の低下につながるおそれがあります。
大量のメールを送信する際は、
- 24時間など一定間隔を空けてメールを送信する
- 少量からメール送信を行い、徐々に増やすようにする
- サーバーのレスポンス、迷惑メール率、ドメイン評価を定期的に確認する
ようにしましょう。
形式や送信サーバー、本文・ヘッダー構成を変更した際にも、少量のメールから徐々に配信を増やすように留意してください。
メールがうまく送れなくなった場合は、SMTPエラー率が低下するまで送信量を減らして対処します。それでもうまくいかない場合は、個別のメール内容や設定方法に問題がないかのチェックを行います。
その他留意したい点
それ以外に、以下の点にも気を付けます。
メッセージの書式
先ほど軽く触れた「メールの正しい形式」を定義しているRFC 5322について、簡単にまとめます。電子メールはヘッダー、本文、添付ファイルから構成されていることとされています。
ヘッダーには、発信日時、送信者アドレス、メッセージIDを含んでいる必要があります。
送信者アドレスは@の前(local)に最大64文字、@の後ろ(domain)に最大255文字までで指定できます。
localの終わり(@の直前)にはピリオド(.)が使用できないほか、ピリオドの連続使用(..)も禁止されています。
本文は1行当たり998文字が最大となっており、これを超過すると文字の処理ができなくなって送信エラーとなります。また、1行あたり78文字を超えるとプログラムにより自動改行になることがあるため、読みやすさの確保のために1行当たり78文字以内での改行が推奨されています。
ヘッダーの内容不備や不適切なメールアドレスの指定、1行が極端に長い文などは、意図して作成しないと違反しにくい内容です。
もし他の内容に全く問題がないにもかかわらずメールが送れない場合には、念のため確認してみましょう。
サードパーティのメールプロバイダを利用している場合
自身の持つドメイン・アドレスを使用してメールを送信することを第三者に許可する場合、第三者が送るメールについて、自身が責任を負います。
そのため、アドレスが意図しない方法で使われていることを報告するためのメールアドレスを、メール受信者に提供しておくことが推奨されています。
また、WHOISレコード(ドメインの所有名義の登録管理データベース)とabuse.net(ネット業者の苦情先窓口データベース)に登録されている連絡先情報が最新のものであるかを確認します。
あわせて、プロバイダのサービスを利用して、迷惑メールを送信したクライアントを排除するようにしましょう。
アフェリエイトマーケティング関連のアドレスと誤認されないように
アフェリエイトは、特定のリンクを経由してユーザーがアクセスした場合に、個人・団体に対して報酬を提供するというプログラムです。
この仕組みを利用してスパムを作成する際に、自社製品が意図せず紐づけられることで、自社ブランドが迷惑メールとして分類されてしまうリスクがあります。
定期的にアフェリエイトを監視して、迷惑メールを送信するプログラム等を排除しましょう。
テストメールはドメインから送信しない
架空のフィッシングメールを作成・送信して、社内のメールに対する意識喚起を行うケースがあります。
しかし、通常業務に使用しているドメインと同一のものからこうしたテストメールを送ると、ドメイン自体がフィッシング詐欺に使われているものと誤認され、拒否リストに追加されてしまうリスクがあります。
新ガイドラインに対応して適切な業務メールを
2024年に施行されたGmailの新ガイドラインは、1日5,000件以上のメールを送信しているユーザーに限定されたものです。そのため、中小企業や個人レベルでは、従来通りの使用方法でも当面問題はないかもしれません。
しかし、迷惑メールや詐欺メールはどんどん巧妙になってきており、今回の新ガイドラインが将来的に全送信者共通の義務になる可能性も考えられます。
今回は対象外だったとしても、早い段階から対策を行い、メールの安全性を高めておくことをおすすめします。
メール送信者のガイドライン|Google Workspace
「Gmail」にメールを送れなくなる恐れ、グーグルによる迷惑メール対策強化の衝撃|日経XTECH
Googleが発表したスパムメール対策、Gmailへの大量送信者に対する新しい要件について解説!|am.arara message
Gmailユーザへメールが届かなくなる?Googleが発表した「新しいメール送信者のガイドライン」とDMARC対応を解説!|NRIセキュアブログ
Gmailが設けた「メール送信者のガイドライン」とは?分かりやすく解説します。|TRICORN LAB
【解決策】2024年2月よりGmailガイドラインが変更!1日5000件以上の配信は対応必須!|blastmail
Benchmark Email サポートセンター|BENCHMARK
PTRレコードは何のために設定するの? DNSの逆引きとメール送信の関係について|ベアメール
Gmail:2024年2月までに対応が必要な「逆引き」の設定について|Googleの「メール送信者のガイドライン」より>対応が必要な場合|OSCARCHAIR.JP
TLS接続とSSL接続|Google Workspace管理者ヘルプ
RFC 5322 – Internet Message Format 日本語訳|RFC Trans
メールのARCとは? ARCの仕組み、設定が必要なケースを解説|ベアメール
DMARCとは?その仕組みと設定方法、SPFやDKIMとの関係|proofpoint
DMARCの設定方法を4手順で紹介!レコードの内容も解説|不正検知Lab
RFC5322: メールの基準を理解する – 必須ヘッダから正規表現まで|HENNGE