40個のドメインを一つのアカウントで管理する方法

いくつかを超えるドメインのメールを管理していると、誰でも最終的に表計算シートを作ります。どのドメインがどの事業者にあるか、どのネームサーバーを使っているか、誰のカードで支払うか、最後にDNSを確認した日、担当者は誰かを記録するためです。40ドメインを1アカウントにまとめれば、プラットフォーム自体が答えを保持するため、このシートは不要になります。

この記事では、この規模で実際に何が変わるのか、どの操作がドメインごとの作業ではなくなるのか、統合すべきでない場面を説明します。

40ドメインで管理が崩れ始める理由

ドメインが40件になっても、1アカウントにあるかどうかにかかわらず、突然何かが壊れるわけではありません。3件なら小さかったドメインごとの作業が、それ自体で仕事になるだけです。

DNS確認が最も分かりやすい例です。1ドメインのレコードが正しいか調べるには1分しかかかりませんが、40件なら午前中の大半を使います。そのため確認頻度が下がり、メールの不達を誰かが報告するまで、壊れたレコードが何か月も見過ごされます。

メールボックスの追加、ストレージの確認、証明書の更新確認、送信経路の変更検知など、ドメイン単位で行うほかの作業も同じです。一つひとつは難しくありません。ただし、すべてを40回行います。

さらに、40ドメインが複数の事業者に分散していると、まとめて確認する場所がありません。そこで表計算シートが必要になります。各システムが個別には知っていても、一緒に表示してくれない情報を手作業で索引にしたものです。

まとめて処理できるようになる操作

40ドメインを1アカウントにすると、一部の操作を繰り返さず、一括で実行できます。時間を取り戻せるのはこの部分です。

DNSを指示するのではなく直接適用。ドメインがCloudflareで管理されている場合、入力用の一覧を誰かに渡すのではなく、API経由でレコードを直接書き込めます。手入力の作業と転記ミスの両方がなくなります。ドメインが一部だけ動く状態になる主な原因は、この転記ミスです。

ドメインの一括追加。40件のドメインを40回ではなく1回の操作で追加でき、それぞれのメールボックスも同じように一括作成できます。

状態を一つの画面で確認。どのドメインが検査に合格しているか、メールが流れているか、動きがないかを一覧できます。表計算シートと同じ役割を、利用者ではなくシステムが保守します。

請求書を一つに集約。最も興味深い利点ではありませんが、移行のきっかけになることが多い点です。4社から届く40枚の少額請求書は、それだけで管理業務になります。

この規模で重要になる上限

40ドメインを1アカウントに収容できるかどうかは、プランごとのドメイン上限で決まります。

40ドメインなら月額$4のStarterに十分収まります。複数ドメイン管理は大企業向けだと思っていた人には意外でしょう。Starterにはフィルターがないため、自動振り分けが必要ならProを選びます。契約前に知っておくべき境界です。

もう一つの制約は、全メールボックスで共有するメールストレージ容量です。Starterは15 GB、Proは50、Agencyは200です。各ドメインに少数のメールボックスがある環境なら問題ありませんが、40ドメインすべてでメール利用が多い場合は足りません。

整理された状態を保つ

40ドメインを1アカウントにまとめると、ツールの問題は解決しますが、整理の問題が生まれます。40件が一つの一覧に並べば、それでも探しにくいからです。

ドメインのメモは、見た目以上に役立ちます。ドメインが存在する理由、所有者、用途を1行で記録しておけば、1年半後に思い出せなくなったときに答えが分かります。誰も更新しない別文書ではなく、ドメインと一緒に保存されます。

ドメイン間で命名規則を統一することも大きな助けになります。どこでも同じ規則でメールボックスに名前を付ければ、調べなくてもアドレスから所属ドメインと用途が分かります。

実際に利用中のドメインとパーキング中のドメインも区別してください。必要な管理が異なります。パーキングドメインには全受信だけで十分です。詳しくは、パーキングドメインのメールで説明しています。利用中のドメインには定期的な確認が必要です。

メモ欄が価値を発揮する場面

ドメインが40件になると、繰り返し出てくるのは設定方法ではなく、そもそもなぜ存在するのかという質問です。

各ドメインに、所有者、用途、最終確認日を1行で記録すれば、誰も更新しない別文書なしで答えられます。環境全体で最も低コストな文書でありながら、最も省略されやすい記録です。

統合が適切でない場合

40ドメインを1アカウントにまとめるべきでない状況が2つあります。どちらも真剣に検討してください。

将来返却する可能性がある顧客ドメイン。顧客が契約を終了し、自分のアカウントへドメインを持っていく可能性があるなら、自社アカウント内で管理すると切り離しが難しくなります。不可能ではありませんが、所有権を渡すだけではなく、移行作業になります。考えるべき時期は契約終了中ではなく、その前です。

明確に異なる要件があるドメイン。1つのドメインだけに、ほかにはないコンプライアンス要件がある場合です。データレジデンシー、特定の保存期間、専用の送信経路などが該当します。ほかの39件と一緒にすると、最も厳しい要件を事実上すべてへ適用するか、例外として個別対応することになります。例外はやがて忘れられます。

多くの代理店や運用代行会社が選ぶのは中間案です。通常のドメインをすべて統合し、本当に特殊な2件か3件だけを分けます。どちらかの極端な方法より合理的です。

週末を費やさずに移行する

40ドメインを1アカウントに集める作業は大きなプロジェクトに聞こえますが、実際の大半は待ち時間です。

一度にすべて行うべきではなく、その必要もありません。ドメインは個別に移動できるため、互いに連携させず、数週間かけて進められます。1件の問題がほかのドメインに影響することもありません。

ドメインごとの作業は、追加、DNSの適用、既存メールボックスの移行です。実際に時間がかかるのは最後だけで、バックグラウンドで実行されます。問題を避けるには、まず動きの少ないドメインから始めます。パーキング中のドメインや通信量の少ないドメインなら、ミスの影響もほとんどありません。手順に自信がついてから、最も利用量の多いドメインへ進みます。

DNSの反映が完了するまで、メールは以前の事業者へ届き続けるため、切り替え中も失われません。瞬時に切り替えるのではなく、新旧が一時的に重なります。既存メールの移行方法は、メール移行で説明しています。コピー成功の表示だけで完全だと決めつけず、移行後に照合処理も実行してください。