DMARCレポートやメッセージヘッダーを開くと、spf=passとdkim=passの隣にdmarc=failと表示されています。見た目ほど壊れているわけではありません。2つのチェックはどちらも成功していますが、DMARCが見ているドメインに対して成功していないだけです。このガイドは、まさにその状況のためのトラブルシューティングの手順です。アライメントとは何かをすでに理解していて、よくある原因のうちどれに当たるかを、可能性の高い順に調べたい方を想定しています。
結論#
DMARCが成功するのは、SPFまたはDKIMが成功し、かつ表示されるFromアドレスのドメインとアライメントしている場合です。「成功」と「アライメント」は別の問いです。SPFはReturn-Path（エンベロープ送信者）のドメインと、DKIMは署名内のd=のドメインと比較されます。メール配信サービスが自社のドメインで署名し、自社のドメインを経由してバウンスを処理していると、2つのチェックはどちらも成功しますが、どちらもアライメントしません。対処はほぼ常に同じです。お使いのドメインでカスタムDKIM署名ドメインを設定し、SPFもアライメントさせたい場合はカスタムのreturn-pathドメインも設定します。strictモードのタグ、転送、サブドメインは、その後で確認してください。概念そのものについては、SPF・DKIM・DMARCの解説をご覧ください。
各チェックが比較する対象#
どのメッセージにも重要なドメインが3つあり、DMARCはそれらを組み合わせて照合します。各チェックがどのドメインを使うのかを言えるようになれば、混乱の大半は解消します。
| チェック | DMARCが比較するドメイン | 確認できる場所 | アライメントする条件 |
|---|---|---|---|
| From | 受信者に表示されるアドレス（Authorドメイン） | Authentication-Resultsのheader.from | 両方のチェックの基準点 |
| SPF | Return-Pathのドメイン（MAIL FROMまたはエンベロープ送信者とも呼ばれる） | smtp.mailfrom、またはReturn-Path:ヘッダー | アライメントモードの条件でFromドメインと一致する |
| DKIM | DKIM-Signatureヘッダー内のd=ドメイン | header.d、または署名内のd= | アライメントモードの条件でFromドメインと一致する |
典型的な失敗は、受信したメッセージでは次のように見えます。Fromは自分のドメインで、2つのチェックはどちらも成功し、残る2つのドメインはどちらも送信者のものです。
Authentication-Results: mx.receiver.example;
spf=pass smtp.mailfrom=bounce.mail.vendor.example;
dkim=pass header.d=mail.vendor.example;
dmarc=fail header.from=yourdomain.com
メールヘッダー解析では、SPF、DKIM、DMARCの判定と、FromおよびReturn-Pathのフィールドを確認できます。DKIMのd=の値は、DKIM-Signatureの行から自分で読み取ってください。集計レポートしかない場合は、同じ情報がauth_results（生の結果とドメイン）とpolicy_evaluated（アライメントを考慮した判定）に分かれて入っています。この区別はレポートの読み方ガイドで説明しています。
判断の手順#
この一覧を上から順にたどり、最初に当てはまった手順で止めてください。各手順は、原因も対処も別のものです。
- DKIMは成功しているが、
d=が送信者のドメインになっている。 最も多い原因で、最も良い対処があるケースです。送信サービスでカスタムDKIM署名（ブランド付きドメインや認証済みドメインと呼ばれることもあります）を有効にし、d=yourdomain.comまたはそのサブドメインで署名されるようにします。DKIMはメッセージとともに運ばれるため、転送後もアライメントが保たれます。 - SPFは成功しているが、Return-Pathが送信者のドメインになっている。 SPFがアライメントできるのは、エンベロープ送信者が自分のドメインの場合だけです。サービスでカスタムのreturn-path（バウンス）ドメインを設定します。通常は
bounce.yourdomain.comのようなサブドメインを、CNAME、またはプロバイダーが提示するMXとTXTレコードでプロバイダーに向けます。プロバイダーを自分のSPFレコードに追加しても、これは解決しません。SPFはReturn-Pathのドメインに対して検査されますが、それはプロバイダーのドメインなので、そのメッセージについて自分のレコードが参照されることはありません。 - どちらもカスタム設定なのに、DMARCが失敗する。 DMARCレコードの
adkimとaspfを確認します。どちらかがs（strict）なら、完全一致が必要になり、mail.yourdomain.comからの署名は、Fromのyourdomain.comとアライメントしません。Fromドメインと完全に一致するドメインで署名するか、strictのタグを外してください。 - 一部の送信元、または一部の受信側でのみ失敗する。 転送、メーリングリスト、またはメールを書き換えるセキュリティゲートウェイを疑います。後述の転送のセクションをご覧ください。
- サブドメインでのみ失敗する。 そのサブドメインに独自のSPFとDKIMがあるか、どのDMARCレコードが適用されるかを確認します。サブドメインのセクションをご覧ください。
- 何も成功していない。 これはアライメントの問題ではありません。その送信元でSPFまたはDKIMが欠けているか壊れていて、より単純な別の問題です。
relaxedとstrictの実際の違い#
デフォルトは、どちらもrelaxedです。relaxedのアライメントでは、2つのドメインが組織ドメインを共有していればよいため、Return-Pathがbounce.yourdomain.comでも、Fromがnews.yourdomain.comとアライメントします。strictでは、完全に同一である必要があります。
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"
文書化された理由がない限り、どちらもrのままにしてください。strictモードが、relaxedモードなら見逃してしまう本物の攻撃を止めることはまれで、正規のサブドメインのメールが失敗する原因になりやすいものです。現行の標準では1つ変更点があります。RFC 9989（2026年5月）はRFC 7489を廃止し、組織ドメインをパブリックサフィックスリストではなく、DNSツリーの探索で定義します。複数ラベルを持つ珍しいドメインを運用している場合は、受信側がどう適用するかを確認してください。
転送で片方のチェックだけが壊れる理由#
メッセージが転送されると、転送サーバーは自分のIPからそのメッセージを送り出します。SPFは接続元のIPに対して評価されるため、SPFは失敗するか、アライメントしなくなります。そのため、ある送信元が、ある受信側では健全なDMARCを示し、別の受信側では失敗を示すことがあります。失敗しているのは、転送されたコピーです。
DKIMは、署名がメッセージの中に含まれて運ばれるため、通常は転送されても残ります。壊れるのは、転送サービスやメーリングリストが、署名された内容を変更した場合です。たとえばフッターの追加や件名の編集です。そのため、アドバイスはいつも同じになります。すべての送信元でDKIMをアライメントさせることです。そうすれば、SPFが成功しなくても、DMARCは成功できます。
転送の問題を、こちら側だけで完全に解決することはできません。転送サービスやリストに起因する小さな失敗が残るのは普通のことで、1日だけの悪い結果ではなく、傾向と送信元ごとの状況で進捗を判断すべき理由の一つです。
サブドメインの不一致#
サブドメインは、親ドメインのSPFレコードを継承しません。DKIMの鍵もセレクターとドメインごとに検索されるため、メールを送るサブドメインには独自の認証が必要です。DMARCポリシーは違います。サブドメインが独自のDMARCレコードを公開していない場合、受信側は親のレコードを探し、親のsp=タグ（あれば）がサブドメインのポリシーを決めます。
サブドメインの問題の大半は、2つの確認で見つかります。1つ目は、送信サービスが、Fromのサブドメイン、またはrelaxedモードなら親ドメインと一致するドメインで署名していることを確認すること。2つ目は、親にsp=rejectを設定している場合、頼る前に、送信を行うすべてのサブドメインが成功していることを確認することです。メールの種類ごとに分離を保つ構成の作り方は、送信用サブドメインのガイドで説明しています。
失敗している送信元をすばやく見つける#
アライメントの失敗で手間がかかるのは、修正ではなく、どの送信元に修正が必要かを見つけることです。レポートはメールを送信元IPごとにまとめるため、送信元自身のドメインで署名している場合、その送信元は、DMARCの割合が低い行として表れます。
QualisendのDMARCレポートは、送信元ごとにDMARC、DKIM、SPFの割合を別々に表示し、100%未満の行にフラグを付けます。ベンダー自身のドメインで署名し、バウンスも処理している送信元は、DMARC、DKIM、SPFの割合がそろって低くなります。これが上の手順1または2のパターンです。このページでは各行のd=ドメインやReturn-Pathは表示されないため、その送信元からメッセージを1通取り出し、ヘッダーを読んで、2つのドメインのどちらが間違っているかを確認する必要があります。また、受信側が返してきたものしか報告されないため、集計レポートを送らない受信側は表示されません。
アカウントなしで最初に確認したい場合は、無料のDMARCレポート解析が、1つのレポートファイルをブラウザー内で読み取ります。送信元をエンドツーエンドでテストするには、無料のメール到達性テストにメッセージを送り、その認証結果を読んでください。
サービスごとのチェックリスト#
送信サービスごとに設定の呼び方は違いますが、作業内容は同じ4項目です。メニューやデフォルト値は変わるため、早見表を鵜呑みにせず、各サービスの公式ドキュメントで確認してください。
- カスタムDKIMドメイン。 「ドメインの認証」「ブランド付き送信ドメイン」「DKIM」といった項目を探します。提示された鍵を公開してください。新しいセレクター名が、既存のものと競合することはありません。
- カスタムreturn-pathドメイン。 「カスタムバウンスドメイン」「return-path」「リンクのブランディング」といった項目を探します。DKIMとは別の設定になっていることも多くあります。
- Fromアドレス。 Fromがお使いのドメインであることを確認します。サードパーティ経由で送る、フリーメールのドメインのFromは、お使いのどのドメインともアライメントできません。
- 一度に変更するのは1つだけ。 変更し、テストを送り、ヘッダーを読み、次のレポートを確認します。一度に複数の変更をすると、どれが効いたのか分からなくなります。
どこまで直せば十分か#
ポリシーの適用を考える準備ができるのは、すべての正規の送信元が、少なくとも1つのアライメントしたチェックを通じてDMARCに成功していて、残る失敗が転送サービス、または身に覚えのないメールによるものだけになったときです。そこへ至る方法をまだ模索しているなら、DMARC設定ガイドに導入の順序が、送信者要件のガイドに、大量送信メールでアライメントしたDMARCが今や重要な理由が書かれています。
よくある質問
01SPFとDKIMがどちらも成功しているのに、DMARCが失敗するのはなぜですか？
DMARCには、アライメントしたうえでの成功が必要だからです。SPFはReturn-Pathのドメインと、DKIMは署名のd=ドメインと比較され、どちらか一方が表示されるFromドメインと一致している必要があります。メール配信サービスが自社のバウンスドメインを使い、自社のドメインで署名していると、2つのチェックはどちらもサービス側では成功しますが、どちらもお使いのドメインとは一致しません。カスタムDKIMドメインを設定し、SPFもアライメントさせたい場合はカスタムのreturn-pathも設定してください。
02メール配信サービスを自社のSPFレコードに追加するだけで十分ですか？
通常は不十分です。サービスをSPFレコードに追加して効果があるのは、エンベロープ送信者であるReturn-Pathがお使いのドメインの場合だけです。サービスが引き続きサービス自身のバウンスドメインを使っているなら、SPFはお使いのドメインではなくそのドメインに対して評価されるため、レコードの内容にかかわらずアライメントしません。確実な対処は、お使いのドメインでのカスタムDKIM署名です。DKIM署名はSPFとは別にアライメントし、ほとんどの場合、転送されても残るからです。
03strictとrelaxedのどちらのアライメントを使うべきですか？
具体的で文書化された理由がない限り、relaxedです。relaxedモードでは、2つのドメインが組織ドメインを共有していればよいため、bounce.yourdomain.comはnews.yourdomain.comとアライメントします。strictモードは完全一致を求め、保護の効果はわずかな一方で、正規のサブドメインのメールを壊しやすくなります。relaxedはDMARCレコードのadkimとaspfタグのデフォルトでもあるため、通常はそのままにしておけば問題ありません。
04転送されたメールでだけDMARCが失敗するのはなぜですか？
転送では、転送サーバーからメッセージが送り出されるため、SPFは許可していないIPに対して検査され、失敗するか、アライメントしなくなります。DKIMは、署名がメッセージの中に含まれて運ばれるため、通常は残ります。ただし、転送サービスやメーリングリストが署名済みの内容を編集した場合は壊れます。そのため、すべての送信元でDKIMをアライメントさせるべきです。転送サービスやリストによる小さな失敗が残るのは普通のことで、こちら側だけで完全に解決することはできません。
アライメントは、そのメールが確かに自分のものであることを受信側に伝えますが、その背後にあるリストについては何も語りません。すべての送信元が成功するようになったら、無料メールチェッカーで数件のアドレスを確認しましょう。1回に1アドレスずつ、構文、MXレコード、タイプミスをテストします。リスト全体には、無料プランの料金ページにある100クレジットで、フル検証を実行できます。完璧にアライメントしたドメインでも、受信トレイに届くには健全なリストが必要です。
