目次
[ 開く ]
[ 閉じる ]
1.導入
昨今、消費者や企業を狙う「詐欺メール」が急増しているというニュースをご覧になった方もいらっしゃると思います。
詐欺メールには幾つか種類がありますが、独立行政法人情報処理推進機構(IPA)が発表している「情報セキュリティ10大脅威 2024」においては、メールに関わる脅威として以下が挙げられています。
【個人向け脅威】
- フィッシングによる個人情報等の詐取
- メールやSMS等を使った脅迫・詐欺の手口による金銭要求
【組織向け脅威】
- ランサムウェアによる被害
- ビジネスメール詐欺による金銭被害
本記事前半では、昨今話題の送信ドメイン認証について、できるだけ技術用語を使用せずに分かりやすく説明します。
後半では、設定担当者向けに、設定例や最新動向を共有いたします。
2.初心者向け情報
2.1 送信ドメイン認証とは?
送信ドメイン認証とは、簡単にご説明すると、「メールを送る際に、本人確認情報も一緒に送る」技術のことです。
そうすることで「本メールの送信者は間違いなく自分である」ということを受信者に伝えられるようになります。
受信者から見れば、本人確認情報を見ることで、「詐欺メール」や本人を騙る「なりすましメール」を判別しやすくなります。
また、本人確認(=送信ドメイン認証)ができないメールは受信者側(具体的にはGmailやOutlook等のメールサーバ側)で受信を拒否したり、迷惑メールボックスに振り分けられるようになります。
2.2 なぜ送信ドメイン認証が重要性を増したのか?
送信ドメイン認証は近年、大手メディア等でしきりに重要性が叫ばれるようになりました。
その理由としては、個人情報を狙うフィッシングメールや、Emotetなどのマルウェアが含まれたメールが急増したためと考えられます。
これらの悪意のあるメールに対応するため、受信メールサービス側も対策を強化しました。
その結果、送信ドメイン認証ができないメールは届きにくくなるため、メール送信者側も送信ドメイン認証への対応が必須となりました。
2.3 Googleの示した新ポリシーはどういうものか?
Googleは2023年12月にメール送信者ガイドラインの更新を発表しました。
要点を示すと、Gmail アカウントに 1 日あたり 5,000 件以上のメールを送信する送信者に対し、下記の3つが義務付けられました。
- 送信メールを認証すること
- 未承諾のメールまたは迷惑メールを送信しないようにすること
- 受信者がメールの配信登録を容易に解除できるようにすること
この中の「1. 送信メールを認証すること」が本記事の主題の「送信ドメイン認証」に該当します。
上記の1~3までの対策を行わなければ、受信拒否または迷惑メール認定されるようになります。
また上記はメールの件数が5,000件/日以上の送信者が対象ですが、5,000件より少ない送信者については、要件を緩和する形ですが「送信ドメイン認証」の設定が求められています。
GoogleだけではなくYahoo!やMicrosoftも同様に送信ドメイン認証を強化しております。
2.4 企業や個人はどのような対応が必要か?
昨今のフィッシングメールの状況から、メールセキュリティは必須のものとなりました。
その中でも「送信ドメイン認証」への対応は事業者が当然行うべきものという認識が必要です。
今まではブランド保護の観点から、企業名等を含むドメインネームを取得するということは広く行われてきました。しかし、ドメインネーム取得しただけではブランド保護は万全とは言えません。
むしろ、ドメインネームを保有しているからこそ、なりすましメールで使用された場合に利用者は騙されやすいと言えます。
個人・企業を含む事業者は使用・未使用に関わらず全てのドメインネームで送信ドメイン認証に対応すべきです。
2.5 送信ドメイン認証に対応するにはどうすべきか?
送信ドメイン認証はドメインネーム毎に設定します。メールにサブドメインを使用している場合にはサブドメイン毎の設定が必要です。
メールで使用しているドメインかどうかによって対応が異なります。
- メールで使用しているドメインネーム
送信元に関する情報(IPアドレス・使用メールサーバ等)をDNSに設定します。 - メールで使用していないドメインネーム
「メールで使用しないドメインである」という情報をDNSに設定します。
3.設定担当者向け情報
実際に設定作業を行うには、下記が必要です。
- 送信ドメイン認証の設定内容の理解
- 送信メールサーバが送信ドメイン認証に対応しているかどうかの確認
以下、それぞれ解説いたします。
3.1 送信ドメイン認証の設定内容の理解
先述の通り、送信ドメイン認証はDNS上で公開し、受信者に「自分が送信者である」ということを伝える技術です。
具体的にはDNSのTXTレコードとして、メールサービスやIPアドレス毎に決まった形の文字列を設定します。SPF・DKIM・DMARCと呼ばれる3種類のレコードがあります。
それぞれ役割が異なりますが、3種類をまとめて「送信ドメイン認証」と言います。
レコード種類 | 役割 | 設定例 |
---|---|---|
SPF | IPアドレスを利用して送信元を認証 | メール使用ドメイン
v=spf1 +192.0.2.1 -all メール不使用ドメイン v=spf1 -all |
DKIM | デジタル署名によって送信元を認証 | メール使用ドメイン
(selector)._domainkey.example.comというサブドメインへメールサービスの「公開鍵」情報を設定(注:上記の他、メールサービス側の設定も必要) |
DMARC | SPFやDKIMによる送信元ドメイン認証に失敗した場合に、そのメールをどう取り扱うかのポリシーを公開し、受信者メールサーバへ伝える | メール使用ドメイン
v=DMARC1; p=quarantine; rua=(集約レポートの送り先メールアドレス) “p=●●●;”の部分を以下の通り設定することで、認証失敗時の対応を受信者側に伝えることが可能となります。 p=none(何もしない=受信してよい) p=quarantine(隔離) p=reject(拒否) |
※あくまで設定例です。設定レコードはメールサービスにて確認が必要です。
なお、メール使用ドメインについては、DNSの上記のレコード設定だけでは「送信ドメイン認証」として稼働できません。特にDKIMについてはメールサービス側の設定等を行う必要がございます。
大きく以下の手順で行います。
- 送信に使用するメールサービスがSPF・DKIM・DMARCに対応しているかを確認する
- メールサービスから設定すべきレコード情報を受け取る
- 2のレコード情報をDNSへ書き込む
具体的にどんなレコードを設定すべきか、ということについては、メールサーバやシステムの環境により異なりますので、サーバ・システムを運営する企業にお問い合わせください。
送信ドメイン認証について、一般的な知識を深めたい場合には、以下のリンクで公開されている「送信ドメイン認証技術導入マニュアル」の最新版が分かりやすく、かつ詳細に解説しているため大変便利です。
https://www.dekyo.or.jp/soudan/aspc/report.html
3.2 送信メールサーバが送信ドメイン認証に対応しているかどうかの確認
上記の通り、送信ドメイン認証に利用するレコードはSPF・DKIM・DMARCが必要です。しかし、送信に使用するメールサーバ側で対応していなければそもそもDNSに設定することはできません。さらに、誤った設定をすると、今まで届いていたメールが相手に届かなくなってしまう可能性がございます。
そのため、メールサーバがSPF・DKIM・DMARCにそれぞれ対応しているかどうかを確認する必要があります。
国内の大手ホスティング事業者は対応している企業が多いです。ですが導入前に確認するようにしましょう。
GMOインターネットグループ株式会社においては「お名前レンタルサーバー RSプラン」や「ConoHa WING」にてSPF・DKIMは標準設定としていますので安心してご利用いただけます。実際、サーバ利用者のほぼ100%が設定しております。
DMARCについては設定は任意となっています。
そのため、DMARC利用率は「お名前レンタルサーバー RSプラン」が2.6%、「ConoHa WING」は1.6%とまだまだ利用されていない状況です。(2024年3月1日現在)
2024年2月1日時点でのGMOインターネットグループ各社のサーバ対応状況は以下のプレスリリースをご覧ください。
2024年2月Gmail送信者ガイドライン改定に伴うSPF・DKIM・DMARC対応について
また、GMOブランドセキュリティ株式会社は国内外の大手企業のドメインネームを管理しています。法人向けのドメインネーム管理会社ですが、ドメインネームの管理をお任せいただければ、送信ドメイン認証設定を含め様々なサポートを受けることが可能です。
4.まとめ
迷惑メールや詐欺メールの対策が強化されたことにより、メールを送信する側で送信ドメイン認証が事実上必須となりました。
それには勿論、Googleなどが打ち出した新たなポリシーに適応するためですが、究極的にはメール受信者の保護、メール送信者の信用向上に資するものです。
SPF・DKIM・DMARCなどの送信ドメイン認証をうまく利用し、安心・安全なメール社会を実現していきましょう。
文責:GMOインターネットグループ株式会社