Defaults.Exposed › 修正 › Guides

DKIM は合格するが DMARC が失敗する：gappssmtp.com / onmicrosoft.com デフォルト署名の落とし穴（2026）

公開日 2026-07-08

データは 2026-06-29 時点 · メソドロジー v7。 261 百万採点済みドメインを対象とした集計センサスデータ。採点方法を参照。

メールはプロバイダーのデフォルト署名で DKIM に合格する — d= が gappssmtp.com（Google Workspace）または onmicrosoft.com（Microsoft 365）で終わる — しかしそのドメインは From ドメインと一致しないため、DMARC はアライメントされた合格を得られない。カスタムドメイン署名を有効にして修正する。Defaults.Exposed の採点済み 261,086,232 ドメインのセンサスによると、Google のメールサーバーを認可する 12,145,313 ドメインのうち、DMARC を適用しているのはわずか 18.5% だ。

修正はメール認証の中でも最もクリーンな部類だ：カスタムドメイン DKIM 署名をオンにする。Google Workspace では管理コンソールの「メールの認証」画面で — キーを生成し、TXT レコードを1件公開し、オンにする。Microsoft 365 では Defender ポータルの DKIM ページで — セレクター CNAME を2件公開し、有効にする。20分の作業で、DMARC がずっと待っていたアライメントされた合格がようやく得られる。

なぜ DKIM は合格するのに DMARC が失敗するのか？

DMARC は「有効な DKIM 署名があるか？」を問わないからだ — 「From ヘッダーのドメインに対して有効な DKIM 署名があるか？」を問う。この第2の条件をアライメントと呼び、これが DMARC の全体的な目的だ：受信者が見るドメインが署名したドメインであることを証明する。

デフォルトでは、Google Workspace はメールを yourdomain-com.20230601.gappssmtp.com のようなドメインで署名し（日付スタンプはドメインによって異なる）、Microsoft 365 は yourtenant.onmicrosoft.com で署名する。両方の署名は暗号的に有効だ — DKIM チェッカーは合格と言う — しかし d= ドメインは Google か Microsoft のものであり、あなたのものではない。DMARC のリラックスアライメント（組織ドメインが一致するだけでよい）でさえ、gappssmtp.com は yourdomain.com ではない。一致なし、アライメントされた合格なし、そして SPF もアライメントしない場合（よくある — 受信側は SPF を From ヘッダーではなく Return-Path ドメインに対して評価し、転送はそれを完全に壊す）、DMARC は失敗する。

これがプロバイダーデフォルトの典型的な落とし穴だ：デフォルトは到達率を与えるが、保護は与えない — アライメントが欠けているキーの一回転だ。 センサスが示す通り、どれだけ多くの送信者がデフォルトで止まっているか：_spf.google.com を通じて Google のメールサーバーを認可する 12,145,313 ドメイン（全 SPF 公開者 138,927,207 のうち）のうち、DMARC を適用しているのはわずか 18.5%。Microsoft の状況も同様だ：10,205,070 ドメインが spf.protection.outlook.com を認可し、85.0% が M365 セットアップが手渡す strict SPF レコードを持つ — しかし DMARC を適用しているのはわずか 21.7%。完全な比較はメールプロバイダー SPF ランキングにある。

この落とし穴は日常使用では見えない：メールは配信され、受信ボックステストは問題なく見え、エラーは何もない — DMARC ポリシーを公開して自分のメールがそれに失敗し始めるまでは。無料スキャンがまさにこのギャップを表面化させる。

Authentication-Results でデフォルト署名の落とし穴を発見するには？

送信したメッセージを開き（Gmail または Outlook のメールボックスへ）、オリジナル/生ソースを表示し、Authentication-Results ヘッダーを見つける。見分け方は DKIM の合格に誤った d= がある — Gmail で受信した例はこう見える：

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=yourdomain.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

3つの質問で読む：

Microsoft が受信したメールでは、同じ状況が dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com と compauth=fail として表示される — Outlook 拒否ガイドでカバーしているパターンだ。

ヘッダーが代わりに dkim=pass と spf=pass の両方を DMARC 失敗と共に示している場合、より広いアライメントのケースに該当する — DMARC が失敗するが SPF と DKIM は合格するガイドがリラックスと strict のアライメントを詳しく説明している。

カスタムドメイン DKIM 署名を有効にするには？

1. 何かを変更する前に defaults.exposed で無料スキャンを実行する。 ドメインがアライメントされた DKIM を持っているか、DMARC ポリシーが実際に何か、この修正後も何か（SPF、DMARC レコードの構文）がまだブロックするかを表示する — 一度で全部やれる。
2. どのデフォルトで署名しているか特定する。 上記の通り Authentication-Results の header.d= を確認する：gappssmtp.com は Google Workspace のデフォルト、onmicrosoft.com は Microsoft 365 のデフォルトだ。
3. Google Workspace：独自キーを生成して公開する。 管理コンソールで「アプリ → Google Workspace → Gmail → メールの認証」に移動し、ドメインを選択して「新しいレコードを生成」をクリックする（DNS ホストが保存できない場合を除き 2048 ビット）。google._domainkey.yourdomain.com に TXT レコードとして公開し、DNS が反映するのを待って（最大 48 時間）、次に — 人々が見逃すステップ — 「認証を開始」をクリックする。レコードを生成しても署名をオンにするまでは何もしない。完全なウォークスルー：Google Workspace での DKIM 設定。
4. Microsoft 365：2つのセレクター CNAME を公開して有効にする。 Defender ポータルで「メールとコラボレーション → ポリシーとルール → 脅威ポリシー → メール認証設定 → DKIM」に移動し、カスタムドメインを選択してキーを作成する。両方の CNAME（selector1._domainkey と selector2._domainkey、Microsoft が示すターゲットを指す）を公開する（ポータルから正確なターゲットをコピーする — 2025年5月以前に有効にしたドメインはテナントの .onmicrosoft.com で終わり；新しいものは .dkim.mail.microsoft で終わる）— 次に署名をオンにする。セレクターが2つあるのは省略できない：Microsoft はそれらの間でキーをローテーションする。完全なウォークスルー：Microsoft 365 での DKIM 設定。
5. 新しい署名を確認する。 外部メールボックスに新しいメッセージを送り、Authentication-Results を再確認する：dkim=pass が header.d=yourdomain.com を示すはずだ。DNS パネルが CNAME ターゲットにゾーンを自動付加したり、長い TXT 値を壊したりした場合、署名は切り替わらない — パネルの癖であってプロバイダーの問題ではなく、ほとんどの失敗はここで発生する。
6. 再スキャンしてアライメントされた合格を活用する。 スキャンがアライメントされた DKIM を示すことを確認し、それを使う：p=none の DMARC ポリシーは何も守らない。採点済み 261,086,232 ドメイン全体で、DMARC を適用しているのはわずか 10.59%（2026-06-29 時点データ）— アライメントされた DKIM が適用を安全に引き上げられるものだ。DMARC の修正方法から始める。

カスタム DKIM を有効にすると何かが壊れるか？

いいえ — これはメール認証の修正の中でも影響範囲がほぼゼロという稀なケースだ：デフォルト署名で送信されていたメールが単により良い署名で送信されるだけで、プロバイダーが引き続きキーを管理する（Microsoft は2つのセレクター間で自動的にローテーションする）。実際の失敗モードは半分だけ実施すること — Google の TXT を公開したが「認証を開始」をクリックしなかった、またはM365のセレクターを1つだけ公開したなど。そして後で「整理するため」に DNS レコードを削除しない；キーが消えた瞬間に署名は停止する。

範囲についての注意：これは Google または Microsoft を通じて送信するメールを修正する。ニュースレタープラットフォームと CRM も独自のデフォルトで署名しており、それぞれのカスタムドメイン DKIM をオンにする必要がある — そのパターンと Gmail のバルク送信者ルールが今それを要求していることは、550-5.7.26 ガイドでカバーしている。

よくある質問

DKIM はすべてのテストツールで「合格」と表示される — なぜ何かを修正する必要があるのか？ ツールは DMARC より狭い質問に答えているからだ。署名は有効だ — しかし gappssmtp.com か onmicrosoft.com のものであり、あなたのものではないため、DMARC のアライメントでは無意味だ。これが多くの送信者がデフォルトで止まっている理由だ：Google を認可する 12,145,313 ドメインのうち、DMARC を適用しているのはわずか 18.5%（2026-06-29 時点データ）。

リラックス DMARC アライメントはデフォルト署名を通過させるか？ いいえ。リラックスアライメントは組織ドメインへの一致を緩めるだけだ — mail.yourdomain.com は yourdomain.com とアライメントする。デフォルト署名の組織ドメインは gappssmtp.com か onmicrosoft.com であり、あなたのものとは何も共有しない。どのアライメントモードもサードパーティの d= を救えない。

gappssmtp.com / onmicrosoft.com 署名は悪いのか？削除すべきか？ 悪くはない — メールが何らかの有効な署名を持つことを保証し、スパムフィルタリングに役立つ。ただあなたのものではないだけだ。削除するのではなく、カスタムドメイン署名を有効にして置き換える。

ドメインは strict SPF 付きの Microsoft 365 上にある — すでにカバーされているか？ おそらくそうではない：その strict レコードは M365 のデフォルトが一つの仕事をしているだけだ。spf.protection.outlook.com を認可する 10,205,070 ドメインのうち、85.0% が strict SPF を持つが DMARC を適用しているのはわずか 21.7%（2026-06-29 時点データ）。SPF は転送下でも壊れる、Return-Path に対して評価されるため — アライメントされた DKIM が生き残るレグであり、それがまさにこの修正が重要な理由だ。

修正にはどれくらいかかるか？ コンソール作業はプロバイダーごとに数分だ。DNS が待ち時間だ：Google は認証を開始する前に最大 48 時間を見るよう言っている；Microsoft の CNAME は通常数時間以内に有効になる。エンドツーエンドで1営業日を見積もり、ほとんどは待ち時間だ。

オーナーにレポートを送る

クライアントや雇用主のためにこれを修正している場合、証拠で締めくくる。新しい署名が有効になったら無料スキャンを再実行し、採点レポートをビジネスオーナーに転送する：日付入りで平易な言葉で、DKIM が自ドメインとアライメントしていることを示す。それがサイバー保険更新や次の取引先セキュリティアンケートのための成果物だ — ドメインが gappssmtp.com のサブテナントとしてではなく、自分自身として認証していることの証明だ。

DKIM のアライメントを無料でチェックする

メールが自ドメインとして署名されているか、正確に何を修正すべきかを — プライベートかつオーナー限定で確認する。

ドメインをチェックする → · DMARC が失敗するが SPF と DKIM は合格する → · DKIM を修正する → · Google Workspace で DKIM を設定する → · 集計データのみ使用。データは EU 内で保存・処理。