こちらからの3部作をまとめて、Qiitaで紹介します。
Qiita公式twitterにいいねされたから載せるわけではない(多分)
全体の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認証に失敗しているんじゃね?」という仮説が浮かび上がった。
次の章では、実際に送信したメールのヘッダーを詳細に解析し、メールが辿った経路と、なぜ認証が失敗したのか、その根本原因を深掘りする。「ヘッダー？マンドクセ...」と思った人もいるかもしれないが、大丈夫だ。自分もそうだ。老眼には細かい文字見るのが辛いんだよ。
第2部：【深掘り＆解決策検討編】Gmail経由送信の落とし穴と、DMARC突破のためのサービス比較
前の章では、fujiba.netからのメールがDMARCエラーで拒否される原因が、自分のドメインの認証設定（Mailgunの存在）と、普段の送信方法にある可能性が高いことを突き止めた。ここでは、実際に送ったメールの「ヘッダー」を解析して、認証失敗のメカニズムを明らかにする。そして、この問題を解決するためのサービス選定について述べる。
メールはどこを通ってきた？：ヘッダー解析
エラーの本当の原因を特定するため、メールがどのような経路を辿り、受信側でどのように認証されたのかを、送信したメールのヘッダー情報から確認した。テストとして、別の自分が持っているアドレス（dream.jpドメイン）宛てにfujiba.netからメールを送ってみた。このメールはエラーにならずに届いた。どうやら、そこのDMARCポリシーはあまり厳格ではないようだ。
そのメールのヘッダー情報を解析した結果が以下だ。（ヘッダー全文は長いので、抜粋して解説する）
Return-Path: <{hogehoge}@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Authentication-Results: cm2.dti.ne.jp; spf=pass smtp.mailfrom={hogehoge}@gmail.com; dmarc=fail header.from=fujiba.net
X-Proofpoint-Orig-Guid: Ce7Vxx1m1okuzXOXN6HRd-oOKv671wVj
X-Mailer: Apple Mail (2.3826.500.181.1.5)
<0B9E207C-20C9-4837-B89E-2894AF0A6BF6@fujiba.net>
X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746622596; x=1747227396; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=MT5xCPig+RNaxG/gstWGZb0KxfbrkEan080/UaHtCgU=; b=nvJ0AbeofmdDTvaWXTXXtzmEwKFABn3xNqoPR7S9CjoSWBjzQXquILBwUQud1terGq c0ULBmxPxvQ5arnNCXw00wTtF9a2iDnlG+4Q7nKQUB3IemV+Jz1QJ1gjJyJ6RGk2nfR0 YqBmYHpsJShIIKrKAO7SPrZbgvraVVPuRn+sQa6IilMY9TRBsbI+nJk6DiMvXrg+MZ6M phtWZoSp1zkct6wKnCfqunddeHFkc8DFQ/DzWwB1fGMTwzqBASuhRaUW3Yt0Kpkr6Fji zSLaDlVjX/CC57X0IfcoaRdCwb3S/eyDXM8tEHljc1iZSMAFzOxN58gNez5UB99/t7fI Bu3A==
Received: from mx03.cm2.dti.ne.jp (mx03-fbp.cm2.dti.ne.jp [10.32.72.10]) by store032-fbp.cm2.dti.ne.jp (3.10pn) with ESMTP id 547CucP5021745 for <{hogehoge}@dream.jp>; Wed, 7 May 2025 21:56:38 +0900 (JST)
Received: from imx22.cm2.dti.ne.jp ([10.236.197.1]) by mx03.cm2.dti.ne.jp (3.11g) with ESMTP id 547Cuc37021035 for <{hogehoge}@dream.jp>; Wed, 7 May 2025 21:56:38 +0900 (JST)
Received: from scpa216.cm2.dti.ne.jp (scpa216.cm2.dti.ne.jp [10.32.11.47]) by imx22.cm2.dti.ne.jp (3.11g) with ESMTP id 547CuchI001588 for <{hogehoge}@dream.jp>; Wed, 7 May 2025 21:56:38 +0900 (JST)
Received: from pps.filterd (scpa216.cm2.dti.ne.jp [127.0.0.1]) by scpa216.cm2.dti.ne.jp (8.18.1.2/8.18.1.2) with ESMTP id 5479Ui1s025955 for <{hogehoge}@dream.jp>; Wed, 7 May 2025 21:56:38 +0900
Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by scpa216.cm2.dti.ne.jp (PPS) with ESMTPS id 46d2m8ajcb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <{hogehoge}@dream.jp>; Wed, 07 May 2025 21:56:38 +0900
Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-30ac24ede15so459622a91.2 for <{hogehoge}@dream.jp>; Wed, 07 May 2025 05:56:38 -0700 (PDT)
Received: from smtpclient.apple ([****:**:****:*:****:****:****:****]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-30ad4f55825sm8529a91.31.2025.05.07.05.56.35 for <{hogehoge}@dream.jp> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 May 2025 05:56:36 -0700 (PDT)
ヘッダーの Received: フィールドを見ると、「smtpclient.apple ... by smtp.gmail.com ...」とあるのがわかる。 つまり、googleのMTAを使っているのがわかる。
そして、最も重要な認証結果を示す Authentication-Results: ヘッダーは以下の通りだった。
Authentication-Results: [受信サーバーのドメイン];
spf=pass smtp.mailfrom=[自分のGmailアドレス]@gmail.com;
dmarc=fail header.from=fujiba.net
この結果から、以下の事実が判明した。
- SPF認証自体は PASS している！ あれ？MailgunのSPF設定で弾かれてるんじゃ?という前回の仮説は、どうやら少し違ったようだ。
- しかし、SPFチェックの対象となったのは smtp.mailfrom （Return-PathやEnvelope Senderと呼ばれる、エラーメールの返送先アドレス）に記載されている情報であった。ここには、自分の @gmail.comアドレス が入っていたのだ。Googleのサーバーは@gmail.comからの送信を許可しているため、@gmail.comドメインに対するSPFチェックはパスするのは当然だ。
- 問題は DMARC だった。DMARCは FAIL している。DMARCは、メールの From: ヘッダーに記載されているドメイン（fujiba.net）と、SPFチェックが通ったドメイン（@gmail.com）またはDKIM署名のドメインが アライメント（一致または関連性があること） しているかを確認する。
このケースでは、From: ドメインはfujiba.netだが、SPFチェックが通った Return-Path ドメインは@gmail.comだ。これらは全く異なるドメインであるため、SPFアライメントは失敗 する。受信相手に見せる名前（fujiba.net）と、エラー時の返送先（@gmail.com）が違うから、「怪しいぞ」と判断されるわけだ。
DKIMについてもヘッダーを確認するとGoogleによって署名されているが、fujiba.netの鍵ではなくGoogle内部のドメインの鍵で署名されており、DKIMアライメントも同様に失敗 していた。
認証失敗のメカニズム：Gmail経由送信の落とし穴
以上の解析により、自分のメールが「なりすまし」と判断され、DMARCエラーとなった根本原因が明らかになった。それは、GmailのMTAを利用して、自身の独自ドメイン（fujiba.net）のアドレスを差出人（Fromヘッダー）としてメールを送信した場合、Return-Pathが自動的にそのGmailアカウントのアドレス（@gmail.com）に設定されてしまうというところだ。
From: ヘッダーは fujiba.net、しかし Return-Path は gmail.com。このドメインの不一致こそが、DMARCが求めるアライメントを満たせず、認証失敗を引き起こしていた元凶と考える。
そして、最初の記事でメールが拒否された相手（me.comなど）のメールサーバーは、DMARC認証がFailしたメールを厳格に拒否するポリシーを採用していたため、メールが受信者の元へ届く前に弾かれてしまった。テストで送信したdream.jp宛てにメールが届いたのは、そのサーバーのDMARCポリシーがFailしても拒否まではしない設定だったためと考えられる。
エラーを解決するために：DMARCアライメントを突破するためのサービス選定
問題点は明確になった。DMARC認証をPassさせ、送信したメールが拒否されることなく確実に相手へ届くようにするためには、Return-Path や DKIM署名のドメインを From: ヘッダーのドメイン（fujiba.net）と一致させられる方法でメールを送信する必要がある。
この問題を解決するための方法として、いくつかの選択肢が考えられる。
-
Google Workspaceで運用する: 独自ドメインでのメール運用に最適化されており、SPF/DKIM/DMARCの認証をGoogleが適切に管理するため、アライメントも問題なくPassする。最も確実な方法だ。
が、そこまではいらないというかGoogle税増えるのはやだ。 -
Mailgunを送信サービスとして利用する: 自分のドメインのDNS設定にも既に名前が見られるサービスだ。Mailgunでfujiba.netドメインを送信設定すれば、Mailgunが Return-Path や DKIM署名を適切に処理し、DMARCアライメントを確保できる。
が、なんか既存の設定と絡んでのトラップがあるっぽい。 -
Mailtrapや他のメール配信サービスを利用する: Mailgunと同様に、独自ドメインでの認証付き送信に特化したサービスだ。他にもSendGridやAmazon SESなどがある。
これが良さそう。
これらの選択肢を、自分の状況（月間送信量が約10通と非常に少ない、既存のGmailでの受信フローは維持したい）を踏まえて比較検討した。この比較検討はGemini Deep Researchを使って調査、比較させた。
その結果、自分の「月間送信量が少ない」「DMARC認証を確実にPassさせたい」「既存のGmail受信フローは維持したい」という要件に対し、Mailtrap または Postmark が最も適しているという結論に至った。これらのサービスは、少ない送信量でも利用できる無料枠があり、DMARCアライメントに必要な Return-Path や DKIMの設定を比較的容易に行える機能を提供している点が優れていた。
特にMailtrapは、無料枠の送信量が比較的多く（月1000通）、Return-Pathの自動設定機能により設定が容易である点が高く評価された。よし、サービスはMailtrapに決めた！
次の章では、この選ばれたMailtrapを使って、実際にfujiba.netドメインでDMARC認証を通せる送信環境を構築する具体的な設定手順について解説する。これが、今回の問題解決における実践的な道のりとなるのだが... 実は、ここからまたトラップにハマるorz
第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に設定する、という方法が最終的にうまくいった。
具体的な手順は以下の通りだ。
- macOSのメールアプリを開き、「設定」（または環境設定）から「アカウント」を開く。
- 「アカウント情報」タブの「メールアドレス」にて、自ドメイン（自分の場合はfujiba.net）のアドレスが選択できるように追加する。「メールアドレスを編集...」を押下しアドレスを追加する。
- 同じアカウント設定画面の「サーバー設定」タブを開く。
- 「送信用メールアカウント (SMTP)」の項目で、Mailtrapから取得したSMTP情報を基に設定を行う。 [画像9: macOSメール設定画面のサーバー設定、送信用メールアカウント] （ここで表示されているSMTPサーバーの選択肢を編集または新規追加し、Mailtrapの情報を設定した）
- 設定した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も雑な依頼をしても相当使えるという状況になったなと実感した。課金は必須やな。