独自ドメインのメールを導入する手順と決めること

ドメインを取ったあと、会社のメールをどこで作るかで手が止まります。サーバーの管理画面には追加ボタンがあり、押せば info@ も個人のアドレスも数分で作れます。作業はそれで終わりますが、何も決めずに押したことが後から効いてきます。

困るのは導入した当日ではありません。担当者が辞めて受信箱を誰も開けられない、問い合わせ用のアドレスを全員が「他の誰かが見ている」と思って放置する、サーバーを移そうとしたらメールまで巻き込まれる。どれも設定の誤りではなく、最初に決めていなかったことが原因です。

ここでは、設定画面を開く前に決める項目を先に置き、そのあとで新規導入と移行の手順を扱います。移行すべきかどうかを迷っている段階であれば、会社のメールを無料のGmailだけで運用してよいのかで判断材料を整理しています。なお、DNSレコードに書く値は利用するサービスごとに違うため、具体的な値は扱いません。

ドメインの名義と管理者を先に決める

メールの土台はドメインです。契約が誰の名義かで、後の自由度が決まります。

よくあるのは、制作を依頼した会社の名義になっている状態と、当時の担当者が個人のアカウントで取得した状態です。前者は取引が終わると移管の交渉が発生し、後者はその人が辞めた時点で更新の通知が誰にも届かなくなります。どちらも、失効して初めて気づきます。

導入時に次の4点を確認してください。

• 登録者の名義が法人（または事業主本人）か。他社や個人の名義なら、移管の手順と費用を先に聞いておく
• 更新料の支払いが、退職で止まらない方法か。個人名義のカードは、その人がいなくなると更新できません
• 管理画面にログインできる人が2人以上いるか
• ドメイン登録時の連絡先を、これから作る独自ドメインのアドレスにしていないか

最後の1点は見落とされがちです。連絡先を admin@自社ドメイン にすると、メールが止まったときに再設定の通知を受け取れません。ここには独自ドメイン以外のアドレスを指定します。

サーバーとまとめて契約する場合も、名義と支払いの考え方は同じです。契約の型を検討中なら、法人向けレンタルサーバーの選び方で要件の決め方を扱っています。

アドレスの命名規則は、後から変えるほうが高くつく

アドレスは名刺、請求書、取引先の宛先帳、各種サービスのログインIDに残ります。1つ作り直すだけでも、告知と差し替えが広範囲に及びます。

個人アドレスの付け方には次の型があります。

• 姓のみ（yamada@）。短く、電話でも伝えやすい一方、同姓の人が入社した時点で破綻します。先に入った人だけが短いアドレスを持ち続ける状態が残ります
• 姓と名を組み合わせる（taro.yamada@、t-yamada@）。衝突しにくく、人数が増えても規則を保てます。長くなるため、口頭で伝える機会が多いと負担になります
• 部署名や役職名（sales@）。担当が替わっても宛先は変わりませんが、個人宛の連絡と混ざります

目安は、今後3年で人数が増える見込みがあるかどうかです。増えるなら姓のみは避けます。増えない前提でも、同姓が来たときの代替案（名の頭文字を足す、など）だけは決めておくと、その場の思いつきで例外が生まれません。

改姓と退職の扱いも規則の一部です。改姓時に旧アドレスをどれだけ残すか、退職者のアドレスを再利用するか。再利用は避けます。前任者宛の連絡が新しい担当者に届き、社外から見て誰に何を伝えたのか分からなくなります。

共有アドレスは「誰が読むか」を決めてから作る

info@ や support@ は、作るだけなら簡単です。機能しなくなる原因は設定ではなく、読む人が決まっていないことにあります。

全員に転送する設定にすると、受信箱には届くものの、誰も自分の担当だと思わないまま数日が過ぎます。人数が少ない会社ほど「言わなくても誰かが見ている」という前提が働きます。

作る前に決めるのは3つです。

1. 一次対応をする人と、不在のときの代わり。日ごとの当番でも、曜日で分けても構いません
2. どれくらいで返信するか。当日中か翌営業日かを決めておくと、遅れが「未対応」として見えます
3. 返信を共有アドレスから出すか、個人アドレスから出すか

3つ目が運用の分かれ目です。個人アドレスで返信すると以後のやり取りはその人だけに届き、担当が替わったときに途中経過が見えません。共有アドレスから返せば、取引先から見た窓口が人に依存しなくなります。

受信の仕組みは、転送、複数人で1つの受信箱を共有する形、グループ宛の配信に分かれます。どれを選ぶ場合も、「対応済みかどうかが他の人から分かるか」を確認してください。ここが見えない仕組みは、3人を超えたあたりで回らなくなります。

サーバー付属のメールと専用サービスは、どこで差が出るか

メールを置く先は、レンタルサーバー付属の機能、メール専用のクラウドサービス、制作会社やベンダーへの一括委託に分かれます。機能の多さではなく、契約と管理がどこに紐づくかで差が出ます。

判断軸	サーバー付属のメール機能	メール専用のクラウドサービス	制作会社・ベンダーへの一括委託
サーバーを移転するとき	サイトと同じ契約のため、移転作業にメールも巻き込まれる	サーバーを替えてもメールは影響を受けない	委託先を替えるかどうかの判断とセットになる
アカウントを増やすとき	プランの範囲内なら追加費用が出にくい傾向	利用者数に応じて費用が増える形が多い	依頼してから反映されるまでの時間差が出る
管理画面を触る人	サーバー全体の権限と同じになりやすく、サイト設定にも手が届く	メールだけの管理権限を分けて渡しやすい	自社では触らず、小さな変更にも依頼が要る
退職者のアカウント	削除するか残すかの二択になりやすい	受信のみ・転送のみといった中間の状態を作りやすい	手順が委託先の運用に依存する
迷惑メール扱いされたとき	送信元の認証設定を自分で調べることになる	認証まわりの設定手順が用意されていることが多い	調査を依頼する形になり、切り分けに時間がかかる
障害が起きたとき	サイトとメールが同時に止まりうる	サイトが止まってもメールは動く	窓口は一本化されるが、一次対応の速さは契約内容による

目安は、サイトとメールのどちらが止まると業務が止まるかです。受注も問い合わせもメール中心なら、サイトと同じ契約に載せないほうが移転や障害の影響を切り離せます。サイトの更新頻度が低く数アカウントで足りるなら、契約を1つにまとめたほうが管理対象は減ります。

導入の手順は、新規と移行で途中から分かれる

新規に作る場合も、既存のメールから移す場合も、序盤は同じです。

1. ドメインの管理画面にログインできる状態を作る（名義と権限の確認）
2. メールを置く先を決め、契約する
3. 決めた命名規則に沿ってアカウントを作る
4. 切り替え前に、新しい環境で送受信できるかを確認する
5. DNSのMXレコードを新しい環境に向ける。送信ドメイン認証（SPF、DKIM、DMARC）の設定も同時に行う
6. 送受信をテストする。社内同士、社外との往復、添付ファイル、自動返信の4つを見る
7. 名刺、サイト、請求書の雛形、各種サービスの登録アドレスを差し替える

新規導入はここで終わりです。移行の場合は「旧アドレスに届き続けるメール」と「過去のメールの扱い」が加わります。

7番目で抜けやすいのが、会計や銀行、業務用サービスに登録したアドレスです。パスワードの再設定通知はここに届きます。まずメールを新しい環境で受け取れる状態にしてから、各サービスの登録を変更してください。逆にすると、確認メールが届かず手続きが止まります。

移行で止まるのは、DNSの切り替えと過去メール

DNSの変更は反映までに時間差があります。切り替えた直後は、新しい環境に届く経路と古い環境に届く経路が混在します。この期間の取りこぼしを避ける手は3つです。

切り替えの数日前に、対象レコードの有効期間（TTL）を短くしておくこと。作業はメールの流量が少ない時間帯に行うこと。そして、古い環境をすぐに解約しないことです。反映が終わるまで古い側でも受信できれば、後から拾えます。解約は、古い側に何も届かなくなってからです。

過去のメールをどうするかは移行前に決めます。作業しながら考えると利用者ごとにやり方が変わり、後で誰の何がどこにあるのか分からなくなります。

判断軸	サーバー間でまとめてコピーする	メールソフトに取り込んでから移す	古い環境を読み取り専用で残す
誰が作業するか	管理者がまとめて実施できる	利用者一人ひとりに作業が発生する	契約を維持するだけで作業はほぼ不要
過去メールの探しやすさ	新しい環境でそのまま検索できる	取り込み方によってフォルダ構成が崩れる	古い環境を開かないと探せない
費用の出方	移行期間だけ2つの契約が重なる	追加費用は出にくいが、人の作業時間を使う	残す期間だけ古い契約の費用が続く
失敗したときの影響	途中で止まると重複や欠落が起きる	端末の故障で取り込んだデータごと失う	解約した時点で参照できなくなる
向いている状況	人数が多く、過去のやり取りを日常的に参照する	対象が数人で、必要な範囲がはっきりしている	保存義務や後日の照会に備えて残すだけでよい

メールを取引の記録として扱うなら、どこまで戻せる必要があるかも合わせて決めます。復旧の目標から逆算する考え方は、小規模企業に必要なバックアップはどこまでかがそのまま使えます。

退職と入社の手順は、導入した日に決めておく

人が辞めるときは急に決まります。手順がないと、その場でパスワードを聞いて共有する、アカウントを放置する、といった対応になります。導入作業の日は権限と設定をまとめて触れる機会なので、次の項目を文書として残してください。

• 退職日にアカウントをどうするか。即日停止か、一定期間は受信だけ残すか、自動応答で新しい窓口を案内するか
• 過去のメールを誰が引き継ぐか。全部か、進行中の案件に関わるものだけか
• 個人アドレス宛に来ていた取引先の連絡を、いつまでに共有アドレスへ寄せるか
• 入社時に誰がアカウントを作るか。命名規則の適用と、初期パスワードの渡し方（本人以外が読める経路で送らない）
• 管理者アカウントの認証情報を、経営者を含む2人以上が確認できる場所に置く

退職時の扱いはメールだけの問題ではなく、共有ファイルや各種サービスのアカウントとまとめて設計するほうが漏れは減ります。順番は、小さな会社の情報セキュリティはどこから手をつけるかで影響の大きい順に整理しています。

着手する順番と、よくある詰まりどころ

今日から進めるなら、ドメインの名義と管理画面の権限を確認し、命名規則と共有アドレスの読み手を紙1枚に書き、置き先を決めて契約します。ここまで終われば、残りは手順どおりの作業です。

既存のアドレスを一部だけ移したい

アドレス単位で置き先を分けることは、DNSの仕組み上できません。1つのドメイン宛のメールは原則として1か所に届きます。分けるなら部署ごとにサブドメインを使う構成になり、管理する対象が増えます。移すなら全員まとめて、と考えるほうが単純です。

切り替えた直後から迷惑メール扱いされる

送信ドメイン認証の設定が古い環境のまま残っているか、新しい環境の分が足りていない可能性があります。DNSの内容を、新しい提供元の手順書と1行ずつ突き合わせてください。推測で書き換えると復旧が長引きます。

新しいアドレスを知らせたのに、古いほうに届き続ける

相手のメールソフトが過去の宛先を記憶しているためで、告知の不足ではありません。古いアドレスを一定期間残し、届いたら新しいアドレスから返信していれば、相手側の記録が入れ替わります。

社内の誰もDNSを触ったことがない

作業は管理画面での入力ですが、間違えるとメールが止まります。販売元や制作会社に依頼できるなら、作業内容・作業日・切り戻し手順を書面で確認して任せる判断も現実的です。その場合も、ドメインの名義と管理画面の権限は自社に残してください。