ZimbraサーバーのDKIM、SPF、DMARCレコードの設定方法

DKIM、SPF、DMARCは、送信メール認証の3つの異なる部分を解決するものであり、信頼性の高いZimbraの導入には、これらが連携して動作する必要があります。SPFは、どのシステムがエンベロープドメインを使用して送信できるかを受信者に伝えます。DKIMは、ドメインに関連付けられた暗号署名を追加します。DMARCは、SPFまたはDKIMの認証が通過したIDが、メッセージのFromヘッダーに表示されるドメインと一致するかどうかを確認し、処理および報告ポリシーを公開します。

ここで重要な現行標準規格の詳細が1つあります。2026年10月現在、有効なDMARCプロトコル仕様は、2026年5月に公開されたRFC 9989です。これは、古いRFC 7489を廃止し、古いpctタグを履歴タグとして扱い、テストタグを導入するなど、いくつかの展開の詳細を変更していますt。これは、以前のZimbraガイドやDNSチュートリアルから古いDMARCの例をコピーする場合に重要です。

DNSを変更する前に必要なもの

Zimbra MTAへの管理者シェルアクセス、送信ドメインの権威パブリックDNSゾーンへのアクセス、およびそのドメインを使用して正当にメールを送信するすべてのシステムの完全なリストが必要です。このリストには、Zimbraサーバー、リレーホストまたはスマートホスト、マーケティングプラットフォーム、チケットシステム、クラウドアプリケーション、および災害復旧メールサービスが含まれる場合があります。

よくある誤解として、Zimbraホストのみのレコードを公開すれば十分だと考えられがちです。しかし、これはZimbraが真に唯一の認証済み送信者である場合にのみ有効です。SPFはSMTP IDに対して評価され、DMARCは適用が有効になると、これまで見落とされていたサードパーティの送信者を露呈する可能性があります。対策：制限的なSPFまたはDMARCポリシーを公開する前に、すべての送信元を一覧化してください。

ステップ1：ZimbraでDKIMキーを生成する

Zimbraにzmdkimkeyutilは、ドメインレベルのDKIM署名を行うためのユーティリティが含まれています。Zimbraの公式ドキュメントでは、MTAサーバー上で実行するように指示されています。まだDKIMデータが設定されていないドメインにDKIMデータを追加するには、Zimbraアカウントに切り替えて、以下のコマンドを実行します。

su - zimbra
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com

このコマンドは、DKIMデータをZimbraのLDAPドメインエントリに保存し、公開する必要のあるセレクタとパブリックTXTレコードを表示します。ZimbraのDKIM署名に関するドキュメント-qには、既存のDKIMデータの照会、-u更新、-r削除の方法も記載されています。

最新のZimbraインストール環境では、出力結果のセレクターの値がオンラインで見かける例と異なる場合があります。セレクターは、defaultやなどの固定の単語ではなくzimbra、ご自身のサーバーが出力するセレクターを正確に使用してください。対処方法：公開鍵レコード全体をコマンド出力からコピーし、手動で再構築しないでください。

ステップ2：DKIM TXTレコードを公開する

DKIM検証者は、セレクタとから構築された名前でDNSから公開鍵を検索します._domainkey。このメカニズムはRFC 6376で定義されています。実際のDNSプロバイダの観点から見ると、レコードは通常次のようになります。

のみを入力するYOUR_SELECTOR._domainkeyか、完全なYOUR_SELECTOR._domainkey.example.comレコード名を入力するかは、DNS コントロール パネルによって異なります。一部のプロバイダはゾーン名を自動的に追加します。アクション: 誤って を作成しないように、保存する前にプロバイダで最終的な完全修飾レコード名をプレビューしてください...example.com.example.com。

ステップ3：送信ドメイン用のSPF TXTレコードを1つ作成する

SPFは、送信認証を記述したいドメインのDNS TXTレコードとして公開されます。RFC 7208では、SPFにTXTレコードが必要であると規定されており、同じ所有者名で複数のSPFレコードが存在すると永続的なエラーが発生するとされています。つまり、v=spf1メールサービスを追加したからといって、2つ目のTXTレコードを作成してはいけません。

Zimbraサーバーが安定したパブリックIPv4アドレスから直接送信する場合の最小限の例は次のとおりです。

v=spf1 ip4:203.0.113.10 -all

ドメインの MX レコードで参照されているすべてのホストが正当な送信元である場合は、 を使用できますmx。サードパーティ サービスが SPF インクルード ドメインを公開している場合は、include:メカニズムが必要になる場合があります。正確なレコードはデプロイメント固有のものであるため、普遍的に正しい Zimbra SPF 文字列は存在しません。

もう一つよくある間違いは、~allが常によりも安全だと考えてしまうことです-all。本当に重要なのは、承認済み送信者のインベントリが完全かどうかです。インベントリが完全な場合は、厳格なが妥当です。対策：すべての正当な送信者を1つのSPFレコードで承認し、本番環境で検証してから、その証拠に基づいて-all最終的な修飾子を選択します。all

SPF はできるだけシンプルに保ちましょう。RFC 7208 では、評価中に DNS ルックアップをトリガーするメカニズムと修飾子を 10 に制限しています。この制限を超えると、エラーが発生する可能性がありますpermerror。対策: 別のベンダーを追加する前に、インクルードやその他の DNS 拡張メカニズムの数をカウントしてください。

ステップ4：まずDMARCをモニタリングモードで公開する

DMARCポリシーは[ウェブサイトアドレス]で公開されています_dmarc.example.com。最初のレコードは慎重に設定してください。

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=noneデータ収集中は、受信者に対しDMARCポリシーに基づいて処理方法を変更しないよう要請します。このruaアドレスは集計レポートを要求します。現在の集計レポート形式はRFC 9990で規定されています。DMARCレポートを処理できるメールボックスまたはレポートサービスを使用し、無人の個人用受信トレイは使用しないでください。

pct=10古い記事から、や、または類似の展開例を盲目的にコピーしないでくださいpct=25。RFC 9989 は、pct運用経験から適用が一貫していないことが判明したため、歴史的なものとしてマークされています。現在の標準では、t=y必要に応じて動作をテストするためにを使用します。アクション: から始めてp=noneレポートを分析します。安全メカニズムとしてパーセンテージサンプリングに頼らないでください。

ステップ5：パブリックDNSの3つのレコードすべてを確認する

DNSプロバイダがレコードを公開した後、権威サーバーの外部、またはパブリックDNSを認識するリゾルバからクエリを実行します。例：

dig +short TXT example.com
dig +short TXT YOUR_SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

SPFについては、その所有者名に対して、特定の文字列で始まるTXTレスポンスが1つだけv=spf1存在することを確認してください。DKIMについては、セレクタがZimbraに現在保存されている値と完全に一致することを確認してください。DMARCについては、想定される名前に対して、使用可能なDMARCポリシーレコードが1つだけ存在することを確認してください。

DNSの伝播は、プロバイダ、TTL、およびリゾルバのキャッシュに依存します。権威ネームサーバーに即座に反映された変更でも、他の場所にキャッシュされている場合があります。対策：Zimbraが古い応答を返す原因だと判断する前に、少なくとも1つの独立したパブリックリゾルバに対してテストを実施してください。

ステップ6：実際のメッセージを送信し、認証の整合性を確認します

Zimbraドメインから別のプロバイダのメールボックスにメッセージを送信し、メッセージヘッダー全体を確認します。通常、正常に送信された場合は、DKIM署名やSPF認証が合格し、DMARC認証も合格しているはずです。これは、少なくとも1つの認証済みIDが、表示されている送信元ドメインと一致しているためです。

ここで別の誤解が明らかになります。DMARCはSPFとDKIMの両方が合格することを要求するわけではありません。合格するアラインメントされたSPF IDまたは合格するアラインメントされたDKIM IDが必要です。RFC 9989ではaspf、と両方について緩和されたアラインメントがデフォルトとして定義されていますadkimが、で厳密なアラインメントを要求することもできますs。対処法：検査してAuthentication-Results、アラインメントされたDMARC合格を提供しているメカニズムを正確に特定してください。

ステップ7：報告書がクリーンな状態になってから監視から執行へと移行する

DMARCデータで正当な送信者が認証され、正しく整合していることが確認できたら、ポリシーをp=quarantineまたはに変更することができますp=reject。現在の標準では、none、quarantine、 はrejectドメイン所有者による未認証使用の評価を表しますが、受信者は引き続きローカルでの処理裁量を保持します。

配信率の最適化として扱わないでくださいp=reject。DMARCは主に認証とドメイン不正利用対策であり、必要なメールを自動的に信頼できるものにしたり、受信トレイへの配信を保証したりするものではありません。対策：DMARCの適用は、受信率の向上を約束するのではなく、認証範囲の整合性に基づいたセキュリティ上の判断として行うようにしてください。

ステップ8：古いDNSレコードをすぐに削除せずにDKIMキーをローテーションする

ドメインのDKIMデータを更新するには、Zimbraのドキュメントを参照してください。

/opt/zimbra/libexec/zmdkimkeyutil -u -d example.com

このコマンドは、更新されたDKIMデータを作成し、新しいDNSエントリを生成します。Zimbraは、以前のキーで署名されたメッセージが転送中またはキューに入っている間も検証できるように、以前のTXTレコードを一定期間DNSに残しておくことを推奨しています。対処方法：まず新しいセレクタを公開し、検証した後、以前のセレクタを一時的に保持してから削除してください。

クイックリファレンス：各記録が証明するもの

Zimbra固有のチェック項目

Zimbraのメール保護に関するガイダンスでは、DKIMはドメインごとに生成し、各ドメインのパブリックDNSに公開する必要があると記載されています。また、古い構成では、特定のペルソナや自動応答の動作で発生する可能性のあるアライメントの問題についても説明されています。これらの詳細は状況によって異なるため、展開環境でエイリアス、ペルソナ、リレー、または通常とは異なるエンベロープからの書き換えを使用している場合は、これらのメッセージパスを個別にテストしてください。

マルチドメインのZimbraインストールでは、送信ドメインごとにDKIMの設定とDNS公開を繰り返してください。SPFとDMARCも同様にドメインポリシーです。ホストされているドメインのレコードが、無関係な別のドメインにも自動的に適用されるとは考えないでください。対策：厳格なDMARC適用を有効にする前に、すべてのドメインとすべての送信ルートに対して小規模なテストマトリックスを作成してください。

最終検証チェックリスト

• v=spf1各送信ドメインには、で始まるSPFレコードが正確に1つ存在します。
• SPFレコードには、承認されたすべての送信ルートが含まれ、SPF DNS処理制限内に収まります。
• Zimbraは、そのドメイン用に保存されているセレクタを使用して送信メールに署名します。
• 一致する DKIM 公開鍵は、パブリック DNS で に表示されますselector._domainkey。
• DMARC TXTレコードは、_dmarc.domain最新の構文を使用して公開されています。
• 外部テストメッセージは、SPFまたはDKIMの認証に合格しており、したがってDMARC認証にも合格していることを示しています。
• 集計報告書は、監視から隔離または却下へと移行する前に審査されます。
• 古いDKIMセレクタは、ローテーション中は一時的に保持され、移行期間が終了した後にのみ削除されます。

これらのチェックに合格すれば、Zimbraサーバーは単に3つのDNSレコードを公開しているのではなく、リモートの受信者が検証できる一貫性のある認証チェーンを提示していることになります。この点は、ガイドからサンプル文字列をコピーするよりもはるかに重要です。なぜなら、適切なSPFソース、DKIMセレクタ、およびDMARC適用タイミングは、組織から実際にメールが送信される方法によって異なるからです。