年三日坊主のKKです。
エンジニアブログというとどうしても自社や自社のお客様の話になりがちですが、今回は最近自身に降りかかった話をご紹介したいと思います。
先日、プライベートで使っているGmailアドレス宛にとあるお店から資料を送って貰おうとメールアドレスをお伝えしたのですが、「Gmailからメールが返送されてしまいメール送付できない」と電話がかかってきました。
その時はとりあえずWebファイル共有サービスで資料を送って貰えて事無きを得たと思ったのですが、私からGmailで送ったメールへの返信がまたしても送れないと今度はショートメール（SMS）が届きました。
このエンジニアブログをご愛読の皆さんはお気づきかと思いますが、どうやらそのお店のメール（ドメイン）設定はGmailなどの迷惑メール対策への対応ができていないようなのです。
これまでに迷惑メール関連の機能などを取り上げたエンジニアブログ記事としては以下のようなものがあります。
- SPFレコードって何？(役割編)
- SPFレコードって何？(設定編)
- Opendkimの設定やってみた
- 弊社「フィッシングメール削除機能」についての技術的解説
- AWSご相談事例002：AWSから送信したメールが届かないことがある(SES)
ただし、これらは基本的にメールを送る事業者側から見た解説でした。
今回は視点を変えてメールを受け取る側がメールを受け取るためにメール送信側にどういう対応をお願いする必要があるか、仕事でもないのに切り分けと助言をした経験を書いていこうと思います。
◆送信ドメイン認証関連のDNS設定状況
まずは以前の記事にも散々出ている送信ドメイン認証関連のDNS設定状況を確認していきます。
今回はWindowsコマンドプロンプトでnslookupコマンドを用いて調査していきます。
nslookupコマンドにタイプを指定してDNSを正引きしていきます。
手始めにネイキッドドメインとwwwのAレコードからC:\> nslookup -type=A example.co.jpC:\> nslookup -type=A www.example.co.jp
次はこのドメイン宛のメールを受信するサーバを指定しているMXレコードC:\> nslookup -type=MX example.co.jp
どうやらWebサーバとメールサーバを1台のサーバで兼ねているようですね。
念のためこのサーバーのIPアドレスを逆引きしてみましょう。C:\> nslookup 182.xxx.xxx.xxx
これはこのサーバーをホストしているホスティング事業者のホスト名ですね。
逆引き設定を依頼していないのでしょう。
そしてお待ちかねのTXTレコードです。C:\> nslookup -type=TXT example.co.jp
回答がありません。
つまり、このお店のドメインにはTXTレコード（で定義されるSPFレコード）が無いです。
ダメ元でDMARCのTXTレコードも引いてみましょう。C:\> nslookup -type=TXT _dmarc.example.co.jp
こちらは明示的に見つけられないという表示がでました。
本当はDKIMのTXTレコード設定も確認したかったところですが、このお店からのメールを受け取れていないのでDKIMのセレクタを知ることが出来ず調べるのは諦めました。
（頼まれもしないのに勝手に公開情報を調べているだけなので文句言ってはいけません）
もしメールヘッダが入手できてセレクタがわかれば以下のコマンドのselectorの部分にセレクタを指定することでDKIMレコード設定内容を確認できます。C:\> nslookup -type=TXT selector._domainkey.example.co.jp
◆お店への助言について
以前の記事でも紹介しましたがGoogleはGmailへのメール送信者向けにメールがブロックされたり、迷惑メールに振り分けられたりすることを防ぐためのガイドラインを公開しています。
参考：Gmailヘルプ - Gmail ユーザーへのメールがブロックまたは迷惑メール扱いされないようにする
未確認ではありますがこのお店のドメインは恐らくDKIMの設定もされていないと思われますので、Gmailへのメール送信者ガイドラインの条件をすべて満たしていない可能性が非常に高いです。
さて、仕事でもないのにメール送信ドメイン設定の問題点を洗い出してしまったのですが、これをどうやってお伝えするのが良いでしょうか。
こういう時、職業エンジニアとして何を悩むかと言えば「責任を取れるのか」という点です。
これが家族やごく親しい友人などであれば、また違った判断になるでしょうけれどお店はこのドメインで商売をされているのですから、私が気まぐれで調べた内容に間違いや考慮漏れがあったら責任の取りようがありません。
ここで一つポイントになるのがこのサーバーの管理者は誰かという点です。
実は逆引き設定を調べた際にこのサーバーがホストされているであろう事業者の目途はついています。
このお店がどのようなサポート契約を事業者と結んでいるかはわかりませんが、お店に対して簡単に事実関係を伝えた上でお店からホスティング事業者に相談して貰うのが間違いないでしょう。
念のため事業者のサイトを調べたところ同じようにGmailへのメール送信ができないという事例が多いようで、「Gmailへのメール送信がエラーになって返ってくる現象でお困りのお客様へ」という直球のお知らせが掲載されていました。
というわけでお店の方には以下のようなおせっかいメールをお出ししました。
| 私のGmailアドレス宛にメールが送れない件、余計なお世話かと思いましたが少し調べたところ、 example.co.jp からメールを送信する際に送信元を証明する設定が不足しているために、送信元が確かではないという理由でGmailがメールの受け取りを拒否しているようです。 exampleホスティングのサーバーをご利用のようですのでお店のドメインやサーバーを管理されている方にexampleホスティングからのお知らせを参考に設定の見直しを依頼されることをお勧めします。 |
同僚からは「仕事でもないのに休みの日に何やってんの」と呆れられつつもエンジニアブログのネタになったので良しとしたいです。
なお、この記事内のエピソードは筆者の体験を元にしたフィクションです。
