【2024/6/12最新】Gmail送信者のガイドライン変更の内容と対応方法を”１から10まで”解説！

2024年1月19日迷惑メール対策

2023年の10月にGoogleは、Gmailへのメール送信者に対して、2024年2月から施行される新しいガイドラインを発表しました。主に迷惑メール対策のための変更ではありますが、正規のメール送信者は迷惑メールでないことを表明するためにもこのガイドラインへの準拠が必要となります。

今回の変更は2023年10月の発表後も更新情報が出続けているため、この記事では最新情報を追いながら変更の内容と対策を解説していきます。

（2024年6月12日時点の情報を反映しました。）

Gmail送信者のガイドライン変更の概要

変更の内容は大きくは3種類に分けることができます。

送信メールを認証すること
未承諾のメールまたは迷惑メールを送信しないこと
受信者がメールの配信登録を容易に解除できるようにすること

要するに、送信元の正当性を正しく認証した上で、ユーザーが迷惑がらないようにメールを送信することがメール送信者には求められています。このガイドラインの要件を満たせていないメールは迷惑メールに割り振られてしまったり、受信を拒否されることがあります。

ガイドラインに準拠していない場合は何が起きる？

ガイドラインに準拠していないメールに関して、Googleはいくつかの種類のエラーコードが出るとアナウンスしています。

具体的なエラーの種類について詳しくは下記のGoogleのQ&Aをご覧ください。

どのようなエラーコードが送信されますか？

エラーコードが出ていない場合も、ユーザーの迷惑メールボックスに入っている可能性もあるので、ご注意ください。

また、明言はされていませんが、ドメインやIPに対するレピュテーションの低下へと繋がっていく可能性も否定できません。

今回アナウンスされた内容は、年々巧妙化していくスパムメールによる詐欺被害や、ユーザーが許可していないメールが大量にメールボックスに入ることによるユーザビリティの棄損に対する対策であり、メールを受信するユーザーにとっても大きな意味を持つ変更となっています。

ガイドラインの対象となるもの

ガイドラインの対象については以下のように整理されています。

対象の受信者の詳細

末尾が @gmail.com または @googlemail.comとなる個人のGoogleアカウントが対象となります。

※2023年12月の情報更新により、企業などが持つGoogle Workspaceのアカウントは対象から外れています。

参考：Email sender guidelines FAQ-Google Workspace accounts

対象の送信者の詳細

今回の制限に関しては個人対個人のメールではなく、企業や事業主から不特定多数の利用顧客への商用のメール送信を対象としていると想定されています。

その上でGoogleは送信者を下記のように説明しています。

1日に5,000通以上のメールを送る送信者と、そうでない送信者に区別される
送信者の単位はプライマリドメインとなる
一度でも5,000件超えると半永久的に5,000件以上のメールを送る送信者に分類される

後述しますが、送信者のメール送信規模によって、求められる要件が変わってきます。

月の中での平均といった集計ではなく、1日に5,000件を送った実績の有無で区別され、その後メールを送る通数が5,000件を下回ることがあっても、1日に5,000件以上を送る送信者として扱われ続けます。

参考：Email sender guidelines FAQ-Bulk senders

また、サブドメインなどを利用していても単一のドメインとして合算されます。

対応すべきもの・しなくても良いもの

対応事項の中には送信者の規模や、送っているメールの種別に応じて対応の必要性が分かれるものがあります。それぞれの対応方法については後述しますが、一覧を記載していきます。

全ての送信者が対応するもの

上述したようにGmail宛に1日に5,000通以上のメールを送る送信者と、そうでない送信者は区別されます。その中でも「全ての送信者」が対応しなければいけないことは以下の通りです。

SPFまたはDKIM認証の設定。
ドメイン又はIPに対して、有効な正引きおよび逆引き DNS レコード（PTR レコードとも呼ばれる）を設定。
メールの送信に TLS 接続を使用。
Postmaster Toolsで報告される迷惑メール率を 0.10% 未満に維持し、決して 0.30% 以上にならないようにする。
Internet Message Format 標準（RFC 5322）に準拠する形式でメールを作成。
ヘッダfromのドメインを@gmail.comになりすまさない。
（メールを定期的に転送する場合）ARCヘッダやList-idヘッダを付ける。

1日に5000通以上のメールを送る送信者が対応するもの

上記内容に加えて、1日に5000通以上のメールを送る場合は以下の内容について対応する必要があります。

全ての送信者が対応するものに記載されているもの全て
SPF 、DKIM、DMARCの全ての認証の設定
ワンクリックでの登録解除の設定

ワンクリックでの登録解除の設定はマーケティング目的や配信登録されたメールを送る際に対応するものが対象となります。

※1日に5000通以上を送る送信者のマーケティングメールに適応されます。マーケティングメールについて厳密な定義は現在示されていませんが、メールマガジンを始めとする商用の宣伝メールがこの対象となり、予約確認やパスワードリセットや、フォームの送信内容確認などのトランザクションメールはこれに含まれません。但し、あくまで目的が宣伝目的であれば、トランザクションメールであっても同時にマーケティングメールとみなされることがあります。

自社のメール配信がGmailガイドラインに対応できているかを確認する方法(Postmaster Tools)

Googleが配信者向けに提供しているPostmasterToolsから、Gmailのガイドラインに対応した配信ができているかを確認可能になりました。
※まだ使ったことが無い方はこちらを参考にして利用を開始してください。

Postmaster Toolsの使い方-ブラストメールブログ

ここではPostmaster Toolsでガイドラインへの準拠状況を確認する方法をご紹介します。

①Postmaster Toolsにログインすると、「コンプライアンスステータスダッシュボード」という表示が出るので、クリックしてください。

②ダッシュボード画面が表示されたら、確認をしたいドメインを指定してください。

③ドメインを選ぶと、そのドメインの順守ステータスが表示されます。順守できていない項目は「要対応」と表示されます。

登録解除の部分はまだ機能開発中のようですが、こちらの画面に出ている項目が全て「順守」となる状況を目指す必要があります。

ガイドライン各要件への具体的な対応方法

ここからは具体的な対応方法について記載していきます。

多くのケースではSPF/DKIM/DMARC、ワンクリック購読解除、迷惑メール率の抑制の3点が重要になりますが、メールの送信は多種多様なので、ご自身の送信環境に応じて必要な対応をしていく必要があります。

なりすましメールの基本（送信ドメイン認証の前提知識）

具体的な対応方法について解説する前段として、そもそもGoogleを始めとするメールを受信する側がどのように不正メールを防ごうとしているのかについて説明します。

メールの送受信の際にサーバー間で利用されるのはSMTPというプロトコル(通信の手順、決まり事)になります。このプロトコルでは送り元のメールアドレスのドメインとして『Fromドメイン』というものを、実際に通信を行ったサーバーのドメインと関係なく指定することができます。

そして、ややこしいことにこの『Fromドメイン』は、エンベロープFrom、ヘッダFromの２つが存在しています。

ヘッダFrom（見出しのFrom）
ユーザーが実際に確認するメールボックス内で表示されるメールアドレス

エンベロープFrom（封筒のFrom）
SMTP通信中に送信元として相手先のサーバーに伝えられるメールアドレス（エラーメールの送付先ともなる。）

ヘッダFromが自由に設定できることで、例えば、メールマガジン配信ツールなどを利用した際に、そのメールマガジン配信ツールのドメインからメールを送ったとしても、ユーザーには自分たちからのメールであることを示すことが可能です。

この仕組みは不正な事業者にとっては簡単に悪用できてしまうもので、銀行や大手のECサイトと同じドメインをユーザーのメールボックスに表示することで、なりすましを行ってしまいます。

Gmailなどのメール受信を行う事業者を始めとするメール関係者（blastengineもその一員です！）は、ユーザー保護の観点からこういったなりすましを排除するために後述のような認証技術等の普及を促進しており、今回のガイドライン強化もそのような動きの一端となっています。

送信ドメイン認証への対応

送信ドメイン認証は、先ほど説明した、送信元のドメインを他社のドメインになりすますパターンを予防するための技術となり、Googleのようなメールの受け手からしても、送信ドメイン認証を完璧にパスしているメールは他社のメールに成りすましているという可能性が低いと判断できる一つの基準として利用することが可能です。

ここではSPF/DKIM/DMARCについて説明していきます。まず、現在のメール送信がGmailで送信ドメイン認証に正しく対応できているかは、Gmail上から簡単に確認することが可能です。

メールの確認画面から「メッセージのソースを表示」を押すと、メールに付与されている認証の情報を確認できます。

下記の画像のようにSPF・DKIM・DMARCが全てPASSと出ていれば正常に認証できます。3つの欄が出ない・結果がFAILとなっている場合には修正が必要な状況です。

※DKIMの場合はドメインの中身が自社のドメインとなっているかを確認してください。

それぞれの認証の詳細は下記で説明していきます。

SPF (Sender Policy Framework)

送信者の正当性を、メールが送信されてきたIPに基づいて認証する方式です。

DNS上にSPFレコードを追加して、そのドメインを名乗ってメールを送ることを許可するIPアドレスを宣言することができます。

これによって、例えばドメインがhoge.comで送られてきたメールがあった場合、そのメールの送信に使われたIPアドレスが、hoge.comのDNS上で許可されているものだと確認することで、なりすましを行っている不正なメールではないことが証明されます。

詳しくは、以下の記事でも紹介しているので確認してみて下さい。

DKIM (DomainKeys Identified Mail)

送られたメールが改ざんされていないことを電子署名を活用して証明する送信ドメイン認証です。

送信時に秘密鍵を利用して電子署名を行い、受信時にメールヘッダ上のDKIM署名で指定されたDNS上の公開鍵を用いて照合することで、メールが署名を行った時点から改ざんされてないものであることを確認することが可能です。

DKIMについては以下の記事で紹介しているので、詳しくはこちらをご覧ください。

DMARC (Domain-based Message Authentication Reporting and Conformance)

DMARCを利用すると、SPFとDKIMで認証された結果を総合して、なりすましの可能性があるメールをどう扱うかをDNS上で宣言することができ、受信側はDNS上の宣言がどのような値になっているかに応じて、メールの処理を変えることが可能です。

SPFはエンベロープFromのドメイン、DKIMは署名で宣言されたドメイン（Fromドメインと一致していないくても良い）をそれぞれ認証することができるのですが、実際にユーザーに表示されるヘッダFromのドメインの認証自体はできておらず、この二つだけでは完全に機能させることは難しい状況です。

それに対してDMARCは、SPFとDKIMの結果に加えて、認証が行われたドメインとヘッダのドメインが一致するかも判定項目としています。それにより、SPFかDKIMの少なくともどちらか一方がヘッダと一致していなければDMARCは失敗するという設定が可能です。

そのため受信者からみると、DMARCが成功しているメールはかなり信頼性が高いと判断することができます。

また、DMARCはDNSに記載するレコードの表記によって、認証が失敗するメール（なりすましの可能性があるメール）が受信側に届いたときの受信サーバーの処理を指定することが可能です。

具体的な設定はGmailのサポートページでは下記のように説明されています。

SPF と DKIM のいずれかまたは両方のチェックに合格しなかったメールをメールサーバーがドメインから受け取った場合、DMARC はそのメールの処理方法をサーバーに指示します。DMARC ポリシーでは、次の 3 つの設定が規定されています。

ポリシーが「none」に設定された場合 – メールへの対処は行われず、通常どおりにメールが配信されます。

ポリシーが「quarantine」に設定された場合 – メールが「迷惑メール」としてマークされ、受信者の迷惑メールフォルダまたは検疫に送信されます。

ポリシーが「reject」に設定された場合 – メールは拒否され、受信者に配信されません。

https://support.google.com/a/answer/2466580?hl=ja

このようなDMARCの働きによって、受信者側から見ても、自社ブランドへのなりすましを予防ができるようになるというメリットが発生します。

DMARC実装上の注意点ーアライメントについて

DMARCを導入するにあたって、理解が難しいポイントとして、アライメント（≒整合性）という概念があります。

アライメントとは、DMARCの認証対象となるヘッダーfromのドメインと、SPFやDKIMで認証されたドメインが一致しているかを検査する仕組みです。

一例としてSPFのアライメントが取れていないケースを紹介します。

DMARCレコード設定
ドメイン：hoge.com

SPF設定
ドメイン：example.com

送信したメール
ヘッダfrom：XXX@hoge.com
エンベロープfrom：YYY@example.com

この場合、DMARCで認証の対象となるドメインはhoge.comですが、SPFで認証されるドメインはexample.comとなるため、認証結果が成功(pass)であっても整合性が取れていない状態、つまりアライメントが取れていないことになります。

ここで重要なポイントはアライメントが取れていない＝DMARCが失敗(fail)しているという訳ではないということです。

以下にアライメントとDMARCの成否について、いくつかのパターンに分けて記載します。

①SPF○、DKIM○→この場合もちろんDMARCの認証は成功(pass)します。

②SPF×、DKIM×→このパターンではアライメントが全く取れていないため、もちろんDMARCの認証は失敗します。

③SPF×、DKIM○→このパターでは片方がアライメントが取れているため、DMARCの認証は成功(pass)します。

紛らわしいのが③のケースですが、アライメントは片方だけとれていればDMARCとしては成功するため、必ずしもSPFとDKIMの双方でアライメントを取る必要はありません。

特にGmailの変更の要件としても、SPFまたはDKIMのどちらかでのアライメントという表現になっているため、③のパターンでもOKです。（SPFのみアライメントが取れているパターンでもＯＫです。）

DMARC 認証に合格するには、メールが SPF または DKIM、あるいはその両方によって認証される必要があります。認証ドメインは、メールの From: ヘッダーに含まれているドメインと一致している必要があります。
https://support.google.com/a/answer/81126?hl=ja

また、実際に多くのメール配信サービスでは、SPFで認証されるエンベロープfromのドメインはメールサービス側のものとなることが多いため、③のケースになります。

Gmailの要求する送信ドメイン認証

今回のガイドラインの変更ではここまでに紹介したSPF・DKIM・DMARCの全てに対応が必要です。

厳密に言うと、１日当たり約5,000通未満の送信数の場合、DMARCはマストではないですが、今後厳格化される可能性や、ビジネスの拡大を見据えてこの機会に全てやってしまうことをオススメします。

上述のDMARCのポリシーについては特に指定が無く、一番弱いnoneでも対応が可能です。

送信元ドメインでGmailになりすまさない

送信ドメイン認証のパートで説明したように、メールは送信元のメールアドレスを任意に指定することができてしまうため、悪意の有無は別にして、Gmailから送っていないメールに関しては@gmail.comといったGmailドメインを送信元のメールアドレスとして指定しないように求められています。

プロジェクトや製品をスタートした時点の名残で、メルマガ配信ツールなどで@gmailが使われているケースは稀に見られるのですが、Gmailは先ほど説明したDMARCの設定によって、Gmailのドメインを名乗っているメール配信を監視しているため、今回のガイドラインにはそういった配信を続けているとメールの到達率に影響が出る可能性があるということが明記されています。

ワンクリック購読解除の実装

Gmailはマーケティング目的のメールと配信登録されたメールに対して、ワンクリック解除の仕組みを実装することを求めています。

日本では広告宣伝のために送信される電子メールに対しては、受信拒否の通知を受けるための電子メールアドレスまたはURLの表示が義務付けられていますが、今回のガイドラインでは、これをワンクリックで購読解除できるようにすることが求められています。

関連記事：総務省-特定電子メールの送信の適正化等に関する法律のポイント

ワンクリック購読解除の対象

例えば、メールマガジンや、ECのセールの告知などが対象となっていますが、明確な判定基準などは明示されておらず、Googleの内部的な基準で対象とそうでないものが分かれると考えられます。

逆に、パスワードリセットメッセージ、予約確認、フォーム送信内容の確認のような個別に送られるメールに関しては対象外ということは現時点でアナウンスされているため、対応が必要ありません。

List-Unsubscribeヘッダでの実装方法

実装方法としては、一般的なオプトアウトリンクの仕組みを用いて、メール本文内に専用リンクを設置する方法の他に、List-Unsubscribeヘッダをメールに含めることで対応することが可能です。

List-UnsubscribeヘッダはRFC 2369 および RFC 8058で標準化されている電子メールヘッダとなり、Gmailのガイドラインにはメール本体に、下記の二つのヘッダを含める方法が紹介されています。

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://hoge.com/unsubscribe/example/mailtipe1>

これをすることによって受信者側に「メーリングリストの登録解除」という文字列が表示され、これを押すことで上記の<https://hoge.com/unsubscribe/example/mailtype1>のURLに対して解除のリクエストが送られるようにすることができます。

イベントの告知、メルマガなど複数の宣伝メールを送っているケースなどはどの種類のメールの解除をユーザーが希望しているかを確かめるために、mailtype1のようにそれぞれの種類で別々のURLを割り振って、解除リクエストのポスト先を分けることができます。

実際に送られるポストの内容は下記になります。

"POST /unsubscribe/example HTTP/1.1
Host: hoge.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
List-Unsubscribe=One-Click"

このポストを受けて、メール配信システム側で、該当するメールをユーザーに送らないように、現在お使いのメールシステム側で処理を実施します。

※多くのメール送信システムにはこういった仕組みが実装されているケースが多いのですが、自社でオプトアウトの管理をしている場合には、こういった仕組みの構築が必要となります。

有効な正引きおよび逆引き DNS レコードの設定（PTRレコード）

メールの受信者はメールの送信に利用したIPアドレスを元に、DNSレコードを確認することで、悪意をもった送信者からのメールでないことを確認しているため、それらが適切に設定されている必要があります。

逆引きと正引きについては下記のように説明されます。

正引き→ドメイン名（ホスト名）からそのドメインに割り当てられているIPを導く。正引きに使われるレコードをAレコードと呼ぶ。
逆引き→IPから、そのIPと対応するドメインを導く。逆引きに使われるレコードをPTRレコードと呼ぶ。

不正なユーザーは自身の保有するドメインを隠したいため、逆引きのレコードを設定しないため、逆引きのレコードが適切に設定されていることで、ある程度の信頼性の証明になります。Gmailに関しては、逆引きで導かれたドメインのAレコードを参照をして、メール送信に使われたIPと一致するかも確認するため、Aレコードも適切に設定されている必要があります。

PTRレコードが適切に設定されているかの確認に関しては、Googleの提供するDigで確認が可能です。

確認方法の例

PTRレコードにメール送信に使うIPを入力する。（XXX.XXX.XXX.XXX）
IPに紐づくPTRレコード上のドメインが変えられる。（hoge.com）
確認の対象をPTR→Aレコードに切り替えて②で得られたドメインを入力する。
Aレコードまで適切に設定されていれば①のIPが返ってくる。（XXX.XXX.XXX.XXX）

これらが適切に設定されていない場合は、DNSの設定や、利用しているメール送信ツールのIPを確認して、改善することが必要になります。

Postmaster Tools内の迷惑メール報告率の削減

序盤でも登場しましたが、GoogleはGmail宛てのメール送信を行っている事業者に向けて、Googleからの信頼性や迷惑メール率をオープンにして改善を促すためのツールとして、『Postmaster Tools』を提供しています。

ここでいう迷惑メール率の定義はGoogleのヘルプサイトによれば下記のとおりです。

迷惑メール率とは、アクティブユーザーの受信トレイに配信されたメールの件数のうち、ユーザーが迷惑メールに分類した件数の比率です。大量のメールが迷惑メールフォルダに直接配信されている場合は、ユーザーが受信トレイに配信されたメールを「迷惑メール」に分類していても、迷惑メール率が低くなることがあります。
Goolge Workspace 管理者ヘルプ　迷惑メール率

つまり、実際に迷惑メールボックスに入った割合ではなく、最初は受信ボックスに入ったが、受け取ったユーザーが自ら迷惑メールであると見なした割合となります。

この迷惑メール率が高くなってくると、自動的に迷惑メールとして判定される割合も上がってくるということがアナウンスされています。

具体的な閾値としては下記のとおりです。

平常時の値→0.10%未満
一時的に上がってしまった場合の値→0.30%未満

数値だけみると厳しいようにも見えますが、ユーザーがわざわざ迷惑メールであると報告する操作を行うことはよっぽどのことです。もし現在の値がこれを上回るようであれば、リスト取得、メール配信の方法について見直しをかける必要があります。

メルマガなどの配信時には、ユーザーに明示的にオプトインの許諾を取る。
メールを送っても反応（開封やクリック）の無いユーザーにはメールを送る頻度を下げる、又は、送らないようにするなどの自社ポリシーを定める。

TLSへの対応

TLSはメールの通信時にメールを暗号化するセキュリティプロトコルです。

インターネット上で通信されるメールにはのぞき見のリスクが存在しており、このリスクへの対策が可能です。このリスクへの対策としてS/MIMEなどもありますが、現在ではTLSと比較するとマイナーな技術と考えられている場合もあります。

Googleも今回のガイドライン変更ではTLSにのみ言及しているため、まずはTLSへの対応をしていく必要があります。

TSLに対応していない通信を行っている場合、Gmailのメールボックス上でユーザー向けに「このメールは暗号化されていません」といった内容の警告メッセージが表示されるようになっているため、自社のメールにそういった警告が出ていないか確認してみてください。

現在対応していない場合には、自社のメールシステムに改修を加えるか、「blastengine」などのTLS対応済みのサービスを使うことでガイドラインへの対応が可能になります。

Internet Message Format 標準（RFC 5322）に準拠する形式でメールを作成

RFC 5322はメールを送る際の国際的な標準規格のようなものになるため、既にメールを送信している場合は既に準拠していると考えてしまって問題ありません。

特に外部のツールを使っている場合はそのツール側で準拠しているケースがほとんどです。

メーリングリストやメール転送を行っている場合のARCヘッダ、List-idヘッダ付与

メーリングリストや、メール自動転送サービスなどの利用によって定常的にメールを転送していく場合には、転送者が送信元のように見えるため、元々の送信者が行った送信ドメイン認証が無効になってしまいます。

このようなケースに対応することができるのがARC ヘッダとなります。ARCヘッダの付与されていると転送が行われているとGoogleが判定します。また、メーリングリストの場合はList-idも追加する必要があります。

この要件に関しては送信側というよりは、受信側の環境設定に依存する部分もあるため、送信側で対応が必要なケースは少ないと考えられます。

もちろん、メーリングリストや転送サービスを使っている、運営している場合は留意する必要があります。

以上が主だったガイドラインへの対応事項になります。先ほども記載をしましたが、SPF/DKIM/DMARC、ワンクリック購読解除、迷惑メール率の抑制の3点が重要な論点となり、他の事項についてはすでにメール配信を行っている場合は満たされていることが多いです。

いつまでに何をすればいいのか

今回のガイドライン変更は大枠では2024年2月からとなっていますが、本格的な適応は段階であることもアナウンスされました。

現在提示されているスケジュールを如何に簡単に記載します。

2024年2月：非準拠のメールの送信のうち一部での一時的なエラーの発生
2024年4月：ポリシーに準拠していないメールを一定の割合で拒否
2024年6月：全ての商用・宣伝メールでワンクリック配信停止が求められる

2024年2月（適応済み）：非準拠のメールの送信のうち一部での一時的なエラーの発生

ここでは送信者への警告の意味合いが強そうですが、メールがガイドラインに準拠していない場合には特定のエラーコードが返るようになります。アナウンスの内容を見ると一時的なエラーとなっているため、メールの到達自体には大きな影響はないのではないかという見方もあります。

そこでまずは２月までを目安に一次的な対応を終えて、警告のエラーが発生していないかを２月から確認していく必要があります。

2024年4月（適応済み）：ポリシーに準拠していないメールを一定の割合で拒否

この時点では本格的にメールの到達率に影響が発生します。

ここでは、例えば準拠しているメールとまだ準拠できていないメールを送っている場合、準拠できていないメールのみ一定の割合で受信拒否が発生するとアナウンスされています。

2024年6月以降（時期未定）：すべての要件を満たす必要がある。

６月以降に適応されるガイドラインの要件は以下となります。（まだ対応していないものがあれば、急いで対応することを推奨します。）

Googleのアナウンス

最低限のポリシー none（p=none）が適用された DMARC レコード。詳しくは、DMARC レコードの値をご覧ください。

マーケティングメッセージにおけるワンクリックでの登録解除

ユーザーから報告された迷惑メール率が 0.3% を超える場合、または送信者が認証の要件あるいはワンクリックでの登録解除の要件を満たしていない場合は、緩和策を利用できません。

メール送信者のガイドラインに関するよくある質問

特に、ワンクリック登録解除については、送信者側で受け口を作るなどの対応が必要になることもあり、準拠状況が芳しくないようです。

ガイドライン準拠していてもエラーが出る場合の「緩和策」とは？

弊社の環境でも、準拠しているにも関わらず、正常な判定を受けていないように見えるメールが発生しております。時間がたてば解決する場合もあるのですが、Googleが専用の問い合わせフォームを設けておりますので、こちらから問い合わせをすることも可能です。
※確実に返信があるとは限りません。

緩和策の問い合わせフォーム

ただし、こちらから問い合わせを送って受理されるのは、Google側で確認した際に、ガイドラインに準拠していると判断された場合のみとなっております。
※ワンクリックに関しては2024年6月以降のタイミングでの適応のため準拠の成否に用いられない可能性もあります。

本記事の序盤に記載したPostmasterToolsの確認を行って準拠となっている場合は、こちらから問い合わせをしてみてください。

Gmail以外は大丈夫？根本的な対応のために

実は今回のガイドラインの変更はアメリカのYahoo!でも同時に行われており、日本のYahoo!メールへの影響は現時点では確認されていないのですが、Microsoftなどを始めとしたその他の受信側の事業にも追従の動きが起きるのではないかという懸念は存在しています。

冒頭でも少し触れましたが、こういったポリシーの強化はメールを受け取るユーザーをフィッシングメールなどの被害から守るための措置となり、近年益々巧妙化しているフィッシングメールなどのメールの悪用技術の流れを鑑みると、受信側のセキュリティと正規の送信者に求められるガイドラインは強化されていくと考えることができます。

API連携・SMTPリレーサービス「ブラストエンジン(blastengine)」の活用

ブラストエンジンは、SMTPリレーサーバーを使用して、簡単に大量のメールを高速配信することが可能です。さらに、メールサーバーを必要とせず、API経由でメールを送信する仕組みも提供しています。

ブラストエンジンは、サーバーの運用やメンテナンスを行っているため、常に高いIPレピュテーションを維持しながら、安全にメールを送ることができます。

以下のような課題がある場合は、ブラストエンジンの利用を検討してみることをおすすめします。

自社のIPアドレスやドメインがブラックリストに登録されていて、メールが届かない場合
国内キャリアにメールが届かず、対応方法がわからない場合
自社でメールサーバーを管理・運用したくない場合

また、ブラストエンジンは各メールプロバイダーや携帯キャリアのドメインに最適化されており、大規模なネットワークを経由してメール配信を行うことで、日本国内での到達率を圧倒的に高めています。

利用料金は月額3,000円からとコストパフォーマンスにも優れており、メールだけでなく、日本語での電話サポートにも対応しています。

メールアドレスの入力のみで無料トライアルが可能ですので、まずは気軽にお試しください。

ブラストエンジンを無料で試してみる >

シェア1位のメール配信システム「ブラストメール」の活用

ブラストメールは、13年連続で顧客導入シェア1位を獲得している信頼性の高いメール配信システムです。ブラストエンジンとは異なり、メルマガなどのメール一斉送信に利用することができます。

このメール配信システムの特徴は、使いやすさとコストパフォーマンスの高さです。さまざまな業種や官公庁でも利用されており、定番のメール配信システムとして広く知られています。

迷惑メール対策機能はもちろん、セグメント配信や効果測定、HTMLメールエディタなど、基本的な機能がすべて揃っています。最も安いプランでも、月額4,000円以下で導入することができます。

シンプルで安価なため、初めてメール配信システムを利用してみたい方にもおすすめです。無料トライアルも用意されているので、まずは試してみることをお勧めします。

ブラストメールを無料で試してみる >

まとめ

長くなりましたが、最後までお付き合いいただき、誠にありがとうございました。

我々blastengineチームは、メール技術自体は既にレガシーなものとみなされることが多く、詳しいエンジニアやプログラマーが減っている中で、企業は自社でそういった環境変化に対応していくことはどんどん難しくなっていのではないかと考えており、専門的な技術者がいなくてもメール送信技術のベストプラクティスがすぐに使えるクラウドサービスを提供しています。

このブログはだいぶ長くなってしまいましたが、最後まで読んでいただいた方には、是非、今回のようなガイドラインの変更といった環境変化への恒久対策としてブラストエンジン（blastengine）をご検討いただけますと幸いです。

検証のための無料トライアルも提供しておりますので、良ければサインアップしてみてください。

※引き続き、アップデートがあれば更新していきます。

Blog一覧