第220回

GmailのDMARC設定における条件｜SPFとDKIMの整合が鍵

Google Workspaceやメール配信システムからGmailアカウント宛てに送信している担当者が、送信者ガイドラインへの対応としてDMARCの設定を検討する場面が増えています。SPFとDKIMを設定済みであれば、DMARCのレコードをDNSに追加するだけでガイドライン対応が完了すると考える担当者も一定数いるはずです。

しかし、DMARCはレコードを設置した時点ではなく、SPFとDKIMのアライメントが一致し、ポリシーを段階的に強められる状態になって初めて機能します。構文が正しくても、送信ドメインとFromアドレスの整合が取れなければ認証は失敗したままです。

本記事では、DMARCがGmail宛てのガイドラインで担う役割から、Google Workspaceでの設定手順、アライメントで崩れやすい条件まで、導入支援の立場で順を追ってお伝えします。

GmailのDMARC対応が必要になった背景とガイドラインの要点

対象は@gmail.comや@googlemail.comのアカウント宛てで、法人が契約するGoogle Workspaceアカウント宛ては直接の対象ではありません。ただし、送信先にGmailの個人アカウントが含まれる限り、企業からのメルマガや通知メールも要件の対象になります。

要件は、すべての送信者に共通するものと、送信量が多い一括送信者に追加で求められるものの二層で構成されています。共通する要件は次のとおりです。

• ・SPFまたはDKIMによる送信ドメイン認証を設定する
• ・迷惑メールとして報告される割合を低く保つ
• ・Gmail宛てメールの差出人（From）ヘッダーになりすましをしない

これらの上に、1日あたり5,000件以上を送信する一括送信者には、SPFとDKIMの両方の認証設定に加え、DMARCレコードの設置が追加要件として求められます。件数のカウントは、1つのFromドメイン（同一の組織ドメインに属するサブドメインを含む）から24時間以内に送られたメールの合計で判定される仕組みです。

DMARCそのものは、SPFまたはDKIMの認証に合格しなかったメールを受信側でどう扱うかを送信側が指定する仕組みです。一括送信者の基準や技術要件は、Gmailヘルプのメール送信者のガイドラインに明記されています。自社の送信量がしきい値に近い場合は、対象になる前提でSPF・DKIM・DMARCの3点を整えておく判断が現実的です。

DMARCの仕組みとSPF・DKIMとの役割の違い

送信元のIPアドレスを認証するSPF

SPFは、ドメインの管理者があらかじめDNSに登録したIPアドレスのリストと、実際にメールを送信したサーバーのIPアドレスを照合する仕組みです。リストに含まれていないサーバーから送られたメールは、SPF認証に不合格となります。メール配信システムを利用している場合は、そのサービスの送信IPを自社のSPFレコードに含めておく必要があります。

電子署名で改ざんの有無を検証するDKIM

DKIMは、送信サーバー側でメールに電子署名を付与し、受信側がDNSに公開された公開鍵で署名を検証する仕組みです。経路の途中でメールの内容が書き換えられていないかを確認できる点が、送信元のIPアドレスだけを見るSPFとの違いになります。

認証結果の処理方法を指定するDMARC

DMARCは、SPFとDKIMの認証結果を踏まえたうえで、認証に失敗したメールを受信側でどう処理するかを送信側が指定する仕組みです。SPFとDKIMのどちらかが合格していれば認証には通りますが、DMARCが合格と判定されるにはアライメントと呼ばれる追加の条件を満たす必要があります。アライメントの詳細は後述します。

3つの仕組みを整理すると、次のようになります。

3つとも設定場所はDNSのTXTレコードで共通していますが、確認する対象がそれぞれ異なるため、1つを設定すれば残り2つが不要になるわけではありません。

DMARCレコードを構成する3つのポリシー

3段階の内容を整理すると、次のとおりです。

表のとおり、3段階は目的が異なるため、導入初期からp=rejectを指定するのではなく、順を追って切り替える判断が求められます。

観測にとどめるp=noneの段階

p=noneは、認証に失敗したメールも通常どおり配信しつつ、認証結果のレポートだけを受け取る設定です。既存の送信を止めずに、どこから来たメールが認証に通っていないかを把握できるため、導入直後の観測期間に用います。

疑わしいメールを隔離するp=quarantineの段階

p=quarantineは、認証に失敗したメールを受信者の迷惑メールフォルダなどに振り分けるよう求める設定です。レポートで正規の送信元がすべて認証に通っている状態を確認したあとに切り替える段階になります。

認証に失敗したメールを拒否するp=rejectの段階

p=rejectは、認証に失敗したメールの受信そのものを拒否するよう求める設定です。なりすまし対策としては最も強い指定ですが、正規の送信元を1つでも認証対象から外していると、そのメールも届かなくなります。

3段階は一気に最終形へ進めるものではなく、レポートの内容を確認しながら順番に切り替えていく前提で設計されています。

GmailのDMARC対応で得られる効果と運用上の負担

自社ドメインを名乗るなりすましメールが減れば、取引先や顧客からの信頼低下を防ぐことにつながります。また、Gmail側から見た送信ドメインの認証状況が明確になるため、迷惑メール判定を受けにくくなる効果も見込めます。

効果と負担は表裏の関係にあり、レポートを確認する体制を作らないまま設定だけを進めると、効果を得る前に運用が止まってしまいます。

DMARCを自社ドメインに設定する4つの手順

SPFとDKIMの認証状況を確認する

DMARCを設定する前に、管理コンソールでSPFとDKIMがすでに認証に合格しているかを確認します。メール配信システムなど第三者のサービスを利用している場合は、そのサービス経由の送信もSPFとDKIMの両方で認証されているかをあわせて確認します。

レポート受信用のメールアドレスを準備する

DMARCの集計レポートを受け取るための専用メールボックスかグループを用意します。個人のメールアドレスに直接届けると通知が埋もれやすいため、担当チームで確認できるグループアドレスを割り当てる方法が扱いやすいはずです。

DMARCレコードの値を決める

v=DMARC1から始まる文字列に、ポリシー（p=none・quarantine・reject）とレポート送付先（rua=）を指定します。導入初期はp=noneを指定し、レポートを確認しながら段階を引き上げる進め方が無理のない選択です。

DNSにTXTレコードとして登録する

「_dmarc.自社ドメイン」というホスト名に対して、決めた値をTXTレコードとして登録します。DNSサーバーの管理画面はドメインの契約先ごとに異なるため、レンタルサーバーやドメイン管理会社の設定画面から操作します。反映には数時間から半日程度かかることがあり、登録直後に確認できなくても慌てる必要はありません。

Google Workspaceヘルプ「DMARCを設定する」にも、同様の4ステップが案内されています。手順自体は公式情報と共通しており、実務で差が出るのは次章で扱うアライメントの整合確認です。4つの手順を終えた時点では、まだp=noneでの観測段階です。ここから先の運用次第で、ガイドライン対応の実質が決まります。

DMARCのアライメント設計で崩れやすい条件

ここで、Google Workspaceの導入からドメイン認証の設定まで支援してきた立場から本音を言えば、DMARCの相談で最も多いのはレコードの構文ミスではなく、アライメントの不一致です。アライメントとは、SPFやDKIMの認証で使われたドメインと、メールのFromアドレスに表示されるドメインが一致しているかどうかの判定です。SPFやDKIMそのものは合格していても、このドメインが一致しなければDMARCは不合格になります。

• ・SPFアライメントは、Envelope-FromのドメインとFromアドレスのドメインが一致している状態を指す
• ・DKIMアライメントは、署名に使われたドメインとFromアドレスのドメインが一致している状態を指す

どちらか一方でも一致していればDMARCは合格と判定されるため、まずはこの2つの一致状況を送信ルートごとに確認する作業が出発点になります。

転送やメーリングリストでSPFアライメントが崩れる場合

メールが第三者のサーバーを経由して転送されると、SPF認証で確認される送信元IPアドレスが転送元のものに変わります。Fromアドレスのドメインとは別のドメインが送信元として記録されるため、SPFアライメントは一致しません。社内のメーリングリストや自動転送設定を経由する送信ルートがある場合は、そのルートを洗い出しておく必要があります。

配信委託先の署名でDKIMアライメントが崩れる場合

メール配信システムに送信を委託している場合、DKIM署名がそのシステム側のドメインで付与されていることがあります。この場合、署名のドメインと自社のFromドメインが一致せず、DKIMアライメントも一致しません。委託先が自社ドメインでの署名に対応しているかどうかは、契約前に確認しておく判断が現実的です。

SPFとDKIMのどちらか一方でもアライメントが取れていれば、DMARCとしては合格と判定されます。両方が崩れているケースを見落とさないよう、送信ルートごとに確認する進め方が欠かせません。

DMARCの運用で起こりやすい設定ミスと対処

レポートを確認する際は、次の3点を軸に見ていきます。

• ・送信元のIPアドレスがSPFレコードに含まれているか
• ・署名のドメインがFromアドレスのドメインと一致しているか
• ・認証に失敗している送信元が社内の他部署のサービスでないか

この3点をレポートで確認したうえで、該当する設定ミスがないかを見ていきます。

検証期間を置かずp=rejectへ引き上げる

レポートを確認しないままp=rejectに設定すると、洗い出せていなかった正規の送信元からのメールが届かなくなります。p=noneで一定期間レポートを収集し、想定している送信元がすべて認証に合格していることを確認してから段階を引き上げる進め方が無理のない選択です。

レポートを取得したまま確認しない

DMARCのレポートはXML形式で送られてくるため、そのままでは読みにくく、届いているのに確認されずに残っているケースがあります。レポートを人が読める形式に変換して確認できるツールを導入するか、確認作業を担当チームの定例業務に組み込んでおく方法があります。

委託先の送信ドメインを認証対象から外し忘れる

請求書発行システムやアンケートツールなど、部署ごとに契約している送信サービスがSPFレコードに含まれていないケースは珍しくありません。DMARCのレポートには、こうした社内の他部署が契約しているサービスからの送信も認証失敗として記録されるため、レポートを確認する際は自社内の他の送信元もあわせて洗い出す前提で見る必要があります。

いずれの状況も、レコードそのものの誤りではなく、送信元の洗い出しとレポート確認という運用面の抜けが原因です。

GmailのDMARC設定に関するよくある質問

個人用Gmailアカウント宛てが少ない場合のDMARC設定要否

必須ではありません。ガイドラインの追加要件は1日5,000件以上を送信する一括送信者が対象で、それ未満であればSPFまたはDKIMの設定が中心になります。将来的に送信数が増える見込みがあるなら、先にp=noneで導入しておく判断もあります。

DMARCレコード設定による既存配信への影響

止まりません。p=noneを指定していれば、認証結果にかかわらずメールは通常どおり配信され、レポートだけが収集されます。配信に影響が出るのは、アライメントが崩れた状態でp=quarantineやp=rejectに切り替えた場合です。

サブドメインにおけるDMARCレコードの要否

個別に設定できます。spタグでサブドメイン向けのポリシーを親ドメインと別に指定できるため、部署やサービスごとにサブドメインを使い分けている場合は、サブドメイン側の送信状況もあわせて確認しておく必要があります。

GmailのDMARC対応はレコード設置で完了しない

本記事で取り上げたポイントを振り返ると、次の通りです。

• ・DMARCは、SPFまたはDKIMの認証に失敗したメールの処理方法を送信側が指定する仕組みである
• ・Gmail宛てのガイドラインでは、1日5,000件以上を送信する一括送信者にDMARCの設置が求められる
• ・DMARCの合否はSPF・DKIM単体の認証結果ではなく、Fromドメインとのアライメントで決まる
• ・p=none・quarantine・rejectの3段階は、レポートを確認しながら順番に引き上げる運用が前提になる

サテライトオフィスはこれまで、Google Workspaceの導入からドメイン認証の設定まで一貫して支援してきました。その経験から言えるのは、GmailのDMARC対応はレコードを1つ追加する作業ではなく、SPFとDKIMのアライメントを整え、段階的にポリシーを引き上げる運用まで含めて初めて完了するという点です。

GmailのDMARC対応にまつわるサテライトオフィスの支援

サテライトオフィスは、Google Workspaceプレミアパートナーとして5,000社以上のGoogle Workspace導入支援を行ってきました。ライセンスの契約からSPF・DKIM・DMARCを含むドメイン認証の設定、導入後のサポートまでを一括で相談できる体制を整えています。

Google Workspaceの導入と合わせてDMARCまで一度に相談したい場合や、送信元が複数部署にまたがっていてレポートの読み解きに迷う場合は、導入支援からドメイン認証の設定まで扱ってきたサテライトオフィスにぜひご相談ください。

サテライトオフィスのGoogle Workspace導入支援の詳細はこちら

※プライバシーポリシはこちら