DMARCに合格しても、受信トレイへの配置は保証されません。
これは、現代のメール配信における最も重要な現実の一つです。
DMARCは、受信メールサーバーに対して、メッセージが送信者の公開された認証ポリシーと整合しているかどうかを伝えます。これにより、受信者はドメインから送信されたと主張するメッセージがSPFまたはDKIMを通じて適切に認証されているかを識別できます。
しかし、GmailとMicrosoftは、DMARC単独で配信の判断を行いません。
送信者のレピュテーション、受信者の行動、苦情率、コンテンツシグナル、フィッシングインジケーター、転送コンテキスト、テナントレベルのルール、内部の不正使用防止システムも評価します。
つまり、2つのメッセージがどちらもDMARCに合格していても、GmailとOutlookでは異なる処理を受ける可能性があります。一方は受信トレイに届き、もう一方は他のシグナルに基づいてフィルタリング、レート制限、スパムフォルダへの振り分け、または拒否される可能性があります。
GoogleとMicrosoftの両エコシステムに送信する組織にとって、教訓は明確です：
DMARCは必要ですが、配信可能性のすべてではありません。
I. GmailとOutlookが認証を異なる方法で処理する理由
GmailとMicrosoftは、どちらもSPF、DKIM、DMARCをサポートしています。
どちらも、真剣な送信者がメールを認証することを期待しています。
どちらも、より広範な不正使用防止の一環として認証を使用しています。
しかし、エコシステム、ツール、ポリシー、フィルタリングレイヤーは同一ではありません。
Googleの公開送信者要件は、バルク送信者に対してより規範的です。Googleは、すべての送信者にSPFまたはDKIMでメールを認証することを要求し、バルク送信者はSPF、DKIM、DMARCを使用する必要があります。Googleはまた、SPFまたはDKIMが認証され、表示されるFromドメインと整合している場合にDMARCが合格すると述べています。
Microsoftも、より厳格な送信者要件に移行しています。2025年、MicrosoftはOutlook.com、Hotmail、Live.comアドレスへの大量送信者に対して、SPF、DKIM、DMARCを含む新しい要件を発表しました。Microsoft 365は、暗黙的なメール認証と呼ばれるものも使用しており、従来のSPF、DKIM、DMARCが、送信者のレピュテーション、送信者履歴、受信者履歴、行動分析、その他の技術などのシグナルと組み合わされます。
実際の違いは、一方のプロバイダーがDMARCを「重視」し、他方がそうでないということではありません。
違いは運用上のものです。
Googleの公開ガイダンスは、送信者にバルクメールコンプライアンスのより明確なベースラインを提供します。Microsoftのフィルタリング環境は、Exchange Online Protection、Defender for Office 365、メールボックスポリシー、許可/ブロックルール、エンタープライズ構成がメッセージの処理方法に影響を与える可能性があるため、テナント固有のバリエーションがより多く含まれることがよくあります。
送信者にとって、これは単純な現実を生み出します：
両方のプロバイダーを満足させる認証と、認証を超えたフィルタリングに耐えられるほど強力なレピュテーションが必要です。
II. DMARC復習：実際に何が合格する必要があるか
DMARCはしばしば誤解されています。
SPFが合格したからといって、メッセージがDMARCに合格するわけではありません。
DKIMが合格したからといって、メッセージがDMARCに合格するわけではありません。
メッセージがDMARCに合格するのは、少なくとも1つの認証された識別子が表示されるFromドメインと整合している場合のみです。
つまり：
- SPFが合格し、SPF認証されたドメインが表示されるFromドメインと整合している必要があります。
- またはDKIMが合格し、DKIM署名ドメインが表示されるFromドメインと整合している必要があります。
これは、サードパーティプラットフォームにとって特に重要です。
マーケティングツール、サポートプラットフォーム、CRM、請求システム、またはトランザクションメールサービスは、独自のドメインを使用してSPFまたはDKIMに合格する場合があります。これはベンダーにとって有用ですが、認証されたドメインが表示されるFromドメインと整合しない限り、DMARC結果には役立たない可能性があります。
ユーザーはあなたのドメインを見ます。
DMARCは、認証結果がそのドメインに戻るかどうかをチェックします。
III. Gmailが送信者に要求する正しい設定
Googleの送信者ガイドラインは、認証をベースライン要件としています。
送信者にとって、これはGmailが以下を期待していることを意味します：
- すべての送信者にSPFまたはDKIM。
- バルク送信者にはSPF、DKIM、DMARC。
- 表示されるFromドメインとのDMARC整合。
- 低いスパム苦情率。
- マーケティングメールの購読と購読解除要件の適切な処理。
Googleは、Postmaster Toolsを通じて可視性も提供しています。その認証ダッシュボードは、送信者のFromドメインを使用するメッセージのSPF、DKIM、DMARCに合格するメールの割合を表示します。Googleは、これらの方法が正しく構成されている場合、送信者は通常高いDKIMおよびDMARC成功率を達成するが、サードパーティ送信者が関与している場合、SPF成功率は低くなる可能性があると指摘しています。
これは、Gmailが送信者に認証の健全性を観察するより明確な方法を提供しているため重要です。
ただし、Gmail Postmaster Toolsは、個々のフィルタリング決定をすべて説明するわけではありません。メッセージは認証に合格しても、他のシグナルがリスクを示している場合はフィルタリングされる可能性があります。
一般的なGmail配信の問題には以下が含まれます：
- ドメインまたはIPレピュテーションの低さ。
- 高いスパム苦情率。
- 突然の送信量の急増。
- 疑わしいコンテンツまたはフィッシングのようなパターン。
- サードパーティ送信者の設定ミス。
- キー変更後のDKIM失敗。
- サードパーティのReturn-PathドメインによるSPF整合の失敗。
Gmailにとって、認証はベースラインです。信頼の会話に参加するためのものです。受信トレイへの配置を保証するものではありません。
IV. Microsoftが送信者に要求する正しい設定
Microsoftのエコシステムには、Outlook.com、Hotmail、Live.com、Microsoft 365、Exchange Online Protection、Microsoft Defender for Office 365が含まれます。
これにより、メッセージの評価方法にバリエーションが生まれます。
Microsoftは、Outlook.com、Hotmail、Live.comアドレスの大量送信者要件として、SPF、DKIM、DMARCを含むことを公に発表しました。Microsoft 365の場合、インバウンド認証は、SPF、DKIM、DMARC、および送信者のレピュテーション、送信者履歴、受信者履歴、行動分析、その他の高度な技術などの追加の暗黙的な認証シグナルを通じて評価されます。
これは、認証が重要であることを意味しますが、より広範な決定システムの一部です。
Microsoft環境に送信されるメッセージは、以下の影響を受ける可能性があります：
- SPF、DKIM、DMARC結果。
- 送信者のレピュテーション。
- 受信者またはテナントの履歴。
- Defender for Office 365ポリシー。
- Exchangeトランスポートルール。
- テナント固有の許可またはブロックリスト。
- スプーフインテリジェンス。
- ユーザーレポート。
- コンテンツと添付ファイルの分析。
- URLおよびフィッシング検出。
これが、送信者がMicrosoftテナント間で違いを見ることがある理由です。
メッセージは、受信テナントが異なるポリシー、セキュリティ設定、許可リスト、または送信者との履歴的な関係を持っているため、ある組織では受け入れられ、別の組織ではフィルタリングされる可能性があります。
これは、MicrosoftがDMARCを無視していることを意味するわけではありません。
これは、Microsoftのフィルタリング環境がDMARC単独よりも多くのレイヤーを持っていることを意味します。
V. GmailとOutlook：送信者にとっての実際的な違い
最も安全な比較は、「どちらのプロバイダーがDMARCをより強く実施しているか」ではありません。
より良い比較は、送信者が2つのエコシステムをどのように経験するかです。
| 領域 | Gmail | OutlookとMicrosoft 365 |
|---|---|---|
| 公開送信者要件 | SPF、DKIM、DMARC、スパム率、購読解除慣行に関する明確なバルク送信者要件 | Outlook.com、Hotmail、Live.comの大量送信者要件；Microsoft 365は、より広範なフィルタリングレイヤーを通じて認証を評価 |
| 認証の可視性 | Google Postmaster Toolsは、認証、スパム率、レピュテーション、配信関連のダッシュボードを提供 | MicrosoftはMicrosoft 365環境内で管理者/セキュリティの可視性を提供しますが、送信者は集中化された外部の可視性をあまり見ない |
| フィルタリングモデル | 認証に加えて、レピュテーション、エンゲージメント、コンテンツ、苦情、不正使用シグナル | 認証に加えて、レピュテーション、テナント構成、受信者履歴、Defender/EOPポリシー、スプーフインテリジェンス、ユーザーレベルのシグナル |
| サードパーティ送信者リスク | SPFまたはDKIMは、DMARCが合格するために表示されるFromドメインと整合する必要があります | 同じDMARC整合要件ですが、テナントルールと暗黙的な認証シグナルが最終的な処理に影響を与える可能性があります |
| 配信のばらつき | Postmaster Toolsを通じてドメインレベルで追跡しやすい | テナントポリシー、エンタープライズ構成、内部Microsoftセキュリティ制御によってより変動する可能性があります |
| DMARCレポートが示すもの | 認証結果、完全な配置理由ではない | 認証結果、完全な配置理由ではない |
運用上の結論は簡単です：
メールがきれいに認証され、適切に整合し、低い苦情を維持し、安定した送信パターンを使用している場合、GmailとMicrosoftの両方でより良い位置にいます。
メールが整合に失敗したり、設定が不適切なサードパーティ送信者を使用したり、レピュテーションが弱い場合、認証の問題は2つのエコシステムで異なって現れる可能性があります。
VI. サードパーティ送信者が一般的な失敗ポイント
ほとんどの組織は、1つのシステムからすべてのメールを送信しません。
以下を使用します：
- マーケティングオートメーションプラットフォーム。
- CRMシステム。
- ヘルプデスクツール。
- チケットプラットフォーム。
- トランザクションメールサービス。
- 請求システム。
- イベントプラットフォーム。
- HRツール。
- 地域またはビジネスユニットのプラットフォーム。
各送信者は認証され、整合されている必要があります。
これは、DMARCプログラムがしばしば破綻する場所です。
サードパーティプラットフォームはSPFに含まれている場合がありますが、Return-Pathドメインがベンダーに属しているため、SPFが整合しない可能性があります。
別のプラットフォームがメッセージにDKIM署名する場合がありますが、DKIM d=ドメインがあなたのドメインではなくベンダーに属している可能性があります。
どちらの場合も、メッセージは認証されている可能性がありますが、DMARC整合には失敗します。
これは、各プロバイダーが認証を他のフィルタリングシグナルと組み合わせるため、GmailとMicrosoftに異なる影響を与える可能性があります。しかし、修正は同じです：
各サードパーティ送信者を、整合されたSPFまたは整合されたDKIMを通過するように構成します。
多くの場合、整合されたDKIMがより信頼性の高いパスです。SPFは転送シナリオや共有送信インフラストラクチャで破損する可能性があるためです。
VII. DMARCが合格しても配信が失敗する場合
DMARCの合格は、受信トレイへの配置と同じではありません。
メッセージはDMARCに合格しても、以下の理由でフィルタリングされる可能性があります：
- 高い苦情率。
- 低いエンゲージメント。
- 低いドメインレピュテーション。
- 低いIPレピュテーション。
- 疑わしいコンテンツ。
- フィッシングインジケーター。
- 安全でないURL。
- 突然の量の急増。
- リストの衛生状態の悪さ。
- 受信者レベルのフィルタリング。
- テナントレベルのルール。
これはGmailとMicrosoftの両方に当てはまります。
認証は、メッセージがドメインを使用することを承認されていることを証明します。
メッセージが望まれている、安全である、または高品質であることを証明するものではありません。
この区別は重要です。
送信者は完璧なSPF、DKIM、DMARCを持っていても、受信者がメッセージをスパムとしてマークしたり、メールを無視したり、コンテンツがフィルタリングシステムをトリガーしたりすると、パフォーマンスが低下する可能性があります。
VIII. DMARCが失敗してもメールが配信されているように見える場合
逆のこともあり得ます。
メッセージはDMARCに失敗しても、配信されているように見える可能性があります。
考えられる理由には以下が含まれます：
- 受信プロバイダーが追加のコンテキストを適用している。
- メッセージが転送され、追加の認証シグナルで評価されている。
- 受信者またはテナントが送信者を許可リストに登録している。
- メッセージが拒否されるのではなく、スパムに配置されている。
- 受信者がドメインの公開ポリシーを特定のシナリオで異なる方法で扱っている。
- メッセージが他のフィルタリングシステムによって低リスクと判断されている。
これは、DMARCが無関係であることを意味するわけではありません。
これは、DMARCがより大きな受信側の決定における1つのシグナルであることを意味します。
送信者は、失敗したメールが時折配信されることを、認証が健全である証拠として使用すべきではありません。
DMARCレポートが失敗を示している場合、ユーザーが配信の問題を報告していなくても、これらの失敗を調査する必要があります。
IX. 注意すべきサイレント障害モード
最も危険な問題は、すぐにサポートチケットを作成しない問題です。
1. 認証のドリフト
ベンダーがインフラストラクチャを変更します。DKIMセレクターが誤ってローテーションされます。SPFのインクルードが変更されます。ビジネスチームが新しい送信ツールを追加します。
メールはしばらく配信され続ける可能性がありますが、DMARCレポートは失敗を示し始めます。
監視がなければ、配信可能性が低下するか、スプーフィングリスクが増加するまで、問題は隠されたままです。
2. レピュテーションマスキング
強力なレピュテーションを持つ送信者は、一部の認証の問題から即座の配信への影響を見ない可能性があります。
これは誤った自信を生み出す可能性があります。
認証のギャップは依然として存在し、レピュテーションが変わったり、量が急増したり、プロバイダーのフィルタリングしきい値が変わったりすると、後で表面化する可能性があります。
3. テナント固有の配信の違い
Microsoft環境は、テナント構成によって異なる可能性があります。
あるお客様はメッセージを受信する可能性があります。別のお客様は検疫する可能性があります。別のお客様は、ローカルルールまたはDefenderポリシーのためにブロックする可能性があります。
これにより、認証結果だけではすべての配信結果を説明できないため、トラブルシューティングがより困難になります。
4. 転送とメーリングリスト
転送は、転送サーバーが元の送信者のSPFレコードで承認されていないため、SPFを破る可能性があります。
メッセージが変更されていない場合、DKIMは転送を生き延びる可能性があります。DKIMも失敗した場合、DMARCは失敗する可能性があります。
ARCは、受信者が転送されたメールのコンテキストを評価するのに役立ちますが、送信者は転送動作への依存を減らすために、強力なDKIM整合を目指すべきです。
X. GmailとMicrosoftの両方に対する実装ガイダンス
強力な認証プログラムは、1つのプロバイダーのみのために設計すべきではありません。
両方のエコシステムで機能する必要があります。
1. DMARCを公開し、レポートを監視する
正当な送信者と失敗を特定するために、監視から始めます。
基本的な静的レコードは次のようになります：
v=DMARC1; p=none; rua=mailto:[email protected]より良いアプローチは、Skysnagを通じて管理されたDMARC監視レコードを使用することです。これにより、レポートが収集、解析され、実用的な送信者インテリジェンスに変換されます。
Skysnagでのdmarc監視を開始し、無料のDMARCレコードを取得してください.
2. すべての正当な送信者を認証する
各送信者について、以下を確認します：
- 必要に応じてSPFが承認されている。
- DKIMが有効になっている。
- 少なくとも1つの方法が表示されるFromドメインと整合している。
- 送信者が文書化されている。
- ビジネスオーナーが知られている。
- 認証が時間とともに監視されている。
3. サードパーティプラットフォームには整合されたDKIMを優先する
可能な場合、サードパーティプラットフォームを、あなたのドメインを使用してDKIM署名するように構成します。
これにより、共有インフラストラクチャまたは転送パスを通過するときに脆弱になる可能性があるSPF整合への依存が減ります。
4. メールストリームを分離する
異なるメールカテゴリに適切なドメインまたはサブドメインを使用します。
例えば：
- トランザクションメール。
- マーケティングメール。
- サポートメール。
- セキュリティ通知。
- 内部システム。
これにより、認証が管理しやすくなり、レピュテーションが保護しやすくなります。
5. 慎重に執行に移行する
p=noneにとどまり続けないでください。
発見と修復の後、成熟したドメインを検疫に、次に拒否に移行します。
段階的なアプローチは、以下に基づく必要があります：
- ドメインの準備状況。
- サブドメインの成熟度。
- 送信者グループの安定性。
- ビジネスの重要性。
- 認証合格率。
- 修復ステータス。
主要戦略として割合ベースのロールアウトを避けてください。現在のDMARC対応プログラムは、pctに依存するのではなく、ドメイン、サブドメイン、送信者グループ、ビジネスユニットごとに執行を段階的に行うべきです。
6. 認証とは別にレピュテーションを監視する
DMARCレポートは認証結果を示します。
受信トレイへの配置を完全に説明するものではありません。
利用可能な場合はプロバイダーツールと運用メトリックを使用します。以下を含みます：
- Google Postmaster Tools。
- 該当する場合のMicrosoft 365メッセージトレースとセキュリティレポート。
- バウンスデータ。
- 苦情のトレンド。
- エンゲージメントメトリック。
- ブロックリストとレピュテーションの監視。
- メールボックスプロバイダー間での配信テスト。
認証とレピュテーションは一緒に監視する必要があります。
XI. コンプライアンスへの影響
メール認証は多くのコンプライアンスとガバナンスプログラムをサポートしますが、正確に記述する必要があります。
DMARCは、フィッシング対策、ドメイン保護、ベンダー監視、通信の整合性の目標をサポートできます。また、組織が不正な送信と認証の失敗を監視している証拠を提供することもできます。
ただし、DMARC自体がGDPR、PCI DSS、HIPAA、SOC 2、NIS2、またはその他のフレームワークを自動的に満たすわけではありません。
より良いフレーミング：
- DMARCはフィッシング対策と通信の整合性制御をサポートします。
- SPFとDKIMは送信者認証をサポートします。
- DMARCレポートは監視と証拠収集をサポートします。
- 執行は、正確なドメインスプーフィングに対する保護をサポートします。
- MTA-STSとTLS-RPTは、安全なメール転送の可視性をサポートします。
Skysnag Complyは、組織が送信元とドメイン全体でメール認証体制に関する可視性、レポート、証拠を維持するのに役立ちます。
XII. 実用的な運用モデル
GmailとMicrosoftに送信する組織にとって、運用モデルはシンプルであるべきです：
- すべての送信者を知る。
- すべての送信者を認証する。
- 少なくとも1つの認証方法を表示されるFromドメインと整合させる。
- DMARCレポートを継続的に監視する。
- プロバイダーのレピュテーションと苦情シグナルを追跡する。
- 機能とリスクによってメールストリームを分離する。
- 準備ができたら、監視から執行に移行する。
- 配信の問題を認証とレピュテーションの両方の問題として扱う。
- サードパーティ送信者を定期的にレビューする。
- 監査とガバナンスのためのドキュメントを維持する。
このモデルは、GmailまたはMicrosoftがすべてのシグナルを内部でどのように重み付けしているかを正確に推測することに依存しないため機能します。
送信者が実際に管理できる制御に焦点を当てています。
XIII. 重要なポイント
GmailとMicrosoftは、どちらも真剣な送信者、特に大量送信者に対して強力なメール認証を要求しています。
Gmailの公開送信者要件は、大量送信者に対してより規範的ですが、Microsoftは従来の認証と、評判、送信者履歴、受信者履歴、行動分析、テナント固有のコントロールなどの暗黙的な認証シグナルを組み合わせています。
DMARCのパスは、受信トレイへの配信を保証するものではありません。
DMARCの失敗は、必ずしも即座の拒否を意味するものではありません。
認証は、評判、苦情率、コンテンツの品質、送信パターン、プロバイダー固有の可視性と並行して管理する必要があります。
最大の運用リスクは、サードパーティ送信者の不整合です。ドメインを代理して送信するすべてのプラットフォームは、整合性のあるSPFまたは整合性のあるDKIMをパスするように構成する必要があります。
最も安全な戦略は、GmailやMicrosoftを個別に最適化することではありません。両方で機能する規律ある認証プログラムを構築することです。
Skysnagでのモニタリングを開始し、無料のDMARCレコードを取得しましょう.
