...
ウェブホスティングのロゴ

独自ドメインでメール設定：MXレコードとツールの説明

MXレコード あなたのドメインのメールがどこに配信されるかを決定する Eメール独自ドメイン を正しく設定し、チェックし、保護する。必要なDNSエントリについて説明する。 ツール そして避けるべき典型的な間違い。

中心点

  • MXレコードドメインごとに担当メールサーバーを定義する
  • SPF/DKIM/DMARC発送承認、署名、ガイドライン
  • プライオリティ/TTL配信シーケンスとDNS更新速度
  • ツールセットアップの確認、エラーの可視化
  • プロバイダー選定適切なパッケージ、良いサポート

MXレコードとは何ですか？

と定義している。 MXレコードどのメールサーバーが私のドメインのメールを受け付けるか。誰かが私のアドレスに書き込むとすぐに、送信サーバーはDNSの関連エントリーを照会する。該当するエントリーは、メールを受け入れ転送するターゲットサーバーを指しています。正しいMXレコードがないと、配信エラーや拒否のリスクがあります。私は、これらのエントリーは明確で、曖昧さがなく、矛盾する情報がないと考えています。 信頼できる 配達。

独自ドメインメールのメリット

自分の住所で仕事をする プロフェッショナル そして、私のブランドを強化します。MXレコードを自分で管理しているので、プロバイダーの変更も自分でコントロールできます。チーム、プロジェクト、サービスのために新しいメールボックスを素早く追加できる。受信者がすぐに私のドメインを認識するため、認知度が高まる。これにより、信頼が確保され コントロール 私のメールのトラフィックについて。

条件を整える

私は自分のドメインとアクセス権を持っている。 DNS管理 をレジストラまたはホスティング会社と共有する必要があります。Google Workspace、Microsoft 365、Proton Mail、またはホスティングパッケージなどのアクティブなメールサービスが利用可能でなければなりません。プロバイダーは後で正確なMXターゲット、ホスト名、優先順位を見せてくれる。IONOSまたは同様のレジストラの場合、コンパクトな IONOS DNSの説明 DNSゾーンを見つけるときにの次のステップで正しく入力できるように、メールプロバイダーからのデータをすべてメモしておく。 ゾーン に入る。

MXレコードの設定ステップ

レジストラにログインしてDNS設定を開き、まず古いMXエントリが存在するかどうかをチェックします。古いエントリーを削除し、競合するサーバーが存在しないようにします。その後、プロバイダーからMXデータを正確にコピーする。smtp.google.com"のような低い優先順位とホスト"@"を指定します。変更がより早く反映されるように、TTLの値は控えめにする。最後に、DNSゾーンを保存し、グローバルに配布するには時間がかかるので、待ち時間を計画する。

プライオリティ、ホスト、TTLを理解する

仝 優先順位 は、どのMXサーバーに最初にコンタクトするかを制御します。数字が小さいほど優先されます。数字が小さいほど優先されます。数字が大きい追加のMXエントリーは、障害が発生した場合のフォールバックとして機能します。私は通常、エントリーがドメインのルートに適用されるように、ホストとして"@"を使用します。サブドメインには独自のMXエントリーが必要です。私は、調整がより早く見えるように、TTL値にかなり短い時間を使うことがよくあります。情報の一貫性を保ち、異なるプロバイダーと同じMXエントリーを混在させないようにしています。 優先順位なぜなら、これは配達を混乱させるからだ。

MXレコードに関する重要なDNSルール

私はいくつかのことを指摘する。 基本ルール私のMXエントリーが技術的にクリーンであるように：

  • MXはホスト名を指すIPアドレスに対してではない。ターゲットホストには有効なAレコードまたはAAAAレコードが必要です。
  • MX宛先にCNAMEがない： MXはCNAMEを参照してはならない。私は常にcanonical hostを使用しています。
  • 同じオーナーにCNAMEがないCNAMEがある場合、他のレコードタイプは存在しません。したがって、MX、TXT (SPF)または他のエントリが必要な場合は、ルートドメインにCNAMEを設定しません。
  • サブドメインは別々にについて sub.example.de の場合、自動的にルートのMXではなく、サブドメインのMXが適用されます。サブドメインでメールを受信する場合は、サブドメインごとにMXを入力します。
  • 賢明なフォールバックの選択複数のMXレコードは、同じプラットフォームからのものであるか、フェイルオーバーが本当に機能するように同期されている。

プロバイダー別MXの例

私はいつもプロバイダーの管理エリアからの情報を使っています。典型的な例は、私が理解するのに役立ちます（変更される可能性があります）：

  • Googleワークスペース次のようなホスト aspmx.l.google.com (優先順位1）とその他のバックアップ alt1.aspmx.l.google.com その他私はすべての推奨エントリーを設定した。
  • マイクロソフト365ほとんど ドメインキー.mail.protection.outlook.com (ドメインごとに個別に)優先度0または10で設定する。
  • プロトン・メール頻繁に mail.protonmail.ch (優先順位10）と mailsec.protonmail.ch (優先順位20）。
  • ウェブホスト多くの場合、カスタマイズされたMXのようなものだ。 mxX.provider.tld.対応するA/AAレコードが存在することを確認する。

私は一般的な例に頼らず、自分のセットアップから正確な値を入力する。

SPF、DKIM、DMARCの補足

MXに加えて、私はいつも SPF 認証されたサーバーだけが私の代わりに送信するように。また、DKIMを有効にして、すべての送信メッセージに暗号署名を持たせています。DMARCを使用して、認証されていないメールに対して受信者が何をすべきかという明確なルールを策定しています。この組み合わせにより、配信率が向上し、私のドメイン経由のフィッシングのリスクが減少します。私は定期的に ガイドライン 特にプロバイダーが変わった後は。

SPF/DKIM/DMARCの実践を深める

SPFでは、私は無駄のないポリシーを持っている。 を含む：-DNSルックアップを最小化し、重複エントリーを避けるためのメカニズム。変更が保留されている場合、私は最初に ~すべて (softfail)し、後で -ぜんぶ (hardfail)すべてのチャンネルが適切にカバーされている場合。DKIMには セレクター-名前（例 s1, s2)を使って、メールを中断させることなくキーを回転させることができます。DMARCでは、まず p=なし に関する分析を収集する。 ルア-集計レポートすべてが安定したら、徐々に 隔離 そして 拒むオプションで pct=を1パーセントだけ強化する。こうして私は、セキュリティと配信性の安定したバランスを見つけるのです。

テストとモニタリングのためのツール

私はテストツールでセットアップをチェックし、警告には即座に対応します。MXチェックや管理ツールボックスのようなサービスは、誤ったホスト名、誤った優先順位、TXTエントリーの欠落などを示してくれます。より詳細な分析には、以下の情報を利用しています。 DNSエラーの認識原因をきれいに分けるために。私は変更のたびに、アクセシビリティ、ディスパッチ、認証をテストしている。こうして MXレコード 永続的に機能し、追跡可能である。

典型的なミスを避ける

私は、同じMXのエントリーが矛盾することを許さない。 優先順位 プロバイダーが異なる場合ホストを"@"または希望のサブドメインに正しく設定し、メールがどこにも行かないようにする。長すぎるTTLは、その後の変換を遅くするので避ける。SPF、DKIM、DMARCの設定は忘れない。変更後は必ずテストを行い、次のことを確認しています。 問題点 直接認識する。

失敗のない移行計画

プロバイダーを変更する前に TTL 私のMXレコードと関連するTXTレコードは、数分-理想的には締め切りの24〜48時間前-に設定します。私はすでに新しいプロバイダーでメールボックスとエイリアスを設定しています。 並行受け入れ (二重配信または転送)を使用して、DNSの切り替え中にメールが失われないようにしています。私は両方のシステムで受信メッセージを監視し、送信者の大半が新しいレコードを使用している場合にのみ、古いMXをオフに切り替えます。きれいなフォールバックプランのために、古い値をメモしておき、必要に応じてすぐに切り替えられるようにしています。

リダイレクト、エイリアス、キャッチオール

私は次のように区別している。 別名 (同じメールボックスの別のアドレス）と 転送 (別の宛先への配送）。転送は、転送先サーバーが認証されていないため、SPFチェックを破る可能性がある。したがって、私は次のように考える。 ディーケーアイエム を安定させ、可能であれば転送サーバーでSRS（Sender Rewriting Scheme）を使用する。A キャッチオール 実用的ですが、スパムが増えます。例えば インフォ 或いは サポート 私は、やり残しがないように明確な責任を課している。

Eメール・プロバイダーの比較

私は、DNSの使いやすさ、セキュリティ、幅広い機能、サポートに基づいてプロバイダーを選んでいます。企業にとって、DNSエントリーの明確な管理は、モニタリングや優れたヘルプテキストと同じくらい重要です。私は、プロバイダが提供する透明性の高いMX仕様と追加レコードに注目しています。迅速なサポートは、配信の問題が発生した場合に時間を節約してくれます。次の表は、私がDNSを利用する際に役立つものです。 分類 ポピュラーなソリューションだ。

プロバイダ 電子メール統合 DNS管理 サポート
webhoster.de 非常に良い 非常にシンプル 素晴らしい
Googleワークスペース 非常に良い シンプル 非常に良い
マイクロソフト365 非常に良い ミディアム グッド
プロトン・メール 非常に良い ミディアム グッド

手順：プロトンメールの設定

Protonの管理エリアで自分のドメインに接続し、所有権を確認します。その後、DNSゾーンに表示されているMX、SPF、DKIM、DMARCレコードを入力します。Protonは、すべてのキーが正しく保存されているか、また 署名 がアクティブになっている。DNS配信の後、テストメールで受信と送信をテストします。その後、プロトンパネルで直接メールボックス、エイリアス、転送を設定し、私の セットアップ 完全に有効だ。

GoogleワークスペースとMicrosoft 365

Google WorkspaceまたはMicrosoft 365を自分のドメインで有効化し、セットアップウィザードに従います。Googleの場合、現在のMXデフォルト、例えば優先度1の "smtp.google.com "と追加のTXTエントリーを採用する。Microsoft 365では、管理センターで必要なエントリーを作成し、確認が通るかどうかをチェックする。その後、受信、送信、SPF検証、DKIM署名をテストする。テストにエラーがなければ、私は プラットフォーム 生産性を高め、定期的な見直しを計画する。

独自のネームサーバーとDNS委任

必要であれば、私は自分のネームサーバーを運用し、自分のドメインを彼らに委任します。私は、きれいなゾーンメンテナンス、正しいNSエントリ、レジストラとの適切なグルーレコードに依存しています。構造化された委任は、責任を明確にし、MX、SPF、DKIM、DMARCを変更する際の経路を短縮します。コンパクトに始めるために、私は ネームサーバーの設定.私はこうして政権をフル稼働させている。 コントロール そして、より素早く反応することができる。

トランスポート時のセキュリティ：TLS、MTA-STS、DANE

私は、プロバイダーに次のことを確認している。 ティーエルエス は、送受信メールの送受信を強制または優先する。とは MTA-STS どのメールサーバーが私のドメインで有効か、TLSが期待されていることを受信者に伝えることができる； TLS-RPT はTLSの問題についてのレポートを提供してくれる。もし私のドメインが ディナセック が署名され、プロバイダがTLSAレコードをサポートしている場合、私はオプションで DANE を追加している。これにより、ダウングレード攻撃のリスクが軽減され、トランスポート暗号化の一貫性が保たれる。

サブドメイン、トランザクションメール、分離

私は一緒に仕事をするのが好きだ。 サブドメインを使って異なるメールフローを分けている：例えば、私は mail.example.de のような別の送信用サブドメインが必要です。 mg.example.de をニュースレターやシステムメール用に使っています。これにより、認証を分離し（独自のSPF/DKIMレコード）、監視を簡素化し、大量メールのエラーがメインドメインに影響するのを防ぐことができます。また、影響を受けるサブドメインのMXレコードとA/AAAレコードが完全で一貫していることも確認しています。

ブロックリスト、バウンス、配達のハードル

私は、送信ディスパッチやMXの宛先が以下のものであるかどうかを監視している。 ブロックリスト (RBL）が現れる。より多くの ソフトバウンス（4xx） を待つ、あるいは後日配送を試みる。 ハードバウンズ (5xx) エラーテキスト（「SPF fail」、「DKIM bad signature」、「Mailbox full」、「User unknown」など）をチェックする。グレイリストの場合は、設定を厳しくせずに再送信しています。私は、風評被害を避けるために、リストをクリーンに保ち、配信停止を管理し、配信不能なアドレスを削除しています。

メールボックス、プロトコル、アクセス

でIMAP/POP3/SMTPアカウントを作成します。 強力なパスワード を起動する。 2FA可能であれば。私はサーバー名、ポート、TLS/STARTTLSのデフォルトを文書化し、古いクライアント用にアプリのパスワードを設定します。私は クォータ (ストレージ・クォータ）を現実的に設定し、メールボックスが一杯にならないようにし、大容量の添付ファイルをアウトソーシングまたは自動的にアーカイブするルールを設定します。これにより、クライアントが安定し、メールにアクセスしやすくなります。

セルフホスティングとクラウドプロバイダー

私自身が メールサーバー 固定IP、正しいIPアドレスが必要 PTR-レート制限、リバースDNS、一貫したHELO/EHLOホスト名、強力なスパムフィルター、クリーンなパッチ管理。キューを安定させるために、レート制限、バックプレッシャー、モニタリングを設定します。多くの組織にとって クラウドプロバイダー チームのリソース、コンプライアンス要件、予算に応じて決定します。

DNSSECとゾーン衛生

私は自分のゾーンにこう署名している。 ディナセック私のレジストラとDNSプロバイダがそれをサポートし、DSレコードを正しく保存していれば。私はゾーンをクリアな状態にしています：古いエントリ、矛盾するCNAME、複数のSPFエントリ（私はコンテンツを ひとつ SPFのTXTレコード)。大きな変更を加える前に バックアップ・コピー 必要であれば、すぐに戻ることができる。

最終合格チェックリスト

  • MXレコードはA/AAAの有効なホスト名を指し、優先順位は正しく設定されています。
  • SPF-TXTあり、ルックアップ制限遵守、重複なし
  • DKIM-Selectorが公開され、署名が有効である。
  • DMARCポリシー定義（p=none/quarantine/reject）、レポート配信
  • オプション：MTA-STS/TLS-RPT公開、DNSSECアクティブ
  • フォワーディング／エイリアスのテスト、キャッチオールの意図的な設定
  • TTL戦略の文書化、移行テスト成功
  • メールボックスがクライアントに統合され、2FA/アプリのパスワードが設定される
  • 配信、バウンス、ブロックリストの監視

簡単にまとめると

私は自分のアドレスを正しく設定した。 MXレコード SPF、DKIM、DMARCを追加し、すべてを徹底的にテストする。優先順位は配信順序を制御し、適切なTTLは変更を加速する。ツールはエラーを即座に認識し、的を絞った方法で修正するのに役立ちます。適切なプラットフォームと優れたサポートがあれば、私はメール業務を確実に実行し続けることができます。これにより、私のコミュニケーションはプロフェッショナルで、追跡可能で、長期的なものになります。 セーフ.

現在の記事