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

第3部：【実践＆設定編】DMARCエラーよ、さらば！選ばれたMailtrapで認証を通して送信する設定

これまでの記事で、fujiba.netからのメールがDMARCエラーで拒否される原因を特定し、その解決策としてMailtrapのような認証付きメール送信サービスが有効であることを確認した。「これで解決や！」とホッと一息… つくかと思いきや、実はここからがもう一段階の戦いだった。今回は、Mailtrapを選び、実際にメールを送信するための設定手順と、最終的な稼働状態について述べるのだが… ここが今回の最大の難所、そしてGeminiとのちょっと切ない（？）やり取りがあった場所だ。

Mailtrapでの初期設定とドメイン認証

まず、Mailtrapの公式サイトでサインアップした。第2部で調べた通り、無料枠があるのが、送信量の少ない自分にとっては大きな利点だ。サインアップ時にはいくつか質問が出たが、利用用途は「Personal project」、機能はSMTPを利用するので「Transactional Stream」を選んだ。

アカウント作成後、Mailtrapの管理画面で自身のドメイン「fujiba.net」を「Sending Domains」に追加する手続きを行った。ドメインが本当に自分のものか確認するため、Mailtrapから指示されるDNSレコード（TXTレコードなど）を、ドメインを管理しているSquarespaceのDNS設定に追加する必要がある。

SquarespaceのDNS設定画面を開き、Mailtrapの指示に従ってレコードを追加した。今回は比較的スムーズに進んだ。特に、SquarespaceにはSPFレコードを自動的に統合する機能があったため、MailgunのSPFレコードを削除することなく、Mailtrapが指示するSPF情報（v=spf1 include:mailtrap.io ~all のような文字列）を 新しいTXTレコードとして追加 するだけで対応できたのは助かった。DKIM用のCNAMEレコードなども同様に追加した。

DNSの変更がインターネットに反映されるのを待ち、「Verified」（認証済み）と表示されれば、Mailtrapからfujiba.netドメインでメールを送信する準備は Mailtrap側では 完了だ。Mailtrapの管理画面で、送信に使うSMTP連携情報（ホスト名、ポート、ユーザー名、パスワード/APIトークン）を控えておく。

つづけて、Gmail側で「別のアドレスやエイリアスからメールを送信する」機能を設定し、Web版のGmailクライアントからfujiba.netドメインアドレスで送信テストする。 いきなりiCloudとかに投げるのもアレなので、DMARCの確認ができるサイトhttps://www.dmarctester.com/を利用した。結果は、PASSした。一山超えたわけだ。

いよいよメールクライアント設定！…のはずがGeminiたんトンチンカン

Mailtrapでのドメイン認証、Gmail Webアプリでの検証も終わり、さあ、いよいよ普段使いのmacOS標準メールアプリにMailtrapの設定を反映させるぞ！と意気込んだのだが… ここが、今回のDMARCエラー解決の過程で、技術的な問題の解決とはまた別の意味で最も「ハマった」ポイントだった。

「さて、MailtrapのMTAをどう反映させるか」と考えるも、Geminiたんは「GmailからmacOSのメールアプリの送信者一覧に引っ張ってくるから問題ないやで」と言うのでそれを信じてdmarctester.comへメールを送るもうまく行かない。騙されたorz

それでも懲りずに、前半戦では優秀だったGeminiたんに助けを求めようとした。エラーメッセージが出るたびにGeminiたんに「これ、どういう意味？」「どう設定したらいい？」と質問してみたのだが… なぜかこのmacOSメール設定に関しては、Geminiの返答がどうもトンチンカンなのだ。 こちらの状況に合わない、試しても解決しないアドバイスばかり。「Geminiたんどないしたん」「なんでや！」と、半ば諦めた。

正直、何度か心が折れそうになり「もう、このままGmail経由で送るのは諦めて、Webアプリだけで送受信しようか…」なんて弱気な考えも頭をよぎった。Geminiも頼りにならないなら、もう無理かもしれない、とすら思った。

まあ、ハナから全てをGeminiたんに頼りっきりなのも癪なので、手当たり次第に設定を試していき、ついに突破口が見えた。地道な（テキトーな）試行錯誤の結果、ついに正しい設定方法にたどり着いたのだ！認証エラーを解消し、無事に送信が成功した、その苦労の結晶である設定方法がこちらだ。

自分の環境の場合、macOSメールアプリには既にGoogleアカウントが設定されており、fujiba.netのメールはそのアカウントに転送されて受信している。この既存のGoogleアカウント設定内に、fujiba.netのアドレスを「追加のメールアドレス」として紐付けた上で、そのGoogleアカウントの送信用メールアカウント（SMTPサーバー）をMailtrapに設定する、という方法が最終的にうまくいった。

具体的な手順は以下の通りだ。

1. macOSのメールアプリを開き、「設定」（または環境設定）から「アカウント」を開く。
2. 「アカウント情報」タブの「メールアドレス」にて、自ドメイン（自分の場合はfujiba.net）のアドレスが選択できるように追加する。「メールアドレスを編集…」を押下しアドレスを追加する。

   

3. 同じアカウント設定画面の「サーバー設定」タブを開く。
4. 「送信用メールアカウント (SMTP)」の項目で、Mailtrapから取得したSMTP情報を基に設定を行う。 [画像9: macOSメール設定画面のサーバー設定、送信用メールアカウント] （ここで表示されているSMTPサーバーの選択肢を編集または新規追加し、Mailtrapの情報を設定した）
   

   

5. 設定したMailtrapのSMTPサーバーの詳細画面で、ホスト名、ポート、認証方法（「パスワード」を選択）、そして特に重要な認証情報（ユーザー名/APIトークン、パスワード/トークン）を正確に入力する。ここで入力するユーザー名とパスワードは、Mailtrapの管理画面で確認したSMTP接続情報だ。 これが間違っていると、いつまで経っても送れないぞ！

   

この設定を完了すると、この既存アカウント（プロバイダやGmail）から送信される全てのメール（差出人が既存アドレスの場合も、fujiba.netアドレスの場合も）が、設定したMailtrapのSMTPサーバーを経由して送信されようとする。

これが本設定のポイントであり、同時に他のメールアドレスからの送信における少しの制約 となる。差出人を元のアドレスにして送信しようとすると、Mailtrapは自身のドメイン（fujiba.net）以外のドメインからの送信を許可しないため、認証エラーとなり送信が拒否される。従って、既存アカウントの中でも最も送信頻度の少ないものを選ぶことをお勧めする。

しかし、差出人を自ドメイン（fujiba.net）アドレスにして送信する場合は、Mailtrapは正規の送信として受け付け、DMARC認証もPassした状態で受信者へメールを配送してくれる。これにより、fujiba.netからのメールがDMARCで拒否される問題は、ついに解決されたのだ！

なお、Mailtrapちゃん、Subjectが空で送った時もエラーにしてMAILER DAEMONさん送りになるらしい。

まとめ：DMARC問題解決の達成、そして（時にはトンチンカンだった？）Geminiとの道のり

長かった…！原因不明のエラーに始まり、DMARCを理解し、DNS設定と格闘し、最適なサービスを選び、そして最後のメールクライアント設定という最大の山場を、Geminiの助けも借りつつ（最後の設定はほぼ自力で！）乗り越えて、ついに fujiba.net ドメインから、DMARC認証を通過した信頼できる状態でメールを送信できるようになった！ これは、自分にとって大きな成果であると同時に、メールの世界の奥深さと難しさを痛感した経験だった。

最終的に、メインで使用するfujiba.netアドレスからの送信はMailtrap経由で行い、犠牲に？なった既存アカウントそのものから送るときは、Webアプリから送るか送信エラー時にサーバーを切り替えて送信する運用となった。

この問題解決の道のり、全体を通して見ると、やはりGeminiの存在は大きかった。最初の原因特定や、複雑なメールの仕組み、ヘッダーを読み解いてもらったり、自身の状況に合致するサービスを比較検討するまでは、間違いなくGeminiが強力な相棒となった。まあ、最後の最後のmacOSメール設定でトンチンカンなことを言うあたりは「りんごのことなんかしらんがな」と言うことにしておく。

いやー、マジで、全体を通してGeminiがいなかったら、原因特定すらできずに途方に暮れてたと思う。最後の設定は自力だったが、そこにたどり着くまでの道筋を作ってくれたGeminiには、課金してよかったと思ってる。そして、今回の経験を通して、メール認証の仕組みや設定の重要性がチョットダケわかった。

この長く、時には（Geminiとのやり取りで）予想外の展開もあった解決の記録が、もし同じように独自ドメインからのメール送信でDMARCエラーに悩んでいる方がいれば、その方の問題解決の糸口となれば幸いだ。

最後に(おまけ)

さて、この3部作、一連のトラシューから解決までGeminiとやり取りしたスレッドで、まとめとしてこの3部作のブログ記事を提案してもらった (最初は構成案出してきたけど、結局中身まで書いてもらったw)
比較的まともに解決へ導いた1部、2部は概ね提案してもらった通りの内容で若干の修正で公開。3部はトンチンカンな名残で大幅修正が必要だった。

トラシューでの利用シーンとしては、以下は特に便利に感じた。

• ログの解析 老眼で目grepの効きも悪くなっている自分にとってはめちゃ強力、多分老眼でなくても読むのだるい奴なので助かる。
• RFCやらプロトコルの理解・解釈 自力で調べてたらいつ終わるかわからんが、割と一貫して助けてくれる
• 回避策の比較検討にDeep Research 自分でググって調べるよりはるかに早くまとめてくれるの助かる

ここ最近で生成AIも雑な依頼をしても相当使えるという状況になったなと実感した。課金は必須やな。