Googleが求めるDMARCに関するQ＆A（日本語版）
dmarc.orgに記載されている、DMARCの設定に関するQ＆Aを日本語に訳しました。無料でできるなりすまし対策として、ポリシーをNONEの状態で2週間から1か月程度様子をみて、問題がないと確認できればREJECTに変更をかける必要があります。
当社がメール配信を行っている日本国内の事業者におけるDMARCの設定状況を2024年7月に調査したところ、REJECT対応しているのは一部の金融機関と航空会社のみで、その他はほぼNONEのままという状態でした。
Googleの送受信ガイドライン更新に伴い導入が必須となったのにも関わらず、世界的に見ても、対策の遅れが際立っている日本において、本Q＆Aが対策推進の一翼を担うことを期待しております。
DMARC.ORGの公式Q＆A集（日本語訳）
DMARCに関する一般的なQ＆A
DMARCはなぜ重要視されるようになったのですか？
SNSやeコマースの普及にともない、悪意があるスパムやフィッシング行為実施者がユーザーのアカウントを乗っ取ってパスワード、銀行口座、クレジットカードなどを盗み、多額のお金を得ようとしています。
SPFやDKIM、DMARCがない時代の送信メールは簡単に偽装でき、知名度の高いブランドは悪意ある犯罪者たちにとっては利便性のいい権威を得るための手段でした。多くのメール受信者は、メールに有名ブランドのロゴを挿入するだけで即座に信頼してしまっていたのです。
メール受信者は必要なメールと悪意のあるメールを区別できず、また、ESP（Email Service Provider）にとってもどのメッセージが安全あるいは危険か判断をする必要がありましたが、正しい判定をできずに、その問題解決手段を探していました。
このような中、SPFおよびDKIMの展開だけでは解決できなかった問題を、DMARCを使うことでなりすまし被害軽減をできるようになったのです。
DMARCとは何？、なりすまし防止対策（フィッシング対策）にどう役立つ？
DMARCは、メール送信者と受信者が協力して、受信したメールの正当性を効率的に確認するためのプロトコルです。これにより、不正なメールを識別し、適切に処理することが可能になります。二つを使うことで、スパムやフィッシング攻撃からユーザーを守ることができます。
DMARCはメールの送受信における標準規格として、メール送信者と受信者が双方のメールに関する情報を共有することを可能にします。送信者はこの情報共有によって自身のメール認証基盤を改善し、全てのメールが正しく認証されるようになります。
さらに、正当なドメイン所有者が、自社になりすました不正なメール（スパムやフィッシングなど）を迷惑メールフォルダに振り分けたり、完全に拒否したりするよう指示できます。
DMARCはあらゆる種類のフィッシング攻撃を防ぎますか？
それは難しいです。DMARCは直接的な”なりすまし”からの保護のみを目的としています。例えば、example.co.jpの所有者や運営者がDMARCを使用してそのドメインを保護したとしても、other-domain.co.jpやexample.net（.co.jpではなく.netであることに注意）には効果がありません。
特定のドメインになりすますことは、フィッシングやその他の悪意ある活動によく使われる手法ですが、DMARCが対処できない攻撃手法も存在します。例えば、DMARCは以下のような攻撃には対応していません。
(1)類似ドメイン攻撃（攻撃対象のドメインに似た別のドメインから送信する方法。例：example.co.jpの代わりにexampl3.co.jpを使用するなど）。(2)表示名の悪用（「From」フィールドを改ざんして、攻撃対象から送信されたように見せかける方法）。これらの手法に対しては、DMARCだけでは十分な保護を提供できません。
DMARCはどのような不正なメールを対処しますか？
DMARCは直接的ななりすましから保護するように設計されています。具体的には、以下のような状況で unauthorized（未認証）の送信者からメールが送られた場合に対処します。(1)悪意のある第三者が送信した場合、(2) 同じ会社内でも、認可されていない、あるいはDMARCに参加していない部署が送信した場合
DMARCは未認証の活動を検出し、設定次第で不正なメールを受信時にブロックまたは破棄するよう要請することができます。つまり、DMARCは正規の送信者以外からのメール送信を防ぎ、なりすましによる不正なメールを効果的に排除することができます。
DMARCの仕組みを簡単に、かつ技術に精通していない方でもわかる言葉で説明すると？
DMARCポリシーは、メールの送信者が以下のことを行えるようにします。(1)自分のメールがSPFもしくはDKIMという方法で保護されていることを示す (2)受信者に対して、SPFかDKIMの認証方法が通過しなかった場合の対処法を指示します。
DMARCにより、認証に失敗したメールの扱いについて、受信者側の推測作業がなくなります。これによって、ユーザーが詐欺的または有害な可能性のあるメッセージにさらされるリスクを制限したり、排除したりできます。
さらに、DMARCは受信者が送信者に対して、DMARCの評価に合格したメールや不合格だったメールについてレポートする手段も提供します。これにより、送信者は自身のメール送信システムの状況を把握し、改善することができます。
いま、なぜDMARCが必要なの？
インターネット上の大量のスパムやフィッシングは、一般ユーザー並びに組織・団体も苦しめています。
例えばjapan.go.jpからのメールが本当にドメイン消費者から来ているかどうかを確認するための様々な方法が導入されてきました。しかし、これらの仕組みは互いに独立して機能し、各受信者が独自の判断で結果を評価し、正当なドメイン所有者（例えばjapan.go.jp）にフィードバックが届くことはありませんでした。
DMARCはこの問題に対処するため、調整された検証済みの方法を提供します。ドメイン所有者は、メール認証（SPFやDKIM）を使用していることを示し、自身のドメインを使用するメッセージ（正当なものもそうでないものも）についてフィードバックを収集するためのメールアドレスを提供し、認証に失敗したメールに適用するポリシー（何もしない、隔離、拒否）を設定できます。
一方、メール受信者は、送信ドメインがメール認証を使用していることを確実に知り、SPFとDKIMを一貫して評価しつつ、エンドユーザーの受信トレイに表示される内容と照合し、認証チェックに合格しないメールに対するドメイン所有者の希望（何もしない、隔離、拒否）を判断し、そのドメインを使用するメッセージについてドメイン所有者にフィードバックを提供できます。
メール認証を導入したドメイン所有者は、まず「監視モード（none）」でDMARCを使用し始め、参加する受信者からデータを収集します。正当なトラフィックが認証チェックに合格していることがデータで示されれば、失敗したメールを隔離するようポリシーを変更できます。
そして、正当なメールが誤って隔離されていないことが確認できれば、「拒否」ポリシーに移行できます。このように、DMARCは段階的に導入し、効果を高めていくことができるのです。
※追記：一般的には２週間から4週間の期間で拒否（REJECT）に変更することが推奨されています
メール受信者が導入しているSPFとDKIMだけでは不十分？
インターネットからメールを受信する組織・団体は、SPFやDKIMだけでなく、セキュリティ会社が提供するスパムフィルターなど、多くの技術を含む様々な方法を適用して受信メールを分析しています。
しかし、多くの場合、受信者Aが行うチェックと受信者Bが行うチェックは異なり、それらのチェックに失敗したメールの扱い方も大きく異なることがあります。
例えば、ある受信者はSPFに失敗したメッセージをやや疑わしいものとして扱う一方で、別の受信者はそのメールがスパムかどうかを判断するために高コストの詳細な分析を行うかもしれません。
DMARCは追加の分析形態の必要性をなくすわけでは、送信者と受信者が協力することで、プロセスの効率化する方法を提供します。受信者Aが送信者BがDMARCを使用していることを知ることができれば、受信者Aは送信者Bのドメインを使用するメールについて、より自信を持って判断を下すことができます。
正当なメールとそうでないメールをより明確に区別できるため、処理のオーバーヘッドを減らしつつ、より多くのスパムやフィッシングメッセージがお客さまの受信トレイに届くのを防ぐことができます。
つまり、DMARCは既存の認証方法を置き換えるのではなく、それらを補完し、より効果的に活用するための枠組みを提供しているのです。これにより、メールシステム全体の信頼性と効率性が向上します。
DMARCは追加の形式の分析の必要性を排除しませんが、参加している送信者と受信者が努力を調整することでプロセスを合理化する方法を提供します。
受信者Aが送信者BがDMARCを使用していることを確認できれば、受信者Aは送信者Bのドメインを使用しているメールに関する決定に対してより自信を持つことができます。
メッセージが正当であるかどうかをより明確に判断できるため、処理にかかる余分な手間や時間を減らし、スパムやフィッシングメールがお客さまの受信箱に到達するのを防ぐことができます。
送信者がDMARCとADSP（Author Domain Signing Practices）の両方を使用している場合はどうなりますか？
ADSPはドメイン所有者がポリシーを公開し、準拠する受信者に対してDKIMでの検証に失敗したメールを拒否するよう指示することを可能にします。ADSPは広く採用されることはありませんでしたが、異なる時期に複数の送信者と受信者によって実運用されました。
DMARCの運用においては、DMARCポリシーが発見された場合、受信者はSPFやADSPなど他の手段で公開されているポリシーを無視しなければならないとされています。
ドメイン所有者がDMARC処理を要求するためにDNSレコードを公開するには積極的な措置を取る必要があるため、DNSにまだ存在する可能性のあるADSPレコードを認識する必要があります。
万が一、DMARCとADSPが併存する場合、DMARCが優先されます。ただし、ドメイン所有者は両方のレコードの存在を把握し、適切に管理することが重要です。
“Mail From”と”From Header”の違いは何ですか？
電子メールは郵便ポストに届く郵便と同様に、メールを含む封筒の概念があります。
この封筒には、(1)ホストの挨拶、(2)”MAIL FROM:”の返信アドレス、そして(3)”Recipient To:”の受信者アドレスリストという3つの識別情報があります。メールの内容は、ヘッダーフィールドのセットと本文で構成されています。
本文は単純なテキストの場合もあれば、構造化された複数のメディアを含む”MIME”形式の添付ファイルの場合もあります。ヘッダーフィールドのセットは非常に広範囲に及ぶことがありますが、通常は少なくとも”Subject:”、”Date:”、”To:”、”From:”が含まれます。
“MAIL FROM”コマンドは、メッセージの配信に問題が発生した場合（例えば不達通知など）の返信先アドレスを指定します。一方、”From:”ヘッダーフィールドは、メールの作成者を示します。
電子メール情報の構成要素を参照する技術的な表記法は、IETFのRFCでフィールドが定義されている場所と参照される特定のフィールドに従って、RFC5321.MailFromとRFC5322.Fromとなります。
これらの情報はすべて偽装される可能性があります。DMARCは、RFC5322:Fromフィールドのドメイン名を偽装から保護することができるのです。
“Mail From”と”From Header”は異なる目的を持つ別個の要素であり、メールシステムにおいて重要な役割を果たし、DMARCは特に”From Header”のドメイン名の信頼性を確保することに焦点を当てています。
集計レポートにZIPファイルを使う理由は？
少なくとも一社が、DMARCの正式な仕様が作成される前の段階で既に非常に大きなレポートを扱っていたため、最初から大きなファイルのサポートが必要になることは明らかでした。
DMARCの仕様書の公開時までに、電子メール以外のレポート転送方法が稼働するかどうかは不明でした。
ZIPは圧縮と複数のファイル（必要な場合）を扱うことができ、すぐに使用可能でした – 既にIANAに正式に登録されたMIMEアプリケーションタイプでした。GZIPはストリーミング可能なため、より適切な圧縮形式かもしれません。GZIPがIANAにMIMEアプリケーションタイプとして登録されれば、DMARCグループはDMARCの仕様書への追加を検討します。
予防措置として、集計レポートを受け取りたい場合は、アンチスパムフィルターとメールサーバーがZIPタイプの大きな添付ファイルを受け入れることを確認してください。特定のタイプの添付ファイルを含むメールを拒否するために、正規表現タイプのフィルタリングルールを使用するのが一般的です。
少なくとも24時間経過してもレポートを受け取っていない場合は、ログを確認し、システムのドキュメントを参照して、ルールが完全かつ正確であることを確認してください。
DMARCレコードにおける “quarantine”（隔離）ポリシーとは何を意味しますか？
システム的な用語の使用を考えると、隔離とは「追加の処理のために取り置く」ことを意味しますが、受信メールインフラの管理者のとらえ方によって異なります。
これは「迷惑メールフォルダに配信する」ことを意味する場合もありますが、専門の担当者がさらに検討するためにデータベースに保持することや、配信前にメールに特定のタグを追加するだけということもあります。
つまり、”quarantine”ポリシーは、疑わしいメールを即座に拒否するのではなく、追加のセキュリティチェックや管理者の判断のために一時的に隔離し、適切な処理を行うための柔軟性を提供します。具体的な実装方法は、各組織のセキュリティポリシーやメールシステムの設定によって変わります。
なぜDMARCに新しいDNSレコードタイプを導入しないのですか？
DMARCのDNSレコードタイプについては多くの議論がありましたが、現在のところ新しいタイプを作成する進行中のプロセスはありません。
理由は多々ありますが、最も簡単な理由は、TXTエントリがDMARCの即時実装への道筋だからです。新しいDNSレコードタイプは、新しいレコードの標準化だけでなく、既存のネームサーバーへの実装も必要となるため、はるかに時間がかかります。
DMARCコミュニティがSPFのような専用のリソースレコードの使用に価値を見出す可能性はあります。しかし、その決定には多くの時間そして議論が求められます。現在のDNS TXTエントリは「実験的」とは見なされておらず、DMARCが提供する保護に興味がある人は、現時点ではTXTエントリを追加することから始めてください。
特定のDNSレコードタイプの使用はDNSの精神により合致しているものの、特定のSPFレコードタイプの導入は困難であり、多くの困難が伴います。
なぜ主要なESPはDMARCレコードを公開しないのか？
無料メールサービスでアカウントを作ればすぐに使えるのにもかかわらず、なぜメールを偽装するのでしょうか。
こう思われるかもしれませんが、実際のところ問題はもう少し複雑です。DMARCは比較的新しい技術で、その導入には優先順位の問題があります。
メールの送信者にとっては、自社ブランドを偽メールから守ることが最大の目的です。そのため、DMARCレコードを公開し、できる限り強力な保護を実施することが最優先事項となります。
一方、受信者側（メールボックスプロバイダー）の最優先事項は、ユーザーのメールボックスに偽メールが届かないようにすることです。そのため、DMARCに基づいた受信メールフィルターの実装に力を入れています。
これらの優先事項は、結果的にメール利用者全体の利益につながる形になります。
IPアドレスが様々なレポートに含まれていますが、これはプライバシーの問題にならないのか？
インターネットプロトコル（IP）アドレスは、特定の個人を識別するために使用できる場合、個人を特定できる情報（PII）と見なされる可能性があります。世界の一部では、インターネットサービスプロバイダー（ISP）があなたの自宅のモデムに割り当てたIPアドレスがPIIと見なされることがあります。
DMARCレポートに含まれるIPアドレスは、送信元のメッセージ転送エージェント（MTA）のものです。個人が自分のMTAを運用することも可能ですが、大多数のメールは多くの個別の送信者のメールのゲートウェイやリレーとして機能するMTAを経由して送信されます。
この一般的なケースでは、報告されるIPアドレスは特定の個人に直接割り当てられているわけではないため、それ自体ではPIIとは見なされません。
つまり、DMARCレポートに含まれるIPアドレスは通常、個人を直接特定するものではなく、メールサーバーや中継サーバーのアドレスであるため、プライバシーの観点からは大きな問題にはならないと考えられています。ただし、個人が独自のメールサーバーを運用している稀なケースでは、注意が必要かもしれません。
DMARC.orgの会員登録をしなくても、DMARCによる保護を受けられますか
はい、DMARC.orgの会員でなくても、DMARCによる保護を受けることができます。送信者の場合は、単にDMARCレコードの公開を始めるだけでよく、受信者の場合は、準備ができ次第DMARCポリシーの宣言に基づいて行動を開始できます。DMARCを導入している大多数の組織は、DMARC.orgの会員ではありません。
DMARC.orgの会員は、単にDMARCの仕様を正式なものにするために協力することに同意した初期の協力者たちです。この仕様が認知された標準化団体（例えば、IETF）に移管されるまで、DMARC.orgのメンバーは仕様の管理と広くコミュニティからの意見を取り入れる責任を負うことに同意しました。
つまり、DMARCの利用とDMARC.orgのメンバーシップは別物です。DMARCは誰でも自由に利用できる技術標準であり、その保護を受けるためには単にその標準に従って実装するだけで十分です。DMARC.orgは主にこの標準の開発と維持を担当する組織であり、DMARCの利用自体には直接関係しません。
DMARCに関する消費者目線のQ＆A
DMARCは消費者にどのように役立ちますか？
DMARCはESP（Yahoo!、Gmail、Outlook、など）がスパムやフィッシングメールをユーザーの受信トレイに届く前に阻止しやすくすることで、消費者のサイバーリスクを軽減させます。
これらは全て従来のスパムフィルタリングと同様に裏で行われており、消費者は結果だけを見ることになります。DMARCを採用するドメインからの不正なメールが減少するはずです。
DMARC関係者は、将来的にDMARCの結果を消費者に表示することも検討していますが、まずは標準を立ち上げ、経験を積み、広く採用されることが最初のステップです。
DMARCを機能させるために何かする必要がありますか？
消費者がDMARCを機能させるために何もする必要はありません。ESPなどがDMARCを使用して、受信トレイに届く不正なメール数を減らすことに依存しています。
なお、メール送信を行う送信者（小売業者、銀行、学校など）はメール認証技術を実装し、DMARCポリシーを公開する必要があります。
さらに、受信者（ISP、ESP、無料メールボックスサービス）はメール認証技術とDMARCポリシーメカニズムを実装する必要があります。
自分が送信するメールを保護するためにDMARCを使用できますか？
DMARCは複数のインフラサービスを通じて実装されます。典型的な消費者がISP、ESP、または無料メールボックスサービスが提供するメールサービスに依存している場合、自身でDMARCを実装することはできません。
しかし、消費者がメールボックスプロバイダーを選択しようとしている場合、または小規模ビジネスがドメインをホストする場所を決定しようとしている場合は、潜在的なプロバイダーにDMARCと関連するメール認証技術を実装しているかどうか確認したほうがいいでしょう。
自分のESP、銀行、学校などがDMARCを使用しているかどうかを知るにはどうすればよいですか？
最も迅速で最新の方法は、お気に入りの検索エンジンを使用することかもしれません。組織の名前と「DMARC」を入力し、公開発表があるかどうかを確認してください。
DNSレコードの表示方法（例：「dig」コマンドの使用）を知っている場合は、DMARC TXTリソースレコードを公開しているかどうかも確認できます。必ず受信メールにDMARCをサポートしているということではありませんが、送信メールを保護するためにDMARCを使用していることを示しています。
メール認証とDMARCを採用している組織を示すスコアカードを作成しようとしているサイトが少なくとも1つあります。これへのリンクや、私たちの注目を集めた追加のサイトについては、リソースページをチェックしてください。
DMARCを使用しているESPを見つけるにはどうすればよいですか？
最も迅速で最新の方法は、お気に入りの検索エンジンを使用することかもしれません。メールボックスプロバイダーの名前と「DMARC」を入力し、プロバイダーが公開発表をしているかどうかを確認してください。
メール認証とDMARCを採用している組織を示すスコアカードを作成しようとしているサイトが少なくとも1つあります。これへのリンクや、私たちの注目を集めた追加のサイトについては、リソースページをチェックしてください。
メールがDMARCをパスしたかどうかを知るにはどうすればよいですか？
DMARC標準は、DMARCチェックをパスしたメールに存在する、または消費者が受信トレイを表示する際に見える指標を指定していません。
メールがDMARCをパスしたかどうかを推測する唯一の方法は、送信者（例：primoposto.co.jp）と受信者（例：Yahoo!、Gmail、Outlook、など）の両方がDMARCを実装しているかどうかを確認することです。
なぜウェブサイトXの「この記事を友人にメールする」ボタンが機能していないのですか？
理由はいくつか考えられます。それは、そのウェブサイトがこの機能をどのように実装しているかによります。
過去によく使われていた方法の一つは、あなた（サイト訪問者）のメールアドレスを使って、あなたのメールサービスになりすますというものです。これは犯罪者が好んで使う手口です。そのため、あなたのメールアドレスを悪用から守り、スパムを除去するために、様々なブロック機能が導入されています。
DMARCは、メール送信のためのドメインの不正使用を制御するのに役立つように設計されています。あなたが使用しているウェブサイトが上記のようにこの機能を実装し、あなたのメールアドレスがDMARCポリシーを主張するドメインにある場合、メールは配信されない可能性があります。
最も簡単な対策は、リンクまたは記事をコピーし、お気に入りの個人用メールプログラムを使用して友人に送信することです。問題のウェブサイトの改善をする場合は、代わりに自分のメールアドレスを使用してそのようなメールを送信することを提案してください。
DMARCに関するメール受信者目線のQ＆A
メール送信者がDMARCを気にする必要があるのはなぜ？
多くのドメイン所有者は、自社のメールシステムから送信されるメッセージのログを収集し、特定の宛先への配信率や1日の業務におけるトラフィックの流れなどを分析しています。
しかし、メール受信者の視点から見た自社ドメインを使用するメッセージ（不正なメッセージや、誤って不正とラベル付けされたメッセージを含む）についての洞察を得ることは非常にまれです。DMARCにより、送信者やドメイン所有者は以下のことが可能になります。
(1)DMARC対応の受信者から、自社ドメインを使用するメッセージに関する統計情報を収集する
(2トラフィックのうち、どれだけがメール認証チェックに合格もしくはるかを確認する
(3認証に失敗した自社ドメインを使用するメッセージを隔離または拒否するよう要求する
(4受信者がこのサービスを提供している場合、失敗したメッセージからヘッダー情報やメッセージ本文のURIなどの抽出データを受け取る
これにより、自社のインフラの運用状況、第三者が代行して運用しているインフラの状況、そして悪意のある者によるドメインやブランドへの攻撃について、前例のない洞察が得られます。
まず第一に、メール認証方法を採用し、それをすべてのメッセージに適用することで、DMARC準拠の受信者が自社ドメインを使用する悪意のある者をより良く検出できるようになります。これは、ブランドと、これらの受信者と共有すお客さまを保護するのに役立ちます。
例えば、断続的なDNSの問題により、自社のメッセージングインフラからの1万通の正当なメッセージが主要なメールボックスプロバイダーによって不正とみなされた場合、それを定期的なレポートで知ることができると想像してみてください。
これはメッセージ量の小さな割合かもしれませんが、重要なメッセージを受け取れなかった多くの怒ったお客さまがカスタマーサービス担当者に電話をかけることになります。
第三者を使ってお客さまにメッセージを送信している場合、これらのレポートは特定の受信者にどれだけのメッセージが配信されているかを追跡するもう一つのデータソースとなります。さらに、これらのベンダーがメール認証を正しく実装しているかどうか、そうでない場合にメッセージがその理由でブロックされたかどうかを確認できます。
また、失敗したメッセージレポートを共有する受信者の場合、ドメイン所有者は詐欺師がお客さまをどのように攻撃しているかの正確な詳細を把握できます。メッセージヘッダーからの詳細情報、そしてしばしばメッセージ内に見つかるURIの文字列が、メッセージ受信後短時間で利用可能になり、フィッシングサイトの削除プロセスを大幅に改善することができます。
DMARCは、受信者のスパムフィルターをすり抜けたり、通常のメール送信制限を突破する？
答えは「いいえ」です。DMARCは、メールが本当に送信者が主張する場所から来たものかを確認する仕組みです。つまり、「このメールは本当にABC社から来ました」ということを証明するのに役立ちます。しかし、DMARCには以下のような限界があります。
スパムフィルター：DMARCはメールの内容が正当かどうかを判断しません。そのため、受信者のスパムフィルターは依然として機能し続けます。
送信制限：DMARCは送信量に関する制限を変更しません。受信者が設定している1日あたりの受信可能なメール数などの制限は、そのまま適用されます。
DMARCは主に「なりすまし」を防ぐためのものです。正当な送信者であることを証明するのに役立ちますが、それだけでスパム対策やメール送信のルールが免除されるわけではありません。つま り、DMARCを使っていても、受信者側のセキュリティチェックや送信制限は通常通り適用されます。
DMARCに関するメール送信者目線のQ＆A
送信者がDMARCを気にする必要がある理由は何ですか？
DMARCは送信者やドメイン所有者に以下のような価値を提供します。
1. DMARC対応の受信者から、自社ドメインを使用するメールの統計情報を収集できます。
2. メール認証チェックのうえ成功率ならびに不成功率を確認できます。
3. 認証に失敗したご自身のドメインによるメールを隔離または拒否し、未設定によるなりすましの被害を軽減できます。
4. 認証に失敗したメールから抽出されたデータ（ヘッダー情報やURL等）を受け取れる場合があります。
メールインフラの運用状況や第三者による代行送信、つまり悪意のあるフィッシング攻撃等を監視することができます。
DMARCはスパムフィルターの役割も果たしますか？
DMARCはそのような機能はありません。
DMARCは、メールが本当に送信者が言っている場所から来たかどうかを確認する仕組みです。つまり、「このメールは本当にABC社から来ました」ということを証明するのに役立ちます。
なお、DMARCは次のようなことができません。
(1)スパムフィルター：DMARCはメールの内容が良いか悪いかを判断しません。そのため、受信者のスパムフィルターは今まで通り働き続けます。
(2)送信制限：DMARCは1日に送れるメールの数などの制限をしません。受信者が設定している制限は、そのまま適用されます。
DMARCは主に「なりすまし」を防ぐためのものです。正当な送信者であることを証明するのに役立ちますが、それだけでスパム対策やメール送信のルールが免除されるわけではありません。つまり、DMARCを使っていても、受信者側のセキュリティチェックや送信制限は通常通り適用されます。
DMARCの実装が100％でないのに、なぜ今DMARCを採用すべきなのですか？
DMARCを採用すべき理由は以下の通りです。
(1) DMARCを実装している少数の受信者が、インターネットメールユーザーの大部分を占めています。
(2) 多くの大手受信者は、DMARCを実装していなくても、SPFとDKIMの組み合わせを実装しています。
(3) より多くの送信者がDMARCを実装すると、まだ実装していない受信者にとってもDMARCの実装がより魅力的になります。
(4) より多くの受信者がDMARCを実装すると、集計レポートを通じてより多くの情報を得ることができます。
なお、2023年10月にGoogleが更新したGmailに24時間で5,000通以上配信する方に対するガイドラインにおいて、DMARCの設定が求められたため、Gmailにメール配信をするかたは対応が求められます。
DMARCが効果を発揮しているかどう確認できますか？
DMARCレコードを公開してから1〜2日後、DMARC受信者からレポートが届き始めます。このレポートには以下の情報が含まれます。
(1) ドメインを使用してメールを送信しているすべてのIPアドレス
(2) それぞれのIPアドレスからのメッセージ数
(3) DMARCポリシーに基づいてメッセージがどのように処理されたか
(4) SPFとDKIMの結果
これらのレポートを分析することで、DMARCの効果を判断できます。
他のメールフローに影響を与えずに、DMARCを段階的に実装できますか？
もちろんできます。実際、DMARCポリシーを少しずつ導入、強化できるようにすることは、DMARCの仕様を設計する際の主要な目標の一つでした。なので、3段階の設計があります。
(1) 監視モード（none）でDMARCレコードを設定します。
(2) SPFとDKIMを導入し、レポートを確認します。
(3) 「隔離（quarantine）」ポリシーを実装し、徐々に適用率を上げます。
(4) 最終的に「拒否（reject）」ポリシーを実装し、同様に徐々に適用率を上げます。
凡そ2週間から4週間かけて、rejectまでもっていく運用が一般的になっております。
自分が送信した以上の情報がレポートにあるのはなぜですか？
レポートには次のようなメールの認証結果が含まれるためです。
(1) 自社のインフラから直接送信されたメール
(2) サードパーティが代理で送信したメール
(3) 転送されたメール
(4) なりすましのメール（フィッシング攻撃など）
これらの情報により、自社ドメインを使用しているすべてのメールを把握できます。フィッシング攻撃の対象になっている場合は、自社で実際に送信したメール数よりも多くの情報がレポートに含まれる可能性があります。
悪意の攻撃者がFrom:の表示フィールドを使って自社ブランドやドメインを偽装した場合はどうなりますか？
これDMARCの対象範囲外です。主にユーザーインターフェースの問題であり、DMARCが提供する仕組みでは適切に対処できません。
これには2つ課題があります。
(1) メールクライアントはFrom:のアドレス部分をユーザーに表示すべきです。一部の企業は、これが一般的なユーザーの行動を変えないと結論づけていますが、ドメインの評判に関する慎重に選ばれた指標と組み合わせることでより効果的かもしれません。
(2) ドメイン名を保護することで、実際のドメインの評判を偽のドメインの評判から分離します。例えば、誰かが次のようなFromヘッダーを使用した場合：
表示方法に関わらず、ユーザーの反応はmiscreant.example.co.jpに適用され、有名大手銀行の実際のドメインには適用されません。そのため、DMARCの防御機能が一定作動します。
一般的に、偽のメールを送信しているメール送信元のIP並びにドメイン評判は急速に悪化し、その評判に基づいてメールは隔離または拒否されます。なお、自社ブランドのドメインは、悪意のある人の行動に基づいてメールを送信する能力を失うことはありません。
DMARCの「p=none」ポリシーは、メールの配信方法に影響しますか？
いいえ、影響しません。「p=none」ポリシーは、DMARCチェックが失敗した場合でも、ドメイン所有者が受信者に何らかのアクションを求めていないことを意味します。
このnoneのポリシーには以下のような特徴があります。
(1) ドメイン所有者は、SPFもしくはDKIMを導入していなくても、自身のドメインを使用しているメッセージに関するレポートを受け取ることができます。
(2) レポートを通じて、悪意がある攻撃者。つまり、フィッシャーなどによってドメインが悪用されているかどうかを判断できます。
(3) メールの扱い方に変更はありませんが、ドメイン名で送信されているメールの状況が把握できるようになります。
【注意事項】
(1) SPFやDKIMを導入しから、DMARCを導入してください。
(2) 初期の導入時は1つのパラメータのみを変更し、レポート機能があるためDMARCから始めることを推奨します。
SPFやDKIMを導入済みの場合、このポリシーを使用することで、すべての自社ドメイン発のメールの保護と進捗の監視ができます。認証対策を実装しながらドメインを監視することで、「p=quarantine」や「p=reject」などのより積極的な保護アクションを要求するポリシーに移行する前に、潜在的な影響を評価できます。
また、受信者はDMARC以外にも多数のフィルタリング対策を使用している可能性があることに注意してください。
これらのメカニズムには、メッセージ内容のスキャン、送信IPアドレスに関連する評判、SPFやDKIM結果のチェックなどが含まれる場合があります。
そのため、ドメイン所有者が「p=none」ポリシーを公開していても、受信者は疑わしいと判断したメッセージや、SPFまたはDKIMチェックに失敗したメッセージに対して、これらの他のメカニズムに基づいてアクションを取る可能性があります。
DMARCを使用することで、ドメイン所有者はそのようなメッセージに関する統計を受け取り、どのIPアドレスから送信されたか、SPFやDKIMに合格したか失敗したかを把握し、それに応じて是正措置を取ることができるようになります。
最初の集計レポートはいつ受け取れますか？
集計レポートは通常1日1回生成されます。DNSにDMARCレコードを公開してから、最初のレポートを受け取るまでに少なくとも24時間かかります。注意点として、この期間中にあなたのドメインを使用するメッセージが特定のDMARC受信者に送信された場合にのみ、レポートが生成されます。
example.co.jpのDNSに設定するDMARCレコードの例です。受信者はメールの処理方法を変更せずに集計レポートの生成を開始し、関連するpostmasterメールアドレスに送信するよう指示されます。
_dmarc.example.co.jp TXT "v=DMARC1;
p=none; pct=100;rua=mailto:postmaster@example.co.jp"よく設定誤りとして、メールアドレスの一部としてmailto:の記述漏れです。DMARCレコードの構文を確認してください。
レポートをドメイン外のアドレスに送信するよう指定した場合、受信側に特別なDMARCレポートDNSレコードを公開するよう要求する必要があります。
_dmarc.example.co.jp TXT "v=DMARC1;
p=none; rua=mailto:aggregate@thirdparty.co.jp"
example.co.jp._report._dmarc.thirdparty.co.jp TXT "v=DMARC1"レポートは非常に大きくなる可能性がありますが、多くのサイトでは10MBに制限されています。接続するIPごとにレコードが含まれ、任意のメールからドメインでのDKIMとSPF検証の組み合わせが含まれる可能性があります。
フィッシングの標的になっている場合、これは非常に大きくなる可能性があります。有効なメールから生成するレポートがはるかに小さくても、いつでも10MBのレポートを受信できるよう準備してください。
予防措置として、集計レポートを受け取りたい場合は、アンチスパムフィルターとメールサーバーがZIP形式の大きな添付ファイルや、名前に”.co.jp”を含む添付ファイルを受け入れるようにしてください。
特定の種類の添付ファイルや実行可能ファイルの可能性がある名前を含むメールを拒否するために、正規表現型のフィルタリングルールを使用するのが一般的です。24時間以上経過してもレポートを受け取っていない場合は、ログを確認し、システムのドキュメントを参照して、ルールが完全で正しいか確認してください。
DMARCフォレンジックレポート（ruf=）を受け取るべきですか？
大量のメッセージを受け取る準備ができるまでは、DMARCフォレンジックレポートは受け取らないでください。
DMARCフォレンジックレポートは自社のメール送信ソフトのバグや、フィッシングなどのなりすまし攻撃を見つけるのに便利です。しかし、DMARCポリシーによってメッセージが拒否されるたびに、即座に失敗レポートが送られてくるので要注意です。
さらに、メールが受け入れられても、認証の一部が失敗した場合にもレポートが送られることがあります。このレポートには、拒否されたメールの内容がそのまま含まれることもあります。
自社のメール送信は適切で、拒否されるメールは少ないはずだと思うかもしれません。しかし、そうではありません。
あなたのドメインを偽装するすべてのメールも拒否され、そのコピーがあなたに送られてきます。これは、正規のメールの何倍もの量になる可能性があります。
なので、十分な準備ができるまでは、失敗レポートを受け取るべきではありません。まずはポリシーを（「p=none」）で簡単なレコードを公開し、集計レポートだけを取得することです。
_dmarc.example.co.jp IN TXT "v=DMARC1;
p=none; pct=100; rua=mailto:dmarc-rua@example.co.jp"集計レポートを調査し、自社のメールインフラを理解し、ポリシーを拒否に変更した場合に何が起こるか、特にどれくらいの失敗レポートを受け取る可能性があるかを理解してください。
運用の目途がたてば、rua=タグが指すメールボックスとは別のメールボックスを指す「ruf=」タグを追加してください。
_dmarc.example.co.jp IN TXT "v=DMARC1;
p=reject; pct=100; rua=mailto:dmarc-rua@example.co.jp;
ruf=mailto:dmarc-ruf@example.co.jp"
MailChimpなどのサードパーティのメール送信機能を使用していますが、どうすればDMARC準拠にできますか？
MailChimpやSalesforceなどのサードパーティを使ったメール送信がDMARCポリシーによって拒否されないようにするためは、いくつかの対策があります。
【外部統合】例えば、MailChimpがあなたの会社のメールを送信する場合。
(1)「newsletter.yourcompany.co.jp」のようなサブドメインをMailChimpに委託します。MailChimpは自社のDKIMとSPFレコードをこのサブドメインに設定します。あなたの会社のメインドメインのDMARCレコードがこれをカバーするので、MailChimpは別途DMARCレコードを公開する必要はありません。
(2) MailChimp専用のDKIM鍵を作成し、秘密鍵をMailChimpに渡し、公開鍵をあなたの会社のDNSに公開します。また、MailChimpの送信IPアドレスをあなたの会社のSPFレコードに追加します。
【内部統合】例えば、Salesforceがあなたの会社のCRMシステムからメールを送信する場合
Salesforceに、あなたの会社のメールサーバーを経由して全てのメールを送信するよう設定します。この方法では、全てのメールがあなたの会社のサーバーから直接送信されるように見えます。
【統合しない】例えば、SurveyMonkeyがアンケート調査のメールを送信する場合
SurveyMonkeyに、From:ヘッダーに「noreply@surveymonkey.co.jp」のような自社のドメインを使うよう依頼します。返信が必要な場合は、Reply-To:ヘッダーに「support@yourcompany.co.jp」のようなあなたの会社のアドレスを設定してもらいます。
DMARCレコードを公開しましたが、失敗レポートやDMARCフォレンジックレポート（ruf=）が届かないのはなぜですか？
レポートを受け取るには、次の条件を満たす必要があります。
(1) 有効なメールアドレスを指す「ruf(Report URI for Aggregate)」エントリーがあること。
(2) そのアドレスが組織のドメインと同じドメインであること。または、別のドメインからのレポート受信を許可するDNS「レポート」レコードを公開すること。
【DMARCレコード例】
_dmarc.example.co.jp. TXT "v=DMARC1;
p=none; rua=mailto:dmarc-feedback@example.co.jp;
ruf=mailto:auth-reports@thirdparty.example.net"【レポート許可レコードの例】
example.co.jp._report._dmarc.thirdparty.example.net. TXT "v=DMARC1"※注意点
(1) 失敗レポートは大量に届く可能性があります。集計レポートを使用して予想される失敗レポートの数を確認してから、「ruf(Report URI for Aggregate)」を公開することをお勧めします。
(2) すべての受信者が失敗レポートを送信するわけではありません。そのため、失敗レポートを受け取らない、または予想より少ない数しか受け取らない場合があります。
(3) データ共有に関するルールは地域によって異なるため、失敗レポートの実装は最終的に受信者の裁量に任されています。
(4) DMARCの標準では、受信者が集計レポートを送信しても、失敗レポートを送信しないことが認められています。
別のドメインにDMARCフォレンジックレポートを送るDMARCレコードを公開しましたが、レポートが届かないのはなぜですか？
DMARCレポートを受け取るには、DMARCレコードに「rua(Report URI for Aggregatex)」や「ruf(Report URI for Aggregate)」タグが必要です。これらのタグのアドレスがレコードを公開しているドメインと異なる場合、受信側のドメインに「外部レポート承認」レコードが必要です。
例えば、以下のようなDMARCレコードがあるとします。
_dmarc.example.co.jp. TXT "v=DMARC1;p=none;
rua=mailto:a-reports@otherdomain.co.jp;
ruf=mailto:f-reports@otherdomain.co.jp"この場合、otherdomain.comの所有者あるいは管理者は、example.co.jpのレポートを受け取る意思を示すために、次のようなDNSレコードを公開する必要があります。
example.co.jp._report._dmarc.otherdomain.co.jp.
TXT "v=DMARC1"
複数のドメイン所有者が全てのレポートを1つのドメインのメールボックスに送りたい場合は、それぞれ外部レポート承認レコードを公開する必要があります。
DNSのワイルドカードレコードを使用して、任意のドメインからのレポートを承認または受け入れることも可能です。
なお、この方法を使うと、あらゆるドメインのレポートでも受け入れることになるため、悪意のある攻撃者に悪用される可能性があることに認識して活用ください。
会社のメール送信ドメインにDMARCを導入する手続きを教えてください
一般論として多くの事業者で有効な手順を簡単に説明します。
(1) まず、「p=none」と設定したDMARCレコードを作ります。レポートを受け取るための特別なメールボックスも用意します。ただし、この時点ではDMARCフォレンジックレポートを受け取る「ruf=」は設定しないでください。サーバーに負担がかかる可能性があります。
(2) 受け取ったレポートを読んで、自社のメールシステムの状態を診断します。SPFとDKIMが正しく動くようにします。
(3) Mailchimpなどの会社にメール送信を頼んでいる場合は、その会社もDMARCに対応しているか確認します。
(4) 自社のシステムがほぼ正しく動いていることがわかったら、「ruf=」レコードを追加するかどうか決めます。追加する場合は、「rua=」とは別のアドレスを指定します。
(5) 受信メールにDMARCフィルターを追加し、すべてのレポートを再確認します。
(6) メールシステムをさらに改善します。受信メールのDMARCフィルターで、まだ気づいていなかった問題が見つかるかもしれません。
(7) DMARCフィルターで、信頼できる大学からの転送サービスを許可リスト（ホワイトリスト）に追加します。
(8) 従業員が使っているメーリングリストも許可リスト（ホワイトリスト）に追加します。
(9) フィッシング等に問題がないか確認します。
(10) DMARCが正当なメールを拒否してしまう可能性がある場合が2つあることを覚えておきましょう。
1. メール転送
2. メーリングリスト
(11) 取引関連のメールを社員のメールとは別のドメインに移すことを考えましょう。
(12) 社員には、メーリングリストに登録する時は個人のメールアドレスを使ってもらいます（メーリングリストがDMARCに対応するまで）。
(13) すべての外部業者にDMARCに対応してもらいます。
(14) これで「p=quarantine」や「p=reject」に移行する準備ができました。
(15) 導入完了です。
一度で多数のドメインをDMARCレコードに設定するにはどうすればいいですか？
ブランド保護などの理由で多数のドメイン名を登録している組織もあります。DMARCレコードにCNAMEを使用し、レポート用にワイルドカードを使用できます。
_dmarc.example.co.jp. IN TXT "v=DMARC1;
p=none; rua=mailto:dmarc-rua@example.co.jp"_dmarc.example.net.
IN CNAME _dmarc.example.co.jp.*._report._dmarc.example.co.jp
IN TXT "v=DMARC1"これで管理するDMARCレコードは1つだけになります。レポートレコードが必要な理由は、example.netの集計レポートを別のドメイン（example.co.jp）に送信するよう要求しているからです。
ワイルドカードを使用することで、このドメインは任意のドメインに関するレポートを受け取る意思があることを示しています。不要なレポートを受け取らないように、dmarc-rua@example.co.jpのメールボックスに適切なメールフィルタリングを設定してください。
【この方法のメリットについて】
– 複数のドメインのDMARC設定を一元管理できます。
– 設定変更が容易になります。
– レポートの受信を1つのメールアドレスに集約できます。
※注意点
ワイルドカードを使用すると、予期しないドメインからのレポートも受信する可能性があります。
すべてのドメインに同じDMARC設定を適用することになるため、個別の設定が必要な場合は別の方法を検討する必要があります。
マーケティング会社として、お客さまにDMARC準拠のメール送信をするにはどうすればよいですか？
この質問への答えは、お客さまとの関係やメールの送信方法によって様々です。大きく分けて2つの場合があります。
(1) 自社ブランドでお客さまの代わりにメールを送る場合（例：customerbrand@marketingbrand.co.jp）
この場合、SPF、DKIM、DMARCを使って自社のメールを認証できます。
(2) お客さまのブランドでメールを送る場合（例：marketingname@customerbrand.co.jp）
この場合、認証されたメールを送るためにお客さまと密接に協力する必要があります。SPFかDKIM、できれば両方が通るようにする必要があります。
■ SPFの場合
お客さまのSPFレコードに、あなたの送信元IPアドレスを含めてもらう必要があります。
■ DKIMの場合
– お客さまのドメインでメールに署名できる鍵を提供してもらう
– あなたが署名用の鍵を生成し、公開鍵をお客さまに公開してもらう
– お客さまのインフラを経由してメールを中継し、お客さま側で署名してもらう
※注意点
– お客さまにあなたの送信IPをホワイトリストに登録してもらう方法は、メールの宛先がお客さまのドメインだけの場合にのみ有効です。
– メーリングリストを経由したり、DMARCの整合性検証に違反するような転送がされたりた場合、機能しません。
【実施手順】
(1) 本番使用前に、多くの異なるメールボックスに送信してテストしましょう。
(2) お客さまのDMARC設定を「p=none」レコードとして2週間から1か月公開してもらい、データを収集します。
(3) この方法を学んだら、DMARC準拠を望むお客さまからの要請に対応する方法を組織内においても共有しましょう。
メールが突然スパムフォルダに入るようになりました。DMARCが原因でしょうか？
一般的に、DMARCはメールの受信箱への振り分けには関与しません。DMARCを正しく設定していれば、メールがスパムと判断されるかどうかは変わりません。
だからこそ、最初はp=noneというゆるい設定のDMARCレコードから始めることが推奨されています。この設定なら、メールの扱われ方を変えずに、どんな結果になるか様子を見ることができます。その後で、必要に応じて隔離（quarantine）や拒否（reject）といったより厳しい設定に変更するのが望ましいです。
DMARCはメールを振り分けるフィルターではなく、「このメールは本当にその送信者から来たものか」を確認するためのルールです。DMARCの目的は、あなたのメールシステムからではない偽物のメールを受信者に拒否してもらうことです。
もし「p=quarantine」（隔離）という設定にしていて、何か問題があれば、あなたが「隔離してください」と言っているので、メールはスパムフォルダに入ります。
「p=none」ポリシーの場合、DMARCは受信者側では何も対応をしません。
システム担当部門などの詳しい人なら、メールの中身を見て、次のような情報をチェックできます。
Authentication-Results: mail.example.co.jp;
spf=pass smtp.mailfrom=member@example.co.jp;
dkim=pass header.d=example.co.jp;dmarc=pass d=example.co.jpこのメールのヘッダー情報は、mail.example.co.jpというサーバーが3つのチェックを行ったことを示しています。
– SPFチェック
– DKIMチェック
– DMARCチェック
そして、これら3つのチェックすべてに合格したということを表しています。簡単に言えば、このメールは本物で、信頼できる送信元から来たものだとサーバーが判断したということです。
メール送信に使わないドメインを持っています。これらをどのように保護できますか？
以下の例では、BINDのレコード表記を使用しています。必要に応じて、お使いのネームサーバーの形式に変換してください。
(1) まず、メインのドメイン（例：example.co.jp）に、使っていないすべてのドメイン用のDMARCレコードを作ります。
_dmarc.parked.example.co.jp IN TXT
"v=DMARC1; p=reject; rua=mailto:aggregates@example.co.jp;"(2) 例えば、example.netが使っていないドメインの場合、次のような形で保護できます。
_dmarc.example.net IN CNAME _dmarc.parked.example.co,jp
example.net IN TXT "v=spf1 -all" *.example.net
IN TXT "v=spf1 -all"CNAMEを使うと、すべての使っていないドメインを一箇所で管理できます。例えば、すべての使っていないドメインの失敗レポートを受け取りたい場合、このように1つの記録を更新するだけでOKです。
_dmarc.parked.example.co.jp IN TXT "v=DMARC1;
e p=reject; rua=mailto:aggregates@example.co.jp; ruf=mailto:failures@example.co.jp;"これで、このCNAMEを使っているすべてのドメインが更新されます。SPFの記録にある「*」（ワイルドカード）は、このドメイン下のすべてのサブドメインやホストを保護します。
(3) example.comのメールボックスでexample.netのレポートを受け取るには、こんな記録も必要です：
example.net._report._dmarc.example.com IN TXT "v=DMARC1;"(4) 使っていないドメインがたくさんある場合は、それぞれに記録を作る代わりに、こんな方法も使えます：
*._report._dmarc.example.com IN TXT "v=DMARC1;"この方法を使うと、どんなドメインのレポートも受け取ってしまう可能性があるため、システムへの負担に注意ください。
なお、この保護はDMARCに対応しているメール受信者に対してのみ有効です。