以前は、バックアップMXを用意するのは良いことでした。インターネットは信頼できず、電子メールは信頼できず、SMTPはそれほど一般的ではなく、bang-pathアドレス指定やその他の形式の手動で指定されたメールルーティングが一般的であり、uucpが選択されたメールプロトコルでした。
それはずっと昔のことです。今日はそうではありません。 MTAを送信すると、未配信のメールがキューに入れられ、数日間（デフォルトは通常4日または5日）配信を試み続けるため、メールサーバーがダウンしているか、数日間到達できない場合、メールは最終的に配信されます。
今日、非常に特殊な状況を除いて、バックアップMXは必要ありません。実際、それが解決する可能性があると想像するよりもはるかに多くの問題が発生します（実際にはほとんど問題を解決しません）。
バックアップMXに、メールを受信することになっているドメインの有効な受信者のリストがない限り、バックアップMXは即座に後方散乱の原因になります（スパムは偽造された送信者アドレスにバウンスします）。また、スパムがスパムフィルターの一部をバイパスする可能性のあるルートにもなります（ネット上のランダムなSMTPサーバーを信頼するよりもMXを信頼する必要があるため）。多くのスパマーは、この理由から（また、セカンダリMXのスパム対策フィルターが弱いことが多いため）、プライマリMXよりもバックアップMXマシンをターゲットにしています。
注：「スパム」と書くときは、スパムとウイルスを意味します。私のPOVからは、それらは同じものであり、とにかく同じスカムバッグによって送信されます（ほとんどのウイルスは何らかのスパムボットです）。
第1の経験則：バックアップMXが必要な理由と、それが引き起こす可能性のある問題と、それらを防ぐ方法を正確に理解していない限り、バックアップMXを使用しないでください。
2番目の経験則：バックアップMXを完全に制御でき、有効な受信者の最新リストと、プライマリMXとほぼ同等のスパムフィルターがあることを確認できない限り、バックアップMXは使用しないでください。
3番目の経験則：ルール1と2を参照してください。疑わしい場合は、バックアップMXを用意しないでください。
パターンを見始めましたか？
ところで、セカンダリMXをターゲットとするスパマーを利用できます。例えば私は、すべての配信試行に対して450 tempfailで応答する偽の最も優先度の低いMXを実行することにより、多くのスパムをブロックします。多くのスパムボットはそれをターゲットにしており、プライマリMXを試していません。そのため、実際のメールサーバーの負荷は大幅に軽減されます。私のメールサーバーは常にオンになっているため、正当な送信者は決してそれを試しません（そして、万が一そうでない場合、送信者は450の一時的な失敗コードを受け取り、後で再試行します）