DMARCの設定方法：安全な段階的導入の手順

DMARCの設定に必要なのは、DNSレコード1つと、守るべき手順1つだけです。まず監視モードで公開し、返ってくるレポートを読み、認証に成功していない送信を修正してから、ようやく受信側にポリシー適用を指示します。いきなりポリシー適用に進むと、自社の正規のメールが迷惑メールに振り分けられるおそれがあります。ここでは、安全な手順を順番に説明します。

結論#

DMARCは、_dmarc.yourdomain.comに設定する1つのTXTレコードです。値はv=DMARC1で始まり、ポリシー（p=none、p=quarantine、p=reject）を指定し、集計レポートを受け取るメールボックス（rua=）を指します。導入の進め方は常に同じです。まずp=noneで、何も壊さずに状況を観察します。レポートで、すべての正規のメールがSPFまたはDKIMにアライメントが一致した状態で成功していることを確認します。そのうえで、ポリシーをquarantine、最後にrejectへと引き上げます。このガイドはDMARC設定の手順書です。SPF、DKIM、DMARCが概念としてどう組み合わさるかは、SPF・DKIM・DMARCの解説をご覧ください。

DMARCレコードとは何か、どこに置くのか#

DMARCレコードは、プレーンテキストのDNSエントリです。受信側のメールサーバーに、2つのことを伝えます。自社ドメインを名乗りながら認証に失敗したメールをどう扱うか、そしてそのメールに関するレポートをどこに送るかです。特別な仕組みではなく、一度公開して、あとは状況に合わせて調整していく1つのTXTレコードにすぎません。

場所は固定されており、変更できません。レコードは、ドメイン配下のホスト名_dmarcに置く必要があります。たとえばexample.comなら、レコード名の完全な形は_dmarc.example.comです。DNSホストが「名前」または「ホスト」欄だけを求める場合は、通常_dmarcと入力すれば、ドメイン部分は自動的に補われます。

最小限の、有効な開始用レコードは次のとおりです。

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

始めるのに必要なのは、本当にこれだけです。p=noneは「何も処理しない」という意味なので、まだ何も強制しませんが、以降のすべての土台となるレポートの送信が始まります。

DMARCレコードの構成#

DMARCレコードは、セミコロンで区切られたタグの一覧です。必須なのはvとpの2つだけで、残りは任意ですが役立ちます。各タグの役割を、わかりやすくまとめます。

レコードによってはruf=タグも見かけます。これはフォレンジック（メール単位）レポートを要求するタグです。プライバシー上の理由から、現在はほとんどのプロバイダーが送信しないため、省略してruaの集計レポートだけを使って問題ありません。

DMARCのアライメントとSPF・DKIMの関係#

多くの設定で間違えやすい概念なので、ここはじっくり確認してください。SPFまたはDKIMに成功するだけでは十分ではありません。DMARCはアライメントも要求します。つまり、認証されたドメインが、受信者が実際に目にする「From」アドレスのドメインと一致している必要があります。

これが重要な理由は次のとおりです。スパム送信者は、自分のドメインでSPFに成功しながら、見える「From」行ではyourdomain.comを偽装したメールを送れます。SPFが確認するのは、受信者が読むアドレスではなく、見えないエンベロープ送信者です。そのため、SPFだけではこのメールも成功と判定されます。DMARCは、認証されたドメインと「From」ドメインの一致を求めることで、この抜け穴をふさぎます。次のいずれかが成り立てば、メールはDMARCを満たします。

• SPFのアライメント：メールがSPFに成功し、かつSPFが確認したドメインが「From」ドメインと一致している。
• DKIMのアライメント：メールに有効なDKIM署名があり、かつ署名したドメインが「From」ドメインと一致している。

アライメントが一致する必要があるのは2つのうち1つだけですが、少なくとも1つは必要です。緩和されたアライメント（デフォルト）では、組織ドメインが一致すれば認められるため、mail.example.comはexample.comとアライメントが一致します。厳格なアライメントでは、完全一致が求められます。特別な理由がなければ、緩和されたアライメントから始めてください。厳格なアライメントは、正規のメールがより多く失敗する割に、実際の保護効果はほとんど増えません。

安全な導入手順#

DMARCは、メール基盤の中でも珍しく、レコードそのものより操作の順序のほうが重要です。以下を順番どおりに進めてください。

1. 集計レポートの送信先を指定してp=noneを公開します。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comというTXTレコードを作成します。メールの扱いは何も変わらず、1日ごとの集計レポートが届き始めるだけです。送信サイクルを一通り把握できるよう、少なくとも2週間はこの状態にしておきます。

2. 集計レポートを読みます。プロバイダーは、ruaのアドレスに1日1回XMLレポートを送ります。各レポートには、自社ドメインを使った送信元IPアドレス、それぞれの送信数、SPF、DKIM、DMARCのアライメントに成功したかどうかが記載されています。生のXMLは一目では読みにくいため、多くの場合はDMARCレポートのパーサーや監視ダッシュボードに取り込み、わかりやすい表にします。確認するのは、自社のメールの正規の送信元（ESP、CRM、トランザクションメールのサービス、自社のメールサーバー）がすべて、SPFまたはDKIMのアライメントが一致した状態でDMARCに成功していることです。失敗しているものは、修正が必要な送信か、検知できてよかったと言えるなりすましのどちらかです。レポートは、すっかり忘れていた送信サービスを見つける手段にもなります。数年続いている組織では、よくあることです。生のXMLを読みたくない場合は、QualisendのDMARCレポートが、ドメインごとのレポートを送信元別に、成功数と失敗数付きでまとめます。送信元がきれいに見えてきたら、p=noneにどれだけ留まるかで、各段階へ進むための終了基準を説明しています。

3. すべての正規の送信でアライメントを一致させます。ここが本当の作業です。失敗している送信サービスごとに、そのサービスのドメインではなく自社ドメインとして認証されるようにします。そのサービスのサーバーをSPFレコードに追加し、サービスのデフォルトではなく自社ドメインでDKIM署名を設定し、サービスが対応していればカスタムのFromドメインまたはReturn-Pathドメインを設定します。優先すべきなのは、通常DKIMのアライメントです。DKIM署名はメールと一緒に届くので転送されても有効ですが、SPFのアライメントは転送された時点で崩れます。ほとんどのメール配信サービスが、カスタム署名ドメインに必要なDNSレコードを公式に案内しています。設定時間の大半はここで費やされます。レポートで正規のメールがすべて成功するようになるまで、繰り返してください。

4. p=quarantineに移行します。レポートに問題がなくなったら、認証に失敗したメールが受信トレイではなく迷惑メールフォルダーに振り分けられるよう、ポリシーを変更します。段階的な導入をpct=に頼らないでください。RFC 9989でこのタグは削除されました。古いレコードにはまだ残っていることがあり、Qualisendのドメイン診断の監視は100未満のpctにフラグを立てます。代わりに範囲で段階を分け、送信しないドメイン、サブドメイン、メインドメインの順に進めます。noneからrejectへの移行で各段階を説明しています。

5. p=rejectに移行します。ここが最終目標です。p=rejectは、認証に失敗したメールを受信側が拒否するよう指示する設定で、なりすましを実際に止められるうえ、大手プロバイダーが評価する設定でもあります。到達するのは、quarantineでしばらくレポートに問題がない状態が続いてからにしてください。これは、大量送信者向けのGoogleとYahooの送信者ガイドラインを完全に満たすポリシーでもあります。

DMARCが今では必須の理由#

かつてDMARCは、上級者向けのベストプラクティスでした。2024年以降は関門です。GoogleとYahooの送信者ガイドラインでは、大量送信者、つまりGmail宛てに1日5,000通を超えて送信する送信者は、SPF、DKIM、アライメント、ワンクリック配信停止に加えて、少なくともp=noneのポリシーを持つDMARCレコードを公開する必要があります。要件はポリシーの公開であり、必ずしもポリシー適用ではありません。しかし、p=noneのまま止めてしまうと、コンプライアンスの形式は満たせても、ドメインはなりすましに対して無防備なままです。rejectに向けて進めることが、送信者レピュテーションを守り、なりすまし犯に自社の名前で評判を傷つけられるのを防ぐ方法です。

よくある注意点#

DMARC設定がうまくいかない原因の大半は、次のいくつかの間違いです。

• いきなりp=rejectにする。監視の段階を省くと、認証に成功していない送信を、自社の請求書やニュースレターがバウンスするという痛い形で知ることになります。
• ruaのアドレスがない。レポートの送信先がないレコードは、目隠しで運転するようなものです。見えないものは直せません。必ずruaを入れてください。
• 送信サービスを忘れる。マーケティングプラットフォーム、ヘルプデスクツール、請求システム、カレンダーの招待はどれも利用者の名義で送信します。それぞれにSPFとDKIMを利用者の独自ドメイン向けに設定しておかないと、ポリシーを適用した時点でDMARCに失敗します。
• 最初から厳格なアライメントを使う。厳格なモードはサブドメインや多くのESPの構成を壊す一方、メリットはわずかです。デフォルトは、緩和されたアライメントが適切です。
• DMARCレコードが複数ある。_dmarcに置けるTXTレコードは1つだけです。2つ目があると、両方とも無効になります。SPFも同じです。
• DMARCを到達率と混同する。認証が証明するのは送信者が誰かであり、優良な送信者であることではありません。完全に認証されていても、無効なアドレスに送信しているドメインのメールは迷惑メールに振り分けられます。これは、正規のメールが迷惑メールに振り分けられる主な原因の1つです。

DMARCは、メールが確かに自社のものだと証明しますが、認証は受信トレイへの入場券にすぎません。無料プランなら検証パイプラインのすべてを実行でき、無効なアドレスやスパムトラップをバウンスする前にリストから取り除けます。信頼できる送信者としての身元が配信につながるのは、その背後にあるリストがクリーンな場合に限られるからです。