はじめましておひさしぶりですこんばんわ。
リベロエンジニアで社員として働きながら、藤波製作所で個人事業主(代表)という活躍の機会をいただいているドラゴン藤波です。
今回は数多の企業、組織、団体に影響のあるTOPICを記事にします。
「メール送信者のガイドライン」とは
Google、米Yahoo!が打ち出した「メール送信者のガイドライン」をご存知でしょうか?
平たく言うと「認証なしのメールは受け付けません」でございます。
この理由は想像しやすいと思います。フィッシングメールやSPAMメールによる情報漏洩、さらには大量のメール受信を起因とするサーバ負荷を考えたら、
セキュリティ認証を実施していないメールや、行儀の悪いメールを受信したくなくなる理由がわかります。
Googleと米Yahoo!の発表:https://www.m3aawg.org/blog/SendingBulkMailToGmail_Yahoo
Googleの公開ガイドライン:https://support.google.com/a/answer/81126?hl=ja
Google、米Yahoo!が打ち出したガイドラインとは
①メール送信のためのドメイン認証を実施せよ!
SPFに対応せよ!
SPF(Sender Policy Framework)とは
特定のドメインから送信されるメールが許可されたサーバーからのものであることを確認するための技術です。
ドメインの所有者はDNSレコードにSPFレコードを追加し、どのメールサーバーがそのドメイン名を使用してメールを送信できるかを指定します。
受信メールサーバーは、このレコードを参照して、メールが正当な送信源から来ているかを確認します。
DKIMに対応せよ!
DKIM(DomainKeys Identified Mail)とは
電子メールが特定のドメインから正式に発行されたものであり、途中で改ざんされていないことを証明するための方法です。送信サーバーはメールにデジタル署名を加え、受信サーバーは公開鍵(DNSに公開されている(※))を使ってこの署名を検証します。これにより、メールの真正性と完全性が保証されます。
※DNSレコードにDKIMレコード(って書き方であってるかな)を追加する必要があります。
DMARCに対応せよ!
DMARC(Domain-based Message Authentication, Reporting and Conformance)とは
SPFとDKIMの両方を組み合わせたポリシーとレポート機能を提供します。ドメインの所有者は、SPFとDKIMの検証に失敗したメールに対してどのような処理を行うべきかを定義し、これらの検証結果に基づいてレポートを受け取ることができます。DMARCは、メールの認証プロセスをより透明にし、フィッシングや偽装メールの問題に対処するのに役立ちます。
DMARCポリシーは、特定のフォーマットのテキストレコードをドメインのDNSに追加します。このレコードは、メールの認証プロセスと、SPFやDKIMによる検証が失敗した場合の処理方法を定義します。
どれもこれもDNSに設定するモノばかりですね。
しかしそれだけでは終わりません。
②簡単に登録解除できるようにせよ!
これはどういうことかというと
ワンクリックでメール配信を解除できる仕組みにせよ!
ということです。ただし
1 日に 5,000 件を超えるマーケティング目的のメールや配信登録されたメールを送信する場合が対象です。
「あれ?ウチ関係ないんじゃね?」と油断することなかれ。
どこが引っかかるかワカったモンじゃないですし、社内に仕組みとして提供してないかぎり
誰が何をやってるかイマイチわからないのがメール営業です。
ワンクリックで配信解除するためには、ヘッダーに次の両方が必要です。
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://solarmora.com/unsubscribe/example>
※上記Googleのページを参考にしました。
どこまで実施すればいいのか
DMARCはドメイン単位なので、MXレコードを持っているドメイン/サブドメイン単位で実施すればいいのかなと思います。(このあたりは自信ない。ごめんなさい。)
問題はSPF/DKIMと、ヘッダー設定です。
配信サービスごとにDNSにレコードを追加する必要がある。
メール配信の機構を内製化している企業様は昔ながらの仕組みで、
SPF/DKIM/DMARC対応は済んでいるところが多いんじゃないかしら(ヘッダーのほうは知らんけど)。
最近の企業様はだいたいメール配信サービス含め、メール配信にSFA/CRMを利用していることが多いと思います。
さらにグループウェアを利用してメールを送信している場合、こちらも設定が必要です。
たとえばGoogleWorkSpaces、Salesforce、配配メール、HubSpot、AWSのSESなどを使っていた場合
それぞれがメール送信機構を保有しており、
またメール配信サービス(例えばSalesforce)はドメイン(例えばlibero-en.jp)の代理で送信することがあるため、設定を推奨するような内容が製品マニュアルに書いてあるはずです。
DNSにはそれぞれのSPF/DKIMレコードを設定することで、送信したメールの真正性が担保されます。
たまにメルマガの送信元に「~~~の代理」とか書いてあるのがソレです。
肝心の設定方法
ご利用のSaaS、グループウェア、ドメイン管理サービスの製品マニュアルをご確認いただくか、弊社にご相談ください。
ブン投げで草
網羅しようとすると手間かかるで。しゃーない
メール送信のセキュリティ、GmailとYahoo!が掲げているということは新常識になりそうですね。
この記事が公開される頃には2024年2月になっていると思いますが、メール運用はご安全に!ヨシ!!