BLOG ベアメールブログ
メールを正しく送受信するには、メールサーバー側の設定だけでなく、ドメインのDNS設定も重要です。DNSレコードに不備があると、メールを受信できなかったり、送信したメールが受信側で不審なメールと判断されたりする原因になります。
メールに関する主なDNSレコードには、受信用のメールサーバーを指定するMXレコード、メールサーバーのホスト名を名前解決するA/AAAAレコード、送信元IPアドレスの逆引きに使われるPTRレコード、送信ドメイン認証に関わるTXTレコードなどがあります。
本記事では、メール送受信に関わるDNS設定の基本や、受信・送信・送信ドメイン認証の3つの観点で確認すべきDNSレコード、迷惑メール判定のリスクを抑えるためのポイントについて解説します。
目次
メールに関するDNS設定とは
メールを送受信するためには、配送先となるメールサーバーや送信元を確認するための情報、認証情報などをDNSで参照できるようにしておく必要があります。そのため、メールに関するDNSレコードは、ドメインを管理するDNS上に適切に登録しておくことが重要です。
ここでは、メール送受信においてDNSが参照される仕組みと、メールに関する主なDNSレコードについて解説します。
DNSの基本的な仕組みや主なDNSレコードの種類については、以下の記事で詳しく解説しています。
メール送受信でDNSが参照される仕組み
Webサイトにアクセスするとき、ブラウザはドメイン名に対応するIPアドレスをDNSに問い合わせます。例えば「baremail.jp」にアクセスする場合、DNSによって対応するIPアドレスが返され、そのIPアドレスをもとに対象のサーバーへ接続します。
メール送信でも、これと同じようにDNSが利用されます。メールを送信する際は、宛先メールアドレスのドメインをもとにDNSを参照し、そのドメイン宛のメールをどのメールサーバーに届けるべきかを確認します。
このように、メールを送受信するためには、宛先ドメインに対応する受信先メールサーバーのホスト名や、そのホスト名に対応するIPアドレスをDNS上で参照できる状態にしておく必要があります。こうした名前解決に必要な情報を提供しているのが、DNSサーバー（ネームサーバー）です。
メール送受信に関わる主なDNSレコード
メール送受信に関わる主なDNSレコードは、以下の通りです。
DNSレコード 主な役割 MXレコード そのドメイン宛のメールを受信するメールサーバーを指定する A/AAAAレコード ホスト名をIPv4アドレスまたはIPv6アドレスに対応づける（正引き） PTRレコード IPアドレスをホスト名に対応づける（逆引き） TXTレコード SPF・DKIM・DMARCなど、送信ドメイン認証に関する情報を公開する
これらのDNSレコードが適切に設定されていない場合、メールを正しく受信できなかったり、送信元の確認ができずに受信側で不審なメールと判断されたりすることがあります。以降では、受信・送信・送信ドメイン認証の観点から、各DNSレコードの役割や基本的な設定内容を解説します。
メール受信に関わるDNS設定
メールを受信するには、宛先ドメインの受信先を送信元メールサーバーがDNSで確認できる状態にしておく必要があります。ここでは、メール受信に関わるMXレコードとA/AAAAレコードについて解説します。
MXレコード
MXレコードは、特定のドメイン宛のメールをどのメールサーバーに配送するかを指定するレコードです。値には、メールを受信するメールサーバーのホスト名を指定します。
＜基本書式＞
[ドメイン名] IN MX [優先度] [メールサーバのホスト名]
＜記述例＞
example.com. IN MX 10 mail.example.com.
MXレコードの優先度は、複数のメールサーバーが設定されている場合に、どのサーバーから順に配送を試みるかを示す値です。数字が小さいほど優先度が高く、優先度が同じMXレコードが複数ある場合は、同じ優先順位の配送先として扱われます。一般的には、10、20のように間隔を空けて設定されることが多くなっています。
MXレコードの詳しい書き方や設定方法については、以下の記事で解説しています。
A/AAAAレコード
Aレコードは、ホスト名をIPv4アドレスに対応づけるレコードです。AAAAレコードは、ホスト名をIPv6アドレスに対応づける場合に使用します。
メール受信では、MXレコードで指定されたメールサーバーのホスト名を、AレコードまたはAAAAレコードによってIPアドレスに変換します（正引き）。そのため、MXレコードの参照先となるホスト名は、A/AAAAレコードで名前解決できる状態にしておく必要があります。
＜基本書式＞
[メールサーバーのホスト名] IN A [IPv4アドレス]
[メールサーバーのホスト名] IN AAAA [IPv6アドレス]
＜記述例＞
mail.example.com. IN A 192.0.2.10
mail.example.com. IN AAAA 2001:db8::10
A/AAAAレコードが正しく設定されていない場合、送信元メールサーバーは配送先のIPアドレスを特定できず、メールを届けられない可能性があります。特にMXレコードを変更した場合は、その参照先のホスト名が正しく名前解決できるかもあわせて確認することが重要です。
メール送信に関わるDNS設定
メールを送信する際に、受信側メールサーバーが送信元のIPアドレスやホスト名をDNSで確認することがあります。ここでは、メール送信に関わるPTRレコードについて解説します。
PTRレコード
PTRレコードは、IPアドレスに対応するホスト名を定義するDNSレコードです。AレコードやAAAAレコードがホスト名からIPアドレスを調べる「正引き」に使われるのに対し、PTRレコードはIPアドレスからホスト名を調べる「逆引き」に使われます。
メール送信では、受信側メールサーバーが送信元IPアドレスの逆引き結果を確認することがあります。PTRレコードが設定されていない場合や、逆引きで得られたホスト名と送信元IPアドレスの対応関係を確認できない場合、受信側のポリシーによっては信頼できない送信元と判断される可能性があります。
＜基本書式＞
※IPv4の場合
[IPv4アドレスを逆順にした値]. in-addr.arpa. IN PTR [ホスト名]
＜記述例＞
IPアドレスが「210.140.191.14」、ホスト名が「smtp.baremail.jp」の場合、以下のように記述します。
14.191.140.210.in-addr.arpa. IN PTR smtp.baremail.jp.
送信ドメイン認証に関わるDNS設定
送信ドメイン認証では、送信元として使用するドメインのDNSにTXTレコードとして認証に必要な情報を登録します。受信側メールサーバーは、その情報を参照することで、送信元ドメインの正当性や認証結果を確認します。ここでは、SPF・DKIM・DMARCに関わるDNS設定について解説します。
SPFレコード
SPFレコードは、そのドメインを使用してメールを送信するメールサーバーのIPアドレスやホスト名をDNS上で公開するためのレコードです。受信側メールサーバーは、送信元IPアドレスがSPFレコードに含まれているかを確認し、送信元ドメインの正当性を判断する材料とします。
＜基本書式＞
[ドメイン名]. IN TXT “v=spf1 [メカニズム] [メカニズム] [allの指定]”
＜記述例＞
example.com. IN TXT “v=spf1 ip4:192.0.2.10 include:spf.example.net ~all”
SPFの仕組みやレコードの詳しい書き方、設定方法については、以下の記事で詳しく解説しています。
DKIMレコード
DKIMレコードは、DKIM署名の検証に使用する公開鍵をDNS上で公開するためのレコードです。送信側はメールにDKIM署名を付与し、受信側メールサーバーはDNSに登録された公開鍵を参照して、署名対象となるヘッダや本文が送信後に改ざんされていないかを確認します。
＜基本書式＞
[セレクタ]._domainkey.[ドメイン名]. IN TXT “v=DKIM1; k=rsa; p=[公開鍵]”
＜記述例＞
selector1._domainkey.example.com. IN TXT “v=DKIM1; k=rsa; p=MIIBIjANBgkqh…”
DKIMの仕組みやレコードの詳しい書き方、設定方法については、以下の記事で詳しく解説しています。
DMARCレコード
DMARCレコードは、SPFやDKIMの認証結果と、ヘッダFromドメインとの整合性をもとに、DMARC認証に失敗したメールを受信側でどのように扱うかを示すためのレコードです。ドメイン所有者は、DNSにDMARCポリシーを公開します。受信側メールサーバーは、ヘッダFromのドメインとSPF・DKIMで認証されたドメインの整合性を確認し、公開されているDMARCポリシーを参照して処理を判断します。
＜基本書式＞
_dmarc.[ドメイン名]. IN TXT “v=DMARC1; p=[ポリシー]; rua=mailto:[レポート送信先]”
＜記述例＞
_dmarc.example.com. IN TXT “v=DMARC1; p=none; rua=mailto:dmarc@example.com”
DMARCの仕組みやレコードの詳しい書き方、設定方法については、以下の記事で詳しく解説しています。
迷惑メール判定リスクを抑えるためのDNS設定のポイントと確認方法
DNS設定を適切に行うことは、迷惑メール判定のリスクを抑えるうえでも重要です。受信側メールサーバーは、送信元SMTPサーバーのIPアドレスやホスト名、エンベロープFromのドメインなどをもとにDNSへ問い合わせを行い、送信元を確認することがあります。
そのため、送信元IPアドレスの逆引きや、SMTPサーバーのホスト名、エンベロープFrom・ヘッダFromに使用するドメインなどを、DNSで正しく参照できる状態にしておく必要があります。
ここでは、迷惑メール判定リスクを抑えるためのDNS設定のポイントと、コマンドを使った確認方法を解説します。
送信元IPアドレスにPTRレコードが設定されているか
まず、送信元SMTPサーバーのIPアドレスにPTRレコードが設定されているかを確認します。PTRレコードが設定されている場合、IPアドレスを逆引きすると、そのIPアドレスに対応するホスト名が返されます。
digコマンドで確認する場合は、IPアドレスの前に「-x」オプションを付けて実行します。
＜コマンド＞
dig -x [送信元IPアドレス]
＜実行例＞
dig -x 123.456.789.10
上記の例では、送信元IPアドレス「123.456.789.10」を逆引きした結果として、「smtp.baremail.jp」というホスト名が返されており、PTRレコードが設定されていることがわかります。
一方、PTRレコードが設定されていない場合は、送信元IPアドレスに対応するホスト名を確認できません。受信側メールサーバーのポリシーによっては、送信元の信頼性を判断するうえでマイナスの材料になることがあります。
なお、PTRレコードは多くの場合、IPアドレスを管理しているISPやクラウド事業者、ホスティング事業者側で設定します。未設定の場合は、利用中のサービスの管理画面やサポート窓口で、PTRレコードの設定可否を確認しましょう。
逆引きと正引きの結果が一致しているか
次に、逆引きで得られたホスト名を正引きし、元の送信元IPアドレスと一致するかを確認します。
＜コマンド＞
dig [逆引きで得られたホスト名]
＜実行例＞
dig smtp.baremail.jp
上記の例では、逆引きで得られた「smtp.baremail.jp」の正引き結果が、送信元IPアドレス「123.456.789.10」と一致することが確認できます。
正引きしたIPアドレスが送信元IPアドレスと異なる場合、受信側のポリシーによっては、迷惑メールと判定される可能性があります。PTRレコードの設定内容や、ホスト名に紐づくA/AAAAレコードを確認しましょう。
正引き・逆引きが一致しない原因や対処法については、以下の記事で詳しく解説しています。
DNSの逆引き・正引きが不一致になるのはなぜ？ 主な原因と対処法を解説｜ベアメールブログ
送信元SMTPサーバーのホスト名がA/AAAAレコードで名前解決できるか
送信元SMTPサーバーのホスト名がA/AAAAレコードで名前解決できるかを確認します。ここでは、PTRレコードで返されたホスト名ではなく、メール送信時に使用しているSMTPサーバーのホスト名自体が正しくDNSに登録されているかを確認します。
＜コマンド＞
dig [送信元SMTPサーバーのホスト名]
＜実行例＞
dig smtp.baremail.jp
IPv6アドレスを使用している場合は、AAAAレコードも確認します。
＜AAAAレコードの確認コマンド＞
dig AAAA [送信元SMTPサーバーのホスト名]
上記の例では、送信元SMTPサーバーのホスト名「smtp.baremail.jp」を正引きした結果として、IPアドレス「123.456.789.10」が返され、Aレコードで名前解決できることが確認できます。
また、正引きしたIPアドレスが、実際にメール送信に使用している送信元IPアドレスと一致しているかも確認しておきましょう。異なるIPアドレスが返る場合は、A/AAAAレコードの設定内容や、送信システム側で使用しているSMTPサーバーのホスト名に誤りがないかを確認する必要があります。
エンベロープFrom・ヘッダFromのドメインが名前解決できるか
エンベロープFromやヘッダFromに使用しているドメインについても、DNSで名前解決できるかを確認します。エンベロープFromはバウンスメールの返送先、ヘッダFromは受信者に表示される差出人として使われます。これらのドメインがDNS上で確認できない場合、受信側のポリシーによっては迷惑メールと判定されるおそれがあります。
まず、MXレコードを確認します。MXレコードを確認する場合は、ドメイン名の後に「MX」を指定します。
＜コマンド＞
dig [エンベロープFromまたはヘッダFromのドメイン] MX
＜実行例＞
dig baremail.jp MX
上記の例では、対象ドメイン「baremail.jp」宛のメールを受信するメールサーバーのホスト名「smtp.baremail.jp」が返され、MXレコードが設定されていることがわかります。
MXレコードがない場合は、対象ドメインのAレコードを確認します。
＜コマンド＞
dig [エンベロープFromまたはヘッダFromのドメイン]
＜実行例＞
dig baremail.jp
IPv6アドレスを使用している場合は、AAAAレコードも確認します。
＜AAAAレコードの確認コマンド＞
dig AAAA [エンベロープFromまたはヘッダFromのドメイン]
上記の例では、対象ドメイン「baremail.jp 」を正引きした結果としてIPアドレス「123.456.789.10」が返され、Aレコードで名前解決できることが確認できます。
エンベロープFromのドメインは、エラーメールの返送先として使われるため、受信可能な状態になっているかを確認しておくことが重要です。また、ヘッダFromのドメインについても、DNS上で存在を確認できる状態にしておくことで、受信側が送信元ドメインを確認しやすくなります。
エンベロープFromとヘッダFromについては、以下の記事で詳しく解説しています。
まとめ
本記事では、メール送受信に関わるDNS設定の基本や、受信・送信・送信ドメイン認証の3つの観点で確認すべきDNSレコード、迷惑メール判定のリスクを抑えるためのポイントについて解説しました。
メールを安定して配信するためには、ドメインのDNSレコードを正しく管理することが重要です。MXレコードやA/AAAAレコード、PTRレコード、SPF・DKIM・DMARCに関するTXTレコードなどに不備があると、不達や迷惑メール判定の原因になる場合があります。
ただし、DNS設定や送信ドメイン認証を正しく運用するには、専門的な知識と継続的な確認が必要です。自社でのメールサーバー運用に不安がある場合や、メールが届かない原因を調査したい場合は、外部サービスの活用も検討するとよいでしょう。
ベアメール メールリレーサービスは、メール配信に特化したクラウド型のメールリレーサービスです。既存のシステムからメールを中継することで、メール配信基盤の運用負担を軽減しながら、安定したメール配信を実現できます。
また、ベアメール 迷惑メールスコアリングでは、テストメールを送信するだけで、迷惑メール判定につながる問題がないかを診断できます。メールが届かない原因を把握し、運用改善に役立てることが可能です。
メール配信環境の見直しを検討されている方や、迷惑メール判定への対策に課題を感じている方は、ぜひお気軽にご相談ください。
