DNS サーバーに登録するメール関連の各レコードに関する設定について整理しました。
目次
一般的な企業の場合のメールシステム
一般的な企業の場合は、ユーザーとコミュニケーションを取るためにメールシステムを持っています。
メールを利用するためには配信用のメールサーバーと受信用のメールサーバーが必要になります。一方的にメールを配信して返信は受け付けないという企業もありますが、スパムメールや迷惑メール判定されるリスクがあります。
一般的な構成
■メール送信・配信
配信用メールサーバー
↓
ユーザーへメール配送
■メール受信
ユーザーからの返信・バウンスメール
↓
MXレコードで指定された受信メールサーバー送信サーバーと受信サーバーは同じとは限りません。
たとえば次のような構成があります。
送信：blastmail、WiLL Mail、SendGrid、自社メールサーバー、Amazon SES
受信：Microsoft 365、Google Workspace、自社メールサーバー企業が物理的・仮想的なメールサーバーを自社で保有せず、外部サービスを使う場合も一般的です。
メール配信だけでなくメール受信も外部サービスを利用する企業が一般的
メール受信も、現在は外部サービスに任せる企業が一般的です。むしろ、自社でメールサーバーを構築・運用する企業は少なくなっています。月100万円くらいずつ払ってエンジニアを複数人雇って運用するくらいなら、月数千円・数万円で外部の信頼できるサービスを利用する方が企業にとってはコストパフォーマンスが良いです。
一般社員へのメール受信とバウンスメールの受信は別にすることが多い
一般社員のメール受信の場合
例えば、企業が次のメールアドレスを使うとします。
employee001@example.com
employee002@example.com
employee003@example.com
support@example.comこの受信環境を、次のような外部サービスに任せます。
- Microsoft 365／Exchange Online
- Google Workspace／Gmail
- レンタルサーバーのメール機能
- メールホスティングサービス
Microsoft 365 を利用する場合、MX レコードは以下のようになります。
example.com MX 0 example-com.mail.protection.outlook.comすると、配送は次の流れになります。
外部の送信者
↓
employee001@example.com 宛てに送信
↓
example.com の MX レコードを確認
↓
Microsoft 365 の受信メールサーバー
↓
社員のメールボックスへ保存この企業は example.com という独自ドメインを使っていますが、実際の受信メールサーバーとメールボックスはMicrosoftが運用しているという構成です。
バウンスメールの受信は別にすることが多い
一方、メルマガのバウンスメールは、社員用メールシステムではなく、配信ベンダーに受信・処理させる構成が一般的です。
例えば次のように分けます。
社員用
@example.com
↓
Microsoft 365で受信
バウンス用
@bounce.example.com
↓
Cuenote や SendGrid 側で受信
業者側でバウンスメールを受信してバウンスメール解析をしてメール到達率やリストから除外するなどの対応をしてくれます。
DNS レコードの設定もそれぞれ別になります。
■社員用
example.com MX 0 Microsoft 365の受信サーバー
■バウンスメール用
bounce.example.com MX 10 配信ベンダーのバウンス受信サーバーバウンスメールは人が読むとは限らない
バウンスメールは、多くの場合、担当者が受信トレイを開いて確認するものではありません。
配信ベンダーが自動的に次を処理します。
バウンス受信
↓
存在しないアドレスか判定
↓
一時的な失敗か判定
↓
配信停止・再送回数などを更新このため、バウンス専用のメールボックスをMicrosoft 365などに作るよりも、配信ベンダーに直接受信・解析させる方が効率的です。
配信用・送信用のメールサーバーのDNSレコードについて
「配信用メールサーバー用のDNSレコード」は、1種類ではありません。一般的には、送信サーバーの所在地を示すレコードと、そのサーバーからの送信を認証するレコードを組み合わせます。
最も重要なのは、メールを送るだけならMXレコードは必須ではないという点です。
基本構成
例えば、次の配信用メールサーバーからメールを送るとします。
送信サーバー名：
mail.example.com
送信サーバーのIP：
192.0.2.10
表示上のFrom：
newsletter@example.com
エンベロープFrom：
bounce@bounce.example.comこの場合、概念的には次のDNSレコードを設定します。
mail.example.com
A 192.0.2.10
192.0.2.10の逆引き
PTR mail.example.com
bounce.example.com
TXT "v=spf1 ip4:192.0.2.10 -all"
selector1._domainkey.example.com
TXT "v=DKIM1; p=公開鍵..."
_dmarc.example.com
TXT "v=DMARC1; p=none"
bounce.example.com
MX 10 mail-bounce.example.comAレコード
Aレコードは、配信用メールサーバー名とIPアドレスを対応付けます。
mail.example.com
A 192.0.2.10これは、mail.example.com のIPアドレスは 192.0.2.10という意味です。
メール送信時には、送信サーバーが相手側に自分の名前を伝えます。
EHLO mail.example.com相手側メールサーバーは、必要に応じて mail.example.com のDNSを確認します。
PTRレコード（逆引きDNS）
PTR（ポインター）レコードは、IPアドレスからサーバー名を調べるためのレコードです。
192.0.2.10
↓ 逆引き
mail.example.comMXレコードとは？
MX レコードとは、そのドメイン宛てのメールを、どのメールサーバーで受信するかを指定するDNSレコードです。
たとえば、以下のドメインとメールアドレスがあるとします。
ドメイン：example.com
メールアドレス：user@example.comこのメールを受信する自社メールサーバーを、次の名前で用意したとします。
mail.example.comDNS には次のように登録します。
example.com. MX 10 mail.example.com.ちなみに、最後の . は「ここまでが完全なドメイン名です」という意味です。完全修飾ドメイン名（FQDN）です。
DNSの仕組み上、ドメイン名は本来、最上位にある「ルート」を表すドットまで含みます。
ドットを付けない場合のトラブル例
ドットを付けなくても人間としては理解できますが、サーバー周りの設定によってはトラブルが発生する場合があります。
DNS のゾーンファイルでは、末尾のドットがない名前は、現在のゾーン名を後ろに補う「相対名」として扱われることがあります。
たとえば example.com のゾーン内で、
mail.example.comと書くと、環境によっては次のように解釈される可能性があります。
mail.example.com.example.com.末尾にドットを付ければ、
mail.example.com.となり、example.com を追加しないことが明確になります。
ちなみに Amazon Route 53 などの DNS 管理画面では、通常は末尾のドットを省略しても適切に処理されます。
mail.example.com ← 内部的に mail.example.com. として処理される。バウンスメールとは
バウンスメールとは、送信したメールを相手に届けられなかったときに返ってくる「配信失敗通知メール」です。
たとえば、次のアドレスにメールを送ったとします。
user@example.comしかし、実際にはこのアドレスが存在しなかった場合、相手側のメールサーバーなどから以下のような通知が返されます。
メールを配信できませんでした
宛先のメールアドレスが存在しません以下は Gmail の場合です。
これがバウンスメールです。
よくあるバウンスの原因
主な原因は次のようなものです。
- メールアドレスが存在しない
- 相手のメールボックスがいっぱい
- 相手のメールサーバーが一時的に停止している
- メールサイズが大きすぎる
- 迷惑メールとして拒否された
- 送信元ドメインやIPアドレスが拒否された
ハードバウンスとソフトバウンス
バウンスは、大きく2種類に分けられます。
ハードバウンス
今後も届く可能性が低い、恒久的な失敗です。
宛先メールアドレスが存在しない
ドメインが存在しない
相手側から恒久的に拒否されたこの場合は、通常、そのメールアドレスを配信リストから除外します。
ソフトバウンス
一時的な失敗です。
メールボックスがいっぱい
相手側サーバーが一時停止している
一時的な通信障害この場合は、時間を置いて再送することがあります。
バウンスメールはどこに返るのか
基本的には、受信者に表示される From ではなく、メール送信時に指定したエンベロープFrom（Envelop From）へ返ります。
たとえば、
表示上の送信元：
newsletter@example.comでも、バウンス返却先を次のようにできます。
bounce@example.comその場合、配送に失敗すると、バウンスメールは原則としてこちらへ返ります。
bounce@example.com受信したメールでは、この返却先が Return-Path として確認できることがあります。
バウンスメールは、人が手作業で返信しているわけではありません。
通常の返信
相手の利用者が返信する
バウンスメール
メールサーバーが自動で配信失敗を通知するメルマガ配信でバウンスメール管理が重要な理由
メルマガを大量に配信すると、古くなったメールアドレスや存在しないアドレスが含まれることがあります。
バウンスを放置して繰り返し送ると、送信元の評価が下がり、正常なメールまで迷惑メール扱いされる可能性があります。
そのため、通常は次のように運用します。
メール配信
↓
バウンス発生
↓
原因を判定
↓
ハードバウンスなら配信停止
↓
ソフトバウンスなら一定回数再送From と エンベロープ From（Envelop From）の違い
From
受信者のメール画面に表示される送信者です。
From: newsletter@example.com受信者には、通常このように見えます。
送信者：newsletter@example.comつまり、From はメール本文のヘッダー情報であり、人が見るための送信元です。
エンベロープFrom（Envelop From）
メールサーバー同士が配送するときに使う送信元です。
SMTP 通信では、次のように指定されます。
MAIL FROM:<bounce@example.com>主な用途は、メールを届けられなかった場合のバウンス返却先です。
通常、受信したメールでは次のような Return-Path として確認できます。
Return-Path: <bounce@example.com>エンベロープFrom には DKIM や DMARC のレコード（設定）は不要
詳しくは以下で開設しますが、info.example.com が エンベロープFrom 専用であり、表示From にも DKIM署名の d= にも使わないなら、info.example.com 用の DKIM・DMARC レコードは不要です。
【例】
表示From：
newsletter@example.com
エンベロープFrom：
bounce-12345@info.example.com
DKIM署名：
d=example.com
s=selectorinfo
送信メールサーバー：
mail.example.com（192.0.2.10）受信メールのイメージ
From: newsletter@example.com
Return-Path: <bounce-12345@info.example.com>
DKIM-Signature: ... d=example.com; s=selectorinfo; ...| 認証 | どの情報を見るか | DNSの確認先 |
|---|---|---|
| SPF | エンベロープFrom | bounce-12345@info.example.com |
| DKIM | DKIM-Signature の d= と s= | selectorinfo._domainkey.example.com |
| DMARC | 表示From | _dmarc.example.com |
従って、この場合の環境は以下のレコードが必要になりますが、エンベロープFrom 用に必要なのは上の3つのレコードです。
下の2つのレコードは DKIM署名用と From（表示From）用に必要なレコードとなります。
info.example.com TXT "v=spf1 ip4:192.0.2.10 ~all" ← エンベロープFrom で必要
info.example.com MX 10 mail.example.com ← エンベロープFrom で必要
mail.example.com A 192.0.2.10 ← エンベロープFrom で必要
selectorinfo._domainkey.example.com TXT "v=DKIM1; k=rsa; p=公開鍵"
_dmarc.example.com TXT "v=DMARC1; p=none"両者は異なるアドレスにできる
From と エンベロープFrom は別物のアドレスです。
例えば、メルマガを次の設定で送信できます。
From:
newsletter@example.com
エンベロープFrom:
bounce@example.comこの場合の動作は次のとおりです。
受信者に表示される送信元
newsletter@example.com
配送に失敗した場合の返却先
bounce@example.comつまり、
From → 人に見せる送信元
エンベロープFrom → メール配送で使う送信元という違いです。
バウンスメール含めた全体像
様々な用語が出てきているので再度全体像からまとめます。
メールには、大きく3つの世界があります。
| 分類 | 役割 |
|---|---|
| メールヘッダー | 人が見る送信元・宛先 |
| SMTPエンベロープ | メールサーバーが配送に使う情報 |
| DNS | どのメールサーバーへ届けるかを決める情報 |
たとえば、次のメールを送るとします。
表示上の送信元：
newsletter@example.com
実際の配送失敗通知の返却先：
bounce@example.com
実際の送信先：
user11@tama-chan.netSMTP上では次のようになります。
MAIL FROM:<bounce@example.com>
RCPT TO:<user11@tama-chan.net>
From: newsletter@example.com
To: user11@tama-chan.net
Subject: お知らせ用語の対応表
| 用語 | 実例 | 役割 |
|---|---|---|
| From | From: newsletter@example.com | 受信者のメール画面に表示される送信元。配送に失敗した際のバウンスメールが必ずこのアドレスへ返るわけではない。 |
| To | To: user11@tama-chan.net | 受信者のメール画面に表示される宛先。実際の配送先はSMTPの RCPT TO で決まる。 |
| Reply-To | Reply-To: support@example.com | 受信者が「返信」を押したときの返信先。FromとReply-Toが異なるアドレスの場合がある。 |
| MAIL FROM | MAIL FROM: bounce@example.com | SMTPコマンド。SMTP上の送信元指定、エンベロープFrom、バウンス返却先。 |
| エンベロープFrom | bounce@example.com | メールサーバーが配送処理に使う配送上の送信元。主な役割は、配送失敗時のバウンスメール返却先。MAIL FROMで指定されたアドレス。 |
| RCPT TO | RCPT TO: user11@tama-chan.net | SMTPコマンド。SMTP上の配送先指定、エンベロープTo、実際の配送先。 |
| エンベロープTo | user11@tama-chan.net | 実際のメールサーバーが配送する宛先。 |
| Return-Path | Return-Path: bounce@example.com | 配送時に使われたエンベロープFromを、受信サーバーがメールヘッダーに記録したもの。メールが配送失敗した場合に、どこへバウンスを返すか設定したもの。 |
| バウンスメール | 配信失敗通知 | 配送できなかったことを知らせるメール。通知は原則として、エンベロープFromへ送られる。 |
| MXレコード | example.com MX mail.example.com | そのドメイン宛てのメールを受信する受信メールサーバーを指定 |
| メールサーバー | mail.example.com | 実際にメールを送受信するサーバー |
メール送信の具体例
次の設定でメールを送るとします。
From:
newsletter@example.com
Reply-To:
support@example.com
MAIL FROM:
bounce@example.com
RCPT TO:
user11@tama-chan.net受信者から見える情報は次です。
差出人：newsletter@example.com
宛先：user11@tama-chan.net受信者が返信ボタンをクリックして返信すると、次へ送られます。
support@example.comメールが配送できなかった場合は、次へバウンスが返ります。
bounce@example.combounce@example.com 宛てのメールをどのサーバーで受信するかは、example.com のMXレコードで決まります。
example.com MX 10 mail.example.com配送成功時の流れ
1. 送信サーバーがメールを送る
MAIL FROM:<bounce@example.com>
RCPT TO:<user11@tama-chan.net>
2. tama-chan.net の MX レコードを確認
3. tama-chan.net のメールサーバーへ配送
4. 受信メールに以下が記録される
Return-Path: <bounce@example.com>
From: newsletter@example.com
To: user11@tama-chan.net配送失敗時の流れ
1. 送信サーバーがメールを送る
MAIL FROM:<bounce@example.com>
RCPT TO:<user11@tama-chan.net>
2. 相手側で宛先が存在しないと判定
3. バウンスメールを作成
4. bounce@example.com 宛てに返送
5. example.com の MX レコードを確認
6. mail.example.com がバウンスメールを受信SPF、DKIM レコード や DARC について
SPF や DKIM レコードは、メール送信の正当性を確認する仕組みです。ちなみに Web サーバー（Web サイト）の正当性は、一般的に SSL/TLS証明書 を用います。
SPFレコード
SPF は、そのドメインを名乗ってメールを送信してよいサーバーを指定するものです。
たとえば、次の設定です。
example.com. TXT "v=spf1 ip4:192.0.2.10 -all"意味は、「example.com をエンベロープFromとして使用してよいのは、192.0.2.10 の送信サーバーです」となります。
SPF が確認するのは、基本的に表示上の From: ではなく、SMTPの MAIL FROM、つまりエンベロープFromのドメインです。
MAIL FROM:<bounce@example.com>この場合、受信側は概ね次を確認します。
1. 送信元IPアドレスを確認
2. example.com のSPFレコードを確認
3. そのIPからの送信が許可されているか判定SPFは MAIL FROM と送信元IPアドレスを使って認証します。
DKIMレコード
DKIM は、送信メールに電子署名を付ける仕組みです。送信メールサーバーは秘密鍵を使って、次のようなヘッダーを追加します。
DKIM-Signature:
v=1;
d=example.com;
s=selector1;
...ここで、
d=example.com：署名したドメインs=selector1：公開鍵を探すためのセレクター
です。
DNSには公開鍵を登録します。
selector1._domainkey.example.com. TXT "v=DKIM1; p=公開鍵..."受信側は、
selector1._domainkey.example.comのDNSレコードから公開鍵を取得し、メールの署名を検証します。
DKIMによって確認できるのは、主に次の2点です。
example.comの秘密鍵を持つシステムが署名した- 署名対象部分が配送途中で改変されていない
DKIM の公開鍵は DNS から取得され、署名検証に使用されます。
DKIM は親ドメインで署名する構成もサブドメインごとに署名する構成もある
「DKIM は親ドメインに設定するのが普通」とは限りません。親ドメインで署名する構成も、サブドメインごとに署名する構成もあります。
そして重要なのは、親ドメインにDKIMレコードがあるから、サブドメインにも自動的に適用されるという仕組みではないことです。
DKIMはメールごとに d= を指定します。
例えば、表示Fromが次だとします。
From: newsletter@info.example.comこのメールを送信するとき、配信サーバーは DKIM 署名にどのドメインを使うかを決めます。
親ドメインで署名する場合
DKIM-Signature:
d=example.com;
s=selector1;受信側が確認するDNSレコードは、
selector1._domainkey.example.comになります。
この場合、表示Fromは info.example.com ですが、DKIM署名ドメインは親の example.com です。したがって、次のレコードは不要です。
selector1._domainkey.info.example.comこれは親ドメインのレコードがサブドメインに「継承」されたのではなく、xxx@info.example.com を表示Fromとしてメールを配信するメールサーバーがメール自体に d=example.com と明示して署名したからです。DKIMでは、メール内の d= と s= を組み合わせて公開鍵のDNS名を決めます。
サブドメインで署名する場合
xxx@info.example.com を表示Fromとしてメールを配信するメールサーバーが次のように DKIM署名することもできます。
DKIM-Signature:
d=info.example.com;
s=selector1;この場合は、受信側が確認するDNSレコードも変わります。
selector1._domainkey.info.example.comしたがって、info.example.com 用のDKIMレコードが必要です。
DKIM の秘密鍵はどこに保管されているか
DKIMの秘密鍵は、メールにDKIM署名を付ける送信システム側に保管されます。DNSに登録するのは公開鍵だけです。
基本構造
メール送信サーバー
├─ 秘密鍵：外部非公開
└─ メールにDKIM署名を付ける
DNS
└─ 公開鍵：受信側が参照できる例えば、送信メールには次のような署名が付与されます。
DKIM-Signature:
d=example.com;
s=selector1;
...受信メールサーバーは、d= と s= を使って次のDNS名を調べます。
selector1._domainkey.example.comそこに登録された公開鍵で署名を検証します。DKIM の仕様では、署名側が秘密鍵を使い、検証側が DNS から公開鍵を取得する構成です。
DMARC
DMARC は、受信者に見える From を基準にします。
From: newsletter@example.comそして、SPF または DKIM で認証されたドメインが、example.com と整合しているかを確認します。
_dmarc.example.com TXT "v=DMARC1; p=none"DMARC はメールサーバーを直接認証するというより、表示上の送信元ドメインが、SPF・DKIM の認証結果と矛盾していないかを確認する仕組みです。
