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

第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📅message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject📅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