「メールが届かない」という問い合わせ
Microsoft 365を運用するひとり情シスにとって、「取引先にメールが届かない／遅れる／迷惑メールに入ってしまう」は最も問い合わせが多いトラブルです。原因はクライアント側ではなく送信ドメイン認証（SPF／DKIM／DMARC）と受信側のスパムフィルタ評価にあることが多く、Outlookの挙動を見ても解決しません。本稿は実機操作ベースで切り分け手順を整理します。
(1) Message Traceで配送結果確認 → (2) 送信ヘッダで認証ステータス確認 → (3) DNSのSPF／DKIM／DMARCを精査 → (4) 受信側の評価情報（Postmaster Tools等）を参照
Step 1：Message Traceで配送結果を確認
Exchange管理センター → メールフロー → メッセージトレース。送信者・受信者・期間を指定して検索。
確認するステータス
| ステータス | 意味 | 対処方針 |
|---|---|---|
| Delivered | 受信側サーバーまで届いた | 受信BOXか迷惑メールフォルダかを受信者に確認 |
| FilteredAsSpam | 送信側でスパム判定し配送停止 | 送信ポリシーまたは内容の見直し |
| Failed | NDR返却（5xx／4xx） | NDRメッセージ内のRBL／DKIM／DMARC理由を読む |
| Pending | 遅延中 | 受信側のグレイリスト／レート制限・DNS時刻整合 |
| Quarantined | 送信前に隔離 | Defender Anti-spam outboundで添付・URL確認 |
「Delivered」なのに受信者が「届いていない」と言う場合、9割は迷惑メールフォルダ／Junk Email／隔離に入っています。受信者側に「迷惑メールではないとマーク」してもらう運用も必要。
Step 2：受信したメールヘッダで認証結果を読む
Outlookで該当メールを開く → ファイル → プロパティ → インターネットヘッダーをコピー。「Authentication-Results」行を探します。
- spf=fail：送信元IPがDNSのSPFレコードに含まれていない
- dkim=fail：署名検証失敗（鍵不整合・改変・タイムアウト）
- dmarc=fail action=reject：受信側で拒否処理（DMARC側のp=rejectポリシー）
- compauth=fail reason=001：Microsoftの複合認証チェック失敗
ヘッダのX-Forefront-Antispam-Report も重要で、SCL（スパム信頼レベル）／BCL（バルク信頼レベル）／CIP（接続元IP）を確認できます。
Step 3：SPF／DKIM／DMARCのDNS精査
SPF
送信元として正当なIPの一覧をTXTで宣言。M365利用なら必ず以下を含める：
- 10ルックアップ制限（include で連鎖した結果が10回まで）
- SendGrid／Mailchimp／HubSpot等のSaaS送信時は
includeを追加 - 2レコードに分けるのは不可。1つのTXTにまとめる
- ~all（ソフトフェイル）／-all（ハードフェイル）の選択。本番運用は -all 推奨
DKIM
送信メールに電子署名を付ける。M365管理センター → セキュリティ → ポリシー → DKIM で有効化すると、CNAMEを2つ追加するよう案内されます。
DNS反映後、Defenderポータルでドメインを「署名を有効化」する操作を忘れずに（DNS追加だけでは有効にならない）。
DMARC
SPF／DKIMの結果と From ヘッダの整合性を判定。ポリシー段階：
Gmail／Yahooの2024年送信者要件以降、大量送信者は p=reject 必須。中小企業も none → quarantine pct=25 → quarantine pct=100 → reject と段階移行を90日かけて実施するのが安全です。
DMARC pass には「SPF passのみ」または「DKIM passのみ」のいずれかでよいが、From ドメイン（header.from）と SPF mailfrom／DKIM d= がアラインメント整合する必要があります。SaaS送信（マーケティングメール等）では、aspf=relaxed・adkim=relaxedを指定してサブドメイン整合を許容する運用が現実的。
Gmail／Yahoo 送信者要件への対応
2024年2月以降、Gmail・Yahooが大量送信者（5,000通／日以上）に課したルールは以下です。
- SPF または DKIM 認証のいずれか必須
- 5,000通／日超は SPF＋DKIM＋DMARC（p=none以上）必須
- RFC 5322 準拠の Fromアドレス
- List-Unsubscribe ワンクリック解除（ヘッダー）対応
- スパム苦情率 0.3% 未満を維持（Postmaster Tools計測）
マーケティングメール配信を行う中小企業は、要件未対応だとGmail宛ての配送停止リスクがあります。Postmaster Tools で日次の苦情率・認証率を監視するのが運用上必須です。
接続フィルター・許可リストの安全な使い方
「特定取引先のメールがスパム判定される」場合に許可リストへ追加するのは便利ですが、設定範囲を間違えるとなりすましメールも通してしまうためリスクが高い。
| 方法 | 安全度 | 使い所 |
|---|---|---|
| 受信メールフロールールで「PCL Override」 | 低（広範に影響） | 非推奨 |
| 許可ドメインリスト（Anti-Spam） | 低 | 非推奨。なりすましOKになる |
| 許可送信者リスト（個別アドレス） | 中 | 限定的に |
| Tenant Allow/Block List（送信元IP／URL／ファイル） | 高 | 推奨。Submitと連動 |
| 受信者個別の差出人セーフリスト（Outlookクライアント側） | 高 | 影響範囲限定 |
外部ツールでの確認
- MXToolbox：SPF／DKIM／DMARC構文と公開状態の検証
- dmarcian：DMARCレポート（rua）の集計・可視化
- Google Postmaster Tools：Gmail宛ての配送状況・スパム苦情率
- Microsoft Smart Network Data Services（SNDS）：MicrosoftのIPレピュテーション
月次チェックリスト
- DMARC ruaレポートの異常値（外部からのなりすまし試行）
- Postmaster Tools のスパム率・認証率
- SPF レコードの長さ（10ルックアップ近い場合は再構成）
- DKIMセレクタの有効化状態
- Tenant Allow/Block List の期限切れ
- 送信元IP／FromドメインのRBLステータス
まとめ
M365のメール配送トラブルは、「Message Traceで結果確認 → ヘッダで認証ステータス確認 → DNSのSPF／DKIM／DMARC精査 → 受信側のレピュテーション確認」の4段階で原因を絞り込めます。設定不備は復旧に時間がかかるため、構築時にDMARC・DKIMを正しく設定し、月次でレポートを確認する運用が結局のところ近道です。Gmail／Yahoo送信者要件の対応は、業務メール送信を継続する中小企業にとって必須の整備となっています。