メールサーバーからGmailへメールを送信したとき、
メールが届かない
迷惑メールフォルダに入る
配送エラーになる
以前は届いていたのに突然届かなくなった
といった問題が発生することがあります。
このとき、
「SPFはPASSしているから問題ないはず」
と一つの項目だけ確認しても、原因を特定できないことがあります。
メールの到達性には、
送信元IP
PTR(逆引きDNS)
EHLO
SPF
DKIM
DMARC
IP・ドメインのレピュテーション
メールの内容
など複数の要素が関係するからです。
この記事では、Gmailへメールが届かない、または迷惑メールになる場合に、どの順番で確認すればよいのかを説明します。
最初に「届かない」と「迷惑メール」を分ける
まず重要なのは、現象を分けることです。
例えば、
① Gmail側からSMTPエラーが返る
② 送信側のメールキューに残る
③ Gmailには届くが迷惑メールに入る
④ 一部のメールだけ迷惑メールになる
⑤ 同じ送信元なのに受信トレイに入るメールと
迷惑メールに入るメールがある
では、調査するポイントが変わります。
特に、
「配送そのものに失敗している」のか、「配送には成功しているが迷惑メール判定されている」のか
は最初に分けて考えます。
1. SMTPの応答を確認する
まず配送エラーになっているなら、送信メールサーバーのログを確認します。
Postfixなら、環境によりますが、
grep "gmail.com" /var/log/maillog
などで配送結果を確認できます。
例えば、
status=sent
なら、少なくとも送信側では相手サーバーへ引き渡せています。
一方、
status=deferred
なら、まだ配送できていません。
さらに相手から、
4xx
5xx
のSMTP応答が返っている場合は、そのコードとメッセージを必ず確認します。
ここを飛ばしてDNS設定を変更するのはおすすめしません。
Gmailへ届かない
↓
まずメールログ
↓
SMTP応答を確認
↓
その後DNS・認証を調査
という順番にします。
2. 送信元グローバルIPを確認する
次に、実際にインターネットへメールを送っているIPアドレスを確認します。
構成によっては、
メールサーバー
↓
メールゲートウェイ
↓
ファイアウォール/NAT
↓
Internet
↓
Gmail
となっているため、メールサーバー自身のIPアドレスとGmailから見える送信元IPが違うことがあります。
重要なのは、
Gmailから見えているグローバルIP
です。
メールヘッダーやメールサーバーのログなどから、実際の送信元IPを確認します。
3. PTR(逆引きDNS)を確認する
送信元グローバルIPが分かったら、PTRを確認します。
Linuxなら、
dig -x 203.0.113.10
Windowsなら、
nslookup 203.0.113.10
です。
例えば、
203.0.113.10
↓ PTR
mail.example.jp
と返ってきたとします。
ここで終わらず、今度はmail.example.jpを正引きします。
dig mail.example.jp A
結果が、
mail.example.jp
↓ A
203.0.113.10
なら、
203.0.113.10
↓ PTR
mail.example.jp
↓ A
203.0.113.10
と戻ってきます。
メール送信用IPでは、この正引きと逆引きの整合性も確認しておきます。
4. EHLOで名乗るホスト名を確認する
SMTPサーバーは相手へ接続すると、
EHLO mail.example.jp
のように自身のホスト名を通知します。
Postfixなら設定によっては、
myhostname = mail.example.jp
などが関係します。
理想的には、
送信元IP
203.0.113.10
↓
PTR
mail.example.jp
SMTP
EHLO mail.example.jp
mail.example.jp
↓
A
203.0.113.10
のように関係が分かりやすくなっているか確認します。
つまり、
IP
PTR
EHLO
A
をセットで確認します。
5. SPFを確認する
次はSPFです。
SPFでは、
この送信元IPから、このドメインのメールを送信してよいか
を確認します。
例えばDNSに、
example.jp. IN TXT "v=spf1 ip4:203.0.113.10 -all"
が設定されていれば、203.0.113.10が許可された送信元になります。
確認には、
dig example.jp TXT
などを利用できます。
ただし注意したいのは、
SPF PASSだけでは十分ではない
ことです。
SPFが認証するドメインと、ユーザーが見るHeader Fromのドメインは必ずしも同じではありません。
ここは後ほどDMARCで確認します。
6. DKIMを確認する
次はDKIMです。
DKIMでは送信メールに電子署名を付け、受信側がDNSに公開された鍵を利用して検証します。
メールヘッダーから、
DKIM-Signature:
を探します。
例えば、
DKIM-Signature:
v=1;
a=rsa-sha256;
d=example.jp;
s=selector1;
なら、
d=example.jp
s=selector1
を確認します。
公開鍵は概念的には、
selector1._domainkey.example.jp
に公開されています。
DNSで確認するなら、
dig selector1._domainkey.example.jp TXT
です。
DKIM FAILなら理由まで確認する
単純に、
DKIM = FAIL
だけを見てはいけません。
例えば、
body hash did not verify
と出ている場合があります。
これは、DKIM署名時の本文と受信側で検証した本文から計算したハッシュが一致しなかったことを示します。
例えば、
送信元
↓
DKIM署名
↓
メール中継サービス
↓
本文・MIME等を変更
↓
Gmail
↓
DKIM FAIL
というケースも考えられます。
そのため、
DKIM FAIL = なりすましメール
と単純には判断できません。
7. DMARCを確認する
SPFとDKIMを確認したらDMARCを見ます。
メールヘッダーの、
Authentication-Results:
には、例えば、
spf=pass
dkim=pass
dmarc=pass
などが記録されます。
理想的には、
SPF PASS
DKIM PASS
DMARC PASS
です。
ただしDMARCでは、単純にSPFとDKIMのPASS/FAILだけを見ているわけではありません。
重要なのが、
Alignment(アライメント)
です。
SPF PASSでもDMARC FAILになることがある
例えば、
Header From:
user@example.jp
SPF認証ドメイン:
mail-service.example
だったとします。
mail-service.exampleのSPF認証には成功して、
SPF = PASS
になったとしても、
Header From
example.jp
≠
SPF認証ドメイン
mail-service.example
なら、SPF Alignmentを満たしません。
DKIM側でもDMARCの条件を満たせなければ、
SPF PASS
DKIM FAIL
DMARC FAIL
となることがあります。
つまり、
SPF PASS = DMARC PASS
ではありません。
8. Gmailで受信できたメールのヘッダーを見る
メール自体はGmailへ届いているなら、受信したメールのヘッダーは非常に重要な情報源です。
Gmailでは「メッセージのソース」などからヘッダー情報を確認できます。
特に、
Received:
Authentication-Results:
Received-SPF:
DKIM-Signature:
From:
Return-Path:
などを確認します。
そして最低限、
| 確認項目 | 結果 |
|---|---|
| 送信元IP | 203.0.113.10 |
| PTR | mail.example.jp |
| SPF | PASS |
| DKIM | PASS |
DKIM d= | example.jp |
| DMARC | PASS |
| Header From | example.jp |
のように整理します。
長いメールヘッダーを上から眺め続けるより、必要な情報だけ表にすると原因を見つけやすくなります。
9. SPF・DKIM・DMARCが全部PASSでも迷惑メールになる?
ここが重要です。
なります。
例えば、
SPF PASS
DKIM PASS
DMARC PASS
だったとしても、
Gmail
↓
迷惑メール
になることはあり得ます。
なぜなら、SPF・DKIM・DMARCはメールの迷惑度そのものを判定する仕組みではないからです。
簡単にいうと、
SPF/DKIM/DMARC
↓
「送信元の認証」
迷惑メール判定
↓
「このメールをどう扱うか」
は別の問題です。
10. 認証が全部PASSなら別の要因を調べる
ここまで正常なら、次はメール認証以外へ調査範囲を広げます。
例えば、
送信元IPのレピュテーション
ドメインのレピュテーション
送信量
急激な送信量の変化
メール本文
件名
URL
添付ファイル
受信者からの迷惑メール報告
過去の送信実績
などです。
つまり、
迷惑メールになった
↓
SPF確認
↓
PASS
↓
DKIM確認
↓
PASS
↓
DMARC確認
↓
PASS
↓
「原因不明」
ではありません。
ここで初めて、
メール認証以外の要因を疑う段階に進んだ
と考えます。
同じ送信元なのに結果が違う場合
さらに難しいのが、
メールA
↓
受信トレイ
メールB
↓
迷惑メール
というケースです。
しかも両方とも、
同じFrom
同じ送信元IP
SPF PASS
DKIM PASS
DMARC PASS
だったとします。
この場合、送信インフラの設定だけでは説明しにくくなります。
次は、
件名
本文
URL
添付ファイル
送信タイミング
送信量
宛先
過去のメールとの違い
など、メールごとの差を比較します。
特にテストメールでは、
件名:テスト
本文:
test
のように極端に短いメールを何度も送信することがあります。
本番メールと条件が大きく違うため、テストメールの判定だけで本番メールの到達性を判断しない方がよいでしょう。
11. DNSを直した直後なら反映時間にも注意
PTR・SPF・DKIM・DMARCなどのDNSレコードを変更した場合、
変更した
↓
すぐ再送
↓
まだFAIL
となる場合があります。
DNSにはTTLやキャッシュがあるためです。
したがって、
DNS変更
↓
権威DNSで確認
↓
外部DNSから確認
↓
TTLを考慮
↓
再度テスト送信
という順番で確認します。
「設定ファイルを変更した」ことと、インターネットから新しいレコードが取得できることは別です。
Gmailへ届かないときの調査フロー
ここまでを一つの流れにすると、次のようになります。
Gmailへ届かない・迷惑メールになる
│
▼
SMTPログを確認
│
┌──────┴──────┐
▼ ▼
配送失敗 配送成功
│ │
▼ ▼
SMTP応答確認 ヘッダー確認
│
▼
送信元IP
│
▼
PTR
│
▼
PTR→A
│
▼
EHLO
│
▼
SPF
│
▼
DKIM
│
▼
DMARC
│
▼
Alignment
│
┌──────┴──────┐
▼ ▼
認証に問題 全部正常
│ │
▼ ▼
設定修正 レピュテーション
本文・件名
URL・送信量等
この順番で調査すると、「何となくSPFを変更してみる」といった場当たり的な対応を減らせます。
私なら最低限ここまで確認する
Gmailへのメール配送で問題が起きた場合、最低限次を確認します。
□ Gmailから返されたSMTP応答
□ 実際の送信元グローバルIP
□ PTR
□ PTRで返ったFQDNのA/AAAA
□ EHLO名
□ SPF
□ DKIM
□ DKIMのd=
□ DMARC
□ Header From
□ SPF Alignment
□ DKIM Alignment
□ Receivedによる配送経路
ここまで正常なら、
DNS・メール認証
から、
レピュテーション
コンテンツ
送信方法
へ調査対象を移します。
まとめ
Gmailへメールが届かない、または迷惑メールになる場合、
SPFだけ確認
では十分ではありません。
まず配送ログを確認し、その後、
送信元IP
↓
PTR
↓
正引き
↓
EHLO
↓
SPF
↓
DKIM
↓
DMARC
↓
Alignment
と順番に確認します。
そして、
SPF PASS
DKIM PASS
DMARC PASS
だったとしても、迷惑メールにならないことが保証されるわけではありません。
ここまで正常なら、
「メール認証の問題ではない可能性が高くなった」
と判断して、送信元レピュテーションやメール内容など、次の調査へ進みます。
メール配送トラブルでは、設定を手当たり次第に変更するより、
「どこまでは正常なのか」を一つずつ確認する
ことが原因特定への近道です。


コメント