さくらのメールボックスがDKIM/DMARCに対応したので設定してみた
私はCloudflare Registrar＆さくらのメールボックスでメールを運用しています。
合わせて年間2000円くらいとかなり安いです。
ただしさくらのレンタルサーバ含め、さくらはDKIM/DMARCに対応していなかったのでGmailをお使いの方にメールがちゃんと届くかちょっと不安という問題がありました。
2023年12月19日、X（Twitter）を見ていたところ下記のお知らせが流れてきました。
【さくらのレンタルサーバ / マネージドサーバ】DKIMおよびDMARC対応予定に関するお知らせ（2024年1月23日 10:00更新） | さくらインターネット
さくらのメールボックスも対象です。
長い間さくらはDKIM/DMARC対応をしていなかったのですが、2024年2月1日からGmailのガイドラインが変わることを受けて対応することとなったようです。
2024年2月より Gmailのガイドライン が変更となります。
【さくらのレンタルサーバ / マネージドサーバ】DKIMおよびDMARC対応予定に関するお知らせ | さくらのサポート情報
これに伴い、さくらのレンタルサーバ / マネージドサーバではDKIM※1およびDMARC※2に対応することとなりました。
Gmailのガイドラインが変わる件はかなり話題になりましたね。
ガイドラインで規定されたのは「1 日あたり 5,000 件を超えるメールを送信する送信者はSPFとDKIMとDMARCを設定してください」ということで対象者は少ないのですが、1月の時点で自分のメールが相手に届かなくなった、実際には5,000件未満であっても対象になるなどの噂もあり、大きく取り沙汰されました。
真相は分かりませんが、騒がれたので企業としても重い腰を上げて対応することとなったのでしょう。
なおGmail側のスパム対策の仕様は詳細が公開されていないので、噂が本当か否かを確かめる術はありません。
SPFなし・DKIMなし・DMARCなしで怪しさポイント+3、はいスリーアウト。みたいな感じで判断されてそうですね（そうか？）
まあ冗談はさておき、5000件というのも個人ではなくドメイン単位の話でしょう。特にBtoC事業をやられてる方は他人事ではありません。
ということで1月31日に対応したため、早速当日中に設定してみた記事です。
ちなみに1月31日は利用者が多すぎて高負荷になり、一時的に設定できない状態になっていました。
17:00頃はダメでしたが、18:00頃には操作できたので滑り込みで設定しました。
噂が真実であってもなくとも自分の送ったメールが迷惑メールに分類されていたなんて話はよく聞きます。
そういったことを未然に防ぐために、対応したのなら設定するに越したことはありません。
忙しい人向けの設定
さくらのサポート情報ページにマニュアルがあります。たすかる。
マニュアルでも言及されていますが、設定方法はレジストラ（お名前.comとかCloudflare Registrarとかのこと）によって違うので注意してください。
私は外部ネームサーバーを使っているので、ちょっとひねった設定が必要です。
さくらインターネット指定のネームサーバーを使っている人はマニュアルだけで十分なので、以下は読み飛ばしてください。
以下はotogeworks.comの設定の例です。
外部ネームサーバーの方はotogeworks.comの箇所を各自書き換えて使ってください。
ちなみに1行目がSPF、2行目がDKIM、3行目がDMARCです。
otogeworks.com. 86400 IN TXT "v=spf1 a:【さくらのホスト名】 mx ~all"
【セレクタ】._domainkey.otogeworks.com. 86400 IN TXT "v=DKIM1; k=rsa; p=【公開鍵の内容】"
_dmarc.otogeworks.com. 86400 IN TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:admin@otogeworks.com"Cloudflare Registrarの管理コンソールでは下記です。（DNSのRecordsから設定）
DKIMレコードとDMARCレコードもそうだが、「Content (required)」にダブルクォートは不要
「Name (required)」に「【セレクタ】._domainkey.otogeworks.com.」を入力すると、保存後に「【セレクタ】._domainkey」に省略される
ちなみに【公開鍵の内容】には改行やダブルクォートを含めないこと。もちろん「-----BEGIN PUBLIC KEY-----」とかも不要（地味に罠）
DKIM同様、「_dmarc.otogeworks.com.」を入力すると「_dmarc」に省略される模様
DKIMの【セレクタ】と【公開鍵の内容】はマニュアルを見れば分かるのでそちらを参照ください。
SPFの【さくらのホスト名】は管理コンソールの「サーバー情報」のホスト名から見れます。
DKIMはさくら側のコンソールの操作が必要なので、マニュアルを参照して操作しましょう。
メールドメイン設定の「DKIMレコード」はDNSレコード設定後にチェックしてください。
画像だと「SPFレコード」にチェックを入れちゃってますが、多分これも不要ですね。
チェックが必要なのは「DKIMレコード」のみです。（さくら側が持つ秘密鍵で署名する必要があるため）
設定したらGmailにメールを送ってみましょう。
メールを送ったら、Gmailにログインしてメールを開いて右上から「メッセージのソースを表示」を選びます。
このページでSPF/DKIM/DMARCの検証結果を見ることができます。
すべて「PASS」になっていれば設定完了です。
DMARCの設定補足
SPF/DKIMは調べればすぐに答えが出てきますが、現時点でDMARCは普及率が低いので補足。
3行目のDMARCだけ万人向けの設定じゃないので注意してください。
相違点は下記です。
| p | adkim | aspf | |
|---|---|---|---|
| さくらのマニュアルの例 | none | r | r |
| otogeworks.comの例 | quarantine | s | s |
DMARCの簡単な取り扱い説明
そもそもSPF/DKIM/DMARCは何のためにあるかというと送信ドメイン認証と言って、誰かがotogeworks.comを騙ってメールを送信しやがった時にNG（FAIL）と判断するための技術です。
意外かもしれませんが偽装自体は簡単です。
基本的にはSPFとDKIMだけで検知できますが、DMARCはこのSPFとDKIMをさらに補強する技術です。
p=quarantine
otogeworks.comを騙るメールを受け取ったメールサーバーはSPFとDKIM（とDMARC）によって「こいつ偽物じゃね？」と気づくので、見逃す・シベリア送り・粛清のどれかの選択肢を取ることになります。
とりあえず名乗ってるとこにどうするか確認しとくか……
ってことでotogeworks.comのDNSサーバーに確認しに行くわけです。
ここでDMARCのDNSレコードがあると、メールを受け取ったメールサーバーに指示を出せます。
- 「p=none」なら見逃す（スルーして普通にメールボックス行き）
- 「p=quarantine」ならシベリア送り（迷惑メールフォルダ行き）
- 「p=reject」なら粛清（メールを破棄）
「じゃあp=rejectでいいのでは？」というと、そうとも限りません。
SPF/DKIM/DMARCを正しく設定できていなければFAILになり、無実のメールが破棄されてしまいます。
正しく設定できている＝全てPASSできることを確認するまでは「p=none」にしておくべきです。
全てPASSできることを確認した後、「p=quarantine」にするか「p=reject」のどちらにするかはお好みです。
個人的には将来的にメールサーバーを別なところに変えたりした時にメールがrejectされると怖いので、安牌でquarantineにしています。
ちなみにどの判断を下すかの決定権は受信側にあるので、「p=none」にしても問答無用で粛清されることもあります
adkim=s; aspf=s;
その名の通り、DKIMとSPFの設定です。
これにはRelaxedモードとStrictモードがあり、どちらもSPFとDKIMに加えてさらにSPFアライメントとDKIMアライメントをチェックするようになるモードです。
Strictモードにするとこのチェックがより厳しくなります。
SPFアライメントとDKIMアライメントとは何ぞやって感じですね。
これは2つとも「ヘッダFrom（※）と比較します」というものです。
※私ならotogeworks.comという文字列
比較対象は下記です。
- SPFアライメントでは送信元メールサーバーのドメイン
- DKIMアライメントではデジタル署名されたドメイン
普通に考えると一致しますが、例えばotogeworks.comからAmazon SESを使ってメールを送ると送信元メールサーバーがotogeworks.comなのにヘッダFrom（差出人）がamazonses.comになるみたいな感じで、こちらが想定した値と違ってFAILになることがあります。
このケースも回避方法はありますが、こういうのって普段は意識しないので落とし穴だと思います。
ここまでがRelaxedモードです。
StrictモードにするとFQDNまで一致している必要があります。
つまりメールアドレスがotogeworks.comなのに、実際にはmail.otogeworks.comからメールが配送されているような例もFAILになります。
サブドメインNGということですね。
ここまで説明しましたが、adkimとaspfは判断が難しいので、よく分からなければマニュアルの通り「adkim=r; aspf=r;」にしてRelaxedモードにした方がベターです。
※私も実物を前に「これどうすればいいか説明して♥」と言われても説明できる自信がありません。なのでこうして備忘録を書いています
参考にした資料
DNSレコードはほとんど触らないので、SPF/DKIM/DMARCなどとうに忘れてしまっていました。
簡単な設定方法については調べた方が早かったですが、
仕様についてはトレンドマイクロのサイトがまとまっていたので紹介。（特にDMARC）
今回はSPF/DKIM/DMARCの設定を半ば強制されたような感じでした。
そのうちDMARCの「p=none」がNGになって「p=quarantine」以上が義務付けられたりするんですかね？
Webに比べるとメール周りのセキュリティ事情は遅れている（特にSSL周り）ので仕方ないんですが、段々面倒なことになってきてドメイン運用者の負担が上がっていきますね。