（UX向上のため記事を時々更新しています）
どうもGmailのスパムメール対策レベルが高すぎるのか、Gmailユーザーにメールが届かないというやっかいなケースに遭遇する機会が増えています。

この「届かない」ケースとは、正確に書くと、
「届いているけれど迷惑メールBOXに振り分けられて気づかないパターン」と、
「Gmailの受信メールサーバでフィルタリングされ、端末に配達されないパターン」
があると思います。

後者のように”Gmail郵便局”で捨てられるのは少数で、ほとんどの場合は配達されたけど迷惑メールBOXに振り分けられているのだと思います。

また特に、受信したGmailをさらに別のメアドに転送設定していると、GmailのMyページにログインすることもないでしょうから、そこで「迷惑メールBOX」にぶっこまれマウンテンとなっていることすら気づかないはずで、その場合も当然「届かないゾ！」ということになります。

その原因も多々ありケースバイケースのため、ここでまとめて備忘録にしておくことにします。

レンタルサーバに依存せずに構築したVPS等でよくあるケースだと思います。

届かないというクレームを受けて初めてやってないことに気づく場合もあるようです。

逆引きできないメールは迷惑メールが多いという理由で、受信はしているものの迷惑メールとして処理されて振り分けられているパターンですね。

なお、バーチャルホストの場合を想定しているのか、受信サーバは逆引き設定の有無だけ見てサーバ名の一致までは見ていないという話も聞いたことがありますが、Gmailでは正引き・逆引きでホスト名の一致まで見ているようでうす。

逆引き設定に関係してきますが、逆引きのないv6 アドレスも（できないからと）ブロックしてしまうケース。

下記の記事を見ると、

gmail の逆引き制限（どさにっきLTE）
_ おとといぐらいからちらほら 話に出てたけど、gmail が逆引きのない v6 アドレスからのメールを蹴り始めたらしい。もうめんどくさいので主張は繰り返さないけど、バカですか。

記事を読み進むとGmail対策が記述されていました。

結論から言えば「IPv4で送ること」しかないようです。

このドメインのメアドはこのIPアドレスから送りますよ、という設定がDNSのSPF設定です。

この設定は、他人のドメインを勝手に騙る「なりすまし」をブロックするために、受信サーバがDNSに確認しているものです。

SPF設定漏れで多いケースとしては、公式サイトとは別のドメインで特設サイトやECサイトを作って、そのサイトから
「承りました」「お問い合わせ有難うございました」
のような自動返信メールを公式サイトのドメインのメアドを使って送信している場合に、漏れているケースが多く見られます。

例えば、example.co.jpのメアドを、通販のexample-shop.comのサーバから自動発信メールとして使っていたりすると、通販サーバ（発信元）のIPがexample.co.jpのDNS（SPF設定）に書かれていなかったということで、Gmailに迷惑メール扱いされるパターンです。

SPF設定がDNSにちゃんと書かれているかどうかは、送信サーバのホスト名またはIPアドレスとメアドがあればSPFレコードチェックのサイトで可能です。

https://www.mailcleaner.net/tools/test_spf.html

このケースは私の経験で言うと、Gmailの受信サーバのレベルで拒否されていて、端末には届きませんでした。

ブラックリストに登録されるというのは、メールサーバにレンタルの共有サーバを使っている場合がほとんどですが、同じサーバの同居者が悪さをすれば、すべての同居人が迷惑するわけです。

このケースに運悪く当たってしまった話は下記に書きました。

メールサーバに共有サーバを使う場合に考えられる、いわゆるブラックリスト入りのリスクについての話。

ブラックリスト入りしたからといって、すべてのメールサーバから村八分になるわけではなく、Gmailをはじめ、受信サーバにスパム対策をガッツリ組んでいるところだけですが、さすがに「厳しい相手先以外は、おおむね届きます」では済まない話です。

また、自分がとった解決策も下記に書きました。

メール送信サーバだけは、やはり専用サーバでないとビジネスには使えないって話。

結局共有サーバは結構な確率でブラックリスト入りしていることが多く、送信には使えないってことで送信（SMTP）サーバだけVPSに構築するという方法をとりました。

それが下記。

なお、SMTPサーバがブラックリストに入っているかどうかは、下記で確認できます。

mxtoolbox.com
または
blacklistalert.org 。

Gmailのヘルプに下記の記述がありました。

迷惑メールとして処理される理由
Gmail の自動システムでは、ウィルスや不審なメールを識別し、メール全体のパターンを見つけ、Gmail ユーザーによる迷惑メール マークを学習することにより、迷惑メールを検出します。
（以下省略）

※太字は私がしました。

Gmailの管理画面で１ユーザーが迷惑メールをGmailに報告しても、どれほど（数的に）集計されたら、全体のフィルターに組み込まれるのかわかりませんが、意外に判定スコアは低いかも知れません。

せっせと「迷惑メールではない」ボタンをユーザーに押してもらうような、不毛な対策しかなさそうです。

なお、なりすまし対策のSPF設定にも関連しますが、報告された「メアド名」だけがスパム判定に登録されると、なりすまされた正規のメアドが濡れ衣で被害を蒙ることになりますが、そこはよくできたものでSPF設定と連携しながら判定していると思われます。

Gmail（など）に拒否される理由が上記各項のいずれかかもしれませんし、複数が原因した合わせ技だったりするケースもあり、テクニカルに疎い私としては頭の痛い事案でした。

追記1：お名前.comの共用サーバでのDNS書き換えに失敗
お名前.comの共用サーバでメールを利用している知人がいて、某大手広告代理店のメールサーバでspamhaus.orgのリストを元に弾かれる（届かない）という現象がありました。

実際、共用サーバで使っているSMTPサーバがブラックリスト入りしているのか（SMTPサーバ名やIPで）確認しても、なぜかspamhaus.orgのチェックではNot Listedと回答してくるため、除外申請も出せない状況でした。

しかたなく、SMTPサーバを外に設定してしまおうと思い、その代替送信サーバ（VPS)のIPアドレスでSPFに追記することになりました。

そこでお名前.comの「ドメイン設定」＞「ネームサーバーの設定」＞「DNS関連機能の設定」を開け、TXT(SPF)の追加設定をしたところ、私の不注意ですが、共用サーバとの紐付けが切れてしまいました。

よく確認すると、SPFの追加設定をする際、同時にネームサーバがgmoserver.jpから01.dnsv.jpなどに変わってしまっていました。

共用サーバを使っている場合は、ドメインnaviにあるDNS設定でTXT（SPF)を追加すると、変えてはいけないネームサーバも一緒に変わってしまうようです。

取り急ぎ、初期に戻す（「ネームサーバの変更」で共用サーバーSD「設定する」を押す）ことで、時間は数時間かかりましたが復旧しました。

結論から言うと、共用サーバを借りているユーザーはドメインnaviにあるDNS設定ではなく、サーバーnaviにあるDNS設定でTXT（SPF)を変更（しかも「追加」ではなく）しなければならなかったようです（汗）。

わかりづらいので詳しく書くと、下記にあります。　

サーバーnaviのHOMEにて　ご利用サービス一覧　＞　ご利用サーバーサービス一覧　＞　共用サーバー　コントロールパネル「ログインする」　＞　コントロールパネル　＞　独自ドメイン設定　＞　DNSレコード設定

同じことをやろうとしている人がいたら、このあたり、自己責任でお願いします。

痛い目にあった素人の私のアドバイスとしては、まずはお名前.comのサポート（03-5456-2560）に電話してからのほうがよろしいかと思います。

追記2：YAHOOメールの迷惑メールの判断基準は常に流動している
私のクライアントの１つである某サイトで申し込みをした方から、「返信メールが自分の使っているYAHOOメールで迷惑メールBOXに振り分けられたが、サイトのセキュリティは大丈夫か？」という質問が来たと知人から話を聞きました。

返信メールとはサーバが自動で送信する「お申し込みを受け付けました」メールのことですが、そんなことでいちいち「サイトのセキュリティは大丈夫か？」と言ってくるユーザーも珍しい気がします。

そのサーバ側の対策（設定）は問題ありませんでしたが、放置するわけにもいかず、私が個人のYAHOOメールを使って当該サイトで申し込みをしたら、正しく受信BOXに入りました。

YAHOOメールでそのユーザーが受け取って迷惑メールBOXに入った時間と、私がYAHOOメールで正しく受信BOXにて受信した時間は数時間程度の時間差です。

その意味では、やはりYAHOOメールが使っている迷惑メールか否かの判断基準は常に流動していると思ったほうがよいようで、昨日と今日でも違うし、さっき受信したAさんと今使ったBさんでも違うかも知れません。