以下の内容はhttps://tech.spacely.co.jp/entry/2026/03/26/173216より取得しました。

自社メールがOutlookに届かない — SPF/DKIM/DMARC起因のメール不達問題を解決した話

はじめに

こんにちは、株式会社Spacelyでバックエンドエンジニアをしているtoshichanappです。普段はRailsアプリケーションの運用・保守を担当しています。

近年、メール認証の要件は急速に厳格化しています。

「SPF / DKIM / DMARCはちゃんと設定してある」——そう思っていませんか？

こうした流れの中で、弊社ではメール不達のトラブルが発生しました。

8年間サービスを運用してきて、Google Workspaceのカスタムドメイン DKIM が未設定のままだったことに気づいたのです。Google Workspaceはカスタムドメインの DKIM を設定しない場合、gappssmtp.com 配下のドメインで DKIM 署名を付けるため、DKIM 自体は pass します。しかし From ドメインと一致せず、DMARC としては fail している状態でした。長年、Gmail が受信側として寛容だったおかげで問題が表面化しなかっただけだったのです。

具体的には、「Outlook宛のメールが届かない」「迷惑メールフォルダに入ってしまう」という報告を受けました。調べてみると、Gmail宛は問題なく届いているのにOutlook（Microsoft 365）宛だけ問題が起きている。迷惑メールフォルダに振り分けられるだけでなく、Exchange Online Protection（EOP）によってブロックされ、受信箱にも迷惑メールフォルダにも届かないケースもありました。

本記事では、原因の調査から解決までのプロセスを体験談として共有します。

前提知識：SPF / DKIM / DMARC

まず、今回の調査で重要になるメール認証の3つの仕組みを簡単に紹介します。

SPF（Sender Policy Framework）

送信元IPの正当性をDNSで宣言・検証する仕組みです。「このドメインからメールを送っていいサーバはこれ」をDNSのTXTレコードで宣言し、受信側がそれを検証します。

DKIM（DomainKeys Identified Mail）

送信時にメールに電子署名を付与し、受信側で改ざんを検知する仕組みです。

DMARC（Domain-based Message Authentication, Reporting and Conformance）

SPF / DKIMで認証されたドメインがFromドメインと一致するか（alignment）を確認し、失敗時のポリシー（none / quarantine / reject）を宣言する仕組みです。

重要なポイントとして、SPF / DKIMがpassでも、Fromドメインとのalignmentが不一致だとDMARCはfailになります。

調査プロセス

ステップ1：差分に着目する

最初に注目したのは「Gmail宛は届くのにOutlook宛だけ届かない」という差分でした。

同じメールで受信先によって結果が異なるということは、アプリケーションのバグや単純な文面の問題ではなさそうです。受信側（メール事業者）の評価ロジックの違いを疑いました。

ステップ2：Outlookのメールヘッダを確認する

Outlook / Exchange Onlineはメールヘッダに詳細な判定結果を出力します。確認した主なヘッダは以下の通りです。

Received-SPF: PermError (invalid SPF mechanism)
X-MS-Exchange-Organization-SCL: 5
X-Microsoft-Antispam: BCL:7;

ここから以下のことがわかりました。

  • SPFがPermError：SPFレコードの処理中にエラーが発生している。DNS/SPF構造に問題がある可能性が高い
  • SCL 5：迷惑メールの疑いありと判定されうるスコア（Exchange Onlineのデフォルトでは SCL >= 6 で迷惑メールフォルダ行き）
  • BCL 7：バルクメール受信者からの苦情率に基づく指標で、高い値は迷惑メール判定されやすいことを示す

ただし、SCL/BCLなどのスコアは値がわかるだけで、なぜそのスコアになったかの理由はヘッダからはわかりません。ここからさらに深掘りが必要でした。

ステップ3：dmarcianで可視化する

SPF / DKIM / DMARCをまとめて確認できるツールとして dmarcian を利用しました。SPFレコードの確認など一部機能は無料で利用できます。

dmarcianで判明したことは以下の通りです。

SPFの問題：

  • SPFのincludeが多段構造になっていた
  • DNS lookup回数が10回を超過していた（SPFの仕様上限は10回）
  • 一部includeでtimeoutが発生していた

DKIMの問題（送信元ごとの切り分け）：

  • Webアプリケーション経由：DKIMは問題なし
  • Google Workspace経由：カスタムドメインでのDKIM署名が未設定
  • Salesforce経由：DKIM用のCNAMEレコードが未設定

結論：

  • SPF → lookup回数の超過によりPermError
  • DKIM → Google Workspace / Salesforce経由でfail
  • その結果としてDMARC failが発生（DMARCポリシーは p=quarantine だったため、受信側にはDMARC failしたメールを迷惑メールとして扱うよう指示している状態でした）

対応内容

調査結果を踏まえ、以下の対応を実施しました。

1. 再発防止：DNS/メール設定のTerraform管理を導入

まず再発防止策として、メール関連のDNS設定をコードで管理できるようにしました。 これまでDNS設定はコンソールから手動で変更していたため、「いつ誰が何を変えたか」が追えない状態でした。Terraform管理に移行したことで、PRベースでのレビュー・変更履歴の管理が可能になっています。

2. メールドメイン設計の見直し

不要・未使用のSPF includeを削除し、SPFのDNS lookup回数を10回以下に削減しました。 サービスの成長に伴いSaaS連携が増え、いつの間にかincludeが膨らんでいた状態でした。

3. DKIM設定の追加

  • Google Workspace：管理コンソールでDKIMを有効化
  • Salesforce：DKIM用CNAMEレコードを追加

結果

対応後、以下の改善を確認できました。

  • SPF / DKIM / DMARCがすべてpassするようになった
  • DMARCレポートでエラー率が大幅に低下
  • Outlook宛メールが正常に受信されるようになった

残った課題

インフラ対応後もSCL（スパム信頼度レベル）は高いままでした。認証はpassしているためコンテンツ起因と判断し、ビジネスサイドにメール文面の改修を依頼しました。

メール到達率の改善は、認証設定だけで完結するものではなく、コンテンツやレピュテーションも含めた総合的な取り組みが必要だと実感しました。

教訓

Gmailで届く ＝ 安全ではない

今回のケースでは、Gmail → Gmailという同一プラットフォーム内の通信だったため、認証の不備が見逃されていた可能性があります。同じメールサービス内では寛容に扱われる問題も、異なるメールサービス宛では厳格に判定されます。Gmailで問題なく届いているからといって、メール認証設定が正しいとは限りません。

メール不達は「設定の有無」ではなく「設計」の問題

SPF / DKIM / DMARCは「設定してあるかどうか」だけでなく、includeの構造やDNS lookup回数、送信経路ごとの署名設定など、設計としての整合性が求められます。

メールは放置すると静かに壊れるインフラ

サービスの成長に伴いSaaS連携が増えるとSPFのincludeが膨らみ、いつの間にかlookup回数の上限を超えることがあります。定期的な監視と棚卸しが重要です。

認証だけでなくレピュテーションも意識する

SPF / DKIM / DMARCがpassしていても、送信ドメイン/IPアドレスのレピュテーション（評判）が低いと迷惑メール判定されます。バウンス率（不達率）が高いとレピュテーションに悪影響を与えるため、宛先リストの定期的なクリーニングも必要です。

おわりに

SPF / DKIM / DMARCは「設定したつもり」になりがちです。冒頭で書いた通り、私たちも8年間気づかなかった設定漏れがありました。

この機会に、一度自社と異なるメールサービス宛にメールを送ってヘッダを確認してみてください。同じメールサービス内（Gmail → Gmailなど）では見逃される問題が、異なるサービスのヘッダには正直に記録されています。

参考資料

Spacely では、Rails / Sidekiq を中心としたバックエンド開発、Terraform によるインフラ管理に取り組んでいます。 今回の記事のような、インフラやメール基盤の課題を一つずつ改善していく仕事に興味がある方と、一緒により良いプロダクトを作っていけたら嬉しいです。

採用ページ



以上の内容はhttps://tech.spacely.co.jp/entry/2026/03/26/173216より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14