【Gmailフィッシング警告解消】独自ドメインメールをgmailメーラーで送受信する時のSPF設定方法

公開日:2022/04/11 最終更新日:2022/04/16 coding

最近（2022年３月頃から）、gmailのSPF判定がとても厳しくなった気がします。
独自ドメイン宛のメールをgmailで受信して開くと、
「このメールにはご注意ください。フィッシングを報告」という黄色の枠が表示されてしまう現象です。
3年ほど運用してきましたが、今までそんな警告は目につかなかったのに、最近になって目にあまるくらい多い感じがします。

なんか気持ち悪い！ということで、調べに調べて、一応解消しましたので、備忘録として。

【前提】独自ドメインメールとgmailとの連携設定

◎ 独自ドメインメールアカウント⇔gmailアカウントの連携設定はSMTP/POP3で、双方やりとりはgmail経由が前提です。

なお、外部メールサーバ側では、以下の設定を無効にしておきます。
※ここでの外部メールサーバはさくらインターネットのケースを例とします。

①ウイルスチェック機能OFF（適宜）
→ウイルスチェックサーバを経由する場合があると、また話が変わってくるので、今回は省略。とりあえず無効に。

②連携しようとしているgmailのメールアドレスへの転送設定
→メールサーバで転送設定している場合もgmailではフィッシング警告になる可能性があるのでやめる。ただ、転送設定をやめるとgmailで受信するまで時間がかかるデメリットはある。。。

そして、今回ご紹介するのは、上記の前提でもフィッシング警告が出た場合に一時的な対応策となります。

※ ここから先はSPFレコードをいじれる人向けのお話。gmailが命で、独自ドメインメールのアカウントを連携しているけど、受信したメールに警告がつくようになった。という方はご参考までに。

SPFレコードってなにそれおいしいの？って方は、メールサーバ会社にまずは問い合わせをされるのをお勧めします。

結論から

まず結論から。フィッシング警告が解消するSPFレコードは

v=spf1 {既存のレコード} include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

です。私の場合はこれで解消しました。

この_netblocks.google.comというドメイン。普通にググっても中々出てこなかったので、linux のdigを利用してgoogle.comのドメインを追跡し辿り着きました。
以下確認した時の状況です。

1. フィッシング警告となったメールのメッセージヘッダーを確認

spf=softfail (google.com: domain of transitioning {独自ドメインメールアカウント} does not designate 209.85.216.44 as permitted sender) smtp.mailfrom={独自ドメインメールアカウント}
Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) (authenticated bits=0) by {メールサーバIP・ドメイン} with 〜

ん？
mail-●●1-f●●.google.com（209.85.xxx.xxx）というサーバからとのことで、SPFの判定がsoftfailになってる。認識ないIP・ドメインだぞ、、、なにこれ！？

そこで、このIP情報を検索してみるとGoogleさんのSMTPサーバということが判明しました。
gmail経由で双方送受信すると、メールサーバだけでなく、GoogleのSMTPシステムも関わってくるらしい。

よく考えればそうかもしれないけど、フィッシング警告が目につくまで、意識したことなかった。
外部メールサーバの情報をSPFレコードに追加してSMTP/POP3で設定すればgmailでもアカウント連携できてるじゃない。
SPFパスされないんだったら、アカウント連携のときにSPFチェックしてエラーを教えてくれたっていいじゃない。Googleさん！って思うのは私だけでしょうか。。。

という愚痴を言ってもしょうがないので、GoogleのSMTPサーバ情報を特定して、SPFレコードに追加するといけるはず。
ということで、さらに調べます。

2. gmail.comのドメインのTXTレコードをDNSに問い合わせ

$ dig gmail.com txt
;; ANSWER SECTION:
gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com"

どうやら、_spf.google.comにリダイレクト（指定されたドメインに認証チェックを転送）されているようです。

3. _spf.google.comのドメインのTXTレコードをDNSに問い合わせ

$ dig _spf.google.com txt
;; ANSWER SECTION:
_spf.google.com. 300 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

という形で、複数のドメインをincludeで指定（include先ドメインのSPFレコードで認証処理が通るならば、認証を通すようです）しています。

このことから、gmail間で独自ドメインメールの送受信をする際はこのドメイン（_netblocks●.gooogle.com）を経由することがわかりました。

そこで、gmailベースで送信する可能性のあるドメインのTXTレコードにこの3つのincludeを追加してみると、フィッシング警告がでなくなりました。とりあえずこれで様子を見ることにしました。

ちなみにinclude:_spf.google.comを追加すると、PermErrorで上手くいきませんでした。

SPFレコードに追加する時の注意点

以下の点について、SPFレコードに追加しても失敗する恐れがありますので、注意ください。

SPFレコードの参照先が多すぎる場合
SPFレコードで、ドメインの参照を伴う機構（aとかincludeとかredirect）を使用できる回数の上限は10回、
また、参照先でさらに参照している場合は追加でカウントされます。
（参考）参照回数を確認するサイト：https://dmarcian.com/spf-survey/
私の場合、include:_spf.google.comを追加して起こったPermErrorはこの上限を超えたためのようです。
include:_netblocks●.google.comは今後変更される可能性あり
Googleさんの仕様が変わる可能性はあり、_netblocks●.google.comというドメインも変更される可能性があります。よって、「一度設定したら絶対大丈夫」という安心材料にはなりません。
再度フィッシング警告が表示されるようになった場合は、Googleの公式情報や、google.comのDNSレコードを確認する必要はありそうです。

今回のレコードを追加するドメイン（_netblocks●.google.com）は、Googleさんの公式にはない情報かと思います。
本来ならば、公式にあるように、include:_spf.google.comを追加するのが正しいかもしれませんが、私の場合は上手く行きませんでした。既存のSPFレコードの状況によるのか、Google Workspaceを利用している時にだけ有効なのか、確証はできてないです。

よって、正規な設定ではないので、これで絶対大丈夫！とは言い切れませんが、最終手段として抜け道があったので、参考程度にまずは検証してみるといいかもです。

さいごに

gmailのヘビーユーザーで独自ドメインメールも連携し、ビジネス右肩上がり、上手く言ってるけど、フィッシング警告に悩まされてる方は、素直にGoogle様のガイドラインに沿ったGoogle Workspaceにメールサーバを移行したほうが早く解決し、安定した運用ができるかなと思いました。DKIM設定もあるしメール通信のセキュリティは安心。

外部メールサーバの弱みをつかんで、自分のサービスに取り込もうとしておられるのでしょうか。さすがGoogleさん。？

ではこのあたりで！

最後までお読みいただき、ありがとうございます。