この記事の結論
DMARC failは、SPFとDKIMのどちらも「通って、Fromのドメインと一致する」状態にならないと出ます。Google Workspaceで送るメールなら、SPFに_spf.google.comを足し、DKIMを自社ドメイン名義で発行し、DMARCはp=noneのままレポートを受け取る形から直します。
目次8項目
DMARC fail の原因は、僕の会社では Google Workspace の送信元が SPF に無く、DKIM の署名も自社ドメイン名義でないことでした。2026年10月4日に、実メールのヘッダーと dig で確かめました。直すのは DNS の3か所と、DKIM の発行です。
ヘッダーの読み方、dig での確かめ方、フォームを別のサーバーから送っている会社の直し方の順に書きます。手順はまとめ終えた段階で、実施はまだ承認待ちです。
DMARC fail の原因：SPF softfail と、自社名義でない DKIM が重なっている
DMARC が fail になるのは、SPF と DKIM のどちらも「通って、しかも From のドメインと一致する」状態にならないときです。片方でも一致して通れば、DMARC は pass します。
ここでいう DMARC とは、SPF と DKIM の結果を From のドメインと照らし合わせ、だめなメールの扱いを受信側に伝える仕組みです。この照らし合わせをアライメントと呼び、既定はゆるめの判定です。
受信側のヘッダーでは、次のような結果として出ます。僕の会社で社員のメールに出ていたのも、この組み合わせでした。
spf=softfail
dkim=pass
dmarc=failSPF softfail とは、送ってきたサーバーが SPF の一覧に無く、「おそらく許可されていない」という弱い失敗の判定です。SPF の末尾を ~all にしているときに出ます。
dkim=pass でも安心はできません。僕の会社のヘッダーのように、署名が Google の既定のドメイン名義（gappssmtp.com 系）だと、From の自社ドメインと一致せず、DMARC の判定には効きません。
原因になりうる形を、ヘッダーの出方と直し方で並べます。
| ヘッダーの出方 | 原因 | 直し方 |
|---|---|---|
spf=softfail・dkim=pass（Google の既定名義）・dmarc=fail | SPF に Google が無く、DKIM が自社名義でない | SPF に include:_spf.google.com を足し、DKIM を自社名義で発行 |
spf=permerror | SPF のレコードが2本ある／DNS の参照が10回を超えた | 1本にまとめる・include を減らす |
フォームのメールだけ dmarc=fail | フォームを置いたサーバーが SPF に無い | そのサーバーを SPF に足すか、差出人と送り方をそろえる |
僕の会社は1行目でした。僕なら、まずヘッダーを1通見て、どの行に当たるかを決めてから DNS を開きます。
ヘッダーと dig で DMARC fail を確かめる手順
確かめるのは、届いたメールのヘッダーと、DNS に今入っている値の2つです。ヘッダーで結果を、dig で原因を見る、という分担で考えています。
- 社外のアドレスへテスト送信して、ヘッダーを開く。 パソコンの Gmail なら、返信アイコンの横の「その他」から「メッセージのソースを表示」で見られます。
- 認証結果の行で
spf=・dkim=・dmarc=を読む。 結果はAuthentication-Resultsの行に並びます。dkim=passなら、header.i=やd=のドメインが自社のものかも見ます。 - dig で SPF を見る。
v=spf1で始まる行が1本だけか、送っているサーバーが入っているかを確かめます。 - dig で DMARC と DKIM を見る。
_dmarcで今のポリシーを、google._domainkeyで Google 用の DKIM の鍵があるかを見ます。 - 送信経路ごとに1通ずつ見る。 社員が普段送るメールと、フォーム・通知のメールは、送っているサーバーが違うことがあります。
使うコマンドは次の3つです。example.com を自社のドメインに置き換えます。
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT google._domainkey.example.comgoogle._domainkey の google は、Google Workspace の管理コンソールで DKIM を作るときの既定のプレフィックスです。別の値で作った場合は、そちらに読み替えます。
SPF の参照回数も数えておきます。include など DNS を引く項目は仕様（RFC 7208）で10回までで、超えると permerror になります。
DMARC 設定の直し方：送信経路が2つある会社は DNS 3か所＋DKIM の発行
社員のメールは Google、フォームはレンタルサーバー、という会社では、片方の経路を消さずに Google の分を足します。DNS は書き換え2か所・追加1か所です。
- SPF の1本を書き換える（2本目を足さない）。 今ある行に
include:_spf.google.comを書き足します。レンタルサーバーの分は残し、~allもそのままにします。
変更前: v=spf1 include:<レンタルサーバーのSPF> ~all
変更後: v=spf1 include:_spf.google.com include:<レンタルサーバーのSPF> ~all- 管理コンソールで DKIM の鍵を作る。 「アプリ」→「Google Workspace」→「Gmail」→「メールの認証」で、鍵は2048ビット、プレフィックスは既定の
googleにします。「認証を開始」はまだ押しません。 - DNS に DKIM の TXT を1本足す。 ホスト名は
google._domainkey、値は管理コンソールに出たものをそのまま貼ります。 - dig で反映を確かめてから「認証を開始」を押す。 公式のヘルプでは、鍵を足してから機能するまで最長48時間ほどかかることがあります。
- DMARC は
p=noneのまま、rua を足す。 rua は、受信側から届く集計レポートの送り先です。
変更前: v=DMARC1; p=none;
変更後: v=DMARC1; p=none; rua=mailto:xxx@<domain>- テスト送信でヘッダーを見直す。 目標は
spf=pass・dkim=pass（自社ドメイン名義）・dmarc=passです。フォームのメールがspf=passのままかも、翌日に確かめます。
Google の DMARC の手順は、SPF や DKIM の設定から DMARC まで48時間空けるよう書いています。僕の手順書はポリシーを変えず rua を足すだけなので、3か所を同じ日に触る段取りです。
公式の48時間に合わせたいなら、DMARC の書き換えだけを後日に回します。どちらにしても、SPF を2本にしないことが一番の注意点です。
裏方で実際に起きた例：2026年10月4日、社員のメールだけ DMARC fail だった
ここからは、僕の会社の2026年10月4日の調査メモ（メール認証の手順書）からの転記です。ドメイン名・アドレス・サーバー名は伏せています。
見つけたのは、別の作業で同じ DNS の画面を使う準備をしていた途中でした。調査は別の作業に切り分け、dig とヘッダーの確認は AI（Claude Code）に手伝わせています。
社員が Google Workspace から送ったメールは、9月末の実メールで spf=softfail・dmarc=fail でした。DKIM は通っていても、署名は Google の既定の名義だけです。
一方、レンタルサーバーの PHP から送るフォームと通知のメールは、10月4日の実メールで spf=pass・dmarc=pass でした。こちらは DKIM の署名が無く、SPF の一致だけで通っています。この通知メールを使う仕組みは Claude Code の通知を受け取る3つの方法 に書きました。
| 送信経路 | spf | dkim | dmarc |
|---|---|---|---|
| Google Workspace（社員のメール） | softfail | pass（Google の既定名義） | fail |
| レンタルサーバーの PHP（フォーム・通知） | pass | 署名なし | pass |
同じドメインでも、経路によって結果が逆でした。僕は、片方の経路だけを見て「認証は大丈夫」とは決めませんでした。手順書にも、実施した翌日にフォームのメールをもう一度見る段取りを入れています。
dig で見た SPF にはレンタルサーバーの分だけが入っていて、Google がありませんでした。DMARC は p=none だけで、集計レポートの送り先（rua）がありません。
SPF の DNS 参照回数は、その時点で5回でした。Google の分を足すと6回で、上限の10回までは余裕があります。
それでも届いていたのは、DMARC が p=none、SPF が ~all のゆるい設定だったからです。Gmail を検索した限り、過去1年に認証が原因で戻ったメールは0件でした。
急ぎではないと判断した一方で、迷惑メールに振り分けられる危険はずっと抱えています。請求書や提案書が届くかどうかに直結するので、直す手順を先にまとめました。
見込みは、僕の手で約20分です。管理コンソールで約5分、DNS の3か所で約10分、残りが確認で、別に DKIM の反映待ちが数十分〜最大48時間あります。
この記事を書いた時点で、手順は承認待ちで、まだ実施していません。実施したら、ヘッダーの結果をこの記事に追記します。
DMARC 設定は p=none から：2〜4週間レポートを見てから quarantine へ
再発を防ぐには、自社のドメインを名乗って送っているサーバーを、まず全部つかみます。rua で届く集計レポートは、そのための材料になります。
Google の手順も、p=none で始めて quarantine、次に reject へ段階的に上げる形を勧めています。僕の会社では、レポートを2〜4週間見てから quarantine へ上げる予定です。
上げる条件は、レポートに出る送信元がすべて pass していることです。把握していなかった送信元が見つかれば、先にそちらを直します。
いきなり p=reject にはしません。設定の漏れた送信元があると、そのメールが受け取りを拒まれるからです。
戻し方も先に決めておきます。SPF と DMARC は前の値に書き戻すだけです。DKIM は管理コンソールで認証を止めてから、DNS の値を消します。
業務で使うときの注意：フォームの差出人・SPF の ~all・rua の受け口
フォームの差出人を確かめる。 僕の会社には、差出人を個人のアドレスにしたフォームがあり、設置先を記録から特定できていません。
別のサーバーに置いていれば、そのメールは今も SPF が通っていない可能性があります。フォームや通知の差出人は、個人の受信箱と混ざらない共用のアドレスにそろえる方が筋がよいと考えています。
フォームの PHP そのものが動いているかは、開くだけ・空で送る・正しく送るの3つで確かめます。手順は .htaccess の SetHandler で PHP のソースが表示される原因 にまとめました。
SPF は ~all のままにする。 -all にすると、把握できていない送信元のメールが止まるおそれがあります。レポートで全部見えてから考えます。
rua の受け口は専用にする。 DNS に書いたアドレスは誰でも見られます。Google のヘルプも、個人のアドレスではなく専用のメールボックスやグループを勧めています。
ほかの DNS のレコードに触らない。 同じ画面に、サイトの A レコードや MX、既存の DKIM の鍵が並んでいます。直すのは SPF・DKIM・DMARC の3か所だけです。
送る量が多いなら要件が重くなる。 Gmail の送信者のガイドラインは、2024年2月から、すべての送信者に SPF か DKIM の設定を求めています。
1日5,000通以上を送るなら、SPF・DKIM・DMARC の全部と、From のドメインの一致が要ります。メルマガを自社ドメインで送る会社は、こちらの条件で見直します。
「DMARC fail と出ているけれど、どこから送ったメールか分からない」というときは、下のフォームからご相談ください。ヘッダーの読み方から一緒に見ます。
まとめ
- DMARC fail は、SPF と DKIM のどちらも From のドメインと一致して通っていないときに出る
- Google Workspace のメールなら、SPF に
include:_spf.google.comが無いとspf=softfail、自社の DKIM が無い僕の会社のメールには Google の既定名義の署名だけが付いていた - SPF は1本のまま書き換え、レンタルサーバーなど今使っている送信元を残す
- DMARC は
p=noneに rua を足して、レポートを見てから段階的に上げる - 僕なら、最初に社員のメールとフォームのメールを1通ずつヘッダーで見て、どの経路が落ちているかを決めてから DNS を触ります
よくある質問
DMARC fail でもメールは届きますか？
DMARC が p=none なら、受信側に特別な扱いを求めない設定なので、それだけで受け取りを拒まれるわけではありません。僕の会社でも過去1年、認証が原因で戻ったメールは0件でした。ただ迷惑メールに入る危険は残るので、SPF か DKIM を自社名義で通す形に直しておくのが安全です。
SPF に Google を足すとき、レコードを2本にしてもいいですか？
いけません。SPF の仕様（RFC 7208）では、v=spf1 で始まるレコードが2本あると permerror になり、どちらも効かなくなります。今ある1本の中に include:_spf.google.com を書き足し、1本のまま書き換えます。
DKIM が pass なのに DMARC が fail になるのはなぜですか？
DKIM の署名のドメインが、From のドメインと一致していないからです。僕の会社では、自社の DKIM をまだ発行していない段階のメールに、Google の既定のドメイン名義の署名だけが付いていました。管理コンソールで自社ドメインの鍵を作り、DNS に入れて認証を開始すると一致する形になります。