Google WorkspaceのSPF・DKIM・DMARC設定手順｜実際に詰まった4箇所も全部書く

自分の名前を騙るメールが届いたのをきっかけに、自社ドメインのメール認証を点検しました。結果、想定より悪い状態でした。SPFは設定されていたものの中身が間違っており、自社から送る正規のメールが認証を通っていませんでした。

この記事では、SPF・DKIM・DMARCを半日で整えるまでの手順と、実際に詰まった4箇所を書きます。管理画面の場所からコマンドまで、そのまま辿れる形で残します。

きっかけは、自分の名前を騙るメールだった

受信箱に届いたメールの差出人は、表示名が私の名前になっていました。しかし実際のアドレスは、まったく無関係なGmailアカウントです。

本文の指示はこうでした。「業務で使うのでLINEグループを作ってほしい」「LINE WORKSではなく通常のLINEで」「まずは一人だけで作って」「完成したら招待用のQRコードをこのメールに返信して」。

指示の一つひとつに意味があります。通常のLINEを指定するのは会社の管理下・監査ログの外へ誘導するため。一人だけで作らせるのは他の人の目に触れさせないため。QRコードを返信させるのは犯人がグループに入り込むため。潜り込んだあと、経営者を装って送金指示を出す——ビジネスメール詐欺の典型的な入口です。

調べると、10日前にも同じ差出人から、件名と文面を少し変えたものが届いていました。一度きりではなく、継続して狙われています。

そこで自社ドメインのメール認証を確認したところ、SPFにGoogleが含まれていませんでした。メールはGoogle Workspaceから送っているので、これでは自社の正規メールがSPFを通りません。なりすまし対策以前に、自分のメールが迷惑メール判定されやすい状態でした。DKIMとDMARCは、どちらも未設定でした。

最初に：作業する場所は3つに分かれる

この手の作業でいちばん詰まるのは「いま、どこで操作しているのか」が分からなくなることです。先に整理しておきます。

場所	何をするか
DNS管理画面	SPF・DMARC・DKIMのTXTレコードを登録する。ドメインを買った会社とは限りません
Google管理コンソール	DKIMの鍵を生成し、認証を開始する
確認コマンド	設定が本当に効いているかを確かめる

私の場合、ドメインはお名前.com、DNSはレンタルサーバー会社、メールはGoogle Workspaceと3社に分かれていました。ドメインを買った会社の管理画面でTXTレコードを設定しても、まったく反映されません。

DNSの管理場所を調べる

ネームサーバーを引けば分かります。ここに出てくる会社の管理画面が、レコードの編集場所です。

dig +short NS example.com

クライアントのドメインを調べたときは、ドメイン会社でもサーバー会社でもない、まったく別のDNSサービスを向いていたこともあります。思い込みで管理画面を開くと時間を無駄にします。

用語は3つだけ

SPF … このドメインのメールはどのサーバーから送ってよいかの宣言
DKIM … メールに付ける電子署名。改ざんされていないこと、正規の送信元であることを証明する
DMARC … 認証を通らなかったメールをどう扱うかの指示。あわせて「誰があなたのドメインを騙ったか」のレポートが届く

SPFとDKIMが「証明する仕組み」、DMARCが「証明できなかったときの扱いを決める仕組み」です。DMARCだけ入れても意味がなく、SPFとDKIMが揃って初めて機能します。

手順0【確認コマンド】現状を調べる

まず自分のドメインがどうなっているかを見ます。3本だけです。

# SPF
dig +short TXT example.com | grep spf1

# DKIM（Google Workspaceの場合）
dig +short TXT google._domainkey.example.com

# DMARC
dig +short TXT _dmarc.example.com

何も返ってこなければ、その項目は未設定です。

手順1【DNS管理画面】SPFを直す

Google Workspaceを使っているのにSPFにGoogleが入っていない、というのはよくあるパターンです。レンタルサーバー契約時に自動生成されたSPFが残り、あとからGoogleに移行したときに更新されていない、という経緯で起こります。

# 変更前（Googleが入っていない）
v=spf1 +a:sv3085.example.ne.jp +a:example.com +mx include:spf.sender.xserver.jp ~all

先頭に include:_spf.google.com を足すだけで直ります。既存の記述は消しません。サーバー経由で送るメール（フォームの通知など）の経路を残したまま、Gmailからの送信を正規と認めさせます。

# 変更後
v=spf1 include:_spf.google.com +a:sv3085.example.ne.jp +a:example.com +mx include:spf.sender.xserver.jp ~all

SPFには2つの落とし穴がある

落とし穴1：SPFレコードは1ドメインに1本だけです。2本になると両方とも無効になります。既存を編集してください。新規追加してはいけません。

落とし穴2：DNSルックアップの上限は10回です。超えるとPermErrorになり、SPFが機能しなくなります。include: a: mx がそれぞれ1回、include の先にさらに include があればその分も加算されます。

私のレコードは実測7回で、上限に余裕がありました。数え方はこうです。

記述	回数	備考
include:_spf.google.com	1	Googleは現在フラット化されており、この先に include はない
+a:sv3085.example.ne.jp	1
+a:example.com	1
+mx	1
include:spf.sender.xserver.jp	1	この先に include が2本あり、それぞれ加算
└ 上記の配下 ×2	2
合計	7	上限10に対して余裕あり

なお、ネット上には「_spf.google.com は内部で3本のincludeを持つので4回消費する」という記述が残っています。しかし現在のGoogleはレコードをフラット化しており、実測すると1回です。古い情報のまま計算すると、上限を超えると誤判断して不要な整理をすることになります。dig +short TXT _spf.google.com で自分の目で確かめてください。

手順2【Google管理コンソール】DKIMを有効化する

DKIMの鍵はGoogleが生成するもので、こちらで作ることはできません。管理コンソールでの操作になります。階層が深いので、直接開くのが早いです。

https://admin.google.com/ac/apps/gmail/authenticateemail

クリックで辿るなら アプリ → Google Workspace → Gmail → メールの認証 です。

ドメイン欄が対象のドメインになっているか確認する
「新しいレコードを生成」をクリックする
表示されたTXTレコードの値をコピーする
DNS管理画面で、ホスト名 google._domainkey のTXTレコードとして登録する
DNSに反映されたら管理コンソールに戻り、「認証を開始」を押す

ここで一度つまずきました。2048ビットの鍵が、DNS管理画面の文字数制限で弾かれたのです。2048ビットだと値が400文字近くになり、パネルによっては登録できません。TXTレコードを255バイトごとに分割して書く方法もありますが、使っていたパネルは「ダブルクォートを自動的に削除します」と明記されており、分割記法が使えませんでした。1024ビットで生成し直して解決しています。

1024ビットで妥協してよいのか

結論として、問題ありません。理由は3つです。

1024ビットのDKIMは Gmail・Outlook・Yahoo など主要な受信側すべてが正常に検証します。DMARCの認証も通ります
署名を偽造するには鍵を素因数分解する必要があります。国家規模の計算資源を要する一方、得られるのは1社のメールを騙れることだけで、割に合いません
そもそも DKIMが無い状態と比べれば、1024ビットでも桁違いに良いです

2048ビットが推奨なのは事実ですが、「推奨に届かないから設定しない」のが最悪です。将来的に上げたければ、DNSの管理を長いTXTレコードを扱えるサービスへ移す選択肢があります。

また、DNSに登録しただけでは、まだメールに署名は付きません。管理コンソールに戻って「認証を開始」を押して初めて機能します。ボタンが「認証を停止」に変わり、ステータスが「DKIMでメールを認証しています」になれば完了です。

手順3【DNS管理画面】DMARCを入れる

最後にDMARCです。値はこれだけです。

ホスト名	種別	内容
`_dmarc`	TXT	`v=DMARC1; p=none; rua=mailto:あなたのアドレス`

p=none は「拒否せず、レポートだけ送ってくれ」という設定です。いきなり拒否にしてはいけません。

SPFとDKIMが揃う前に p=reject にすると、自社の正規メールが取引先に届かなくなります。必ず「SPF修正 → DKIM有効化 → DMARC p=none で1〜2週間監視 → p=quarantine → p=reject」の順で進めてください。

レポートはXMLの添付で毎日届きます。そのままだと受信箱が埋まるので、Gmailで件名に Report domain を含むメールのフィルタを作り、「受信トレイをスキップ」＋「ラベルを付ける」にしておくと邪魔になりません。

つまずき早見表

症状	原因と対処
パネルに保存したのにDNSに反映されない	まず2〜3分待ってください。私はここで焦りました。管理画面には新しい値が表示されているのに、権威サーバー3台すべてが古い値を返す。保存が失敗したと思い込んで「設定する」を何度も押しました。実際はゾーンへの配信に2〜3分かかっていただけです。危ないのは、ここで「既存を削除して新規追加し直そう」と考えることです。SPFを消して入れ直す間、認証が消えます。削除・再作成に走る前に、まず数分待つ。
SPFが2本になった	両方とも無効になります。1本に統合してください。`dig +short TXT example.com \| grep -c spf1` で本数を数えられます
2048ビットのDKIMが登録できない	パネルの文字数制限です。1024ビットで生成し直すのが現実的な解です
DKIMを登録したのに署名が付かない	管理コンソールで「認証を開始」を押していない可能性が高いです
確認コマンドで何も返ってこない	リゾルバが「存在しない」という応答をキャッシュしています。権威サーバーに直接聞けば分かります

確認は、権威サーバーとリゾルバの両方で

設定した本人が値を見間違えていることは、よくあります。必ず引いて確かめてください。

# 権威サーバーに直接聞く（設定が本当に入ったか）
dig +short TXT example.com @ns1.example-dns.jp

# 公開リゾルバ経由（世の中から見えているか）
dig +short TXT example.com @8.8.8.8
dig +short TXT example.com @1.1.1.1

最終的には実際にメールを1通送って確かめるのが確実です。自分宛にテストメールを送り、Gmailで開いて右上の「その他」から「メッセージのソースを表示」。上部に SPF: PASS DKIM: PASS DMARC: PASS と3つ並べば、設定は完全に機能しています。

正直に書いておくこと：今回の詐欺メールは、これでは防げない

冒頭の詐欺メールは、表示名だけを偽装したもので、ドメインは騙られていませんでした。差出人は無関係なGmailアカウントです。つまりDMARCを設定していても防げませんでした。実際には、Gmailの標準の迷惑メールフィルタが正しく振り分けています。

DMARCが効くのは「自社ドメインを名乗る偽メールが、取引先に届く」ケースです。今回とは別の攻撃に対する備えになります。ここを混同して「DMARCを入れればなりすましメールが止まる」と説明すると、あとで「効かなかったじゃないか」となります。できることとできないことは、分けて説明すべきです。

一方で、今回いちばん実利があったのは、なりすまし対策そのものではありませんでした。SPFにGoogleが入っていなかったのを直したことです。これまで自社から送るメールはSPFを通っておらず、迷惑メール判定されやすい状態でした。提案書も見積書も請求書も、すべてこの経路で送っています。

やっておくべきこと（メール認証の外側）

DNSの設定と並行して、社内ルールを決めておく価値があります。

メールやLINEで届いた送金・振込の指示には、金額の大小を問わず必ず電話で本人確認を取る。

今回の手口の目的は、最終的に送金させることです。技術で入口を塞ぐのと同時に、仮に入り込まれても実害が出ない運用を作っておく。人は間違える前提で、間違えても壊れない受け皿を用意しておくほうが確実です。

あわせて、社外の協力者にも共有しておいてください。代表を名乗るメールは、社内より社外の人のほうが疑いにくい立場にあります。

要点

場所を確定してから始める。ドメイン会社・DNS・メールは別々のことがある。dig +short NS でネームサーバーを引けば、DNSの管理場所が分かる
順序を守る。SPF修正 → DKIM有効化 → DMARC p=none で監視 → quarantine → reject。飛ばすと自社のメールが届かなくなる
反映されなくても、まず数分待つ。削除・再作成に走ると、その間だけ認証が消える。焦って壊すのがいちばん危ない

本記事は2026年8月時点の実作業に基づく記録です。管理画面の名称や仕様は変更される場合があります。コマンド例のドメイン名・サーバー名は説明用に置き換えています。