2024年1月中旬からにわかに騒がしくなったGmailの迷惑メール対策。これに伴って慌ててSPF・DKIM・DMARCを設定した企業様も多いかと思いますし、未だに対応出来ていない企業様もいらっしゃるようにお見受けします。しかしながら、SPF・DKIMに関しては相当以前から所謂キャリアメールで弾かれないための対策として広く知られているところでしたし、Gmailについては2023年秋にはアナウンスされており、直前になって慌てるようなものではなかったんですね。しかしながら、噂話的なものが先行していて正しく設定されていない企業様も多く見受けられるように思います。現実問題として神奈川県の高校受験出願システムでは大事故になっていましたし。
そこで、弊社が実際に行った例を書いてみたいと思います。弊社が対応した範囲について図示しますね。
弊社で管理している御客様の分もまとめて書いていますが、比較的多くのパターンがあることが判るかと思います。これをパターン毎に解説いたします。
パターン１
これは一般的なパターンになります。メールサーバーから何も経由せずに送信されるケースになります。この場合は非常にシンプルです。DNSに以下のレコードを追加します。ちなみに発出するメールのアドレスはxxx@example.jpとなります。以下、パターン4を除き同じ形式になります。
example.jp TXT "v=spf1 a:mail.example.jp -all"
A._domainkey.example.jp TXT "v=DKIM1; k=rsa; p=[Aの公開鍵]"
_adsp._domainkey.example.jp TXT "dkim=unknown"
_dmarc.example.jp TXT "v=DMARC1; p=none; rua=mailto:rua@example.jp; ruf=mailto:ruf@example.jp; fo=1;"という感じになります。ここら辺は殆どのサイトで言及されているので特に難しいことはないかと思います。
パターン２
これは少々異色のパターンになります。弊社の場合はウェブサーバーとメールサーバーを分離しているので、問い合わせフォームからのメールはこのようなルートを通ることになります。
このパターンで少々手間取ったのは「メールを転送」しているパターンに見えるんですが、実はそうではないという事です。キモは「ローカル接続」という部分になりいます。
あと、WordPress＋ContactForm7という組み合わせの時に問題になる部分がありました。ContactForm7ではヘッダFromは指定出来るものの、エンベロープFromは指定出来ません。そのため、発出されるメールのドメイン（SPF設定済）と、ウェブサーバーのドメイン（SPF未設定）が異なる場合にエンベロープFromがウェブサーバーのドメインになってしまうためにSPFがFailになってしまうと言う問題が発生します。これの解決方法として殆どのサイトで「テーマのfunction.phpを書き換えろ」とされていますが、この場合、テーマがアップデートされると設定が消えてしまうと言う問題が起こります。そこで、弊社では「wp_mail return-path」というプラグインを使って書き換えるようにしました。このプラグインはエンベロープFromをヘッダFromと同じアドレスに書き換えてしまうと言うもので、設定は必要なく、有効化するだけで機能しますので簡単に使えるのがメリットです。
このパターンではSPFやDKIMの設定はパターン1のまま行けるんですが、それだけだとDKIM署名がなされないため、メールサーバーの /etc/opendkim/TrustedHosts にウェブサーバーのIPアドレスを追加します。
# OPENDKIM TRUSTED HOSTS
# To use this file, uncomment the #ExternalIgnoreList and/or the #InternalHosts
# option in /etc/opendkim.conf then restart OpenDKIM. Additional hosts
# may be added on separate lines (IP addresses, hostnames, or CIDR ranges).
# The localhost IP (127.0.0.1) should always be the first entry in this file.
[IPAddr:Bを追加]
127.0.0.1
::1
#host.example.com
#192.168.1.0/24これはあくまでも「ローカル接続」だから有効な手段であると理解してください。それ以外の場合は少々危険な香りがしてきますので。
パターン３
この場合はメール配信システム側でDKIMに対応していることが求められます。何故なら、DKIMに対応していないと署名が出来ないからです。これ、プランによってはDKIMに対応しないというケチなシステムもありますので要注意です。弊社で使っているシステムもプランを上げないと対応してくれませんでした。
弊社で使っているシステムでは発信メールアドレスを様々に設定出来るため、発信メールアドレス毎に鍵の生成が可能になっていますので鍵の生成をします。ちなみにメールサーバーで生成した鍵を手動で設定することも可能になっていましたが、セキュリティ的には宜しくないと思われるので、システム側で生成したのを使いました。あと、SPFについても追記する内容が提示されていますので、それをDNSに追記します。
example.jp TXT "v=spf1 a:mail.example.jp include:spf.example.com -all"
A._domainkey.example.jp TXT "v=DKIM1; k=rsa; p=[Aの公開鍵]"
C._domainkey.example.jp TXT "v=DKIM1; k=rsa; p=[Cの公開鍵]"
_adsp._domainkey.example.jp TXT "dkim=unknown"
_dmarc.example.jp TXT "v=DMARC1; p=none; rua=mailto:rua@example.jp; ruf=mailto:ruf@example.jp; fo=1;"こんな感じになります。ここも、システム側で例示がされていたりもするので、それほど難しくないかと思います。
パターン４
このパターンは一見すると外部からの転送パターンに見えますが、実際にはメールサーバー内で止まり外部には出ていかないので難しくありません。DNSに追記する内容を記します。必要なのは監視サーバー側で鍵の生成を行う必要があるだけです。あと、こちらから発出するメールのアドレスのみxxx@a.example.jpとなります。
example.jp TXT "v=spf1 a:mail.example.jp a:a.example.jp include:spf.example.com -all"
A._domainkey.example.jp TXT "v=DKIM1; k=rsa; p=[Aの公開鍵]"
C._domainkey.example.jp TXT "v=DKIM1; k=rsa; p=[Cの公開鍵]"
_adsp._domainkey.example.jp TXT "dkim=unknown"
_dmarc.example.jp TXT "v=DMARC1; p=none; rua=mailto:rua@example.jp; ruf=mailto:ruf@example.jp; fo=1;"
D._domainkey.a.example.jp TXT "v=DKIM1; k=rsa; p=[Dの公開鍵]"
_adsp._domainkey.a.example.jp TXT "dkim=unknown"
_dmarc.a.example.jp TXT "v=DMARC1; p=none;"こんな感じになります。DKIMの公開鍵の設定やDMARCの設定はメールアドレスの@以降のドメインとなりますので、それぞれ別途指定している形になります。
パターン５
パターン3と類似しているのですが、DKIMの鍵の在処がシステム側から指定されているのが異なる点となります。基本的には指定されたとおりに追記するのみとなります。
example.jp TXT "v=spf1 a:mail.example.jp a:a.example.jp include:spf.example.com include:spf.example.co.jp -all"
A._domainkey.example.jp TXT "v=DKIM1; k=rsa; p=[Aの公開鍵]"
C._domainkey.example.jp TXT "v=DKIM1; k=rsa; p=[Cの公開鍵]"
E._domainkey.example.jp CNAME E._domainkey.example.co.jp
_adsp._domainkey.example.jp TXT "dkim=unknown"
_dmarc.example.jp TXT "v=DMARC1; p=none; rua=mailto:rua@example.jp; ruf=mailto:ruf@example.jp; fo=1;"
D._domainkey.a.example.jp TXT "v=DKIM1; k=rsa; p=[Dの公開鍵]"
_adsp._domainkey.a.example.jp TXT "dkim=unknown"
_dmarc.a.example.jp TXT "v=DMARC1; p=none;"という感じになります。異なる点はTXTではなくCNAMEで指定している点ですね。
さて、ここまで色々なパターンについて書いてきましたが、実は弊社では設定する必要がなかったものの、メールを転送する際に必要な設定があります。先ずはパターンを図示しますね。
何も考えずに受信した側で転送を掛ける（メーリングリストにも当てはまります）と、送信メールサーバーにてDKIM署名をしたものが受信メールサーバーでDKIM署名を上書きされてしまうために、転送先メールサーバーではDKIMがFailになります。また、転送先メールサーバーから見ると受信メールサーバーが発信元になっている為にSPFもFailになり、結果としてDMARCがFailになります。DMARCがp=noneで運用されている場合には特に問題が起こらないように見えますが、それ以外のポリシーで運用されている場合は不達になる可能性があります。実際には転送先メールサーバーでの運用による部分ではありますが。
弊社ではDMARCのレポートを可視化するツールを使っているため、メールの送信先で何も考えずに転送されているとDMARCがFailになったというレポートが届きます。そのレポートを分析すると多くは自社のメールサーバーからGmailに転送しているのが判ります。これが大量で結構迷惑だったりするのですが、それはさておき、何をすれば解決するのでしょうか？ここに言及している記事は見たことがないのですが、実はGoogle側から提示されているのが「転送する際にはARCヘッダを追加すること」という一文です。そうなのです、Gmailの迷惑メール対策に於いて転送する際の規定も書かれているわけですよ。でも、殆どの記事がSPF・DKIM・DMARCのみに言及していてARCに言及しているのは見かけません。
では、どうすれば良いのでしょうか？
実はOpenARCというプログラムがリリースされており。それを導入して、DKIMの鍵をARC用にコピーして所有者をOpenARCに変更するだけなんですよね。あとはOpenARCとPostfixがやり取り出来るようにPostfixの設定を変更するだけなのです。たったそれだけなのですが、これでARCヘッダを付加してDKIM再署名を行ってくれるんです。その結果、元のメールに付いていたDKIM署名を辿れるようになって、転送先メールサーバーでDKIMがPassするようになるという仕組みなのです。SPFはFailのままですが、これはどうしようもないので放置でOKですし、DMARCはDKIMかSPFのいずれかがPassであればPassになるので問題はありません。
弊社では今後のスケジュールとして2024年4月からDMARCのポリシーをnoneからquarantineに移行する予定です。また、Gmailも4月からはガイドラインに準拠していないメールは拒絶するというスケジュールになっているそうなので、ARCの対応をせずに転送している場合、大量の不達メールが発生する可能性が大きくなります。それこそ大騒ぎですね。
改めて、Gmailのガイドラインに書かれている重要なポイントを挙げておきます。
- DKIMまたはSPFを設定すること
- DMARCを設定すること
- 接続にはTLSを使用すること
- 転送する際にはARCヘッダを追加すること
- メーリングリストにはList-idヘッダを追加すること
- メルマガなどではワンクリック購読解除出来るようにヘッダで設定をすること
拒絶の運用に入るまで2ヶ月を切りました。今一度、これら全てが守られているのか確認をしてみてください。特にARCの対応を忘れている企業様が大多数だと思われますので、早急な対応を行ってください。
投稿者プロフィール
