概要
電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。
本記事は、DMARC認証についてまとめたものです。
SPF、DKIM、DMARC、ARC、BIMIといった送信ドメイン認証を俯瞰的にまとめた記事はこちらです。
本記事の目的
- DMARC認証の概要を理解する。
- DMARC対応の際してのポイントを把握する。
※本記事では、整理しておきたいポイントを中心に記載しています。ネット上に解説記事が多そうな内容については省略している場合があります。
目次
基本
DMARCの認証対象と認証成否
- メールのFromヘッダのドメインを認証します。
- ヘッダFromのドメインのDNSに登録されたDMARCレコードに基づいてSPFとDKIMの認証結果を検証し、いずれかが成功であれば認証成功です。
具体的には、以下のいずれかの認証が成功("Pass")すれば、DMARCとして認証成功ということです。 - DMARCレコードを保有するDNSドメインの管理元により、そのメールのヘッダFromに対して、以下のいずれか、あるいは両方を担保するものです。
- SPF認証が成功した場合
「そのIPアドレスが、該当ドメインをエンベロープFromドメインとして使用することを許可されている」という点、および「そのエンベロープFromドメインはヘッダFromのドメインと一致している」という点
※DMARCではalignmentによりFromドメインとエンベロープFromドメイン(RFC5321.MailFromのドメイン)と一致するSFPのみを扱う。詳細は後述のalignment modeに補足あり - DKIM認証が成功した場合
「メールに署名することを認められたメール送信システム、あるいはメール中継システムが、そのメールの配送経路上に存在した」という点、および「その電子署名の中で指定されたドメインはヘッダFromのドメインと一致している」という点
※DMARCではalignmentにより作成者署名のDKIMのみを扱う。詳細は後述のalignment modeに補足あり
※”署名することを認められた"という表現は、検証に成功する署名を作成できるのは、DNSレコード上の公開鍵とペアになる秘密鍵を持つシステムのみであるという意味
- SPF認証が成功した場合
認証時の動作
- メールを受信する側が、上記の認証を行います。
- "ヘッダFromのドメインと一致するドメイン"に対するSPFまたはDKIMの認証結果を検証することを、DMARCのalignmentと呼びます。一致するドメインのみを対象とすることで、SPF単体やDKIM単体では実現できなかったヘッダFromと紐づく認証を実現できます。
- メールを受信する側が、ヘッダFromのドメインに対するDMARCレコードをDNS問合せた際、レコードが見つからなかった場合、そのドメインの組織ドメイン(Organizational Domain)に対するDMARCレコードをDNS問合せし直します。
例えば、ヘッダFromが"@a.b.c.d.example.com"のメールを受信した際、"a.b.c.d.example.com"に対するDMARCレコードが見つからなかった場合、"example.com"のDMARCレコードを検索する動作になります。
この仕様の詳細は、RFC 7489の"6.6.3. Policy Discovery"、"3.2. Organizational Domain"に記載があります。
ちなみに、これはドメインのレベルを1つずつ減らしながら繰り返し問い合わせるDNSデボルブ(DNS devolution)とは異なる動作です。
DMARC対応に必要な設定
- DMARC対応に必要な設定は、基本的にDNSレコード登録のみです。
- DMARCレポートを受け取る場合にはレポートを受信するための管理者用のメールアドレスが必要です。
- なお、DMARCはSFPとDKIMを前提としますが、実際にはどちらかを導入済みであれば、DMARCレコードの登録によりDMARC対応できます。
基本的に、SPFとDKIMの両方に対応済みであることが望ましいです。 - 設定に際しての補足事項は別記事にまとめる予定です。
認証結果
DKIMの認証結果は、大きく"Pass"か、"Pass以外"("Fail"等)に分類できます。種類は以下の通りです。
認証結果
- DMARCの認証結果は、大きく"Pass"か、"Pass以外"("Fail"等)に分類できます。全ての種類は以下の通りです。
- DMARC(RFC 7489)では、以下が定義されています。
"SUCCESS"、"PERMFAIL"、"TEMPFAIL"が定義されています。
- pass
- fail
- temperror
- permerror
- DMARC(RFC 7489)では、以下が定義されています。
"SUCCESS"、"PERMFAIL"、"TEMPFAIL"が定義されています。
- DMARCの認証結果は、大きく"Pass"か、"Pass以外"("Fail"等)に分類できます。全ての種類は以下の通りです。
- 認証結果は、送信ドメイン認証において共通的に使用されるAuthentication-Results(AR)ヘッダに記録されます。ARヘッダの詳細は別記事にまとめる予定です。
詳細
導入ステップや運用ポリシーに応じた調整のポイント
- 本格的にDMARC対応するかどうかに関わらず、まず試験的にポリシー"p=none"にてDMARCレコードを公開すると良いです。"p=none"であれば、自ドメインからのメールがDMARCにより拒否されることは基本的にありません。
DMARCレコードを公開することで、DMARCレポートを受信できるようになるので、自ドメインから送信されるメールの配送状況(送信ドメイン認証失敗の状況)を分析できます。DMARCレポートを受信するには、ruaタグ、rufタグの指定が必要です。 - DMARC対応は、最終的にp=none以外(reject,quarantine)のポリシーで運用することで正式なものとなります。p=none以外の設定を、DMARC Enforcementと呼ぶことがあります。
- 補足
- DMARCは、送信ドメイン認証自体の他、ポリシー定義(p=)やレポートの機能が特徴的です。また、アラインメントモード(alignment mode)を調整することもできます。
- ポリシー定義は、自ドメインからのメールを受信する側においてDMARC認証が失敗した際、そのメールをどのように扱って欲しいかを示すことができます。 DMARCレコード中のpタグにて指定します。
指定可能な値は、"none"(何もせず受信)、"quarantine"(隔離)、"reject"(拒否)です。
以下にいくつか大手メールサービスのDMARCレコードの例を記載します(2022年8月時点)。Gmailはp=none、米Yahooはp=reject、日本のYahoo(yahoo.co.jp)はp=noneです。_dmarc.gmail.com. 600 IN TXT "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
_dmarc.yahoo.com. 1800 IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"
_dmarc.yahoo.co.jp. 900 IN TXT "v=DMARC1; p=none; rua=mailto:ymail_dmarc_report@yahoo.co.jp"
- DMARCレポートは、以下の2種類があります。
- aggregate feedback
ruaタグで指定したアドレスに送信される集約レポートであり、1日1回など、ある期間の認証結果をまとめたもの - message-specific failure information
rufタグで指定したアドレスに送信される認証失敗レポート、認証失敗が発生するたびに送信される
- aggregate feedback
- アラインメントモード(alignment mode)は、DMARCレコード中のadkimタグ、aspfタグによりalignmentの厳密さを指定します。adkimタグはDKIM用のアラインメントモード、aspfタグはSPF用のアラインメントモードをそれぞれ指定します。
指定可能な値はr(relaxed mode)、s(strict mode、デフォルト)です。
- strict mode:
DMARCの認証対象であるヘッダFromのドメインと、SPF(もしくはDKIM)の認証対象ドメインが一致していない場合に、DMARCとしてはそのSPF(もしくはDKIM)の認証結果をもとに認証できません。完全一致している場合にのみ認証できます。
例えば、SPF(もしくはDKIM)の認証対象ドメインが"news.example.com"、ヘッダFromのドメインが"example.com"であった場合、SPF(もしくはDKIM)が認証成功していたとしても、DMARCとしてはその認証結果をもとに認証成功になることはありません。
※SPFの認証対象ドメインはエンベロープFrom(SMTPのMAIL FROMコマンド)のドメイン、DKIMの認証対象ドメインはDKIM署名のdタグで指定されたドメインです。 - relaxed mode:
strict modeよりも緩和された条件です。DMARCの認証対象であるヘッダFromのドメインが、SPF(もしくはDKIM)の認証対象ドメインのサブドメインであれば、DMARCとしてはそのSPF(もしくはDKIM)の認証結果をもとに認証できます。よって、完全一致していなくても認証成功する場合があります。
- strict mode: