DNSの設定ミスが「メールが届かない」原因に――DNSレコードのチェックポイントを解説：意外と知らないメールサーバ構築・運用の基本（6）

　DNSは、ドメイン名とIPアドレスの対応関係を管理する仕組みとして広く知られています。メールの送受信では、「この送信元は信頼できるか？」を判断するための重要な手掛かりとしても活用されています。

　メール送信プロトコルSMTP（Simple Mail Transfer Protocol）には、認証やなりすましを防ぐための機能はもともと備わっていません。そのため、悪意ある送信者が他人になりすましたメールを簡単に送信できてしまう問題がありました。この問題に対処するために、まず導入されたのが、逆引きDNS（PTRレコード）やAレコードの整合性確認といった、インフラレベルでの信頼性確認でした。これらは現在でも、スパムフィルターやレピュテーションベースのフィルタリングにおける評価指標の一つとして使われており、適切に設定されていない場合はそれだけで受信拒否の対象になることもあります。

　その後、送信ドメインの正当性を確認するための技術として、SPF（Sender Policy Framework）やDKIM（DomainKeys Identified Mail）、DMARC（Domain-based Message Authentication, Reporting and Conformance）といった認証方式が登場し、現在では多くのメールサービスで導入が進んでいます。これらはいずれもDNSにTXTレコードとして設定され、受信側が送信者の信頼性を評価する材料となります。

　このように、メール配信との関連性が意識されることは少ないかもしれませんが、実はDNSの設定はメールの到達率を大きく左右する重要な要素なのです。

到達率を上げるために重要なDNSレコード

　この章では、迷惑メール判定を避けるために確認すべきDNSレコードを取り上げ、それぞれの役割と設定のポイントを解説します。

Aレコード

　（1）Aレコードの重要性

　Aレコードは、ホスト名（FQDN：Fully Qualified Domain Name）をIPv4（Internet Protocol version 4）アドレスに変換するためのDNSレコードです。

　メール送信では、送信元SMTPサーバが実在するものかどうかを確認するために参照されます。もしAレコードが存在しなければ、「適切に管理されていない」と受信側に判断される可能性があります。

　（2）Aレコードの書式

　Aレコードは、次のように記述します。

mail.example.com.    IN    A    192.0.2.1

　この例では「mail.example.com」というホスト名に対して「192.0.2.1」というIPアドレスが対応付けられています。

　（3）Aレコードのチェックポイント

　Aレコードについては、以下の観点で正しく設定されているかどうかの確認が必要です。

• 送信元SMTPサーバのホスト名のAレコードが登録されているか
  メールを送信するSMTPサーバのホスト名に対して、IPアドレスのAレコードが正しく設定されているかどうかを確認する

PTRレコード

　（1）PTRレコードの重要性

　PTRレコードは、IPアドレスからホスト名への変換、いわゆる「逆引き」に使用されるDNSレコードです。

　メール送信では、送信元のIPアドレスが正当なホスト名とひも付いているかどうかを確認するために、受信側のサーバが参照します。これは、スパム送信者が一時的に取得したIPアドレスを悪用していることが多いので、正規のホスト名との整合性を確認することで、信頼性の判断材料とするからです。

　PTRレコードが設定されていない、あるいはホスト名との対応が不適切な場合、スパムメールと見なされてブロックされる可能性が高まります。

　（2）PTRレコードの書式

　PTRレコードを設定するには、IPアドレスを逆引き用表記にする必要があります。逆引き用表記は、IPアドレスの各オクテットを逆順に並べ、その後ろに「in-addr.arpa」を付与します。例えば、IPアドレス「192.0.2.1」の逆引きは次のように記述します。

1.2.0.192.in-addr.arpa.    IN    PTR    mail.example.com.

　これで受信側サーバがIPアドレス「192.0.2.1」を逆引きすると、「mail.example.com」というホスト名を得ることができます。

　（3）PTRレコードのチェックポイント

　PTRレコードに関しては、以下の3点を確認しましょう。

• 送信元SMTPサーバのIPアドレスにPTRレコードが設定されているかどうか
  PTRレコードが設定されていないと、受信側は逆引きに失敗し「正体不明の送信元」と判断される可能性がある。迷惑メールフィルターによっては、これだけでブロックの対象になることもある
• 逆引きしたホスト名と送信元SMTPサーバのホスト名が一致しているかどうか
  逆引きで得たホスト名と、SMTPセッション中に送信サーバが名乗るホスト名（HELO/EHLO）が一致していると、送信元の信頼性が高いと評価されやすくなる
• 逆引きで得られたホスト名に対して正引き（Aレコード）が設定されており、かつIPアドレスが一致しているか
  PTRで得たホスト名をさらに正引き（Aレコード）して、元のIPアドレスに戻るかどうかを確認する。この「逆引き→正引き」の往復の整合性が取れていれば「ドメインとIPの対応が明確だ」と判断され、スパム判定のリスクを低減できる

MXレコード

　（1）MXレコードの重要性

　MXレコードは、特定のドメイン宛てのメールをどのメールサーバに転送すべきか指定するDNSレコードです。

　通常、MXレコードは受信のための設定ですが、送信者の信頼性を判断する材料として参照されています。ヘッダFromやエンベロープFromに使用されているドメインにMXレコードが存在しない場合、「メール受信を想定していないスパム送信者だ」と判断される可能性があり、迷惑メールフィルターによってブロックされるリスクが高まります。

　（2）MXレコードの書式

　MXレコードは次のように記述します。

example.com.    IN    MX    10    mail.example.com.

　この設定では、「example.com」宛てのメールは「mail.example.com」に優先度「10」で配送されることを意味します。

　MXレコードは、必ずFQDN（ホスト名）を指定する必要があり、IPアドレスを直接記載するのは誤りです。またMXレコードで指定したホスト名は、別途AレコードまたはAAAAレコードを設定して名前解決できるようにしておく必要があります。

　（3）MXレコードのチェックポイント

　MXレコードに関しては、以下の点を確認しておくとよいでしょう。

• エンベロープFromのドメインにMXレコードが設定されているかどうか
  Return-Pathに記載されるエンベロープFromのドメインが、実在するものと判断されるためには、MXレコードの存在が望まれる
• ヘッダFromのドメインにMXレコードが設定されているかどうか
  ヘッダFromのドメインにもMXレコードが存在すると、より信頼性が高まる
• MXレコードに指定されたホスト名が正しくAレコードまたはAAAAレコードで解決できるかどうか
  MXレコードの指す先が正しく解決できないと、受信側で不審に思われることがある

TXTレコード（SPF、DKIM、DMARC）

　（1）TXTレコードの重要性

　TXTレコードは、SPFやDKIM、DMARCといった送信ドメイン認証に使われており、現在ではメール送信に不可欠になっています。設定が不十分な場合は、受信側での認証に失敗し、迷惑メールと判定されるリスクが高まります。

　（2）TXTレコードのチェックポイント

　少なくとも「存在するかどうか」はすぐに確認できるチェック項目として非常に重要です。詳細な実装例や注意事項については連載の次回記事で取り上げる予定なので、ここでは最低限、次の点を押さえておきましょう。

• SPFレコードが存在するかどうか（"v=spf1"から始まるTXTレコード）

example.co.jp.  IN  TXT  "v=spf1 ip4:123.456.789.10 -all"

そのドメインでメール送信を許可するIPアドレスを指定するためのもの。送信ドメイン認証の中でも最も基礎的なもので、必ず設定する

• DKIMレコードが存在するかどうか（"v=DKIM1"を含むTXTレコード）

selector1._domainkey.example.co.jp.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0G...（公開鍵）"

DKIMは、セレクタという識別子ごとにTXTレコードを登録する。どのセレクタが使われているかは、送信したメールのDKIM-Signatureヘッダに記載されている「s=」パラメーターを確認することで分かる

• DMARCレコードが存在するかどうか（"v=DMARC1" を含むTXTレコード）

_dmarc.example.co.jp.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

「Gmail」「docomo」「Apple iCloud」「Microsoft Outlook」など、DMARCを設定していない送信者のメールを迷惑メールとして扱うメールサービスプロバイダーが増えている。DMARCが設定されているかどうかも確認する必要がある

運用現場の送信環境を想定した設定例

　ここまで解説してきたDNSレコードの設定は、理論的には理解できても、運用現場におけるイメージが湧きにくいかもしれません。そこで本章では、具体的なメール送信環境を例にとり、どのようにDNSを設定すればよいかを整理します。

　次のような構成の、社内システムから直接インターネット経由でメールを送信するケースを想定します。

• 送信元：社内の業務システム（通知送信など）
• 送信手段：SMTPサーバ（「Postfix」など）から直接インターネット経由で送信する
• ヘッダFromのアドレス：[email protected]
• エンベロープFromのアドレス：[email protected]
• 送信元IPアドレス：123.456.789.10
• SMTPサーバのホスト名：smtp.example.co.jp

　この場合に必要となるDNS設定は下表の通りで。

DNSレコードの設定確認方法

　ここまで、送信メールの信頼性を保つために必要なDNSレコードの設定を見てきました。では、それらが正しく設定されているかどうか、どう確認すればよいのでしょうか。

　「MXToolBox」などのオンラインツールを利用すれば、特定のDNSレコードの設定有無だけでなく、構文の誤りや不備などがないかどうかの確認も可能です。

　しかし、配信動作と整合しているかどうかを確認するには、メールのヘッダやSMTPサーバの設定との突き合わせが必要な場合もあります。

　下表にツールで確認可能な項目と、自身で突き合わせて確認する必要がある項目を整理しました。

　こちらのチェック項目を参考に、自社のDNSレコードの設定状況を確認してみてください。

まとめ

　メールの到達率を左右する要因の一つとして、DNSの設定は見過ごせない存在です。もしメールの到達率に課題を感じている場合は、本記事で紹介した各レコードのチェックポイントを参考に、自社ドメインのDNSレコード設定状況を点検することをお勧めします。

　次回は、今回触れたSPFやDKIM、DMARCについて、それぞれのメリットや設定方法、認証結果の見方などをより詳しく解説します。