Defaults.Exposed › 修正 › Guides
SPF と DKIM は合格なのに DMARC が失敗する？アライメント修正（2026）
公開日 2026-07-08
データは 2026-06-29 時点 · メソドロジー v7。 261 百万採点済みドメインを対象とした集計センサスデータ。採点方法を参照。
DMARC は合格だけでなく、合格した SPF または DKIM のドメインが From ドメインと一致することを必要とする。「SPF 合格、DMARC 失敗」のほとんどは、ベンダーのバウンスドメインで SPF が合格しており、自ドメインではないことが原因だ。Defaults.Exposed センサス（2026-06-29）によると、採点済み 261,086,232 ドメインのうち、適用済み DMARC ポリシー下で SPF アライメント合格なのはわずか 7.4% だ。
修正は混乱が示すより早い。Authentication-Results ヘッダーを読み、どのレグ（SPF か DKIM か）が誤ったドメインで合格しているかを確認する；次に、送信サービスのカスタムドメイン DKIM 署名を有効にするか（通常は CNAME を数件追加するだけで、転送に耐える修正だ）、カスタム Return-Path を設定して SPF が自ドメインで合格するようにする。アライメントされたレグが1つあれば DMARC は十分だ。
SPF と DKIM の両方が合格しているのに DMARC が失敗するのはなぜか？
DMARC は「SPF は合格したか？」を問わないからだ。DMARC が問うのは：SPF または DKIM が、受信者が見る From アドレスと一致するドメインで合格したか？ この追加条件をアライメントと呼ぶ。これが DMARC の本質だ — なければ、誰でも自分が所有するドメインで SPF を合格させながら From ヘッダーに他人のドメインを表示できる。
各チェックが認証するドメインは異なる：
| チェック | 実際に評価するドメイン | 確認場所 |
|---|---|---|
| SPF | Return-Path（RFC5321.MailFrom、バウンス/エンベロープ From アドレス）— From ヘッダーではない | Authentication-Results の smtp.mailfrom= |
| DKIM | 署名の d= タグのドメイン — 署名者が選んだもの | Authentication-Results の header.d= |
| DMARC | From ヘッダーのドメイン — SPF のドメインまたは DKIM の d= がそれと一致することを要求する | Authentication-Results の header.from= |
通常の問題の起き方はこうだ：ニュースレタープラットフォームや CRM が [email protected] のような Return-Path でメールを送り、SPF は vendor.com に対してチェックされて合格し、DKIM は d=vendor.com で合格する — そして DMARC は失敗する。どちらの合格ドメインも yourcompany.com と一致しないからだ。各チェックは正直だったが、どれもあなたを認証していない。自分の SPF レコードを編集しても修正できない — そもそも参照されていなかったのだから。SaaS ツールで SPF が失敗するで説明している落とし穴と同じだ。
センサスが示す通り、この最後の一歩を完了する送信者は少ない：採点済み 261,086,232 ドメインのうち 27,640,987（10.59%）が適用済み DMARC ポリシーを持ち、アライメント付き SPF が合格しているのはそのうちの 7.4% のみだ。SPF の末尾が softfail（~all）の 77.5 百万ドメインのうち、適用済み DMARC ポリシー下にあるのはわずか 9.2%；hardfail（-all）の公開者では 12,142,351 が適用済みで 42,514,532 はそうでない。ほとんどのドメインは「SPF 合格」で止まる — しかしDMARC なしでは、それはほぼ何も守らない。
Authentication-Results を読んでどのレグがアライメントしていないか確認するには？
失敗しているサービス経由でテストメールを送り、生のソースを開いて Authentication-Results ヘッダーを探す。典型的なアライメントなしの結果はこう見える：
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=bounces.espmail.net;
dkim=pass header.d=espmail.net;
dmarc=fail (p=NONE) header.from=yourcompany.com
3つの比較で読む：
- SPF レグ：
smtp.mailfrom=が自ドメインで終わっているか？ここではbounces.espmail.net— アライメントなし。 - DKIM レグ：
header.d=が自ドメインで終わっているか？ここではespmail.net— アライメントなし。 - DMARC の判定：
header.from=が DMARC が守っているドメインだ。どちらのレグも一致しなかったためdmarc=fail— 個別のチェックは両方ともpassを示しているにもかかわらず。
すでに自ドメインが関与しているレグ（またはそうできるレグ）が修正対象だ。必要なのは1つだけだ。
リラックスと strict のアライメントの違いは？
DMARC は2つのマッチングモードを提供し、DMARC レコードの aspf（SPF）と adkim（DKIM）タグで設定する：
- リラックス（
r、デフォルト）： 2つのドメインが同じ組織ドメインを共有していればよい — Public Suffix List に基づく登録可能なドメイン。bounce.yourcompany.comはyourcompany.comとアライメントする；DKIM のd=mail.yourcompany.comも同様だ。これが、サブドメイン上に存在するベンダーのカスタム Return-Path とカスタム DKIM が機能する理由だ。 - Strict（
s）： ドメインは文字通り完全に一致しなければならない。bounce.yourcompany.comはもはやyourcompany.comとアライメントしない。
レコードに aspf や adkim の記載がなければリラックスモードだ — そしてほぼ確実にそのままにしておくべきだ。Strict モードはほとんどの送信者に意味のあるセキュリティ向上をもたらさず、設定したすべての正規サブドメイン送信者を静かに壊す。DMARC が失敗していてレコードに aspf=s または adkim=s が含まれている場合、それだけがバグの原因である可能性がある。
DMARC アライメントを修正するには？
- DNS を変更する前に defaults.exposed で無料スキャンを実行する。 DMARC レコードとポリシー、SPF と DKIM のアライメント設定状況、その他の問題点が確認できる — 正しいレグを最初に修正できる。
- 各送信サービスのテストを行い Authentication-Results を読む（上記の通り）。すべての送信元（メールボックスプロバイダー、ニュースレターツール、CRM、請求アプリ）をリストアップし、送信元ごとに
smtp.mailfromとheader.dが自ドメインかベンダーのドメインかをメモする。 - 各ベンダーのカスタムドメイン DKIM 署名を有効にする — 長持ちする修正だ。 すべての主要な送信サービスは「ドメイン認証」を提供している：
d=yourcompany.com（またはリラックスモードでアライメントするサブドメイン）で署名できるようにする CNAME レコードを数件追加するだけだ。アライメントされた DKIM は通常より簡単な修正であり、転送が SPF を壊すため、転送に耐えられる唯一の修正でもある。 - SPF アライメントには、ベンダーのカスタム Return-Path を有効にする（カスタムバウンスドメインとも呼ばれる）— 通常は
bounce.yourcompany.comがベンダーを指すような CNAME を1件追加するだけだ。SPF は自ドメインで合格してアライメントする。提供されている場所では実施するが、アライメント DKIM の代替ではなく第2のレグとして扱う。 aspf=s/adkim=sに明確な理由がない限り、アライメントはリラックスモードのままにする。- 再スキャンして両方のレグを確認し、適用に向けて進む。
p=noneの DMARC ポリシーはレポートするが何もブロックしない；実際の送信者がアライメントしたら、保護ポリシーへの完全な道筋は DMARC の修正ページにあり、IONOS の DMARCのようなプロバイダーごとの手順が DNS パネルの操作をカバーしている。
SPF アライメントと DKIM アライメント、どちらを修正すべきか？
送信元ごとにアライメントされたレグが1つ必要だ。1つしかできないなら、選択は明らかだ：
| 修正 | 内容 | 転送に耐えられるか？ |
|---|---|---|
| アライメント DKIM（カスタムドメイン署名） | ベンダーの「ドメイン認証」パネルで CNAME を数件追加 | はい — 署名はメッセージと共に移動する |
| アライメント SPF（カスタム Return-Path / バウンスドメイン） | ベンダーが提供している場合は CNAME を1件 | いいえ — 転送元のサーバー IP がベンダーの IP を置き換える |
知っておくべき特殊ケース：Google Workspace と Microsoft 365 は、デフォルトでそれぞれのフォールバックドメイン（gappssmtp.com、onmicrosoft.com）でメールを DKIM 署名する — そのため DKIM は pass を示しながら DMARC は失敗する。これはこの問題全体で最も一般的なケースであり、独自のガイドがある：DKIM は合格するが DMARC が失敗する：デフォルト署名の落とし穴。
よくある質問
DMARC が合格するには SPF と DKIM の両方がアライメントする必要があるか？ いいえ — アライメントされた合格が1つあれば十分だ。ただし転送で SPF レグが壊れたときに DKIM レグが DMARC の合格を維持できるよう、両方をアライメントするのがベストプラクティスだ。2026-06-29 センサスで採点された 261,086,232 ドメインのうち、SPF + DMARC + DKIM の完全なトライアドを完了しているのはわずか 3.87% だ。
ESP のダッシュボードが SPF と DKIM を「確認済み」と表示しているのに DMARC が失敗するのはなぜか？ 「確認済み」は通常、ベンダー自身の送信がベンダーのドメインで合格していることを意味する。ベンダーのカスタムドメインの手順（DKIM CNAME、カスタム Return-Path）を完了していない限り、メールはあなたとしてではなくベンダーとして認証される — DMARC は From ドメインと比較する。
strict な -all SPF レコードはアライメントなしで十分か？
いいえ。strict な修飾子は Return-Path ドメインへの SPF の判定を強化するが、DMARC はそのドメインが自分のものであることを引き続き必要とする。2026-06-29 センサス時点で、-all を公開しているドメインのうち適用済み DMARC ポリシー下にあるのは 12,142,351 のみ — 残り 42,514,532 は何もポリシーが作用しない strict なレコードを持っている。
より多くのセキュリティのために strict アライメント（aspf=s/adkim=s）に切り替えるべきか？
ほぼ常に不要だ。リラックスアライメントはすでに同じ登録可能ドメインを要求しており、なりすまし攻撃者はそれを制御できない。Strict モードは主に自分のサブドメイン送信者を壊す — アライメントが予期せず失敗するときは必ず確認する。
転送したメールだけ DMARC が失敗する — 同じ修正か？ それは転送中に SPF レグが死ぬケースだ：転送元サーバーが Return-Path の SPF レコードに含まれていない。転送されたメールの SPF は修正できない；アライメントされた DKIM が答えだ。署名は転送後も無傷で残る。詳細は転送メールが SPF に失敗するを参照。
オーナーにレポートを送る
クライアントや雇用主のためにこれを修正している場合、証拠で締めくくる。CNAME が反映されたら無料スキャンを再実行し、採点レポートをビジネスオーナーに転送する：日付入りで平易な言葉で、SPF、DKIM、DMARC がアライメントして合格していることを示す。それがサイバー保険更新や次の取引先セキュリティアンケートに必要な成果物だ — 「DNS レコードを追加した」というだけでなく、機能している設定の証明だ。
ドメインをチェックする → · DKIM は合格するが DMARC が失敗する → · DMARC を修正する → · 採点方法 → · 集計データのみ使用。データは EU 内で保存・処理。