\ もう始まってるよブラックフライデーはこちら /

DMARC認証の整理しておきたいポイント

当サイトには広告を含みます。

当サイトでは、広告掲載ポリシーに沿って広告を掲載しています。
※広告でなく、単に商品やサービスを自主的に紹介しているだけという場合もあります。

"オススメ" として紹介している商品やサービスは、個人的にそう思えたものだけです。

共感、興味をもっていただけるものがあればご利用ください。

1,000P獲得できるお得なAmazonプライム入会

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証 (Sender Domain Authentication)。

本記事は、DMARC認証についてまとめたものです。

SPF、DKIM、DMARC、ARC、BIMIといった送信ドメイン認証のまとめ記事はこちらです。

本記事では、整理しておきたいポイントを中心に記載しています。ネット上に解説記事が多そうな内容については省略している場合があります。

ちなみに、次期 DMARC (DMARCbis) については、以下の記事で少しまとめています。

目次

基本

DMARCの認証対象と認証成否

  • メールのFromヘッダのドメインを認証します。
  • ヘッダFromのドメインのDNSに登録されたDMARCレコードに基づいてSPFとDKIMの認証結果を検証し、いずれかが成功であれば認証成功です。
    具体的には、以下のいずれかの認証が成功(“Pass”)すれば、DMARCとして認証成功ということです。
    • “ヘッダFromのドメインと一致するドメイン”に対するSPF認証
    • “ヘッダFromのドメインと一致するドメイン”に対するDKIM認証
      ※成功していない方が認証失敗(“Pass”以外、つまり”Fail”等)であったとしても、DMARCとしては認証成功となります。DMARC自体の仕様としては、SPFとDKIMの両方が成功した場合にのみ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レコード上の公開鍵とペアになる秘密鍵を持つシステムのみであるという意味

認証時の動作

  • メールを受信する側が、上記の認証を行います。
  • “ヘッダ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”等)に分類できます。種類は以下の通りです。

    • DKIM(RFC 6376)では、以下が定義されています。
  • 認証結果

    • DMARCの認証結果は、大きく”Pass”か、”Pass以外”(“Fail”等)に分類できます。全ての種類は以下の通りです。
      • DMARC(RFC 7489)では、以下が定義されています。
        • pass
        • fail
        • temperror
        • permerror
  • 認証結果は、送信ドメイン認証において共通的に使用されるAuthentication-Results(AR)ヘッダに記録されます。

詳細

RFC

DMARCの仕様は、RFC 7489 で定義されています。

導入ステップや運用ポリシーに応じた調整のポイント

  • 本格的にDMARC対応するかどうかに関わらず、まず試験的にポリシー”p=none”にてDMARCレコードを公開すると良いです。”p=none”であれば、自ドメインからのメールがDMARCにより拒否されることは基本的にありません。
    DMARCレコードを公開することで、DMARCレポートを受信できるようになるので、自ドメインから送信されるメールの配送状況(送信ドメイン認証失敗の状況)を分析できます。DMARCレポートを受信するには、ruaタグ、rufタグの指定が必要です。
  • DMARC対応は、最終的にp=none以外(reject,quarantine)のポリシーで運用することで正式なものとなります。p=none以外の設定を、DMARC Enforcementと呼ぶことがあります (ただしp=quarantineの場合はpct=100が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タグで指定したアドレスに送信される認証失敗レポート、認証失敗が発生するたびに送信される
    • アラインメントモード(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)の認証結果をもとに認証できます。よって、完全一致していなくても認証成功する場合があります。

まとめ

本記事では、DMARC認証についてまとめてみました。

送信ドメイン認証 関連記事

これらの記事は、個人的に理解を深めるため少しずつ調べてまとめたもので、何かしら不正確な記載等もあるとは思いますがご了承願います。

送信ドメイン認証全般に関する記事
個々の送信ドメイン認証に関する記事
送信ドメイン認証のTIPS

Authentication-Results ヘッダまとめ ※機会があれば作成予定…

送信ドメイン認証の動向
記事作成、サイト管理
プロフ画像 (暫定版)

happynap
(はっぴぃなっぷ)

3人家族で暮らし
ITっぽい仕事をしつつ
ポイ活、投資を趣味的に
スキマ時間に、ゆるく全力でブログ
のんびり昼寝したい

お得情報

出張先、旅行先のホテル予約はお早めに

よろしければシェアいただけると
目次