メール配送で利用されるDNS問い合わせの流れ

目次
メール配送で利用されるDNS問い合わせの流れを理解しよう
メールを送信すると、SMTPサーバは相手のメールサーバへ直接メールを届けているように見えます。
しかし実際には、その前段階で複数のDNS問い合わせが実行されています。
DNSが正常に動作していなければメール配送は成立しません。
また近年では迷惑メール対策のため、メール配送時に利用されるDNS情報も増えています。
本記事ではSMTPサーバが実際にどのようなDNS問い合わせを行いながらメールを配送しているのかを解説します。
メール配送はDNSから始まる
例えば以下のメールを送信するとします。
user@gmail.com
送信側SMTPサーバは、いきなりGmailへ接続するわけではありません。
まずDNSへ問い合わせを行い、配送先メールサーバを特定します。
メール配送の全体像
簡略化すると次のような流れになります。
メール送信
↓
MXレコード問い合わせ
↓
Aレコード問い合わせ
↓
SMTP接続
↓
メール配送
まず配送先メールサーバを調べる必要があります。
具体例で考える
例えば次のメールを送信するとします。
student@example.com ↓ user@gmail.com
送信側SMTPサーバはgmail.comを取り出します。
gmail.com
そしてDNS問い合わせを開始します。
ステップ1 MXレコードを問い合わせる
最初にMXレコードを確認します。
$ dig MX gmail.comSMTPサーバ内部でも同様の問い合わせが行われています。
MXレコード取得例
実際には次のような結果が返されます。
gmail.com. IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. IN MX 10 alt1.gmail-smtp-in.l.google.com.配送先メールサーバ候補を取得できます。
なぜMXレコードが必要なのか
メール受信サーバはWebサーバとは異なる場合があります。
例えば以下の構成です。
www.example.com ↓ Webサーバ mail.example.com ↓ メールサーバ
そのため専用のMXレコードが必要になります。
ステップ2 Aレコードを問い合わせる
MXレコードにはホスト名しか記載されていません。
そこでSMTPサーバはさらにAレコードを問い合わせます。
$ dig A gmail-smtp-in.l.google.comIPアドレスを取得します。
Aレコード取得例
gmail-smtp-in.l.google.com. IN A 74.125.xxx.xxxこれで接続先IPアドレスが分かります。
ステップ3 SMTP接続を行う
SMTPサーバは取得したIPアドレスへ接続します。
74.125.xxx.xxx:25
SMTP通信が開始されます。
SMTP通信の例
220 smtp.example.com
EHLO mail.example.com
MAIL FROM:
RCPT TO:
DATAここでメール配送が行われます。
配送先サーバ側でもDNSを利用する
実は受信側SMTPサーバもDNSを利用します。
送信元サーバの信頼性を確認するためです。
ステップ4 PTRレコード確認
受信側SMTPサーバは送信元IPアドレスを確認します。
203.0.113.10
そして逆引きDNSを実行します。
$ dig -x 203.0.113.10送信元ホスト名を取得します。
PTR確認の目的
送信元SMTPサーバの信頼性確認です。
スパムサーバの多くは逆引きDNSを設定していません。
そのため重要な判定材料になります。
ステップ5 FCrDNS確認
さらに正引き・逆引きの整合性確認を行う場合があります。
203.0.113.10
↓
mail.example.com
↓
203.0.113.10
これをFCrDNSと呼びます。
ステップ6 SPF確認
受信側SMTPサーバはSPFレコードを確認します。
$ dig TXT example.com送信元IPアドレスが許可されているか確認します。
SPF確認の流れ
送信元IP取得
↓
SPF取得
↓
IP照合
↓
Pass / Fail
なりすまし対策として利用されます。
ステップ7 DKIM確認
メールヘッダにDKIM署名が存在する場合です。
受信側SMTPサーバはDNSから公開鍵を取得します。
mail._domainkey.example.com
DNSへ問い合わせます。
DKIM公開鍵取得例
$ dig TXT mail._domainkey.example.com公開鍵を取得して署名検証を行います。
ステップ8 DMARC確認
DMARCレコードもDNSから取得します。
$ dig TXT _dmarc.example.com認証失敗時の処理方針を確認します。
DNS問い合わせの全体像
現在のメール配送では次のような問い合わせが行われます。
MX取得 ↓ A取得 ↓ SMTP接続 ↓ PTR確認 ↓ SPF確認 ↓ DKIM確認 ↓ DMARC確認
想像以上に多くのDNS問い合わせが発生しています。
DNSキャッシュの役割
毎回問い合わせを行うと遅くなるため、DNSキャッシュが利用されます。
SMTPサーバもDNSキャッシュの恩恵を受けています。
メール配送性能にも影響します。
DNS障害が発生するとどうなるか
DNSサーバへ問い合わせできない場合です。
DNS障害
↓
MX取得失敗
↓
配送不能
メール送信に失敗します。
DNS設定ミスで起こる問題
- MXレコード誤り
- Aレコード誤り
- PTR未設定
- SPF誤設定
- DKIM公開鍵未登録
- DMARC未設定
メール到達率低下の原因になります。
実務でよく使う確認コマンド
MX確認です。
$ dig MX example.com
Aレコード確認です。
$ dig A mail.example.com
逆引き確認です。
$ dig -x 203.0.113.10
SPF確認です。
$ dig TXT example.com
DKIM確認です。
$ dig TXT mail._domainkey.example.com
DMARC確認です。
$ dig TXT _dmarc.example.comメールが届かない時の調査手順
まず以下の順で確認すると効率的です。
- MXレコード
- Aレコード
- SMTP接続
- PTRレコード
- SPF
- DKIM
- DMARC
DNS関連が原因であるケースは非常に多くあります。
まとめ
メール配送ではMXレコードだけでなく、Aレコード、PTRレコード、SPF、DKIM、DMARCなど多くのDNS情報が利用されています。
SMTPサーバは配送先特定のためにDNSを利用し、受信側SMTPサーバは送信元の信頼性確認のためにDNSを利用します。
現在のメールシステムはDNSとの連携によって成り立っていると言っても過言ではありません。
メールサーバの構築や障害対応を行う際は、DNS問い合わせの流れを理解しておくことが重要です。





