ガイド認証

SPFとDKIMがpassなのにDMARCがfailになるとき

2つのチェックはどちらもpass（合格）なのに、DMARCはfail（不合格）になる。原因は、Fromアドレス（差出人アドレス）と一致していないドメインです。テストメールを1通送れば、どのドメインかが分かります。直すには、そのメールを送信している側の設定を変えます。

最終更新：2026年10月5日読了目安：9分

要点

DMARCがpassになるのは、SPFまたはDKIMが、Fromアドレスのドメインについてpassした場合だけです。事業者のドメインについてのpassは数に入りません。
送信したメッセージをGmailのShow original（メッセージのソースを表示）で開き、Authentication-Resultsヘッダーのsmtp.mailfrom、header.i、header.fromを見比べます。
まずDKIMを直します。あなたの代わりに送信するすべてのサービスで、自分のドメインによる署名を有効にしてください。DKIM署名は転送されても残りますが、SPFは残りません。
サブドメインは、既定では一致しているとみなされます。DMARCレコードにadkim=sやaspf=sがあると、一致とはみなされません。
ウォームアップでは、アライメント（ドメインの一致）は直りません。ウォームアップメールはあなたのメールボックスを通して送信されるので、同じようにfailします。

DMARCが見るのは、SPFとDKIMがpass（合格）したかどうかではありません。どちらかがFromアドレス（差出人アドレス）のドメインについてpassしたかどうかです。SPFが事業者のバウンス用ドメインについてpassし、DKIMが事業者の署名ドメインについてpassした場合、どちらの行にも「pass」と出るのに、DMARCは「fail」（不合格）になります。直す場所は送信元です。自分のドメインで署名させるか、自分のドメインのバウンスアドレスを使います。どちらか一方で足ります。

この一致を指す用語が、アライメント（ドメインの一致）です。DMARCのうち、DNSのチェックツールでは見えない部分です。メールのアライメントが取れているかどうかは、実際に送信されたメッセージでしか分かりません。このページでは、その読み方を説明します。

どのメールにも3つのドメインが付いている

メールには、最大で3か所にドメインが入っています。それぞれのチェックは、別々の場所を見ます。

封筒の紋章が入った紺色の旗、真鍮の札が付いた郵便袋、封蝋のある手紙が、岸壁に並んでいる。封蝋には旗と同じ紋章があり、札にはない — 旗はFrom欄、郵便袋の札はReturn-Path、封蝋はDKIM署名です。DMARCは、札か封蝋のどちらかが旗と一致することを求めます。

場所	別の呼び方	ここを見るチェック
読み手に見えるFrom欄	ヘッダーFrom、`header.from`	DMARC。ほかの2つを測る基準になります。
Return-Path	エンベロープ送信者、MAIL FROM、バウンスアドレス、`smtp.mailfrom`	SPF。送信サーバーがこのドメインを使ってよいかを確認します。
DKIM-Signatureヘッダーの`d=`の値	署名ドメイン、`header.d`または`header.i`	DKIM。このドメインの署名が有効かを確認します。

SPF（RFC 7208）とDKIM（RFC 6376）は、それぞれ狭い問いに答えるもので、どちらの問いにもFrom欄は出てきません。メールマガジン配信サービスは、自社のバウンス用ドメインについてSPFをpassし、自社の鍵で署名できます。それでもメッセージは、あなたから届いたものだと名乗れます。DMARCはこの隙間をふさぎます。2026年5月からDMARCの標準規格となっているRFC 9989は、結果の裏にあるドメインがFromドメインと一致する場合にだけ、その結果を受け入れます。DKIMについての理由は、次の1文で示されています。

DMARCは、DKIMで認証された識別子に識別子アライメントを適用することを求めます。メッセージには、悪意のある者が使うドメインも含め、どのドメインの有効な署名でも付けられるからです。

SPFにも同じことが言えます。自分が所有するドメインのSPFレコードは、誰でも公開できるからです。したがって、ルールはこうなります。SPFがpassし、かつそのドメインのアライメントが取れているか、DKIMがpassし、かつそのドメインのアライメントが取れていれば、DMARCはpassします。

実際のメッセージ1通で不一致を見つける

必要なのは、普段のメールと同じ方法で送ったメール1通と、それを受け取るGmailアドレスです。

問題のメールボックスまたはツールから、自分で開けるGmailアドレスにメッセージを送ります。
パソコンのGmailでそのメッセージを開きます。Reply（返信）の横にあるMore（その他）をクリックし、Show original（メッセージのソースを表示）を選びます。Googleも完全なヘッダーでメールを追跡するのページで、同じ手順を説明しています。
Authentication-Resultsヘッダーを探します。受信側のサーバーが、チェックの結果を書き込むヘッダーです（RFC 8601）。次の3つの値を見比べます。smtp.mailfrom=の後のドメイン、header.i=@の後のドメイン（header.d=と書く受信側もあります）、header.from=の後のドメインです。この行の読み方は、メールヘッダーの読み方で順を追って説明しています。

次は、SPFとDKIMはpassし、DMARCはfailするメッセージの典型例です。ヘッダーは一部を省略し、例示用のドメインを使っています。

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

下から読みます。Fromドメインはexample.comです。SPFはpassしましたが、対象はsend.vendor-mail.exampleです。DKIMもpassしましたが、署名はvendor-mail.exampleのものです。どちらもexample.comではないので、From欄の名前を保証するものが何もありません。

サービス側で、自分のドメインで署名するように設定すると、同じメッセージは次のようになります。

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPFは今も提供元のドメインを指しています。それでかまいません。DKIMが一致するようになりました。DMARCに必要なのは、アライメントの取れたpassが1つだけです。

どこまで一致していればよいか：relaxedとstrict

2つのドメインは、完全に同じである必要はありません。既定では、アライメントはrelaxed（緩やかな一致）です。両方が同じ登録ドメインに属していれば足ります。標準規格は、これを組織ドメインと呼んでいます。strict（厳密な一致）では、完全に一致していることが求められます。どちらにするかは、DMARCレコードのタグで選びます。DKIMはadkim、SPFはaspfです。

SPFまたはDKIMがpassしたドメイン	Fromドメイン	relaxed（既定）	strict
`example.com`	`example.com`	一致	一致
`mail.example.com`	`example.com`	一致	不一致
`example.com`	`news.example.com`	一致	不一致
`vendor-mail.example`	`example.com`	不一致	不一致

標準規格は、「ほぼすべてのドメイン所有者が、relaxedのアライメントで自らのニーズを十分に満たせると判断しています」と述べています。それでも、自分のレコードは確認してください。GoogleのDMARCを設定するページの冒頭にあるレコード例は、adkim=s; aspf=sで終わっています。そこからコピーしたレコードはstrictになります。自分のレコードにこの2つのタグがあり、サブドメインから送信するツールがある場合は、タグを削除してください。Google自身もそのページで、strictのアライメントでは「関連するサブドメインからのメッセージが拒否されたり、迷惑メールに振り分けられたりする可能性があります」と注意しています。

不一致のよくある原因

自社のサーバーから送信するサービス

メールマガジン配信サービス、CRM、請求書ツール、ヘルプデスクは、自社のインフラからあなたのメールを送信します。あなたがドメインを接続するまでは、たいてい自社ドメインのバウンスアドレスを使い、自社の鍵で署名します。この場合にSPFのアライメントがめったに取れない理由を、Amazonのドキュメントは率直に述べています。Return-Pathは「プロバイダー（SES）が、自らが所有するアドレスを使って追跡するバウンスと苦情に使われる」からです（Amazon SES）。これを直す設定の名前はサービスごとに違いますが、最後は、あなたの側でDNSレコードをいくつか追加することになります。

サービス	ドメインを接続する前	探す設定
Twilio SendGrid	メールは「via sendgrid.net」（sendgrid.net経由）で送信されたと表示されます。	Domain authentication（ドメイン認証）：バウンス用サブドメインと2つのDKIM鍵のためのCNAMEレコード。
Amazon SES	Return-Pathは`amazonses.com`のサブドメインです。	署名にはEasy DKIM、SPFにはカスタムMAIL FROMドメイン。
Mailchimp	ドメインは確認済みですが、認証されていません。	Email domain authentication（メールドメイン認証）：DKIM用のCNAMEレコード2つ。

これらは、2026年10月時点での各社自身の説明です。ほかのサービスも同じような仕組みです。各社のヘルプで「authenticate domain」「custom DKIM」「branded sending domain」を検索してください。

メール事業者が自社ドメインで署名している、またはまったく署名していない

独自ドメインのメールボックスでは、Return-Pathは通常あなた自身のアドレスです。そのため、SPFレコードにメール事業者が含まれていれば、SPFのアライメントは取れます。smtp.mailfrom=の後の値で確認できます。切り替えが必要なのはDKIMのほうです。

Google Workspace。あなたが自分のドメインのDKIMを有効にするまで、Googleはこれまで自社のドメインの1つで署名してきました。Googleのヘルプページの以前の版には、その場合Gmailは「次の既定のDKIMドメイン鍵で署名します：d=*.gappssmtp.com」とありました。現在のページにはこのドメイン名がないので、自分のヘッダーで確認してください。header.iがgappssmtp.comで終わっていれば、あなたの鍵は有効になっていません。管理コンソールでApps（アプリ）、Google Workspace、Gmail、Authenticate email（メールの認証）の順に進んで鍵を生成し、表示されたTXTレコードを追加してから、Start authentication（認証を開始）をクリックします（DKIMを設定する）。
Microsoft 365。2026年8月に更新されたMicrosoftのドキュメントには、「現在、カスタムドメインからの送信メールにはDKIM署名が行われません」とあります。CNAMEレコードを2つ公開し、Defenderポータルで署名を有効にします（カスタムドメインのメールにDKIMを使用する方法）。

DKIM鍵のために追加するレコードは、必ず_domainkeyの下に、メール事業者が決めた名前で置かれます。Google Workspaceの場合は次のようになります。鍵は途中で省略してあります。

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

あなたのメールボックスに接続し、そこを通して送信するツールは、独自の署名を付けません。そうしたツールからのメールは、あなたが手で書いたメールとまったく同じに見えます。したがって、直す場所はメール事業者であり、ツールではありません。

メッセージが転送された

受信者があなたのメールを自動転送すると、メールは、あなたのSPFレコードに載っていないサーバーから届きます。SPFはfailするか、転送した側のドメインについてpassします。DKIM署名は、誰もメッセージを変更しない限り、転送されても残ります。フッターや件名のタグを付け足すメーリングリストは、署名も壊します。これは、あなたの側では直せません。Googleの送信者向けFAQは、Gmailでは「転送されたメッセージやメーリングリストのメッセージには、DMARCアライメントは必須ではありません」としています。SPFだけに頼らず、DKIMのアライメントを取っておくべき理由はここにあります。

封をした手紙が、郵便船から別の郵便船へ渡される。どちらの船にも専用の郵便袋と札があり、手紙の封蝋は破れていない — 転送では、郵便袋と札が入れ替わります。手紙の封蝋はそのまま残ります。

そもそも自分のメールではない

DMARCレポートに、一度も使ったことのないサーバーからのfailが出ている場合、誰かがあなたのアドレスで送信している可能性があります。そうしたメッセージは、failするのが正しい動きです。直すものは何もありません。後でポリシーを厳しくするときの根拠になります。

まずDKIM、次にSPFを直す

どちらを直してもpassになります。どちらかを選ぶなら、DKIMのほうが有利です。メッセージと一緒に運ばれるからです。M3AAWGのベストプラクティスは、これをルールとして示しています。「すべての送信メールに、RFC5322.Fromヘッダーのドメインとアライメントの取れたDKIM鍵で署名すること。」RFC 9989は、両方を使うことを推奨しています。

自分のドメインで送信しているものを、すべて書き出します。メールボックス、メールマガジン配信ツール、CRM、請求書、サイトの問い合わせフォームなどです。忘れていたものは、DMARCレポートに出てきます。
1つずつテストします。上のヘッダーの確認方法を使い、2つのドメインのどちらが自分のものでないかを書き留めます。
自分のドメインによる署名を有効にします。header.iに別の名前が出ているものすべてが対象です。サービスから示されたレコードを公開してください。DNSを管理しているサービスが対応していれば、2048ビットの鍵を選びます。Gmailは1024ビット以上を必須とし、2048ビットを推奨しています。
カスタムのバウンス用ドメインを設定します。サービスが対応している場合に、bounce.example.comのようなサブドメインで設定します。これでSPFのアライメントも取れます。
もう一度テストを送ります。dmarc=passになっているか確認してください。DNSの変更は、反映に時間がかかることがあります。Googleは、新しいDKIM鍵が動作し始めるまでに最大48時間を見込んでいます。

うまくいかないのは、提供元を自分のレコードに追加する方法です。SPFレコードに提供元のinclude:を入れても、Return-Pathが提供元のドメインにあるなら何も変わりません。SPFが調べるのはそのドメインのレコードであり、あなたのレコードではないからです。DMARCレコードに、信頼する第三者を列挙することもできません。標準規格は、そのための「一般に受け入れられた仕組みはない」としています。

ヘッダーにdmarc=passと出ているのに、メッセージがまだ迷惑メールに入る場合、原因はもう認証ではありません。その続きは、SPF・DKIM・DMARCがpassなのに迷惑メールに入るときで扱っています。

ポリシーがp=noneの間、DMARCのfailで失うもの

p=noneは、failしても何もしないよう受信側に求めるものです。そのため、あなたのポリシーが原因で拒否されるメールはありません。それでも、2つの点で不利に働きます。

大量送信者向けのルール。Gmail、Yahoo、Outlook.comは、大量送信者にアライメントの取れたメールを求めています。GmailとOutlook.comでは、1日5,000通以上が対象です。Googleの送信者向けFAQは、Fromヘッダーが「認証されたSPFまたはDKIMの組織ドメインのどちらともアライメントが取れていない」メールに対する一時的なエラー4.7.32を挙げ、その結果として「一時的または恒久的なエラーコード、あるいは迷惑メールフォルダへの振り分け」を示しています。
次の段階に進めなくなります。p=quarantineやp=rejectに移ったとたん、アライメントの取れていない自分のメッセージはすべて、迷惑メールとして扱われるか、拒否される対象になります。Gmailでは、バウンスメールに「Unauthenticated email from domain-name is not accepted due to domain's DMARC policy」（domain-nameからの未認証メールは、ドメインのDMARCポリシーにより受け付けられません）と書かれます。エラーは5.7.26です（DMARCの問題のトラブルシューティング）。

DMARCレコードがまったくない場合は、追加するレコードから始めてください。レコードを追加するとレポートも届くようになり、すべての送信元のアライメントを一度に確認できます。

ここでウォームアップにできること、できないこと

ウォームアップでアライメントは直りません。WarmupBayはあなたのメールボックスに接続し、そこから送信します。そのため、ウォームアップメールは、あなたが自分で書くメールとまったく同じように、あなたのメール事業者によって送信され、署名されます。メールボックスがDMARCにfailするなら、ウォームアップメールも同じようにfailします。先にレコードを直してください。

WarmupBayが役に立つのは、その前と後です。メールボックスを接続すると、そのドメインのSPF・DKIM・DMARCを確認し、72時間たってもレコードがない場合はウォームアップを停止します。レコードが整うと、あなたのメールボックスは共有プール内の他のメールボックスと1日に数通のメールを交換し、ダッシュボードに届き先が表示されます。受信トレイ、Gmailタブ、迷惑メールのどれに届いたかを、Googleとその他の事業者に分けて確認できます。メールマガジン配信ツールやCRMからのメールはテストしません。それらは、あなたのメールボックスを通らないからです。また、Microsoft 365とOutlook.comのメールボックスは、まだ接続できません。毎日10通のウォームアップメールまで無料です。ヘッダーにdmarc=passと出たら、メールボックスを接続してください。

よくある質問

SPFはpassしてアライメントも取れていますが、DKIMのアライメントが取れていません。これで十分ですか？

DMARCとしては十分です。アライメントの取れたpassが1つあれば足ります。ただし、受信者があなたのメールを転送すると足りなくなります。転送後はSPFが一致しなくなるからです。またGoogleは送信者向けFAQで、SPFとDKIMの両方でのアライメントが今後おそらく要件になると書いています。いずれにしても、自分のドメインでDKIMを設定しておきましょう。

DMARCが、ある受信者ではfailし、別の受信者ではpassするのはなぜですか？

メールが届くまでの経路や、送信元が違うからです。別のメールボックスに転送している受信者やメーリングリストがあると、SPFから見える内容が変わり、場合によってはDKIMから見える内容も変わります。複数ある送信サービスのうち、まだ設定していないものが原因のこともあります。集計レポートは結果を送信サーバーごとに並べるので、どのケースかが分かります。

Reply-ToアドレスはDMARCに関係しますか？

いいえ。DMARCが使うのは、Fromヘッダーのドメインだけです。Reply-Toアドレス、表示名、Senderヘッダーはチェックの対象外です。

ヘッダーを開かずにアライメントの問題を見つけるには、どうすればよいですか？

DMARCの集計レポートで確認できます。各recordにはpolicy_evaluatedブロックがあり、dkimとspfの結果が入っています。これはアライメントの判定を経た後の結果です。その下のauth_resultsブロックには、判定前の結果と、その対象になったドメインが入っています。判定前はpassで、判定後はfailという組み合わせが、まさにこのページで扱っているケースです。レポートは、DMARCレコードにruaアドレスを追加すると届きます。

ヘッダーにdkim=failやdkim=neutralとあります。同じ問題ですか？

いいえ。その場合は署名そのものが検証できておらず、別の不具合です。body hash did not verify（本文のハッシュを検証できませんでした）と書かれている場合、原因はGoogleのトラブルシューティングのページに示されています。署名の後でメッセージが変更されたのです。たとえば、フッターを付け足すゲートウェイが原因になります。アライメントが扱うのは、署名は有効だが別のドメインのものである、というケースです。

自分の代わりに送信するサービスごとに、別々のDKIM鍵が必要ですか？

実際にはそうなります。各サービスは自前の鍵で署名し、その鍵を、あなたのドメインの_domainkeyの下に、サービスごとのセレクタ名で公開します。そのため、複数の鍵が衝突せずに並びます。この点は、1つのドメインに1つのレコードしか持てないSPFとは違います。