SPF・DKIM・DMARCの設定方法：コールドメール向けステップバイステップガイド

ご自身のドメインからコールドメールを送る場合、受信側のサーバーがそのメールを本当にあなたのものだと信じるかどうかは、3つのDNSレコード、SPF・DKIM・DMARCで決まります。これらがなければ、どれだけ上手に書いた最初のメールでも、誰かが読む前にフィルターされてしまうことがあります。

このガイドは、you@yourcompany.com のようなアドレスから、たいていGoogle Workspaceを通じて営業のメールを送る創業者や営業チーム向けです。当社（Outreach）は、設定すべき順番に各レコードを説明し、GoogleのヘルプページとRFCが公開しているとおりのレコード形式を示し、レコードが問題なさそうに見えて実は静かに失敗してしまうミスを指摘します。

DNSの専門家である必要はありません。必要なのは、ドメインのDNS設定（レジストラまたはDNSホスト）へのアクセスと、DKIMについてはGoogle Workspaceの管理者アクセスです。

SPF・DKIM・DMARCとは、それぞれ一言でいうと何ですか？

SPFはドメインに代わってメールを送ってよいサーバーを一覧にし、DKIMはメッセージが偽造・改ざんされていないことを証明する暗号の署名を加え、DMARCはメッセージがそれらのチェックに通らなかったときの扱いを受信側に伝えます。3つとも、ドメインのDNSにTXTレコードとして公開します。

レコード	置き場所	答える内容
SPF	`yourcompany.com`（ホスト `@`）	このサーバーは、このドメインの代わりに送信してよいか？
DKIM	`google._domainkey.yourcompany.com`	このメッセージは、そのドメインによって署名されており、変更されていないか？
DMARC	`_dmarc.yourcompany.com`	チェックに失敗した場合、ドメインの所有者はどう扱ってほしいか？

この3つは連携して働きます。SPFとDKIMはそれぞれ限られた内容を証明し、DMARCはその証明を、人が実際に目にする差出人（From）のアドレスに結びつけます。

コールドメールには、これらのレコードは本当に必須ですか？

はい — GmailとYahooでは、すべての送信者に少なくともSPFまたはDKIMが必須で、大量送信者には3つすべてが必要です。これは推奨される運用の提案ではなく、両プロバイダーが公開している送信者ルールに定められています。

Googleのメール送信者のガイドラインは、すべての送信者に「送信ドメインにSPFまたはDKIMのメール認証を設定する」ことを求めています。「1日あたりGmailアカウントへ5,000通を超えるメッセージ」を送る送信者は、さらに「SPFとDKIMの設定」に加えて「送信ドメインのDMARCメール認証」も行う必要があり、差出人（From）のドメインはSPFまたはDKIMのドメインと一致していなければなりません。これらのルールは2024年2月1日に施行されました。

YahooのSender Hubのベストプラクティスも同様で、すべての送信者は「最低でもSPFまたはDKIMを実装する」必要があり、大量送信者は「SPFとDKIMの両方を実装する」とともに「少なくともp=noneの有効なDMARCポリシーを公開する」必要があります。

小規模なコールドメールの運用では、1日5,000通に達することはないかもしれません。それでも3つすべてを設定してください：費用はかからず、半日で終わり、基準がどこにあるのかを確かめる必要がなくなります。

SPFはどのように設定しますか？

ルートドメインに、v=spf1 で始まり、あなたの代わりにメールを送るすべてのサービスを列挙し、~all で終わるTXTレコードを1つ追加します。Google Workspaceだけを通じて送信するドメインについては、GoogleのSPF設定ページが次のレコードをそのまま示しています：

v=spf1 include:_spf.google.com ~all

手順：

ドメインを管理しているサービスのDNS設定にサインインします。
TXTレコードを作成します。ホストまたは名前の欄には、サブドメインではなくルートドメインに追加する場合、@ を入力するとGoogleは説明しています。
レコードを値として貼り付け、保存します。
待ちます。Googleは「SPF認証が機能し始めるまで最大48時間かかることがあります」と説明しています。

ニュースレターのツール、CRM、トランザクションメールのサービスなど、ほかのサービスもあなたのドメインからメールを送る場合は、それぞれが同じレコードの中に独自の include: を必要とします。Googleのページは、次のような組み合わせの例を示しています：

v=spf1 include:_spf.google.com include:amazonses.com ~all
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

各送信サービスが自社向けに公開しているinclude値を使い、推測で入れないでください。

SPFレコードの末尾は ~all と -all のどちらにすべきですか？

Googleの設定ガイドは ~all を使っており、あなたの代わりに送信するすべてのサービスをまだ把握しきれていない間は、それが安全な既定値です。この2つの末尾は、SPFの標準であるRFC 7208で意味が異なります：

~all（softfail）は、「公開側のADMDによる、そのホストはおそらく許可されていないという弱い表明」です。
-all（fail）は、「そのクライアントが、指定されたアイデンティティでそのドメインを使用することを許可されていないという明示的な表明」です。

-all を使うと、含め忘れた送信サービスは明確な失敗（ハードフェイル）になります。DMARCを導入し、そのレポートで正当な送信元がすべて通過していることが確認できると、受信側が従う指示はDMARCのポリシーになるため、SPFの末尾の重要性は下がります。

includeが多すぎるとSPFが壊れるのはなぜですか？

SPFのチェックで発生させてよいDNS参照は最大10回までで、それを超えると結果全体がエラーになるためです。RFC 7208の第4.6.4節は、実装は「SPFの評価中は、それらの項目の合計を10に制限しなければならない（MUST）」とし、「この制限を超えた場合、実装は『permerror』を返さなければならない（MUST）」としています。

数えられる項目は、include、a、mx、ptr、exists、そして redirect 修飾子です。重要なのは、数えるのが評価全体であるという点で、それ自体がさらにincludeを含む include: は、10回の枠のうち複数回ぶんを使ってしまいます。Google自身のページは「SPFレコードには最大10個のinclude:タグを入れられる」と書いていますが、入れ子の参照も数えるため、RFCのほうが厳しい読み方です。

長年のあいだに営業やマーケティングのツールをいくつも追加してきた場合は、新しいincludeを追加する前に、使わなくなったものを削除してください。

ドメインにSPFレコードが2つあるとどうなりますか？

SPFはエラーで失敗します — 2つのレコードは、組み合わせる2つのリストではなく、壊れた設定として扱われるためです。RFC 7208は、ドメインに v=spf1 のレコードが複数あると、チェックは「『permerror』という結果を生じる」としています。

よくあるのは、誰かが新しいツールのために、既存のレコードを編集せずに2つ目のTXTレコードを追加してしまうケースです。直すには、上の例のように、複数の include: を入れた1つのレコードにまとめます。

Google WorkspaceでDKIMを有効にするにはどうすればよいですか？

管理コンソールでキーを生成し、google._domainkey にTXTレコードとして公開してから、「認証を開始」をクリックします。GoogleのDKIM設定ページが手順を示しています：

Google管理コンソールで、アプリ > Google Workspace > Gmail > メールの認証に移動します。（Gmailの「設定」管理者権限が必要です）。
ドメインを選び、新しいレコードを生成します。
キーの長さを選びます。Googleは、「ドメインのプロバイダーが2048ビットのキーに対応している場合」に2048を選ぶよう案内しており、その理由は「長いキーは短いキーより安全である」ことで、「ドメインのホストが2048ビットのキーに対応していない場合」にのみ1024を選ぶとしています。
既定のプレフィックスセレクタ google はそのまま使います — Googleはこれを、Workspaceでの「推奨オプション」と呼んでいます。
Googleは、DNSのホスト名 google._domainkey と、v=DKIM1 で始まるTXTの値を表示します。その両方を、DNSホストの新しいTXTレコードにコピーします。
管理コンソールに戻り、認証を開始をクリックします。

Googleが生成するTXTの値は、次のような形です（キー自体は、ドメインごとに固有の長い文字列です）：

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)

所要時間：Googleは、キーを追加してから「DKIM認証が機能し始めるまで最大48時間かかることがある」としています。新しいドメインでGmailを設定したばかりの場合、DKIMキーが管理コンソールで利用できるようになるまでに「24–72時間待つ必要がある」とGoogleは説明しています。

ほかのサービスがあなたの代わりにメールを送る場合は、そのサービスが独自のセレクタを持つ独自のDKIMレコードを提供します。それも公開してください — セレクタが異なる複数のDKIMキーは、SPFと違って共存できます。

自分のメールをブロックせずにDMARCを設定するにはどうすればよいですか？

まず _dmarc.yourcompany.com に p=none のTXTレコードを公開し、レポートを読んでから、ポリシーを厳しくします。GoogleのDMARC設定ページは、「DMARCを使い始めるときは、ポリシーのオプション（p）をnoneに設定することをおすすめします」と述べ、さらに「DMARCを設定する前に、SPFまたはDKIM（あるいはその両方）の設定から48時間待つ」ようにも勧めています。

Googleのページは、次の完全な例のレコードを示しています：

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

この例は、完成した最も厳しい状態を示しています。最初のレコードには、監視用のポリシーとレポートの宛先アドレス1つを入れた同じ形式で十分です — たとえば v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com のようにします。rua タグは集計レポートをそのメールボックスに送り、レポートが大量に届くことがあるため、Googleは専用のメールボックスまたはグループを推奨しています。

DMARCの仕様で定義されている、3つのポリシー値は次のとおりです：

ポリシー	受信側に求める動作
`p=none`	特別な処理はせず、レポートだけ送る
`p=quarantine`	失敗したメールを疑わしいものとして扱う（たとえば迷惑メールフォルダ）
`p=reject`	DMARCチェックに失敗したメールを拒否する

1つのドメインに持てるDMARCレコードは1つだけです。RFC 9989では、複数のDMARCレコードが返された場合、「それらはすべて破棄される」とされ、つまりポリシーがまったく適用されません。

「アラインメント」とは何を意味し、SPFが通ってもDMARCが失敗するのはなぜですか？

DMARCが通るのは、SPFまたはDKIMが、受信者が目にする差出人（From）のアドレスと一致するドメインで通った場合だけです。SPFは送信サービス自身のドメインで通る一方で、差出人（From）にはあなたのドメインが表示されることがあり、その場合は、通ったドメインが一致していないため、DMARCは失敗します。

DMARCの仕様は、少なくとも1つの認証方式が「アラインメントしている識別子に基づいて」パスを出せば、メッセージは通ると定めています（RFC 7489で、現在はRFC 9989に引き継がれています）。既定では、アラインメントはrelaxed（緩やか）で（adkim と aspf の既定値は r）、mail.yourcompany.com と yourcompany.com は同じ組織ドメインを共有しているため一致と見なされます。Googleの例のようなstrictモード（s）では、完全な一致が必要です。

実際には、これがコールドメールでDKIMが非常に重要な理由です：送信サービスがあなたのドメインで署名すれば、SPFのアラインメントが通らなくても、DKIMのアラインメントは通ります。

DMARCの標準は2026年に変わりましたか？

はい。RFC 9989は、2026年5月にStandards Track文書として公開され、元のRFC 7489を置き換えるもので、pct タグを廃止しています。既存の v=DMARC1 のレコードは引き続き動作します。

ほとんどの送信者が気づく主な変更は、pct（失敗したメールの一部の割合にだけポリシーを適用する設定）がなくなったことです。RFCは「運用上の経験から、指定された値が0か100のどちらかでない限り、『pct』タグは通常、正確に適用されないことが分かった」と説明しています。その代わりに用意されたのがテスト用のフラグ t=y で、ポリシーをテストしている間は、宣言したポリシーを適用しないよう受信側に求めるものです。

Googleのヘルプページは、今も例の中に pct=100 を示しています。それで何かが壊れることはありません：RFC 9989は「未知のタグは無視しなければならない（MUST）」としているため、残っている pct は単に読み飛ばされます。次にレコードを編集するときに、削除して構いません。

すべてが正しく動作しているかを確認するにはどうすればよいですか？

公開したレコードを調べ、次にGmailのアドレスに実際のメッセージを送って、その認証結果を読みます。手早くできる確認が2つあります：

DNSレコードを調べます。当社の無料チェッカーは、入力したアドレスのドメインについて、SPF・DKIM・DMARCのレコードを調べます — 新規登録は不要です。GoogleのDKIMセレクタの既定値（google._domainkey）を確認するため、送信サービスが別のセレクタを使っている場合は、設定してあってもDKIMは確認できないと表示されます。このツールは英語と韓国語で利用でき、送信に使うメールアドレスを入力します。
実際のメッセージを確認します。自分が管理するGmailアカウントにメールを送り、開いて、「メッセージのソースを表示」を選び、SPF: PASS、DKIM: PASS、DMARC: PASS を探します。

その後、DMARCレポートを1週間か2週間ほど見ます。使っている正当な送信元がすべて通過と表示されたら、p=none から p=quarantine に移し、なりすましへの最も強い保護を望むなら、のちに p=reject に移します。

認証が壊れる原因で最も多いミスは何ですか？

SPFレコードが2つある、SPFの参照が多すぎる、DKIMを生成しただけで開始していない、SPFとDKIMが機能する時間を置く前にDMARCを公開した、というミスです。チェックリスト：

SPFレコードは1つにして、すべての送信元をその中の include: として入れ、参照の項目は10個以内にします。
DKIMキーを公開したら、「認証を開始」をクリックします — DNSレコードだけでは足りません。
DMARCを追加する前に、SPFとDKIMの設定から約48時間待ち、ルートではなく _dmarc に公開します。
自分が管理しているドメインから送信します。@gmail.com のアドレスにはDMARCを公開できません。

認証は、メールを検討の対象にしてもらうためのもので、受信者がそのメールを読みたいと思うようにするものではありません。迷惑メールの苦情は引き続き数えられます — GoogleもYahooも、迷惑メール率を0.3%未満に保つよう述べており、これはコールドメールが迷惑メールフォルダに入る理由で解説しています。また、存在しないアドレスに送るとバウンスが発生するため、送信前にアドレスを確認することをおすすめします。

要点まとめ

GoogleとYahooは、すべての送信者にSPFまたはDKIMを、大量送信者（Gmailへ1日5,000通以上）には3つすべてとアラインメントを求めています。
SPF：@ にTXTレコードを1つ、たとえば v=spf1 include:_spf.google.com ~all。DNS参照の項目は10個以内にします。
DKIM：2048ビットのキー、セレクタは google、TXTは google._domainkey に置き、そのあと認証を開始をクリックします。
DMARC：_dmarc にTXTレコードを1つ、レポートの宛先アドレスを付けて p=none から始め、あとで厳しくします。RFC 9989（2026年5月）は pct を t=y に置き換えました。
当社のメール認証の無料チェッカーでレコードを確認し、そのあと実際のメッセージで確かめます。