DMARC failの原因は？エラーの読み方と直す順番を担当者向けに解説

DMARC failとは、受信側の判定で、SPFとDKIMのどちらも、Fromのドメインと一致した形で合格できなかった状態です。

今日やることは、failの出ている送信元を「自社で使うもの」「知らないもの」⁠に分けることです。直すのは自社で使うものだけで、件数の多い順に進めます。

レポートがまだ手元にない場合は、DMARCレポートの読み方⁠で受け取り方を確かめます。メールセキュリティの解説全体の中では、送信元の認証の話です。

何が揃えばDMARCに合格する？

Googleの管理者向けヘルプ⁠によれば、次の少なくとも一方を満たせば合格です。

• SPFの認証に合格し、ドメインも一致している
• DKIMの認証に合格し、ドメインも一致している

ここでの「一致」⁠は⁠、アライメントと呼ばれます。見比べる相手は次のとおりです。

標準の緩和モードでは、サブドメインでも一致とみなされます。厳格モード（aspf=s、adkim=s）⁠で⁠は⁠、完全に同じドメインだけが一致です。Googleは、通常は緩和モードで十分としています。

見落としやすいのは、認証の失敗より、この一致の失敗です。SPFやDKIMがpassでも、ドメインが別なら、DMARCでは不合格です。

エラーはどこを読む？

見る場所は、集計レポートとメールのヘッダーの2つです。

集計レポートの場合

Microsoftの解説は、レポートの中で次の2か所を比べるよう示しています。

auth_resultsがpassでpolicy_evaluatedがfailなら、認証は通ったのに一致していない状態です。Microsoftはこの差を、集計レポートから得られる重要な情報と説明しています。

メールのヘッダーの場合

1通を手元で確かめる方法もあります。自社から社外のメールアドレスへテストを送り、受信側でヘッダーを開きます。Gmailではメッセージのソースを表示から詳細ヘッダーを見られます。

Microsoft 365では、Authentication-Resultsヘッダーを見ます。Microsoftの解説にある例では、次の3つ⁠の値を読みます。

• smtp.mailfrom=：SPFで見たドメイン
• header.d=：DKIMで見たドメイン
• header.from=：Fromのドメイン

上の2つ⁠のどちらも3つ目と一致していなければ、failの理由はここにあります。

SPFとDKIMに分けると、原因はどう見える？

Microsoftの解説が示すパターンを、やることまで整理します。

厳格モードを使っている場合は、もう1つ確かめます。aspf=sでは、MAIL FROMがサブドメインでFromが親ドメインだと、failになります。

直す順番は？

次の順に進めます。

1. レポートの送信元を一覧にして、件数の多い順に並べる
2. 社内のシステム、複合機、配信サービスの担当者に、送信元を確かめる
3. 自社で使う送信元のうち、件数の多いものからDKIMの署名を自社ドメインにする
4. DKIMが設定できないサービスは、MAIL FROMを自社のドメインかサブドメインに変える
5. どちらも難しいサービスは、送信専用のサブドメインを分けることを検討する
6. 翌週以降のレポートでpolicy_evaluatedがpassになったか確かめる
7. 正規のfailがなくなってから、ポリシーを上げる

DKIMを先に試す理由は、転送の影響です。Microsoftの解説は、本文が変更されていなければ、転送してもDKIMは残ると説明しています。SPFは転送でエンベロープ送信者が変わると崩れます。

Googleのヘルプは、DMARCを有効にする48時間以上前から、DKIMとSPFでメールが認証されている必要があると書いています。設定を足した直後の結果で判断しないようにします。

DNSの変更は、誤るとメール全体に影響します。変更の手順や権限をほかのDNSの管理と揃えたい場合は、DNSセキュリティの比較も参考になります。

たとえば、複合機と受注システムからfailが出る場合

機械部品のメーカーで、人が送るメールはMicrosoft 365、見積フォームの自動返信は外部のサービス、受注通知は基幹システムから、という構成を考えます。3つとも、Fromは自社のドメインです。

レポートでは、Microsoft 365はpassのまま、見積フォームと受注通知だけfailが並ぶ形になり得ます。この場合、直す相手はメールサーバーではなく、各サービスの送信設定です。

• 見積フォームのサービス：管理画面に自社ドメインのDKIM署名の設定があるか確かめる
• 基幹システム：保守会社に、送信に使うサーバーとMAIL FROMのドメインを確かめる
• 工場の複合機：スキャンの送信先が社外に向いているか確かめる。社内だけなら優先を下げる

ここで失敗しやすいのは、担当が工場や営業にいて、情シス担当の一覧に載っていないサービスです。レポートを、送信元の棚卸しとして使います。

failをすべて消す必要はある？

ありません。消すのは自社で使う送信元のfailです。

なりすましのfailは、直す対象ではありません。Microsoftの解説は、知らないIPから大量の試行があり、すべてfailのパターンについて、設定の修正は不要としています。これは認証が偽のメールを見分けている状態です。ただし、受信者を守るのはポリシーなので、p=noneのままでは受信側に強い処理を求められません。

転送やメーリングリストのfailも、一部は残ります。RFC 9989は、メーリングリストへ投稿する利用者がいるドメインのp=rejectについて、運用上の問題が起きると注意しています。社外のメーリングリストを使う部署がないかは、ポリシーを上げる前に確かめます。

ポリシーはいつ上げる？

正規の送信元のfailがなくなったのを確かめてからです。RFC 9989⁠によれば、p=noneから始める理由は、SPFとDKIMの設定で見落としたサーバーや外部の送信を、レポートで洗い出すためです。

ただし、ずっとp=noneには置きません。フィッシング対策協議会のガイドライン2026年度版は、ウェブサイト運営者に向けて、p=noneでは意味をなさないと書き、まずp=quarantineとし、最終的にp=rejectを目指す流れを示しています。

受信側の扱いも確かめます。Gmailの送信者ガイドラインは、すべての送信者にSPFまたはDKIMを、1日5,000件⁠を超えて送る送信者にSPF、DKIM、DMARCを求めています。failの解消は、届きやすさの面でも無関係ではありません。

送信元が多くて手で追えない場合は、DMARCレポート解析サービスの比較で、送信元の識別と通知の機能を見ます。受信側のフィッシング対策はDMARCとは別で、フィッシングメールの対策⁠やメールセキュリティ製品の比較で扱います。社員向けの話はフィッシングメールの見分け方⁠にあります。