独自ドメインからのメール送信でDMARCエラーに悩まされた話（3部作 その1）

全体のLT;DR（長い話いらん、って人のための超要約）

LT;DR: 自分が管理してる独自ドメイン(fujiba.net)から送るメールが、ある日突然、一部の宛先に届かなくなった。Googleからエラーメールが来て見てみたら、「DMARC policy」で拒否されたって書いてある。DMARC…ああ、なんかあったなあ。調べてみたら、原因は無料版GmailのSMTPサーバー経由で独自ドメインのアドレスから送ると、Return-PathとFromドメインが一致せずDMARCアライメントに失敗したということ。月に10通くらいしか送らないってことで、Geminiたんに無料枠でDMARC認証を通せるサービスを探してもらってMailtrapを選んだ。Mailtrapでドメイン認証（DNSにSPF/DKIMレコードを追加）やって、macOSのメールアプリの送信設定をMailtrapの情報に変更。これがまた難儀で、結局最後はほぼ自力で解決！おかげでDMARC認証をクリアした状態でメールを送れるようになった。ちなみに、Gmailアドレス(やプロバイダメール)からの送信はこの設定やとエラーになるので適宜手動で送信サーバを切り替えるか、Web版Gmail使うとかで対応してる。原因特定から解決まで、長い道のりだったけど、Geminiたんには初期段階から助けられっぱなしだった。トラップもあったけどw

第1部：【原因特定編】独自ドメインからのメールが突然DMARCエラーで届かなくなった。何が起きたのか？

自分は普段、所有する独自ドメイン「fujiba.net」のメールアドレスを使っている。受信は全部Gmailに転送してるから。送信は、使い慣れたmacOS/iOS標準のメールアプリで、差出人アドレスをfujiba.netにして送っていた。

この「いつもの」流れでやってたある日、突然変なことになった。特定の宛先(iCloudなど)のアドレスに送ったメールが、エラーになって戻ってくるようになったのだ。Googleから届いた配信エラーメール、いわゆるバウンスメールを確認した。

エラーメッセージの全文には色々な情報が入ってたが、特に目に飛び込んできたのがこの一文だ。

550 5.7.1 Your message was rejected due to fujiba.net's DMARC policy.

「fujiba.netのDMARC policyによって拒否されました」、だと？ DMARCポリシー？めんどくせぇ・・・できれば触れたくなかったorz

さて、このエラーメッセージが、今回の問題解決のスタート地点であり、最も重要な手がかりとなる。ここから、DMARCというめんどくさいくさい奴との戦いが始まった。

エラーの正体：DMARCとは何か。SPF・DKIM・アライメントの重要性

DMARC（Domain-based Message Authentication, Reporting & Conformance）とは、メールの送信元が本当にそのドメインから送られたものなのかを確認し、なりすましメールを見つけたり防いだりするための認証技術だ。インターネットでは、悪い奴らが勝手に他人のドメインを名乗って迷惑メールを送るのが後を絶たない。これに対抗するために、いくつかの技術が生まれた。

• SPF (Sender Policy Framework): 送信元ドメインの持ち主が、「うちのドメインのメールを送っていいのは、このサーバーのIPアドレスだけだよ」というリストをDNSに公開する。受信側はそのリストと、実際にメールを送ってきたサーバーのIPを照らし合わせてチェックする。例えるなら、「この店の正規の配達員はこの人です」と名簿を公開するようなものだ。
• DKIM (DomainKeys Identified Mail): 送信するメールに、改ざんされていないことを証明する電子署名を付ける。受信側はその署名が正しいかを検証することで、メールが途中でいじられていないか、送信元が本当に名乗っているドメインの持ち主から送られたものかを確認する。これは、「この手紙には、確かに本人のサインと封がしてあります」と確認するようなものだ。

そして DMARC は、このSPFとDKIMのチェック結果を見て、そのメールが認証に成功したか失敗したかを判断する。もし認証に失敗した場合に、受信側のメールサーバーがどう対応すべきか（受け取る、迷惑メールフォルダに入れる、問答無用で拒否するなど）を、ドメインの管理者がDNSにポリシーとして設定しておく仕組みなのだ。

今回受け取ったエラーメッセージ「rejected due to fujiba.net’s DMARC policy」は、つまり「送られてきたメールがfujiba.netドメインのDMARC設定で定められた認証チェックに引っかかったから、そのポリシーに従って受け取りを拒否しました」という意味だった。自分のfujiba.netからのメールが、受信側から見ると「なりすましの疑いがある」と判断されてしまったわけだ。

原因を探る：自分のドメインのDNS設定はどうなっているか

なぜ、自分のメールが「なりすまし」と疑われたのだろうか。原因は、fujiba.netドメインの認証設定、あるいは実際の送信方法にあるはずだ。まずは、自分のドメインのDNS設定を確認してみることにした。ドメインNamesDirectで取得後、紆余曲折を経て旧Google Domains、現在のSquarespaceで管理している。

Squarespaceの管理画面でDNS設定を開いた。

SPFレコード（タイプがTXTで、v=spf1 から始まるやつ）を確認すると、そこに「v=spf1 include:mailgun.org \~all」という設定があった。「Mailgun？なんやっけ？」と、ここで最初の疑問符が頭に浮かんだ。見覚えのない名前だ。

MXレコード（メールの受信サーバーを指定する設定）も同様に確認したところ、こちらもMailgun(mxa.mailgun.org, mxb.mailgun.org)を指していた。

これらの設定から、少なくともfujiba.netドメイン宛てのメールは、Mailgunというサービスを経由するようになっていることが分かった。そして、SPFレコードは「fujiba.netからのメールはMailgunから送信されるのが正当だ」と主張していることになる。

なぜMailgunが設定されているのか、最初は全く記憶になかったが、過去にGoogle Domainsでメール転送設定を行った際、Googleがその裏側でMailgunのような第三者サービスを利用していたらしいという情報を見つけた。おそらく、この設定が原因であると至った。

しかし、自分は普段、Mailgunのサービス画面からメールを直接送っているわけではない。使っているのはmacOSの標準メールアプリからgoogle or DTIのMTAを介して送信している。そして、エラーメールはGoogle (googlemail.com) から送られてきた。

この時点で、「あれ？自分のメールは、Mailgun以外から送信されており、その経由したサーバーがfujiba.netのSPF設定（Mailgunが正当だと主張してる設定）で許可されていないため、SPF認証に失敗しているんじゃね?」という仮説が浮かび上がった。

次回の記事では、実際に送信したメールのヘッダーを詳細に解析し、メールが辿った経路と、なぜ認証が失敗したのか、その根本原因を深掘りする。「ヘッダー？マンドクセ…」と思った人もいるかもしれないが、大丈夫だ。自分もそうだ。老眼には細かい文字見るのが辛いんだよ。