メールサーバー

PleskでSPF、DKIM、DMARCを正しく設定する方法

このガイドでは、次のステップを紹介する。 SPF DKIM とPleskのDMARCを利用することで、Eメールが確実に認証されるようになります。DNSエントリ、Pleskスイッチ、テスト方法など、配信可能性を高め、不正な送信者をブロックするための明確な手順が提供されます。

中心点

SPF は、どのシステムがあなたのドメインのメールを送信する権限を持つかを決定します。
ディーケーアイエム 送信メッセージに署名し、不正操作から保護する。
ＤＭＡＲＣ SPF/DKIMをガイドラインやレポートとリンクさせる。
プレスク クイックスタートのためのウィザードとDNSテンプレートを提供します。
モニタリング のDMARCレポートは、運用中のポリシーをより鮮明にします。

Pleskで前提条件を確認する

設定を行う前に、私は プレスク そしてDNS管理。これらのサービスはSPF、DKIM、DMARC機能を提供しているからです。また、ドメインがPlesk DNSにDNSゾーンを持つか、外部プロバイダに持つかも確認します。 プレスク を追加する必要がある。スムーズな運用のために、私はホスト名、逆引きDNS、有効なTLS証明書をきれいにしておく。スタート地点をきれいにしておくと、後で多くの時間を節約できる。評判.

PleskでSPFを設定する - ステップバイステップ

手始めに、「ツールと設定」→「DNS設定」を開き、次のように始まるTXTレコードを検索する。 v=spf1 が始まる。例えば、欠けていたら、それをつける： v=spf1 a mx include:yourmailprovider.de -all許可されたシステムは送信を許可され、それ以外はブロックされるようにする。ドメインがMicrosoft 365、Google Workspace、ニュースレターサービスなどの追加送信者を使用している場合、私は適切な送信者を追加します。含む-そのドキュメントに記載されているメカニズムを参照してください。保存後、変更がグローバルに反映されるまで最大48時間待ち、選択したメールボックスにテストメールを送り、SPFチェッカーでレコードをテストする。各メカニズムの相互作用に関するコンパクトな分類はコンパクトガイド最も重要なシナリオを説明している。

PleskでDKIMを有効にする - これがその方法です。

のために ディーケーアイエム ツールと設定」→「メールサーバーの設定」で、送信メールに署名するオプションを有効にする。その後、ドメインレベルで "ウェブサイトとドメイン"→ドメイン→"メール"→"設定 "を開き、各ドメインで署名がオンになっているかチェックする。DNSを外部で管理する場合、私は以下のサイトからデータをエクスポートする。 プレスク 生成されたDKIM公開鍵をDNSプロバイダーにTXTレコードとして入力する（セレクタ名に注意）。最大24～48時間後、受信者はDKIM署名を検証するはずです。私はDKIMチェックのメールボックスにテストメールを送るか、ヘッダーチェックで確認します。有効な署名は 配達可能性 目につく。

DMARCポリシーの定義とレポートの使用

今、私は ＤＭＡＲＣ をTXTレコードとして _dmarc.yourdomain.tld を持つ。 v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s.タグ p, ルアそして コール 管理方針と報告 アドキム/アスプ 厳密なアライメント（strict）を定義する。実際には p=なし2週間から4週間かけて報告書を評価し、その後、次の報告書を作成する。 隔離 或いは 拒む .レポートは、どのシステムがあなたの代わりにメールを送信し、SPFまたはDKIMが失敗した場所を示し、直接修正することができます。より詳細な一連のステップでは DMARCの実装具体的な例とともに。

DNSの伝播、テスト、ベストプラクティス

DNSの変更には毎回時間がかかるので、世界的なDNSの変更には最大48時間を予定している。伝播オン。この段階では、外部のメールボックスにテストメールを送り、ヘッダーの spf=パス, dkim=パス そして dmarc=pass.メールを受信した場合 ソフトフェイル 或いは ニュートラル私はSPFメカニズム、DKIMセレクタ、envelope-from（リターンパス）がFrom:と一致しているかをチェックしている。リダイレクトを使う場合は、DMARCの結果を監視している。DKIMは通常これを補う。 ~すべて 永続的に、そして生産的なセットアップのために一貫して依存している。 -ぜんぶ.

DMARCタグと値 - コンパクトな表

私は次のような概要を使っている。 ＤＭＡＲＣ 迅速かつ確実に、そして誤解を避けるために。メインドメインとサブドメインで値を一貫させ、変更を追跡可能な方法で文書化する。生産性の高いドメインについては、厳格なアライメントを設定し、常に集計レポートを有効にしている。フォレンジック・レポート(コール私はデータ保護規則を遵守して計画を立てています。明確なガイドラインを設定することで評判ドメインの

日	意味	可能な値	推薦
p	メインドメインのポリシー	なし、隔離、拒否	何もないところから始め、次に拒否する数を増やす
sp	サブドメインのポリシー	なし、隔離、拒否	生産的なセットアップにはsp=reject
ルア	集計レポート	mailto:adresse	自分の報告用アドレスを使用する
コール	科学捜査報告書	mailto:adresse	必要な場合のみ作動させる
アドキム	DKIMアライメント	r（リラックス）、s（厳格）	adkim=sで明確な割り当て
アスプ	SPFアライメント	r（リラックス）、s（厳格）	誤報を減らすaspf=s
パーセント	応募の割合	0-100	pctによる段階的な引き締め

外部送信者の統合Microsoft 365、Google、ニュースレターサービス

ドメインが追加の配送経路を使用する場合、私は以下のSPFインクルードを追加します。 マイクロソフト 365、Google Workspace、Mailgun、SendGrid、またはニュースレターツールは、ドキュメントに記載されているとおりに使用する。各サービスについて、別のDKIMキーが有効かどうか、送信元ドメインが本当に署名されているかどうかをチェックする。重複や多すぎる署名は避ける含む-SPFのDNSルックアップは10回に制限されているためだ。ルックアップの予算が足りない場合は、送信者を統合したり、個々のストリームを独自のDMARCポリシーを持つサブドメインに移動させたりしている。こうしてSPFの無駄を省き、DMARCの安全性を確保している。署名より。

綿密なチェックとサーバー選定

受信メールについては プレスク SPF、DKIM、DMARCをチェックし、サーバーが早い段階でスパムをフィルタリングできるようにします。Linuxではこれらのチェックはデフォルトで利用でき、WindowsではSmarterMailで実装されている。署名ルーチンとパーサーが最新の状態に保たれるように、メールサーバーが適切にアップデートされていることを確認する。偽陽性の問題があれば、スコアリングのしきい値を調整するが、決して方針自分のドメインのものです。このようにして、私は高い保護率を維持し、正当な送信者からの配信を保証しています。

よくあるエラーと迅速な解決策

ミーツ "SPF permerror "の場合、通常は構文エラーか、ルックアップの上限を超えている。DKIMが失敗した場合は、セレクタ、公開鍵レコード、およびTXT値の終端が正しい逆カンマで終わっていることを確認します。DMARCが失敗した場合 失敗まず、From-Domain、Return-Path、DKIM-d=が完全に一致していることを確認する。SPFがリダイレクトで壊れる場合は ディーケーアイエム そして署名のステータスを安定させる。私はこの順序を使うことで、配送に関するほとんどの問題を、長い時間をかけて検索することなく解決している。

PleskのDNSテンプレートと自動化

多くのドメインを管理する場合は DNSテンプレート をPleskにインストールし、SPF、DKIM、DMARCの標準レコードを保存しています。新しいドメインはすぐに強固なデフォルトを受け取ることができ、私はそれを微調整するだけでよいのです。また、テンプレートとスクリプトを使用して、ドメイン全体でより厳格なDMARCなどの計画的な変更も実装しています。DKIMキーのローテーションについては、段階的に変更できるように2つのセレクタを使用しています。こうすることで、数十のドメインで一貫した運用を維持することができます。 維持可能.

DMARCレポートの評価とポリシーの強化

本番稼動後、私は毎日のように集計レポートを分析し、次のようなことを確認している。 情報源ドメインに代わって無許可で送信するものです。私は、ポリシーを強化する前に、予期しないIPをブロックし、古くなったツールをクリーンアップします。からの変更 p=なし に於いて 隔離 そして後に 拒む 私は、次のことを実行する。 パーセント 段階を踏んで、コントロールされた方法で効果を測定できるようにした。失敗したレポートに正当な送信者が表示された場合、私はSPFを修正するか、独自のDKIMキーを有効にする。このルーチンは評判可視化され、なりすましを減らすことができる。

アライメントを正しく理解する

だから ＤＭＡＲＣ 私は一貫して正しいアライメントを確保している。そして SPF は、envelope from (リターンパス)のドメイン、またはHELO/EHLO IDであり、可視のfromドメインと一致しなければならない(strict: 同一、relaxed: 同じ組織のドメイン)。とは ディーケーアイエム をチェックする。 d=-署名の属性：同一ドメイン（strict）または同一組織ドメイン（relax）を指すこと。実際には、次のことを確認する：

使用されるバウンスパス（リターンパス）がfromドメインと一致するドメインを使用しているか、独自のDMARCポリシーを持つサブドメインに意図的にアウトソースされている、
すべてのサードパーティプロバイダのFromドメイン サイン (DKIM)である、
DKIM署名は、SPFの破壊を補うために、転送中もそのまま残ります。

アライメントが欠落している場合、有効なSPF/DKIMにもかかわらず、DMARC受信者はエラーを報告する。 dmarc=失敗.だから、私は電子メールのヘッダーにあるフィールドをチェックするのだ。 認証結果, リターンパス とDKIMパラメータを比較する。これによって、SPFとDKIMのどちらが整合性がとれていて、どこを改善する必要があるかがすぐにわかる。

鍵管理とDNSパラメータ

堅牢な ディーケーアイエム-セットアップでは、2048ビットのキーを使用した。で プレスク 私はドメインごとにキーの長さを設定することができる。私は古い1024ビットのキーを速やかに上げる。必要であれば、長いDKIM TXTレコードをいくつかの逆カンマセグメントに分割し、DNSサーバーが正しく配信できるようにしている。また、意味のある TTL-値：ロールアウト段階では300〜900秒、生産的には1〜4時間を使う。これにより、キャッシュに負荷をかけることなく、変更に柔軟に対応できる。

仝 ローテーション 私はこれを2つのセレクタで失敗なくやっている：

Pleskで新しいセレクタを作成し、公開鍵をDNSでTXTとして公開します。
送信者を新しいセレクタに変更し、モニタリング（ヘッダの表示）を観察する。 s=新しいセレクタ).
すべてのフローが変換されたら、DNSの古いセレクタを削除し、Pleskで無効にします。

私は可能な限り、第三者のプロバイダーを利用している、 委任統治 DKIMレコード(例えばプロバイダセレクタへのCNAME)。これによって、私は自分のゾーンの制御を維持し、運用中断のリスクを冒すことなくキーを回転させることができる。

特殊なケース転送、メーリングリスト、ゲートウェイ

実際の環境では、メールを書き換えるリダイレクトやメーリングリスト、セキュリティゲートウェイを定期的に見かける。私は特にこの効果に注意を払っている：

転送転送先IPが送信者ドメインのSPFにないため、SPFはしばしば壊れる。私はここで ディーケーアイエムこれはコンテンツ保護を提供する。署名が変更されない場合、DKIMアライメントを介してDMARCが存在する。
メーリングリスト多くのメーリングリストはサブジェクトやフッターを変更するため、DKIM署名が壊れてしまいます。そのような場合、私はリラックスしたアライメントを計画し、リストがSRS/ARCまたは独自の署名を使用しているかどうかを確認します。可能であれば、リストには独自のDMARCポリシーを持つサブドメインを使います。
セキュリティ・ゲートウェイメッセージに再署名したりenvelope-fromを書き換えたりするゲートウェイは、送信者ドメインと正しく整合していなければならない。私はその役割を文書化し、SPF（ip4/ip6）またはインクルードでアンカーを付け、アライメントが維持されるようにしている。

とのメールのやり取り spf=失敗 フォワーディングを経由する限り、自動的にクリティカルになることはない。 dkim=パス が存在し、DKIMアライメントが正しい。個々のシグナルを個別に評価するのではなく、認証結果全体を評価する。

共有IP、HELO/EHLO、rDNS

複数のドメインが同じ発信IPを共有している場合、私はクリーンなIPに頼っている。 rDNS および一貫したHELO/EHLO名を指す。逆ポインタはFQDNを指す（たとえば mail.hosting-example.tld)、そのAレコードは同じIPを指している。MTAはまさにこの名前で報告する。私は SMTP TLS証明書 は、HELO名（複数の名前が提供されている場合はSNI）と一致します。各送信者ドメインについて、SPF/DKIM/DMARCが完全かつ正しく整合していることも確認する。認証が有効である限り、共有IPだけではDMARCには影響しない。

専用の送信者（例：トランザクションメールとマーケティングメール）については、サブドメインと、オプションで独自のIPで分けたい。これは 評判管理は、DMARCレポートの評価を簡素化し、相互干渉を最小限に抑えます。

モニタリングと展開の実際

スムーズなオペレーションを保証するために、私は継続的な DMARC分析 明確な展開ステップとともに：

ベースライン2～4週間 p=なしすべての集計レポート（ルア）を収集し、エラーの原因を特定する。
後片付け未承認の送信者を削除し、SPFインクルードをクリーンアップし、すべての正規システムでDKIMを有効にする。
ドレッシングと パーセント 徐々に 隔離後に 拒む を増やし、その効果をパーセンテージで測定する。
注意喚起しきい値（新規IP、プロバイダーごとの失敗率、ドメインからの新規）を定義し、通知を設定します。
ドキュメンテーションセレクタ、TTL、キーのランタイム、SPF予算、責任をバージョン管理下に置く。

をチェックする。 SPFルックアップ予算 (DNSクエリで最大10メカニズム)を含み、統合する。以下のような重要なメカニズム ピーティーアール 或いは +すべて 私は通常、使用しない； アイピーフォー/アイピーロク, a, エムエックス とターゲット 含む が選択の手段であることに変わりはない。これが、私がセットアップを安定させ、監査可能な状態に保つ方法である。

各ドメインのクイックチェック

各インストールの最後に、私は固定された チェック を通して：SPFレコードが利用可能で、ルックアップ予算が10以下、メカニズムが正しくソートされている、 -ぜんぶ アクティブ。DKIM署名が有効で、セレクタが文書化され、キーの長さが十分で、ローテーションが計画されている。有効なTXTレコードを持つDMARC、厳格なアライメント、アクセス可能でアーカイブされたメールボックスを報告。テストメールの表示 spf=パス, dkim=パス そして dmarc=pass をヘッダーに追加する。私は、セットアップの再現性を保つために、この順序を使用している。 誤差が少ない.

素早く成功するための実践的まとめ

私はすべてのプロジェクトを明確にして始める。規格SPFに無駄をなくし、各送信者のDKIMを有効化し、DMARCをレポーティング付きで展開する。その後、2週間から4週間かけてモニタリングし、盲点をつぶしてガイドラインを強化する。外部サービスを管理された方法で統合し、その内容を文書化し、ルックアップの予算を管理しています。複数のドメインにDNSテンプレートを使用し、署名を新鮮に保つためにDKIMキーのローテーションを計画する。有用な実践的アイデアとトラブルシューティングのヒントは、私の Pleskのヒント 2025 その結果、あなたたちは強いチームワークを維持することができる。 配達可能性 に達する。