MENU
サイバー攻撃から企業を守る、情報セキュリティの総合サービス | Proactive Defense
  1. ホーム
  2. ブログ
  3. トレーニング
  4. え！？自社のドメインから、迷惑メールが配信されている？　なりすましメール対策(SPF/DKIM/DMARC)　【セキュア開発技術Blog】

え！？自社のドメインから、迷惑メールが配信されている？　なりすましメール対策(SPF/DKIM/DMARC)　【セキュア開発技術Blog】

トレーニング
ガイドラインセキュア開発セキュリティ対策

Securityチーム オーナーの松田です。
迷惑メール、なりすましメール、フィッシングメール、標的型攻撃メールなど、メールを起点とした攻撃は現在も非常に多く実施されています。その中でも、稀に実在する会社のメールドメインを使われているようななりすましメールを目にすることがあります。受信側もあれ？っと思いますし、なりすまされた企業としても、冗談ではありません。

本記事は、そういった攻撃メールに自社のドメインが使われてしまうことへの対策についてご紹介したいと思います。

目次

送信者アドレスには何を記載してもいい？

にわかに信じがたい事実ですが、メールの送信者アドレス（以下、ヘッダーFrom）には仕様上、どんなメールアドレスを指定してもいいんです。この事実は、私も社会人になってインフラを勉強して初めて知りました。

信じられない方は、ハガキを想像してもらえればと思います。差出人には何を書いても宛先さえ正しく書いていれば届きますね。それと同じだと考えていただければと思います。私が学生だった時に、自分自身からメールが来るという迷惑メールが流行りました（1990年代です）。当時は、全く意味が分かりませんでしたが、この事実を知って理解できました。

つまり、誰でも kdl.co.jp （当社のドメイン）のドメインを指定してメールを送ることができます。この仕様を悪用して、なりすましメールが送られていると考えています。

でも、にわかに信じがたいですよね。なぜ、こんな仕様なのでしょうか？

実は、メールの技術自体は、1980年代からあります。その当時、おそらくはメールを使って攻撃を仕掛けるということは、念頭に無かったのではないかと思います。つまり、差出人をなりすますということが考慮されてなかったのではないでしょうか？

そのため、後世に追加された仕様にて、対策を行う必要があります。

対策は

勝手に kdl.co.jp のドメインを指定してメールを送られると困りますので、対策が必要です。対策としては、自社の承認されたメールサーバ以外から送られた場合、受け取り側のメールサーバに受信しないように、お願いすることです。逆に、自社のドメインをなりすまして、メールを送ること自体を禁止する方法は現時点ではありません。

具体的な対策は、SPF（Sender Policy Framework）、DKIM（DomainKeys Identified Mail）、DMARC（Domain-based Message Authentication, Reporting, and Conformance）を利用することです。

  1. SPF（Sender Policy Framework）
  2. DKIM（DomainKeys Identified Mail）
  3. DMARC（Domain-based Message Authentication, Reporting, and Conformance）

早速、一つ一つ見ていきましょう。

SPF（Sender Policy Framework）

SPFとは、正規のメールサーバからメールが送信されたかどうかを認証する送信ドメイン認証技術です。メールの送信元IPアドレスが、送信元ドメインのSPFレコード（実際にはTXTレコード）に記載されたIPアドレスに含まれているかどうかを照らし合わせることで、メールサーバが承認されたものかを認証することができます。

例えば、kdl.co.jp では、以下のように登録されております。

kdl.co.jp.        60  IN  TXT "v=spf1 include:spf.protection.outlook.com -all"

意味としては、kdl.co.jp が差出人（厳密にはエンベロープFromであり、Return-Pathで指定されたメールアドレス）の場合、includeで指定されたドメインの送信帯域から配送されたメールのみを正規とし、それ以外は拒否してください、という意味です。

ここで、-allの-はFail、つまり拒否してくださいを表します。~もありますが、この場合、SoftFailを表し、メールを即座に拒否されない可能性があります。

SPFは、DNSのTXTレコードに登録するだけですので、比較的簡単に対応できます。

また、Webサイトなどで、Amazon SESやSend Gridなどのメール配信システムを利用している場合、Return-Pathはメール配信システムのドメインになるケースがあります。その場合、SPFレコードとして対応すら不要になります（後述するSPF Alignmentには注意が必要になります）。しっかり対応していきましょう。

しかし、SPFには、注意点があります。通常受信者に表示されないエンベロープFromのドメインを基準に認証します。そのため、メールに表示されたヘッダーFromが偽装されている場合のなりすましメールを防げないという弱点があります。

DKIM（DomainKeys Identified Mail）

DKIMは、「なりすまし」でないことと、送信途中で内容が「改ざん」されていないことを証明する送信ドメイン認証技術です。DKIMは、送信の際にメールサーバで、メールに署名をつけます。

実際に送られたメールの内容を見ると、以下のような署名がメールヘッダに含まれます。

DKIM-Signature: v=1; a=rsa-sha256; d=kdl.co.jp; s=<selector>; ...

署名を検証するための公開鍵は、DNSに登録します。<selector>._domainkey.kdl.co.jp というFQDNのTXTレコードに登録されています。※selector はメールサービス（または自社メールサーバ）が発行・指定する識別子です。

DKIMは、「なりすまし」でないことと、メール送信の途中でメール内容が「改ざん」されていないことを証明するための技術です。メールサーバで署名つけるなど、手間が多い点に注意が必要です。

メール配信システムを使っている場合は、DKIMに対応している製品も多く出ていますので、そういった製品を選ぶと良いと思います。そうした製品の場合、DNSへの登録だけで済むケースもあります。もちろん、自身のメールサーバーで署名つけることも可能です。

ただし、DKIMにも弱点があります。DKIM単体ではFromと一致しない署名でもPASSするためです。つまり、対象ドメインをd=kdl.co.jpと指定しており、これがヘッダーFromアドレスのドメインと一致していなくてもPASSします。

DKIM単体では、ヘッダーFromドメインの完全ななりすまし防止にはなりません。

DMARC（Domain-based Message Authentication, Reporting, and Conformance）

DMARCは、SPF→DKIMの後に出現した、メールのヘッダーFromのドメインから正規に送信されたメールであるかどうかを認証する、送信ドメイン認証技術です。

これまでにでてきたSPFまたは DKIMの認証と後述するSPF/DKIM Alignmentによって認証した結果、メールの扱いを、None（何もしない）、Quarantine（検疫）、Reject（拒否）のいずれかに指定することができます。これが肝です。

DMARCポリシーと言いますが、メールの扱いを、例えば拒否に指定することで、SPFやDKIMを認証しないメールを拒否し、自社ドメインになりすまされたメールを受信しないようにお願いできます。

さらに、送信ドメイン所有者側はDMARCの判定結果についての情報をレポートとして受け取ることができます。このレポートを参照することで、自社ドメインになりすましメールが、世の中にどれくらいあるかを判定することもできます。

例えば、kdl.co.jp では、以下のように登録されております。_dmarcを付与したFQDNのTXTレコードに登録します。※実際の登録内容と異なります。

_dmarc.kdl.co.jp. 300 IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; aspf=r; adkim=s; rua=mailto:example@dmarc.example"

p=reject が指定されているため、DMARC認証に失敗したメールは受信拒否されるよう、受信側に依頼しています。

DMARC PASSとは

DMARC認証の成功、つまりPASSになる条件は、以下のどちらかです。

(SPF PASS かつ SPF Alignment PASS)
        OR
(DKIM PASS かつ DKIM Alignment PASS)

どちらか一方でも、OKであればいいです。ここでAlignmentについて、触れていきます。

Alignment

SPF Alignment PASSは、エンベロープFrom（Return-Path またはバウンスとも呼ばれます）アドレスのドメインと、ヘッダーFromアドレスのドメインが、一致していることです。つまり以下はPASSです。

Return-Path: <...@kdl.co.jp>
From: <...@kdl.co.jp>

SPFは、エンベロープ送信者が対象となるため、例えばメルマガを送信サービスから、メルマガを送信するような場合、しばしばヘッダーFromアドレスのドメインと一致しないことがあります。SPF自体は、それでもPASSになりますが、SPF Alignmentは、エンベロープFromアドレスのドメインとヘッダーFromアドレスのドメインが異なる場合は、PASSにはなりません。

DKIM Alignment PASSは、関連する DKIM ドメイン(d=のドメイン)と、ヘッダーFromアドレスに含まれるドメインが、一致していることです。つまり以下はPASSです。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kdl.co.jp; ...
From: <...@kdl.co.jp>

DKIMでも、署名をつけるための鍵ペアがメールサーバで一つしか準備できないなどの理由で、d=に指定するドメインを変更する必要が出るかもしれません。ただ、SPFほど多くはないと思いますので、できればDKIM AlignmentをPASSにできるといいと思います。

DMARCをPASSにするためには、以下の条件なので、どちらかのAlignmentをPASSする必要があります。

(SPF PASS かつ SPF Alignment PASS)
        OR
(DKIM PASS かつ DKIM Alignment PASS)

この辺は、Googleが詳しいです。

出典：Google Workspace 管理者ヘルプ, DMARC を設定する
https://support.google.com/a/answer/2466580?hl=ja

DMARCの設定内容

DMARCの設定内容は、オプションが非常に多くわかりづらいです。代表的なものをピックアップします。

  • v: （必須）DMARC のバージョン。DMARC1 を指定します。
  • p: （必須）認証に合格しないメールの処理方法。none(そのまま受信)、quarantine(迷惑メールに分類)、reject(拒否し、通常受信サーバーは受け取りません)
  • pct: (オプション) DMARC ポリシーが適用されるメールの割合。1～100 の整数を指定し、100はすべての未認証メールでポリシーが適用されます。デフォルトは100です
  • rua: (オプション) DMARC レポートの送信先、メールアドレス。
  • sp: (オプション)プライマリ ドメインのサブドメインからのメールに関するポリシー。サブドメインに異なる DMARC ポリシーを使用する場合は、このオプションを使用します。
  • adkim: (オプション)DKIM のAlignmentポリシー。s—厳格。Fromドメインと、DKIMドメインが完全に一致する必要があります。r—緩和(デフォルト): サブドメインでもOK。
  • aspf: (オプション)SPF のAlignmentポリシー。s—厳格。Fromドメインが、エンベロープFromのドメイン名と完全に一致する必要があります。r—緩和（デフォルト）: サブドメインでもOK。
  • ruf: (オプション)失敗レポートの送信先。対応していない場合もあります

可能であれば、pやspには、rejectを指定して、厳格化したいところです。

DMARCもDNSに登録することで対応が完了します。ただし、SPFとDKIMに対応していないと、正規のメールが相手に届かなくなることがあります。SPFもしくはDKIMに対応し、DMARCにも対応しましょう。

対策状況の確認

今、自社のメールサーバからメールを送った時に、これらの対策ができているかどうかを確認する方法はあるのか？が気になります。

最も手軽なのは、gmailで確認することです。自身のgmailアドレスにメールを送ってみてください。判定結果を見ることができます。gmailで対象のメールを開き、右上の３点リーダーをクリックして、<>原文を表示をクリックすると、判定結果を見ることができます。

Alignmentの判定結果は、明確には見えませんが、DMARCがPASSしていることから、どちらかはPASSになっています。

まとめ

いかがでしたでしょうか？これらの送信ドメイン認証技術については、2023年にGoogleからアナウンスされた「メール送信者のガイドライン」で明確に記載され目にする機会が増えたのでは無いでしょうか？

Google Workspace 管理者ヘルプ, メール送信者のガイドライン
https://support.google.com/a/answer/81126?hl=ja

この「メール送信者のガイドライン」では、DMARCポリシーをnoneにも設定できるため、もしかしたらnoneのままで運用されているケースも多いのではないでしょうか？noneの場合は、受信者にメールが届いてしまいますので、自社のドメインから、迷惑メールが配信されているということが起こりえます。

ぜひ、段階的にでも、DMARCポリシーを厳格化して、自社のドメインから、迷惑メールが配信されているということを制限していただければと思います。

出典

この記事を書いた人
松田　康司

株式会社神戸デジタル・ラボ
デジタルビジネス本部　Securityチーム オーナー / 生産技術チーム

神戸大学情報知能工学科卒。2014年にKDLに入社。自社で構築するECサイトのほぼすべてのプロジェクトに関与しながら、多くの開発プロジェクトを経て、現在はSecurityチーム オーナーと全社のセキュア開発を推進する生産技術チームを兼任。開発部門主導のセキュア開発を実践している。
コミュニティ活動として、OWASP Kansaiボードメンバー、アルティメットサイバーセキュリティクイズ実行委員を務める。

トレーニング
ガイドラインセキュア開発セキュリティ対策
  • URLをコピーしました！
目次