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

メール配送で利用される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.com

SMTPサーバ内部でも同様の問い合わせが行われています。

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.com

IPアドレスを取得します。

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

メールが届かない時の調査手順

まず以下の順で確認すると効率的です。

  1. MXレコード
  2. Aレコード
  3. SMTP接続
  4. PTRレコード
  5. SPF
  6. DKIM
  7. DMARC

DNS関連が原因であるケースは非常に多くあります。

まとめ

メール配送ではMXレコードだけでなく、Aレコード、PTRレコード、SPF、DKIM、DMARCなど多くのDNS情報が利用されています。

SMTPサーバは配送先特定のためにDNSを利用し、受信側SMTPサーバは送信元の信頼性確認のためにDNSを利用します。

現在のメールシステムはDNSとの連携によって成り立っていると言っても過言ではありません。

メールサーバの構築や障害対応を行う際は、DNS問い合わせの流れを理解しておくことが重要です。