【法人向け】GmailのDMARC設定方法｜コピペで使える記述例と失敗しない手順

コラム更新日：2026.08.19

取引先にビジネスメールが届かないといったトラブルにお困りではありませんか。近年、フィッシング詐欺やなりすましメールの急増にともない、GoogleはGmailにおける「メール送信者のガイドライン」を厳格化しました。規定の認証要件を満たさないメールは、迷惑メールへの振り分けや受信拒否される可能性が高まります。

この課題を解決し、メールを確実に届けるために必須となるのが「DMARC（ディーマーク）」の設定です。しかし、「DNSの変更で障害が起きないか」「設定を間違えて全社のメールが止まらないか」と不安を感じる担当者様も少なくありません。専任のIT管理者が不在の企業では、日常業務と兼任しながら対応を進める必要があり、精神的な負担も大きくなりがちです。

本記事では、Google Workspace環境でのDMARC設定手順、コピペできる記述例、陥りやすい失敗パターンと注意点を分かりやすく解説いたします。自社での対応と専門業者への依頼を比較検討するうえで、ぜひ本記事をお役立てください。

※本記事で解説する内容は、法人向けのGoogle Workspace環境における設定を前提としており、個人向けの無料版Gmailとは設定方法が異なります。

執筆・監修：TSクラウド編集部

Google Cloud の「プレミア認定」を保有する、Google Workspace 正規販売代理店です。業界歴 17 年、延べ 3,500 社以上の導入支援実績（ 2026 年 2 月時点）に基づき、Google Workspace の最新機能から活用術、DX推進に役立つノウハウを専門的な視点で解説しています。

※情報は記事公開（更新）時のものです。Google Workspace の仕様や価格は変更される場合があるため、最新情報は必ず公式ページでご確認ください。

DMARCとは？Gmailで設定が必要な理由と「未設定」のリスク

DMARC（Domain-based Message Authentication Reporting and Conformance）とは、電子メールの送信元ドメインを認証し、なりすましやフィッシング詐欺を防ぐためのセキュリティ技術です。これまで、メールの送信元を証明する技術としてSPFやDKIMが利用されてきましたが、これらを補完し、認証に失敗したメールをどのように処理するかを受信側に指示するのがDMARCの役割です。

近年、メールの送信者を対象とした悪意のある攻撃が巧妙化し、社会問題に発展しています。それを受けGoogleは、1日あたり5,000件以上のメールを送信する一括送信者を対象に、SPF・DKIMに加えてDMARCの設定も必須化しました。

ここでは、適切な設定を行い、ビジネスメールを確実に届けるための基礎知識として、DMARCを設定しないリスクとSPF・DKIMとの違いについて解説します。

関連記事：Gmail送信者ガイドライン対策｜必須DNS・運用要件完全ガイド

DMARCを設定しないリスク（メール不達・なりすまし）

DMARCを未設定のままメール送信を継続すると、企業活動に深刻な悪影響を及ぼすリスクが高まります。代表的なリスクとして挙げられるのが、自社から送信した重要なビジネスメールの不達です。たとえば、顧客への請求書や商談の連絡などが迷惑メールと判定されたり、受信サーバー側でブロックされたりする可能性があります。主要なメールプロバイダはDMARCを設定しているドメインからのメールを優先的に受信箱へ届ける傾向にあるため、設定しないまま利用を続けるとメールの到達率を低下させる原因となります。

さらに脅威となるのが、なりすましの被害に遭うリスクです。DMARCを設定していないドメインでは、第三者によるなりすましメールが増加するリスクが高まります。メールの仕組み上、差出人として表示されるアドレスは偽装が比較的容易です。SPFやDKIMを導入していても、DMARCによる「認証失敗時の制御ルール」が定義されていないと、受信側サーバーは偽装メールを完全に排除できません。そのため、攻撃者から「なりすましが成功しやすいドメイン」と判断され、自社名を騙ったフィッシング詐欺の標的にされやすくなります。もし自社のドメインが悪意のある第三者に悪用され、フィッシング詐欺に利用されてしまった場合、企業の社会的信用は失墜してしまうでしょう。

メールの到達性を確保し、企業の信頼を守るためにも、あらかじめ適切な設定を行うことが欠かせません。

DMARCの役割とSPF・DKIMとの違い

DMARCの役割を正しく理解するためには、前提となる「SPF」と「DKIM」との違いを把握することが大切です。これらはすべて送信ドメイン認証技術ですが、それぞれ担う役割が異なります。

• DKIM（DomainKeys Identified Mail）：メール転送中の内容への変更を防ぎます。
• SPF（Sender Policy Framework）：スパマーなどの攻撃者が送信者を装った「なりすましメール」を防ぎます。

DKIMは、メールに電子署名を付与し、送信途中で内容が改ざんされていないかを検証する仕組みです。SPFは、送信元サーバーのIPアドレスをチェックし、事前に登録された正しい場所から送られてきたかを照合する仕組みです。SPFとDKIMを組み合わせることで、該当のメールが「真の送信者によって作成され、送信されたものである」という正当性をより強固に証明することが可能になります。

しかし、攻撃者が送り主のアドレスを偽装したりする高度な手法に対しては、SPFやDKIM単体ではなりすましを完全に防ぐことが難しいという欠点がありました。

そこで活躍するのがDMARCです。DMARCは単体で動くのではなく、SPFとDKIMの認証結果を利用して動作します。受信側のサーバーに対して、SPFやDKIMの認証に失敗したメールを「そのまま受信する」「迷惑メールフォルダに入れる」「受け取りを拒否する」といった処理をするよう、送信者側があらかじめ独自のポリシーとして指示（宣言）を出しておく仕組みです。

したがって、DMARCを設定するには前提としてSPFまたはDKIMの設定が必要です。なお、DMARC自体はどちらか一方の設定でも機能しますが、Googleの「メール送信者のガイドライン（一括送信者向け要件）」をクリアするためには、SPFとDKIMの両方を設定することが必須となります。

DMARCの設定手順（SPF/DKIM設定・レコード記述例・DNS登録・テスト確認）

ここからは、実務においてどのようにDMARCを設定すればよいのか、一連の流れを解説します。設定の流れは、大きく分けて以下の3つのステップに分かれます。

1. SPFとDKIMの設定
2. DMARCのレコードを作成
3. DNSサーバーへの登録と反映確認

これらを順番に、抜け漏れなく実施していくことが、メール配信の安全性を高め、設定ミスによる障害を防ぐための鍵となります。それぞれのステップについて詳しく見ていきましょう。

【STEP1】SPFとDKIMの設定

DMARCを正しく機能させるためには、まず前提としてSPFとDKIMのいずれかの設定が完了している必要があります。この2つは、Google Workspaceの管理コンソールおよびドメインのDNS設定画面で設定できます。ここでは、推奨されている両方の設定方法について解説します。

なお、ドメインのDNS設定は、対象ドメインを運用しているDNSサーバー側での作業が必要です。具体的な設定手順については、社内インフラ担当者やドメイン管理会社へご確認ください。ドメイン側でこれら2つがデフォルトで設定済みの場合や、Google Workspace契約時にGoogleパートナー経由でドメインを取得されたケースでは、あらためて作業する必要はありません。

まず、SPFの設定では、自社のドメインからメールを送信することを許可するIPアドレスやサーバー情報をDNSのTXTレコードに記述します。SPFの設定は、ドメインホストのSPFの手順に沿ってSPFレコードを追加してください。管理コンソールでの設定はありません。

DKIMの設定は、管理コンソールからDKIMキー（公開鍵）を生成し、ドメインのDNSサーバー上に記述します。DKIMキー（公開鍵）の生成は、管理コンソールで、「メニュー」＞「アプリ」＞「Google Workspace」＞「Gmail」 ＞「メールの認証」画面で行います。

「選択したドメイン」で、DKIM の設定対象となるドメインを選択し、「新しいレコードを生成」をクリックします。

新しいレコードを生成ボックスでDKIM鍵の設定を選択し「生成」ボタンをクリックします。

正しく行われると、「メールの認証」ページで「TXTレコードの値」が更新され、「DKIM 認証設定が更新されました 」というメッセージが表示されます。生成されたTXTレコードの情報はドメインプロバイダに登録するものです。

ドメインホスト（ドメインを購入したサービスなど）にログインして、生成したTXTレコードと以下の情報を追加し変更を保存します。

• Type（レコードタイプ）: TXT
• Host（名前、ホスト名、エイリアス）: google._domainkey
• 値（TXT レコードの値）: v=DKIM1 から始まる長い文字列

ドメイン側での登録が完了したら、再びGoogle管理コンソールの「メールの認証」画面に戻り、「メールの認証」画面から「認証を開始」をクリック。DKIMを有効にします。

ページ上部の「ステータス」が 「DKIMでメールを認証」に変わったら設定完了です。なお、DKIM鍵の設定追加後、認証が正常に動作し始めるまでには最大48時間ほど要する場合があります。

設定が機能しているかを確認するために、GmailかGoogle Workspaceを使用しているユーザーにテストメールを送信します 。自分自身にメールを送ってもDKIMが有効であることを確認できません。

受信者の受信トレイで該当のメールを開き、「その他」＞「メッセージのソースを表示」でメッセージ ヘッダー全体を確認します。ヘッダー内で「Authentication-Results」の文字列を探し「DKIM=pass」や「DKIM=OK」といった表記があれば設定が正しく行われた証拠です。

SPFやDKIMの設定を変更したあとは、インターネット上のDNSに情報が反映されるまで一定の時間がかかります。そのため、SPFやDKIMを設定してからDMARCのレコードを追加するまでには、少なくとも48時間程度の間隔を開けることをおすすめします。

【STEP2】DMARCのレコードを作成

SPFとDKIMの設定と反映が完了したら、DMARCレコードを作成します。このとき、認証結果のレポートを受信するための専用メールアドレス（例：dmarc-reports@自社ドメイン）をあらかじめ作成して用意しておきましょう。レコード内でそのメールアドレスを記述します。なお、レポートの受信は、日常業務で使っている個人のメールアドレスを指定することも可能ですが、非常に数多くのレポートが送られてくることが予想されます。そのため、専用のメールアドレスやメーリングリストを新しく作成するのをおすすめします。

コピペで使える推奨の記述例は以下の通りです。

推奨記述例

「専用メールアドレス」の部分を、レポート受信用に用意したメールアドレスに置き換えましょう。たとえば、「専用メールアドレス」が「dmarc-reports@yourdomain.com」の場合のDMARCレコードは以下になります。

また、上記の記述内にあるポリシー（pタグ）の比較は以下の表のとおりです。

ポリシー（pタグ）は、まずは「p=none」から開始し、ある程度の期間を設けつつ段階的にポリシーをquarantine（またはreject）へと強化していくことが、Googleのガイドラインで推奨されています。

参考：Google Workspace「DMARC を設定する」

【STEP3】DNSサーバーへの登録と反映確認

作成したDMARCレコードは、ドメインを管理しているドメイン管理会社（ドメインホスト）の管理画面から、DNSのTXTレコードとして追加登録します。

登録する情報の形式は以下の通りです。

• レコードタイプ（Type）: TXT
• ホスト（名前、ホスト名、エイリアス）: _dmarc （または_dmarc.yourdomain.com）
• 値（TXT レコードの値）: STEP2で決定したDMARCレコード （記述例: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com）

※ドメインプロバイダによっては、レコードの「値」をダブルクォーテーション（”）で囲む必要がありますので、ホスト側のヘルプもあわせてご確認ください

設定が正しく反映されているかの確認は、インターネット上で提供されている無料のDMARCチェッカーを利用するとよいでしょう。ツールに自社のドメインを入力して検証を実行し、正常に検出されれば成功です。

ただし、DNSレコードの変更が完全に反映されるまでには、最大で48時間から72時間ほどかかる場合があります。

自社設定で陥りやすい3つの失敗パターンと注意点

DMARC設定は、仕組みを理解すれば手順自体はシンプルに思えるかもしれません。しかし、専任のIT担当者が不在のなかで、兼任の管理者が自力で設定をおこなった際、設定ミスや思わぬ不達などトラブルが発生するケースがあります。ここでは、自社対応で特に陥りやすい3つの典型的な失敗パターンと注意点について詳しく解説します。自社対応に潜むリスクを客観的に認識し、安全な運用方法を検討するための判断材料としてください。

わずかな構文ミスによる認証失敗

DMARCのTXTレコード記述は非常にシビアであり、たった1文字の構文ミス（シンタックスエラー）があるだけで、レコード全体が無効化され認証エラーを引き起こす原因となります。

よくある失敗例として挙げられるのが、各タグを区切るためのセミコロン（;）の入力漏れや、全角文字の混入、不要なスペースの挿入などです。たとえば「v=DMARC1」の大文字の部分を小文字にしてしまったり、メールアドレスの前に「mailto:」をつけ忘れたりといった、ちょっとした見落としでレコード全体が無効化されてしまいます。

構文にわずかでもエラーがあると、DNSサーバーや受信側のメールサーバーは記述内容を正常に解釈できず、認証失敗や意図しない動作の原因となります。レコードをDNSに登録する際は、手入力を避けてテキストエディタ等で慎重に作成し、不自然なスペースや記号の抜けがないかを細かくチェックしましょう。

SPF/DKIMアライメント不一致によるメール不達

DMARC認証を正しく通過するためには、メールの差出人アドレス（Header From）のドメインと、SPFやDKIMで認証されたドメインが一致している「アライメント（一致関係）」が保持されている必要があります。

しかし、メルマガ配信システムや問い合わせフォームなどの外部サービスからメールを送信している場合や、自動転送設定を利用している場合、このアライメント不一致が発生します。外部システム側の送信ドメイン設定が不十分なままだと、正規のビジネスメールがスパム扱いされ、相手に届かなくなるという深刻な事態に陥ります。社内で利用しているすべてのメール送信経路を、あらかじめ網羅的に洗い出して設定することが重要です。

IT専任者不在の中での障害対応と業務への支障

DMARCの設定ミスやアライメント不一致によってメール不達の障害が発生した場合、企業活動全体に大きな影響が及びます。「大切な取引先へ送信したメールが届かない」「顧客からの問い合わせに対する返信メールが相手に届かない」といったトラブルが起きた際、迅速な原因特定と復旧作業をおこなわなければなりません。

しかし、専任のシステム管理者がおらず、総務や他部署の業務と兼任している担当者の場合、障害の原因がDNSの構文ミスなのか、アライメントエラーなのか、あるいは受信側のセキュリティ判定なのかを判別することはきわめて困難です。専門知識がない状態で手探りで調査をおこなうと、問題の特定までに長い時間がかかってしまいます。

さらに、DNSレコードの修正をおこなったとしても、設定がインターネット全体に反映されるまでには数時間から最大で72時間ほどかかる場合があります。そのため、原因究明と修正対応が遅れると、その間全社のメール機能が停止し、業務の停滞や取引先との信頼関係の悪化を招くおそれがあります。日常業務を抱える兼任担当者にとって、この復旧作業は精神的にも大きな負担となります。見よう見まねで重要な設定を変更することには、こうした潜在的なリスクがともなう点に留意しておきましょう。

失敗できないメール設定はプロにお任せ｜TSクラウドの初期設定代行

DMARCをはじめとする認証設定は、わずかなミスが重大なトラブルに直面するリスクがあります。自力での対応に限界を感じ、見えない不達リスクや作業負担を避け、安全かつ確実に設定を完了させたい場合、専門家へ設定作業を以来することをおすすめします。

株式会社TSクラウドでは、Google Workspaceの導入から運用開始フェーズを支援する「Google Workspace 導入支援サービス」を提供しております。IT専任者が不在の企業でも、専門スタッフがDNS設定から初期セットアップまでを代行いたします。ぜひ導入支援サービスの活用をご検討ください。

GmailのDMARC設定を適切に行って安全なメール環境を整えよう

昨今の巧妙化するサイバー攻撃やフィッシング詐欺に対抗するため、Gmailをはじめとする主要メールサービスにおけるDMARC設定は、すべての企業にとって不可欠なセキュリティ要件となりました。適切な設定をおこなうことは、自社のドメインをなりすましから守り、取引先や顧客に対するブランドの信頼性を保護することにつながります。また、重要なビジネスメールが迷惑メールとして処理されるのを防ぎ、確実なコミュニケーションを維持するためにも欠かせない対応です。

とはいえ、DNSレコードの編集やアライメントの調整には専門的な知識が求められ、設定の失敗がビジネスに甚大な影響を与えるリスクも伴います。メール環境の安全性と到達率を向上させるためには、適切な知識に基づいた設定が不可欠です。しかし、DNSの編集や送信経路の全体把握には専門性が求められるのも事実です。もし、自社での対応に少しでも不安を感じたり、設定ミスのリスクを避けたいとお考えの場合は、決して無理をして自力で進めず、プロのサポートを検討することが安全な選択肢と言えます。自社で設定を行うか、専門家の力を借りるか。自社に合った最適な方法を選択し、安心で安全なメール運用環境を構築しましょう。