お世話になっております。未経験出身エンジニア、勤務歴がちょうど4.5年経過したosです。
今回は「まさかこんなに苦労するとは…」と感じた作業について、独り言を記載させていただきます。
（あとは忘れたくないので備忘録も兼ねています）
タイトルの通り、自社ドメインにサブドメインを作成し、それを用いて毎日メールを自動配信する機能を実装しました。
経緯としては、案件でメール配信サービスを作成することになり、その動作確認に自社のサブドメインを使うことになった、というものです。
今回はちょっとコアな内容なので、わからない人に向けて「ドメインとは！」という基礎知識から簡単に記載いたします。
また、記事がなかなかのボリュームになってしまったので、以下に目次も記載しました。
・ ドメイン？サブドメイン？
・ DNSについて（Aレコード、MXレコード）
・ メール送信者なりすまし対策のために必要な対応について（SPF・DKIM・DMARC）
・ いざ実装へ
・ 苦労した点、まとめ
・ 最後に
ドメイン？サブドメイン？
ドメインとは！
このブログ記事のURLに含まれている「softem.com」がドメインに当たります。
ドメインとは、一言でまとめると「インターネット上の”住所”」です。
本来、インターネット上の通信ではIPアドレスが使われています。
極端な話、もしドメインがこの世に無ければ、弊社のこのブログ記事を見るのにも数字の羅列をブラウザに直接打ち込む必要があります。
※しかも実際は、数字の羅列の直接入力だけではうまく表示できないことがほとんどです。
サブドメインとは！
先に紹介した「ドメイン」から派生した、名前の通りサブのドメインです。
「[sub].softem.com」が「softem.com」のサブドメインです。
このとき、「softem.com」を「親ドメイン」と呼びます。親ドメインが会社のビルなら、サブドメインはビルの中の部屋や部署というイメージです。
今回は、この「[sub].softem.com」を用いて配信メールを送信しました。
DNSについて（Aレコード、MXレコード）
さて、それでは本題です。
このドメインを使ってメールを送受信するためには「DNS」という仕組みを活用する必要があります。
DNSとは、ざっくり言うとインターネットの「電話帳」です。
「softem.com」という名前を、コンピューターが理解できる数字の住所（IPアドレス）に変換してくれたり、
「このドメイン宛てのメールはどこに届ければよいか」といった情報を調べたりできる仕組みです。
弊社のメールアドレスにも「softem.com」は使用されています。
じゃあちょっとここで「え？ブラウザでもsoftem.comなのに、メールでもsoftem.comってなんで使えるの？」
と疑問に感じた勘のいい方に向けて補足説明も行います。
実は、同じドメインでも、Webサイトにアクセスするときとメールを届けるときでは、DNSから取得する情報が異なります。
Webサイトでは接続先のIPアドレスを、メールでは宛先のメールサーバーを調べる必要があるからです。
そこで登場するのが「Aレコード」と「MXレコード」です。
Aレコード
ドメイン名とIPv4アドレスを紐づけるための情報です。
例えば「softem.com にアクセスするなら、このIPアドレスを参照してね」という情報を登録しておくイメージです。
MXレコード
そのドメイン宛てのメールを、どのメールサーバーに届ければよいかを示す情報です。
例えば「○○@softem.com 宛てのメールは、このメールサーバーに届けてね」という情報を登録しておくイメージです。
なお、MXレコードにはIPアドレスではなく、メールサーバーの名前と優先度が登録されています。実際にメールを届ける際は、そのサーバー名からIPアドレスを調べます。
それでは、この2種類のレコードが実際にどのように使われているのか、それぞれの流れを見てみましょう。
ブラウザで「softem.com」を入力した場合の流れ
① ブラウザが「”softem.com”って入力された！こやつは何者？」とキャッシュDNSサーバー（住所を調べてくれる案内係）に質問。
② キャッシュDNSサーバーが、必要に応じて softem.com の原本を持っている別のDNSサーバーに聞きに行き、「この情報ですよー」とAレコードに記されたIPアドレスを返却。
③ ブラウザがその情報を基にアクセスすることで画面にWebサイトが表示されます。
「○○@softem.com」宛てにメールを送った場合の流れ
メールも、同じDNSという電話帳を使っています。ただし、見ている欄が違います。
① 送信側のメールサーバーが「”softem.com”宛てのメールを預かった！送り先ポストはどこ？」とキャッシュDNSサーバーに質問。
② キャッシュDNSサーバーが、必要に応じて softem.com の原本を持っている別のDNSサーバーに聞きに行き、「送り先はここやで」とMXレコードに記されたメールサーバー情報を返却。
③ 送信側のメールサーバーがその情報を基にメールを届けることで、相手の受信箱にメールが届きます。
※ブラウザの場合は端末（PCやスマホ）がDNSに質問していましたが、メールの場合はあなたの端末ではなく「メールを預かった送信側のメールサーバー」が質問します。
要約すると、ブラウザでアクセスする際はAレコードから、メールを送信する際はMXレコードから情報を得ていると認識してください。
ブラウザは「Aレコードを教えて」、メールサーバーは「MXレコードを教えて」と、それぞれ必要な欄を指定して質問しているので、
一つのドメインでサイトの表示もメールの受け取りもできるわけなんですね。
また、サブドメインを作成した場合、サブドメイン側に親ドメインとは別のAレコード・MXレコードを設定することも可能です。
メール送信者なりすまし対策のために必要な対応について（SPF・DKIM・DMARC）
メールサービスにおいては、なりすまし対策として代表的な仕組みが3種類あります。
専門用語のまま書きますが、それぞれ「SPF・DKIM・DMARC」です。
SPF
SPFは、「softem.com のメールを送っていいのは、このサーバーです」という名簿を、DNSのTXTレコードに登録しておく仕組みです。
DKIM
DKIMは、送信するメールに電子署名を付ける仕組みです。
送信側は「封をする鍵」をこっそり保管しておき、メールを送るたびにその鍵で封をします。一方、DNSには「封を開ける鍵」を用意しておきます。
メールを受け取った側は、DNSの「封を開ける鍵」で封を開けてみて、ちゃんと開けば「本当に softem.com が送ったメール」、
開かなければ「偽物か、途中で書き換えられたメール」と判断します。
DMARC
DMARCは、SPFやDKIMのチェック結果をもとに、差出人のなりすましを判断する仕組みです。
SPFやDKIMは「封筒に書かれた差出人が事前に聞いている本人であるか」は確認できますが、受け取った人が実際に目にする「差出人欄の名前」と一致しているかまでは確認しません。
例えるなら、窓口で「佐藤です」と名乗った人が、免許証を出してきた状況を想像してください。
免許証は本物。でもよく見ると名前が「田中」と書かれているとします。
SPFやDKIMは「免許証が本物か」を確認するだけなので、この二つだけだとこの免許証は本物なのでOK！と扱われてしまいます。
そこでDMARCが、「免許証の名前と、差出人欄の名前がちゃんと一致しているか」を確認するというイメージです。
いざ実装へ
さて、長らくお待たせいたしました。
メール配信システムを実装するためだけに、ここまでの準備と知識が必要です。
では、いよいよ配信機能の実装を！
…の前にまたまた事前準備です。
今回、自動配信にはAmazonが提供しているAWSのサービス「Amazon SES」と「Route 53」を利用しました。
…まーた新たな専門横文字が出てきましたね。
ですが、Amazon SES の説明は簡単です。
SESの正式名称はわかりやすく「Simple Email Service」です。
本当に文字通り、Amazonが提供してくれている、メールを送信するためのシンプルなサービスです。
続けてRoute 53 についてです。
こちらも、Amazonが提供しているサービスの一つで、主にDNSに関するサービスです。
つまり、これまで散々登場してきた「インターネットの電話帳」を、AWS上で管理できるサービスだと思ってください。
実際にこれらを使ってメールを配信するためには、以下の準備が必要でした。
① Route 53 でサブドメイン専用の電話帳（ホストゾーン）を作成。
すると「このサブドメインのことはRoute 53に聞いてね」という意味合いを持つ、委任用の「NSレコード」というものが発行されます。
② 発行されたNSレコードを、親ドメインのDNSに追加。親ドメインの設定とは別に、サブドメイン用のレコードとして追加します。
これにより、サブドメインの管理がRoute 53に委任され、SPFなどの設定をRoute 53側で行えるようになります。
※この作業を省略した場合は、親ドメインのDNSですべて設定する必要がありました。
③ Amazon SESにサブドメインを登録し、発行されたDKIM用のレコードや、SPF・DMARCのレコードを①で作成したRoute 53に設定。
④ 設定と検証が完了したSESを使って、メールを自動配信するシステムを作成。
です。
正直、この中では④のシステム実装が一番楽でした(笑)
苦労した点、まとめ
今回の作業では、プログラムの実装が一番楽に感じられたので、
プログラミングという行為自体にはだいぶ慣れてきたのかなと嬉しい気持ちになりました。
ですが、初めての分野だったうえ、DNSやAWSのややこしい設定にも振り回され、
総合的に見ると言葉に表せないめちゃくちゃな気持ちになりました(笑)
正直、今回対応した内容については、理解にかなり時間を要しました。
特に、「SPF・DKIM・DMARC」について学習することに一番苦労しました。
具体的には、以下のような疑問が頭の中をぐるぐると巡っていました。
「SPFのチェックって、送信側・受信側・DNSのどこでやってるの？」
「DKIMの封を開けているのは、結局どのサーバー？」
「DNSサーバーって送信側？受信側サーバーを指しているの？」
といった内容です。
DNSについて調べた際、「DNSは仕組み」であることを知ったが故に、この仕組みを実行しているのが
「送信側」、もしくは「受信側」のメールサーバーだと思い込んでしまったわけですね。
また、「サーバー=1台の機械」という認識を無意識に持っていたので、これも混乱の原因になりました。
上記の3つの疑問の答えとしては、以下の通りになります。
SPFとDKIMのチェックはどこで？
どちらも「受信側」のメールサーバーです。
ついでにいうと、DMARCのチェックも受信側で行っています。
DNSサーバーは送信側？受信側？
こちらは実は、「どちらでもない」というのが答えになります。
正確には、送信側・受信側のメールサーバーとは、役割が異なるということです。
「サーバー＝サービスを提供する”役割”」と考えると、メール送受信プロセスにおいて登場人物は、
1. メール送信サーバー
2. メール受信サーバー
3. DNSサーバー（DNSサービス提供の役割）
以上の３名だったというわけです。
そして、「サーバー=1台の機械」という認識が足を引っ張ったのがここに繋がります。
このDNSサーバーが「実際にどこにあるか」は一概には言えません。
今回の場合、Route 53 がサブドメインのDNS情報を管理・提供する役割を担っています。
企業によっては自社でDNSサーバーを管理していることもあるので、
場合によっては送信処理を行っているハードが、そのままDNSの役割を担っていることもあります。
要するに、「3者は役割としては別物」程度の認識で良かったというわけです。
最後に
はい、というわけでここまで初めてのメール配信サービス実装で経験したことや、
苦労したこと等を一通り記載してみました。
この記事がメール自動配信システムを作る方のお役に立てれば幸いです。
（かなり限られていると思いますが…）
今回はClaude AI に頼りっきりの対応だったのですが、それでもかなり混乱しました。
メールというサービスは日常に広く普及していますが、こうした実装背景を知ると、メールを普及させた方々のすごさを改めて感じますね。
私のように混乱しまくってドツボにはまる方が量産されないことを願います。
ここまでご覧いただき誠にありがとうございました。