独自ドメインのメールアドレスの作り方｜ゼロから最短で使える手順と注意点

2024年12月28日2026年1月31日

「仕事用に信頼感のあるメールアドレスが欲しい」
そう思って 独自ドメインのメールアドレス を作ろうとした瞬間、こんな壁に当たりませんか？

「そもそも独自ドメインのメールって、何が必要なの？」
「ドメインは取ったけど、メールが届く設定（MXとかDNS）が難しそう…」
「Gmailみたいな画面で使える？それとも専用のサービスが必要？」
「転送で済むの？サーバー？クラウド？結局どれが正解？」
「迷惑メールに入ったり、届かなくなったりしないか不安…」
「費用はどのくらい？無料でできる範囲ってある？」
「移行や更新忘れで止まったら怖い。長く安全に運用したい」

独自ドメインのメールは、結論から言うと
「ドメイン（@以降の住所）」＋「メールの受け皿（どこで受信するか）」 を決め、
必要なDNS設定を整えれば、初心者でも最短で始められます。

ただし、手順を飛ばしたり、転送だけで済ませたりすると、後から

送れない／届かない
迷惑メール判定が増える
乗り換えや引き継ぎが大変

といったトラブルにつながりがちです。

そこで本記事では、ゼロから最短で使える手順 を、初心者向けに「やる順番」で解説します。
さらに、よくある落とし穴（DNS・MX・SPF/DKIM/DMARC・転送運用の注意点）や、
個人／小規模／チームで失敗しない選び方まで、まとめて整理します。

読み終える頃には、あなたがやるべきことが

最短で始める方法（転送／サーバー／クラウド）
届く・送れる状態にするDNS設定
迷惑メールに入らないための認証
長期で困らない管理ルール

として、迷わず決められる状態になります。

【おすすめ独自ドメイン取得サービス↓】

お名前.com公式サイト
ムームードメイン公式サイト
XServerドメイン公式サイト
シンドメイン公式サイト
スタードメイン公式サイト

ラッコドメイン公式サイト

【メールサーバーおすすめ比較↓】

まず結論：ドメインのメールアドレスは「ドメイン」＋「メールの受け皿」で決まる

独自ドメインのメールアドレス（例：info@your-domain.jp）は、見た目は“文字列”ですが、実際に大事なのは次の2つです。

ドメイン：@の右側（住所の「地名」みたいなもの）
メールの受け皿：メールを受信・保管し、送信もできる仕組み（郵便受け＋配達ルール）

つまり、ドメインを取っただけではメールは届きません。
「そのドメイン宛のメールを、どこで受け取るか」を決めて初めて使えるようになります。

最短で始める3パターン（あなたはどれ？）

ここでは、初心者が迷いやすいポイントを整理しながら、最短で失敗しにくい選び方を提示します。
（※細かいDNS設定は後の章で扱うとして、ここでは全体像をつかむのが目的です）

パターンA：転送だけで運用（受信は今のアドレスのまま）

イメージ：info@自社ドメイン に届いたメールを、今使っている Gmail や プロバイダメール に転送する方式。

こんな人向き

まずは 名刺・問い合わせフォームの受け皿 を用意したい
受信は今のGmail等で十分（新しい受信箱は不要）
重要メールの量が多くない（見落としが致命傷になりにくい）

メリット

✅ 最短で開始できる（“受信先を変えない”）
✅ 運用がラク（普段の受信箱で管理）

注意点（ここが落とし穴になりがち）

⚠️ 返信の見た目が崩れやすい
転送だけだと「送信元を info@自社ドメイン にしたい」場面で設定が増えます（送信サーバー／SMTPなど）。
⚠️ 迷惑メール判定の影響を受けることがある
転送経由だと受信側の判定が変わり、重要メールが迷惑メールに入るケースもあります。

ざっくり費用感

多くは 低コスト（ドメイン代＋転送機能の有無で変動）
“とにかく早く”なら最安になりやすい

失敗しないコツ

重要用途（請求・契約・採用）には、転送だけを主軸にしない
重要メールは「受け皿に届く」方式（B or C）が安心です。

パターンB：サーバー付属のメール機能で運用（小規模向き）

イメージ：レンタルサーバー（またはメール専用サービス）にメールボックスを作って、
info@自社ドメイン をそこで受信・保管する方式。

こんな人向き

個人〜小規模で、1〜数個のアドレスをしっかり運用したい
月額を抑えつつ、「独自ドメインメールとして成立」させたい
Webサイトも同じサーバーで運用する可能性がある

メリット

✅ 転送より“ちゃんとしたメール”になりやすい（受信箱が独立する）
✅ 料金が比較的安いことが多い（メール専用プランなら特に）
✅ アドレス追加や転送設定など、管理画面で完結しやすい

注意点

⚠️ 管理するものが増える
受信箱・パスワード管理・端末設定（IMAPなど）が必要になります。
⚠️ 迷惑メール対策（送信ドメイン認証）を“後回しにしない”
独自ドメインで送るなら、SPF/DKIM/DMARCを整えないと到達率が落ちやすいです。

ざっくり費用感（例）

メール専用プランは 月額換算で100円前後〜のものもあり、容量・機能で差が出ます。
サーバー付属の場合は、サイト運用込みで考えるとコスパが良いこともあります。

失敗しないコツ

最初に作るアドレスは多くしすぎない
例：info@ / contact@ / billing@ など、運用に必要な分だけに絞ると管理が楽です。

パターンC：クラウド型メールで運用（複数人・共有向き）

イメージ：クラウドメール（グループウェア）で、
独自ドメインのメール運用を“会社の仕組み”として整える方式。

こんな人向き

2人以上で運用、または今後増える予定がある
共有受信（例：support@）、権限管理、退職者対応が必要
セキュリティ・管理を重視（監査、ログ、端末管理など）

メリット

✅ 管理が強い（ユーザー追加・停止、権限、セキュリティ統制がしやすい）
✅ チーム運用が前提の機能が多い（共有、予定、チャット等）
✅ 到達率・信頼性の面で安心材料になりやすい（※運用前提）

注意点

⚠️ 基本は“ユーザー課金”
人数が増えるほど月額が増えます。
⚠️ “安く始める”より“長期の運用設計”が重要
退職者のメール引き継ぎ、共有アドレス運用（グループ／共有受信箱）などを先に決めると失敗しにくいです。

ざっくり費用感（代表例）

Microsoft系は月額・年額の選択で単価が変わります
Google系は公式だと米ドル表記で提示されることがあります（為替影響あり）
Zohoなどは低価格帯プランから用意されていることがあります

人数・用途・予算で選ぶ判断軸

迷ったら、まずは次の3軸で切り分けると早いです。

「受信箱」を増やしても運用できるか（増えるほど管理が必要）
複数人で扱うか（共有・権限・退職者対応が必要か）
重要度（請求・契約・採用など“落ちたら困る”メールがあるか）

以下の表は、ざっくりの選び分けです。

スクロールできます

目的/状況	おすすめ	理由
まずは名刺用・問い合わせ用を用意したい	パターンA	最短で開始しやすい
個人〜小規模で、独自ドメインメールを“ちゃんと運用”したい	パターンB	コスパと実用性のバランスが良い
2人以上で運用・共有受信・退職者対応が必要	パターンC	管理・セキュリティ・引き継ぎが強い

個人／副業／フリーランス

おすすめの考え方

まずは A（転送）でスピード優先 → 重要用途が増えたら B（受け皿）へ
という段階移行が現実的です。

よくある最適解

「普段はGmailで受けたい」→ A
「仕事用の受信箱を分けたい・信用を上げたい」→ B
「外注や共同運営で、人の入れ替えが起きる」→ C（早めが安心）

失敗しやすい例（避けたい）

“見た目だけ独自ドメイン”で転送運用し、
返信だけが別アドレスになって信用を落とす（相手が混乱する）

会社・チーム（共有受信・監査・退職者対応が必要）

結論：最初からC寄りで考える方が事故が減ります。

チーム運用で本当に困るのは、次の3つです。

共有アドレスの扱い（問い合わせ・請求・採用など）
退職者のアカウント停止と引き継ぎ
情報漏えい対策（端末紛失、パスワード使い回し等）

このあたりを“仕組み”で解決しやすいのが パターンC。
一方で、人数が少なくコストを抑えたいなら B＋運用ルール整備でも成立します。

小規模チームでも最初に決めたいルール（例）

個人アドレス：name@（責任の所在が明確）
共有アドレス：info@ support@（担当変更しやすい）
退職時：アカウント停止→必要ならメール保管→転送/共有設定を変更

@以降は何を意味する？ドメインとメール配送の基本

独自ドメインのメールアドレスでつまずきやすいのは、「@以降（ドメイン）」が“住所の行き先”を決める部分だという点です。
ここを押さえると、DNS設定（特にMX）の意味が一気に理解しやすくなります。

メールアドレスの構造（ユーザー名／ドメイン）を図解で理解

メールアドレスは、基本的に 2つのパーツでできています。

ユーザー名（ローカル部）  @  ドメイン（ドメイン部）
taro                         @  example.com

ユーザー名（@の左側）
- どの“受信箱（アカウント）”に入れるかを表す部分
- info / support / taro など、運用ルールで自由に決められます
ドメイン（@の右側）
- どの“メール受け皿（メールサーバー）”へ運ぶかを表す部分
- つまり メール配送の行き先（配送ルート）を決める要です

ここで重要なのは、インターネット上で「どこに届けるか」は@以降で決まり、@より左は“届いてから振り分ける”情報だということです。

よくある誤解

❌「mail.example.com を作ればメールが動く」
→ 実際は DNSのMX（どこに届けるか） が決まっていないと届きません。
❌「ドメインを取れば info@ドメイン が自動で使える」
→ ドメイン取得だけでは不十分で、受け皿（B/Cのどれか）＋DNS設定が必要です。

「どこに届くか」を決めるのはDNS（特にMX）

メールは、送り先ドメイン（@以降）を見て、送信側のメールサーバーがDNSに問い合わせます。
ざっくりの流れは次のとおりです。

送信側が「example.com宛のメールはどこへ送ればいい？」とDNSに質問
DNSが MXレコード（Mail eXchanger）を返す
送信側はMXに書かれた“宛先メールサーバー”へSMTPで配送する
受信側メールサーバーが、@より左（ユーザー名）を見て受信箱に振り分ける

まずはこの表だけ覚えると早いです

スクロールできます

DNSレコード	役割（超ざっくり）	例
A / AAAA	「この名前はこのIP」= Webやサーバーの宛先	`example.com → 1.2.3.4`
CNAME	「この名前は別名」	`www → example.com`
MX	「このドメイン宛のメールはここへ」	`example.com → mail.example.net`
TXT	“テキスト情報”を載せる（確認や認証で多用）	SPF/DKIM/DMARCなど

MXのポイント（初心者がハマりやすい所）

優先度（Priority）が小さい方が優先されます
例：10の方が20より先に試される（冗長化にも使える）
MXはIPではなく“宛先ホスト名”を指すことが一般的です
そのホスト名は、最終的にA/AAAAでIPへ解決されます
MXがないとメールが不安定になる可能性がある
仕様上、MXが無い場合にA/AAAAへフォールバックする挙動がありますが、運用としては推奨しにくいです（「メールの受け皿がある」と明示するためにもMXを用意するのが基本）。
MXの向き先にCNAMEを置くのは避けるのが無難です
運用上トラブルになりやすく、仕様としても推奨されません。

反映に時間がかかるのは普通です

DNSは、設定後すぐに世界中へ一瞬で伝わるわけではありません。
TTL（キャッシュの残り時間）により、切り替えが遅れて見えることがあります。

「設定したのに届かない…」→ まずは 反映待ちの可能性を疑う
本番切り替え時は、“反映に時間がかかる前提”で計画すると事故が減ります

同じドメインでWebとメールを両立する時に起きやすい混乱

同じ example.com で Webサイトとメールを両方やるのは普通です。
ただし、両方とも“DNSを使う”ため、管理画面で混乱しやすいポイントがあります。

混乱1：Webを移転したらメールまで壊れた

Web移転では主に A/AAAAやCNAMEを触ります。
一方、メールは MXが要です。

✅ Web移転だけなら、基本は MXは触らない
❌ DNSを「別のサービスに丸ごと移管」した結果、MXが消えてメールが止まる
→ ネームサーバー変更やDNSゾーンの引っ越しが絡むと起きやすいです

対策（チェックリスト）

ネームサーバーを変更する前に、DNSレコードを棚卸し
- A/AAAA（Web）
- CNAME（wwwなど）
- MX（メール）
- TXT（SPF/DKIM/DMARC、各種所有確認）
変更後に、MX・TXTが残っているか必ず確認

混乱2：「www」と「@」の違いが分からない

DNS画面でよく見る「ホスト名」表記が原因です。

@ は ルートドメイン（example.comそのもの） を指す表示
www は www.example.com
mail は mail.example.com

メール宛先として一般的なのは ルートドメイン（@）にMXを置く形です。
mail.example.com は“メールサーバー名”として使う場合はありますが、必須ではありません。

混乱3：Cloudflareなどの“プロキシ設定”をメールにも適用しようとしてしまう

CDNやWAFのサービスは、主にWeb向けに A/AAAA/CNAMEをプロキシできます。
一方、MXレコードは通常プロキシ対象ではありません。

対策

メール関連は基本「DNSのみ」で扱う、という前提で設定する
Webだけオレンジ雲（プロキシ）、メールはグレー雲（DNSのみ）…のように切り分ける

混乱4：メールサービスを変えたのに、古い方へ届く

メールサービス（受け皿）を変更した場合、やるべきことはシンプルで、

MXを新しい受け皿に向ける
必要なら TXT（確認や認証）も更新する

ただし、切り替え直後はDNSキャッシュの影響で混在することがあるため、

旧受け皿をすぐ解約せず、移行期間を確保する
大事なメールがある場合は、テスト送受信をしてから本番運用に切り替える

メールアドレスの種類を整理して、独自ドメインが必要か判断する

「ドメイン　メールアドレス」で検索する人の多くは、実は “メールの種類の違い” が曖昧なまま、

どれを使うべき？
乗り換えで困らない？
仕事用は独自ドメインが必要？

を知りたいケースがほとんどです。ここで一度スッキリ整理しましょう。

代表的な4種類（無料／契約に紐づく／携帯回線／独自ドメイン）

まずは「長期で使えるか」「信用につながるか」を軸に、代表的な4タイプを比較します。

スクロールできます

種類	例	長期の安定性	乗り換え耐性	仕事の信頼感	ひとことで
無料メール	Gmail / Yahoo!メール / Outlook.com	高め	強い	中	便利で強い“個人の名刺”
契約に紐づくメール	プロバイダメール / 学校・勤務先メール	変動	弱い〜中	中〜高	契約が切れると不安
携帯回線メール（キャリアメール）	docomo/au/SoftBankのアドレス	以前は弱い→今は改善	中（有料継続あり）	中	スマホ契約とセットの印象
独自ドメインメール	info@あなたのドメイン	最高	最強	高	“住所”を自分で持つ

無料メール（Gmail等）

メリット

✅ すぐ使える／管理が楽／迷惑メールフィルタが強いことが多い
✅ 回線やプロバイダを変えても、基本的に継続しやすい

注意点

⚠️ 仕事の「公式窓口」としては、相手が不安に感じるケースも（特にBtoB）

契約に紐づくメール（プロバイダ・学校・勤務先）

メリット

✅ 契約中は整っている（サポートが付く場合も）

注意点

⚠️ 解約・卒業・退職で 使えなくなる／使いづらくなる 可能性がある
⚠️ 「連絡先＝ログインID」になっていると、切り替えが大変

携帯回線メール（キャリアメール）

昔は「回線解約＝メール終了」が一般的でしたが、今は “持ち運び（有料継続）” が選べる状況になっています。

ドコモ：月額330円、解約後31日以内など条件あり（初回31日無料の案内あり）
au：月額330円、解約後31日以内など条件あり
ソフトバンク：月額330円／年額3,300円（メールアドレスごと課金）

※この「持ち運び」は便利ですが、“有料の延命措置” という位置づけ。長期の仕事用途は、次の独自ドメインも検討すると安心です。

独自ドメインメール

最大の強みは、メールサービス（受け皿）を変えても アドレス自体は変えずに運用できる 点です。

✅ 名刺・請求書・契約など「信頼」が必要な場面に強い
✅ サービス乗り換え（サーバー→クラウド等）でもアドレスを維持しやすい
✅ チーム運用（info@、support@）にも向く

注意点

⚠️ “ドメインの更新忘れ”は致命的（失効するとメールも止まる）
⚠️ 送信ドメイン認証（SPF/DKIM/DMARC）など、最低限の運用が必要

乗り換えで困るポイント（失効・連絡先変更・ログイン認証）

メールは「連絡手段」であると同時に、いまや “本人確認の鍵” です。乗り換えで詰まるのは主にこの3つ。

1) 失効（使えなくなる）

失効の典型パターンは次の通りです。

プロバイダ解約で、そのメールが停止（または条件付き継続）
退職・卒業でアカウント無効化
キャリア解約で停止（※持ち運びで回避できる場合あり）
独自ドメイン更新忘れで停止（最悪、第三者取得のリスクも）

対策の基本

「ログインIDになっているメール」は、特に慎重に扱う
解約前に、最低でも “復旧用メール／電話番号” を最新にしておく

2) 連絡先変更（あらゆる登録情報の更新地獄）

メールアドレスは、次のような場面で「登録情報」として大量に使われています。

EC（注文確認・返品・領収書）
銀行・証券・決済
SaaS（会計、請求書、予約、チャット等）
SNS、クラウド、サブスク

1つ変えると芋づる式に更新が必要になり、更新漏れが“機会損失” になります。

現実的な進め方（おすすめ）

重要度で分類して、上から潰す
1. お金（銀行・決済・税金）
2. 仕事（顧客・取引先・業務ツール）
3. 生活（通販・サブスク）
4. 趣味（SNSなど）

3) ログイン認証（2段階認証・本人確認で詰む）

今いちばん怖いのがこれです。

2段階認証コードが 旧メールに届く設定 のまま
パスワード再設定のリンクが 旧メールに飛ぶ
退職・解約で旧メールに入れず、復旧不能

移行前のチェックリスト（最低限）

✅ 主要サービスの「復旧用メール」「電話番号」を更新
✅ 二段階認証の方法を見直し（認証アプリ／SMSなど）
✅ 重要アカウントはバックアップコード保管
✅ 旧メールは一定期間“受け取れる状態”を残す（並行運用）

補足：無料メール側で“アドレス変更”できる場合もある
たとえば一部サービスは、既存アカウントに別のアドレスを追加したり、メインを切り替えたりできます。
ただし、制約や段階提供があるため「できる前提」で進めず、実際の管理画面で確認するのが安全です。

独自ドメインが向いている人／向かない人

「独自ドメイン＝絶対正義」ではありません。向き・不向きがあります。

独自ドメインが向いている人

✅ 仕事の信用が大事（請求書・契約・採用・広報など）
✅ 長期で活動する（事業・副業・フリーランス・団体）
✅ サービスを乗り換えても連絡先を変えたくない
✅ チーム運用や役割アドレス（info@、support@）が必要
✅ 「メールを資産化」したい（名刺・サイト・SNSと統一したい）

おすすめの考え方

いきなり大量に作らず、まずは
info@ / contact@ / 自分用 の最小構成から始めると失敗しにくいです。

独自ドメインが向かない人（今は不要な人）

⚠️ ほぼ個人用途で、仕事のやり取りが少ない
⚠️ 管理（更新・パスワード・設定）に時間をかけたくない
⚠️ 連絡先が頻繁に変わっても困らない（短期プロジェクトなど）
⚠️ まずはコスト最優先で試したい

この場合は、まず無料メールで運用し、必要になったタイミングで独自ドメインへ移行するのが合理的です。
ただし、重要アカウントの連絡先（復旧用） だけは早めに整えておくと安心です。

作る前にやること：失敗しない「ドメイン名」と「アドレス設計」

独自ドメインのメールアドレスは、作ってから直すほど手間が増えます。
先に 「ドメイン名」 と 「アドレスの設計」 を決めておくと、あとが一気に楽になります。

ここでは初心者でも迷いにくいように、実務で事故が起きにくい決め方に絞って解説します。

ドメイン名の決め方（覚えやすさ・信頼・長期運用）

独自ドメインは「住所」なので、メールでもWebでも長く使う前提で考えるのが安全です。
名刺・請求書・見積書・契約書などに載ることも多く、信頼感に直結します。

短く・読み間違えにくく・将来の事業拡張にも耐える

まずは“読み間違えない”が最優先です。検索や口頭共有の場面で差が出ます。

短い（できれば 10〜15文字程度を目標）
発音しやすい（電話口で通じる）
見間違えにくい
- l（小文字エル） と 1（いち）
- O（オー） と 0（ゼロ）
- rn と m など

避けたい要素（地味にミスが増えます）

ハイフンが多い（例：my-best-service-xyz.com）
綴りが難しい英単語（相手が打ち間違える）
流行語・年度・一時的な肩書（数年後に古く感じる）

“将来の事業拡張”に耐える考え方

事業を広げる可能性があるなら、
「特定商品名ど真ん中」より ブランド／屋号ベースが無難です。
例：
- 商品特化：○○-only.com（事業転換で不自然になる）
- ブランド型：brandname.com（拡張しやすい）

TLD（末尾）の考え方（ざっくり）

信頼・汎用性：.com
国内向けの印象：.jp（用途により相性が良い）
業種TLD：.shop .studio など（“意味が伝わる”ならアリ）

迷ったら「ブランド名 + .com（または .jp）」が無難です。

企業・団体で注意したいルール（表記ゆれ、商標、更新忘れ）

法人・チーム運用では、ドメイン周りで起きる事故がだいたい決まっています。
先にルール化しておくと、後々の混乱が激減します。

1）表記ゆれ（会社名・サービス名の揺れ）

companyname / company-name / companyjp …と複数案が出がち
ロゴ表記・名刺表記・SNS表記と合わせ、公式表記を1つに固定する

おすすめは「正式表記を決める → それ以外は保護取得（余裕があれば）」です。

2）商標・類似名称

既に有名ブランドと似ていると、トラブルになり得ます。
最低限、次の観点で確認すると安全です。
- 同業で同名・類似名がないか
- 商標として登録されていないか（可能なら検索）

3）更新忘れ（最重要）
ドメインは更新が止まると、メールもWebも止まります。
さらに悪いと、第三者に取得されるリスクもあります。

事故を防ぐ設定（必須級）

自動更新をON
支払い方法は長期で維持できるもの（法人カード・請求払い等）
更新通知は複数人に届くように（管理者が不在でも気づける）

4）WHOIS情報の扱い

個人・小規模なら WHOIS公開代行（プライバシー保護） があるか確認
法人なら「公開して問題ない名義・連絡先」を整備しておく

メールアドレス設計の基本（役割アドレス／個人アドレス）

メール運用で一番困るのは、担当者が変わった時に
「誰が返信するの？」「過去履歴は？」「退職したらどうする？」が崩れることです。

そこで、最初に 役割アドレス と 個人アドレス を分けて考えると、設計が一気に安定します。

役割アドレス：窓口のためのアドレス（担当が変わっても維持）
個人アドレス：本人のためのアドレス（責任の所在が明確）

最初に作るべき代表アドレス例（問い合わせ・請求・採用など）

最初から大量に作ると管理が破綻しがちです。
まずは「最低限の3〜6個」から始めるのがおすすめです。

個人・副業で最小構成（例）

you@domain（あなた用）
info@domain（名刺・問い合わせ窓口）
contact@domain（フォーム送信先を分けたい場合）

小規模チームの基本セット（例）

info@domain（総合窓口）
support@domain（サポート）
billing@domain（請求・支払い）
recruit@domain（採用）
name@domain（個人用：人数分）

“迷ったら作らない方がいい”例

admin@domain（攻撃者に狙われやすい・用途が曖昧になりやすい）
ceo@domain（人に紐づき、退職・役職変更で面倒）

コツは「外向きは役割アドレス」「内向きは個人アドレス」です。

「属人化」を避ける分け方（引き継ぎ・共有受信・自動転送）

属人化を防ぐには、アドレスを増やすより 受け方の仕組みを整える方が効きます。

おすすめの運用パターン

役割アドレス（例：support@）は
- 共有受信箱（複数人で見られる）
- または グループ配信（担当者に届く）
  のどちらかにする
個人アドレス（例：name@）は本人が管理（責任が明確）

自動転送の使いどころ

受付を info@ に統一し、内容で担当へ転送
→ ただし転送だけに頼ると見落としが起きやすいので、重要用途は共有受信箱が安心です。

引き継ぎ時の“事故を減らす”ルール例

退職・異動時は、まず個人アカウント停止（権限回収）
役割アドレスの担当割り当てを更新（窓口は止めない）
必要なら過去メールを保管（監査・法務・顧客対応）

小技：エイリアス（別名）を活用する

1つの受信箱で、複数の宛先を受け取れる仕組み
例：info@ と contact@ を同じ箱で受ける
→ 「窓口は増やしたいが管理は増やしたくない」時に便利です

文字列のルール（使える文字・長さ・大文字小文字の扱い）

メールアドレスは仕様上いろいろな書き方が可能ですが、現場では“届く・通る”が最優先です。
そのため、初心者ほど「安全に動く書き方」に寄せるのが正解です。

ローカル部（@の左側）でおすすめの文字

基本はこれで十分です。

英小文字（a-z）
数字（0-9）
記号は最小限：.（ドット）, _（アンダースコア）, -（ハイフン）

避けるのが無難

連続ドット（例：a..b@）
先頭・末尾ドット（例：.info@ / info.@）
特殊記号の多用（例：sales+tokyo@ などはシステムによって不可のことも）
日本語ローカル部（例：営業部@）
→ 規格としては拡張がありますが、相手側の対応状況に左右されやすく、初心者にはおすすめしません。

ドメイン部（@の右側）の現実的なルール

ドメインは基本的に「英数字とハイフン」で構成されます。

運用で安全な方針

メール用途なら、ASCII中心（英数字・ハイフン）のドメインが無難
日本語ドメイン（例：例.jp）は、相手環境によって表示・入力がブレることがあるため、
仕事メールでは慎重に（使うなら併用や転送設計を）

大文字小文字はどう扱う？

多くの環境では、実務上は 小文字運用が安全です。
理由はシンプルで、
相手が手入力する時に大文字小文字を気にしないからです。

おすすめルール（チームで統一しやすい）

すべて小文字
区切りはドットかハイフンを1つだけ（例：taro.yamada@ など）

手順：ドメインのメールアドレスをゼロから使えるようにする

この章のゴールは、「取得したドメインで、送受信できるメールアドレスを安全に運用開始する」ことです。
専門用語は最低限にしつつ、手順どおりに進めれば迷いにくい順番でまとめます。

STEP1：ドメインを取得し、更新・支払いを安定させる

ドメインメールで最も怖い事故は、技術設定よりも 「更新忘れ」 です。
更新が止まると、メールが届かないだけでなく、復旧に時間・費用がかかることもあります。

【おすすめ独自ドメイン取得サービス↓】

お名前.com公式サイト
ムームードメイン公式サイト
XServerドメイン公式サイト
シンドメイン公式サイト
スタードメイン公式サイト

ラッコドメイン公式サイト

更新忘れを防ぐ設定（自動更新・通知・支払い方法）

最低限、次は“最初の日”に固めてください。

自動更新：ON
支払い方法：有効期限が長いもの（法人カード／請求書払い等）
通知先メール：個人アドレスだけにしない（複数人・複数メール推奨）
管理者アカウントの保護：強いパスワード＋可能なら2段階認証
ドメイン管理の担当：個人運用でも「自分＝担当」を明文化（メモでもOK）

おすすめの小ワザ

更新通知が迷惑メールに入ると詰むので、レジストラからの通知ドメインを受信許可に入れておく
クレカ更新失敗を想定して、予備の支払い手段を用意（可能なら）

WHOIS情報とプライバシーの考え方

ドメイン登録には登録者情報（WHOIS）が関わります。ここは方針が大事です。

個人・小規模
- 住所や個人情報を出したくない場合、WHOIS情報の公開範囲・代行（プライバシー保護）を確認
- 連絡用メールは「長期で維持できる」ものに（失効しない無料メールなど）
法人・団体
- “担当者個人”ではなく、会社として管理できる名義・連絡先に寄せる
- 退職・異動でも引き継げるよう、管理情報を社内で共有

ここでのポイントは「公開される可能性がある情報」と「長期で連絡が取れる連絡先」を最初から整えることです。

STEP2：「メールの受け皿」を決める（転送／サーバー／クラウド）

独自ドメインのメールは、受け皿（どこで受信・保管するか）を決めて初めて動きます。
迷ったら、先に「何を大事にしたいか」を決めると早いです。

とにかく早く：転送
コスパと実用性：サーバー付属
複数人・管理重視：クラウド

【メールサーバーおすすめ比較↓】

必要な機能チェック（容量・共有・端末設定・サポート）

比較するときは、料金より先に「運用で困るかどうか」を見てください。
初心者でもチェックしやすい項目を並べます。

最低限ほしい（個人でも）

IMAP/SMTP対応（スマホ・PCで扱える）
Webメール（端末がない時に使える）
迷惑メール／ウイルス対策
転送・自動返信
SPF/DKIM/DMARCに対応（送信の信頼性に関わる）

チーム運用なら重要

共有受信箱（support@を複数人で見る）
権限管理（誰が管理者か、誰が見られるか）
退職者対応（アカウント停止・引き継ぎが容易）
移行サポート（過去メールの移し替え）

参考：公式情報から見える“容量の考え方”例

例として、クラウド型は「ユーザーあたりの共有ストレージ」などの概念があり、プランで大きく変わります。
サーバー型は「アドレスごとの上限」＋「サーバー全体の上限」という形もあります。
（どちらが良いではなく、運用に合うかで選ぶのがポイントです）

後から乗り換える前提で決めるポイント

メールは後から移行できますが、移行がラクになる選び方があります。

乗り換えやすくする設計

ドメインは、できれば メールサービスと別で管理（乗り換え時に混乱しにくい）
受け皿を変えるときは基本 MXを変更すればOK、という状態にしておく
重要なメールは、移行前後で並行運用期間を取る（いきなり解約しない）

移行のしやすさに効く機能

IMAP同期が使える（多くの移行ツールがIMAP前提）
エクスポート手段がある（万一の保全）
サポート窓口がある（初心者ほど安心材料）

STEP3：DNSを設定してメールを届く状態にする

ここが「ドメインメールの心臓部」です。
やることは多そうに見えますが、基本は “指定された値を正確に入れる” だけです。

MXの考え方（優先度・複数レコード・古い設定の落とし穴）

MXは「このドメイン宛のメールをどこへ届けるか」を示します。

まず押さえる基本

優先度（Priority）は数字が小さい方が優先
複数MXは、冗長化（バックアップ）やサービス仕様で使う
受け皿を変えたら、基本は MXも変更が必要

よくある落とし穴

以前の受け皿のMXが残っていて、メールが分散・不達になる
MXを入れたつもりで、別ドメイン（wwwやサブドメイン）に設定している
DNSの場所を間違える（ドメイン会社のDNSと、別サービスのDNSが混在）

安全策

設定前に、DNS画面で「現在あるMX」をスクショ or メモ
変更後は、テストメールを 外部（別ドメイン）から送って確認

TXT/CNAMEが必要になるケース（確認・認証・署名）

メールは「届けばOK」ではなく、迷惑メールに入らない／なりすまし対策も重要です。
そのためにTXTやCNAMEを使う場面が増えています。

よくある用途

所有確認：サービス側が「このドメインはあなたのもの？」を確認
SPF（TXT）：送信してよいサーバーを宣言
DKIM（TXT or CNAME）：送信メールに署名を付け、改ざん・なりすまし耐性を上げる
DMARC（TXT）：SPF/DKIM失敗時に受信側へ扱い方を指示する

失敗しやすいポイント

SPFをTXTで複数作り、衝突させる（TXTは“1つにまとめる”のが基本）
DKIMを入れたのに有効化が別画面で必要（「DNSに入れた＝完了」ではないことがある）

反映時間（TTL）と切り替え手順の安全策

DNSは反映に時間がかかることがあります。焦って何度も触ると、逆に壊れます。

安全な切り替えの流れ（おすすめ）

事前にTTLを短くできるなら短くする（可能な範囲で）
新しいMX/TXT/CNAMEを追加
反映を待つ（数分〜最大48時間程度の幅を見込む）
テスト送受信
問題なければ、古い設定を整理（必要なものだけ残す）

STEP4：メールボックス／アカウントを作成する

DNSが整ったら、次は「受け皿の中」に実際の受信箱を作ります。
ここでの設計が、日々の運用のラクさを決めます。

容量・パスワード・権限を決める

最初に決めると良いこと

メール容量（足りなくなると業務が止まりやすい）
パスワードポリシー（長さ・使い回し禁止）
管理者権限を持つ人（チームなら複数人が安全）

最低限のセキュリティ

長いパスワード（12〜16文字以上を目安）
可能なら 2段階認証
共有アドレスのパスワードを“みんなで共有”しない
→ 共有受信箱や権限機能で運用するのが安全です

エイリアス／拡張アドレス／共有受信箱を使い分ける

同じ窓口でも、運用を増やさずに“受け口だけ増やす”方法があります。

エイリアス：別名アドレス（同じ受信箱に入る）
- 例：contact@ と info@ を同じ箱で受ける
拡張アドレス：user+xxx@ のように分類に使えることがある
- ただしシステムによって非対応もあるため、初心者は無理に使わなくてOK
共有受信箱：複数人で同じ窓口を扱う
- 例：support@ を担当者全員が見られるようにする

注意：キャッチオール（全受信）

便利ですが、迷惑メールも大量に受けやすいので、初心者の初期設定では非推奨です。

STEP5：端末・アプリに設定する（送受信方式と暗号化）

最後に、PCやスマホで使えるように設定します。
ここは「方式」と「暗号化」を押さえれば、だいたい解決できます。

IMAPとPOPの違い：基本はIMAPが無難

結論：迷ったらIMAPでOKです。

IMAP：サーバーにメールを残し、複数端末で同期しやすい
- ✅ スマホ＋PCなど、複数で見る人向き
POP：端末に取り込む前提で、サーバーに残さない設定もある
- ✅ 1台だけで管理したい、軽く使いたい人向き（ただし事故りやすい）

初心者がPOPで困る典型は、
「片方の端末で取り込んだら、もう片方に見えない」「バックアップがない」などです。

SMTP送信の設定で詰まるポイント（ポート・TLS・認証）

送信で詰まりやすいのは、この3点です。

ポート選び
- 送信（SMTP）は 587（Submission） を使うのが一般的
- 25 はブロックされることが多く、初心者は避けた方が無難
- 465 を案内されるケースもあります（サービス仕様による）
暗号化（TLS/STARTTLS）
- 設定画面で「SSL/TLS」や「STARTTLS」を選ぶ必要があることがあります
- ここを間違えると「認証エラー」「接続できない」になりがちです
SMTP認証
- 「送信はできるはず」と思っても、実は 認証が必要なことがほとんど
- ユーザー名（メールアドレス）とパスワードを入れているかを確認

よくある現象→原因の当たり

受信はできるのに送れない → SMTP設定（587/465、TLS、認証）を疑う
送ったのに相手に届かない → 迷惑メール判定（SPF/DKIM/DMARC未整備）を疑う
たまに届かない → DNS反映中／MXが二重／旧設定残りを疑う

迷惑メールに入らないための必須設定：送信ドメイン認証を整える

独自ドメインのメールで「送ったのに届かない」「迷惑メールに入る」が起きる原因の多くは、内容の良し悪し以前に“送信元として信用できるか”を証明できていないことです。
その“信用の土台”になるのが、送信ドメイン認証（SPF／DKIM／DMARC）です。

ここでは初心者でも迷いにくいように、考え方→最小構成→安全な強化手順→転送の注意点までをまとめます。

なぜ「届かない」が起きる？受信側の判定が年々厳しくなる理由

最近はGmailやYahoo、Outlookなど主要サービスが、メールのなりすまし・フィッシング・スパムを減らすために、送信者へ「守るべき最低ライン」を求める流れが強まっています。

受信側が見ているのは、ざっくり言うとこの3つです。

この送信者は本物？（なりすましではない？）
このドメインは“いつも同じ作法”で送っている？（整備されている？）
受信者が嫌がる送り方をしていない？（苦情率・解除・運用姿勢）

このうち、今回のテーマである「認証」が弱いと、本文が真面目でも

迷惑メールへ隔離
一時的な遅延（テンポラリエラー）
場合によっては拒否

のように扱われやすくなります。

最低限そろえる3点セット（SPF／DKIM／DMARC）

3つは役割が違います。“全部入れると強い”のは、重ねがけで穴を埋める構造だからです。

スクロールできます

仕組み	何を証明する？	設定する場所	ざっくりイメージ
SPF	「このサーバーは送信してOK」	DNS（TXT）	許可リスト
DKIM	「改ざんされてない／署名が正しい」	DNS（TXT or CNAME）＋送信側で署名ON	デジタル署名
DMARC	「SPF/DKIMが失敗したらどう扱う？」＋整合性（アラインメント）	DNS（TXT）	最終判定ルール

ポイントは DMARCは“SPFかDKIMのどちらかが合格”しないと成立しないこと。
つまり、DMARCを入れるならSPF/DKIMもちゃんと整える必要があります。

SPF：送信を許可するサーバーを宣言する

SPFは「このドメインから送るメールは、どの送信元（サーバー）を使うか」をDNSで宣言します。

初心者が押さえるべきコツ

SPFレコードは基本“1つにまとめる”
（複数あると評価が崩れたり、意図せず失敗しやすい）
送信に使うものを全部入れる
- 自社メール（Google Workspace／Microsoft 365など）
- フォーム通知（WordPress、フォームツール）
- メルマガ配信（配信ASP）
“よく分からないから適当に”は危険
→ 送信できなくなるか、なりすまし耐性が落ちます

よくあるミス

メルマガツールを追加したのにSPFへ入れていない
→ 「一部のメールだけ届かない」が起きやすいです

DKIM：メールに署名して改ざん・なりすましを減らす

DKIMは、送信側がメールに署名を付け、受信側がDNSの公開鍵で検証します。
SPFが“経路の許可”なら、DKIMは“内容の署名”のイメージです。

初心者が詰まりやすい点

DNSにレコードを入れただけで終わりだと思う
→ 実際は「管理画面でDKIM署名を有効化」する手順が別にあることが多いです
DKIMキー長が短い設定のまま
→ 最近は最低要件や推奨値が明確になっています（サービス側の案内に従うのが安全）

よくあるミス

署名するドメイン（d=）が想定と違う
送信経路が複数あるのに、DKIMが付くのは一部だけ

DMARC：失敗したメールを受信側にどう扱わせるか指示する

DMARCは「SPFまたはDKIMが通らなかったメールをどう処理するか」を受信側へ伝えます。
さらに大事なのが アラインメント（整合性）で、

表示上の差出人（From）のドメイン
SPFで使われるドメイン（MAIL FROM）
DKIM署名のドメイン（d=）

のどれかが、ルールに沿って一致していないと“認証はしてるのにDMARCは落ちる”が起きます。

DMARCの進め方（最初は監視→段階的に強化）

DMARCは、最初から強くしすぎると事故が起きます。
おすすめは 「見える化 → 問題を潰す → 強化」の順です。

ステップの型（初心者向け）

p=none（監視）で開始
- まずは「誰が送っているか」を把握する
SPF/DKIMの不足（フォーム、メルマガ、外注ツール）を洗い出して修正
問題が落ち着いたら p=quarantine（隔離寄り）へ
最終的に p=reject（拒否）へ
- なりすまし耐性が一気に上がる

いきなりrejectは、正規メールまで弾くリスクがあるので、監視期間を挟む方が安全です。

レポート受信の考え方（誰が・どこから送っているかを可視化）

DMARCを入れるなら、レポート（rua）を受け取れると運用が一段ラクになります。

レポート受信の“現実的な設計”

レポートは量が多くなることがあるので、普段使いの受信箱ではなく
専用アドレス（例：dmarc@ドメイン）を作るのがおすすめ
レポートを読み解くのが大変なら、DMARCレポート対応ツールを使う手もあります
（最初は“把握できる範囲”で十分です）

初心者がやりがちな失敗

ruaを設定したのに、そのメールボックスが存在しない／容量がない
→ 気づかないうちにレポートが受け取れていないことがあります

転送運用で起きやすい落とし穴（認証が崩れるケース）

「転送だけで運用（今のGmailへ転送）」は手軽ですが、認証的には不利になりやすいです。

なぜなら、転送されると

SPFは「送信元IPが変わる」ため失敗しやすい
DKIMは「途中で件名付与・フッター追加・メーリングリスト加工」などで署名が壊れることがある
結果、DMARCも失敗し、迷惑メールへ行きやすくなる

という“連鎖”が起きるからです。

転送前提で事故を減らすコツ

重要メール（請求・契約・本人確認）は、可能なら
転送ではなくIMAPで同じ受信箱を見に行く運用を検討する
どうしても転送するなら、転送先での迷惑メール判定に左右される前提で
- 送信元側（あなたのドメイン）のSPF/DKIM/DMARCを整える
- 取引先には「受信許可（ホワイトリスト）」も案内できると盤石
メーリングリストや転送サービスを運営する側なら、
ARC（転送の認証情報）のような対策が必要になることがあります

費用の目安：ドメイン代＋メール機能の料金を分けて考える

年間・月額で何がかかる？コストの内訳

「独自ドメインのメール」は、ざっくり ①ドメイン維持費 と ②メールの受け皿費用 を足したものです。
ここを分けて考えると、見積もりが一気にラクになります。

基本式（ざっくり）

年間コスト＝ ドメイン更新費（年） ＋ メール（ユーザー数×月額×12） ＋ 必要なら追加費用

主な費用項目

ドメイン費用（年）
- 更新料（2年目以降が本番）
- WHOIS代行（無料のこともあれば、有料のこともある）
メールの受け皿費用（月／年）
- 転送だけ（0円〜）：受信は既存のGmail等へ流すだけ
- メール専用ホスティング（低〜中価格帯）：メールボックスを持てる
- クラウド型メール（中〜高価格帯）：1ユーザー課金（管理・共有・監査が強い）
見落としがちな追加費用（必要な人だけ）
- 退職者メールの保全（アーカイブ／バックアップ）
- 迷惑メール対策の上位機能
- 移行作業（外注する場合）
- 送信数が多い場合の対策（配信基盤を分ける等）

料金の見方のコツ

ドメイン：「初年度の安さ」より「更新費」 を重視
メール：「アドレス数」より「実ユーザー数（ID数）」 を重視（クラウド型で特に重要）

費用イメージ早見表（目安）

スクロールできます

区分	何に払う？	料金の形	コストが増えるポイント
ドメイン	@以降の住所を維持	年額	更新料、複数ドメイン運用、更新忘れ対策
転送のみ	受信を既存アドレスへ回す	無料〜	送信は別手段が必要／認証崩れで届きにくいことがある
メールホスティング	メールボックスを持つ	月額/年額	容量、バックアップ、サポート、セキュリティ機能
クラウド型	“会社のメール基盤”一式	1ユーザー課金	ユーザー追加、退職者保全、上位セキュリティ

「無料に見える」パターンの注意点（転送のみ・容量制限・制約）

「無料（または安い）」は魅力ですが、どこが無料で、何が有料なのか を先に押さえると事故りません。

よくある“無料っぽい”ケースと落とし穴

転送だけで運用（受信だけ独自ドメイン）
- ✅ 低コストで開始できる
- ⚠️ 返信や送信をどうするかで詰まりやすい
- ⚠️ 転送経路によっては、送信ドメイン認証が崩れて迷惑メール扱いされやすいことがある
「アドレス無制限」でも実は容量がボトルネック
- ✅ アドレスは増やせても、保存容量はプラン依存
- ⚠️ 画像添付が多い業種だと、すぐ運用が苦しくなる
“独自ドメイン無料”の条件がある
- ✅ 一見お得
- ⚠️ サービス解約と同時に条件が外れて、結局ドメイン費が別に発生…というパターンもある
サポート・復旧が別料金
- ✅ 自力でできる人には安い
- ⚠️ トラブル時に「対応は有料オプション」だと結果的に高くつくことも

無料運用を選ぶ前のチェックリスト

送信（SMTP）まで含めて“独自ドメインで完結”する？
迷惑メール対策（SPF/DKIM/DMARC）を自分で整えられる？
受信容量が不足したとき、追加料金や上位プラン移行は現実的？
退職者や共有アドレスの扱い（引き継ぎ・保全）を想定している？

ケース別ざっくり見積もり（個人／小規模／チーム）

金額はサービスや支払い方法で変わるので、ここでは設計→計算がしやすい形で示します（税別/税込の表示ルールもサービスごとに異なる点に注意）。

個人／副業（1人運用、まずは最低限）

おすすめの考え方：

連絡用は「独自ドメインに見せる」
受信は今のGmail等に集約（転送） or 低価格のメールホスティング

目安

ドメイン更新：年 約2,000〜4,000円前後（種類と会社で差）
メール：
- 転送のみ：0円〜
- メールホスティング：月 数十円〜数百円 からのプランもある

こうすると安定＆安い

送信用は「既存メール＋差出人設定」ではなく、可能なら“独自ドメインで送れる環境”を用意（将来のトラブル予防）

小規模（2〜5人、共有受信や引き継ぎが出る）

おすすめの考え方：

役割アドレス（info@ / billing@ など）は「共有受信（グループ）」で作り、個人アカウントを増やしすぎない

目安（例：クラウド型メールの場合）

ドメイン更新：年 約2,000〜4,000円前後
クラウド型：ユーザー数 × 月額 × 12
- 例：3ユーザーなら「月額×3×12」で概算できる

コストが跳ねるポイント

「代表アドレス＝ユーザーを追加」で作ってしまう（本来はエイリアスや共有受信で足りることが多い）

チーム（6人以上、監査・退職者対応・セキュリティ重視）

おすすめの考え方：

退職者メールを“消さない”運用（保全）を最初から前提にする
セキュリティ（端末管理・脅威対策）込みのプランを検討

目安

ドメイン更新：年 約2,000〜4,000円前後
メール基盤：ユーザー数がそのまま固定費になりやすい
追加で見ておくと良い費用：
- アーカイブ／バックアップ
- 端末管理やセキュリティ上位機能

コスト最適化の小技

役割アドレスは「共有受信箱」「グループ」「エイリアス」で設計し、“人＝課金”の数を増やさない
送信元（サービス通知、フォーム通知、メルマガ等）を分けて、トラブル時の影響範囲を小さくする

運用で差が出る：長期で困らない管理ルール

独自ドメインのメールは、作ること自体よりも 「止めない・漏らさない・引き継げる」運用で差が出ます。
この章では、初心者でも今日から取り入れられて、かつ“後から効いてくる”管理ルールをまとめます。

アカウント棚卸し（退職・異動・外注を前提に）

チームで一番起きやすい事故は、「誰が使っているか分からないアカウントが残る」ことです。
棚卸しは“セキュリティ”だけでなく、“コスト最適化”にも直結します。

まず作るべき台帳（これだけでOK）

スプレッドシート1枚で十分です。項目は次の7つだけ。

アドレス（例：support@〜）
種別（個人／役割／共有）
所有者（担当者名、またはチーム）
権限（管理者／一般／閲覧のみ等）
用途（請求・採用・問い合わせなど）
関連サービス（フォーム、メルマガ、決済通知など）
最終利用日（だいたいでOK）

“用途”と“所有者”が書けないアドレスは、将来ほぼトラブルになります。

退職・異動・外注のときにやること（最短チェックリスト）

アカウントを「消す」より、順序が大事です。

個人アカウントのアクセス停止（退職当日〜即時）
役割アドレス（info@等）の担当付け替え
必要なメールの引き継ぎ（共有受信箱・委任・エクスポート等）
関連サービスの登録メール更新（フォーム・決済・クラウド等）
2要素認証の回収（個人端末に紐づく認証を解除・再設定）

“増えすぎ”を防ぐ設計のコツ

役割アドレスは「人＝アカウント追加」で増やすより、共有受信箱／グループ／エイリアスで吸収する
「担当者の個人メール」を窓口にしない
- 例：sales@ はOK、tanaka-sales@ は後で詰みやすい

バックアップと保管（復旧・監査・訴訟リスク対策）

メールの“守り”は混同されがちですが、目的が違います。
先に違いを押さえると、過不足のない設計ができます。

まず整理：バックアップ／保管（アーカイブ）／保持（リテンション）

スクロールできます

目的	何を守る？	典型例	ポイント
バックアップ	復旧（誤削除・障害・乗っ取り）	別場所にコピー	“戻せる”が価値
保管（アーカイブ）	証跡・記録（監査・社内ルール）	長期保管庫	検索性が重要
保持（リテンション）	残す/消すルール（法務・規程）	〇年保持、期限後削除	“消す設計”も含む

初心者がよくやる失敗は、「保持設定があるからバックアップ不要」と思うことです。
保持は“ルール”、バックアップは“復旧手段”なので、同じではありません。

何年保管すべき？の決め方（迷ったらこの順）

法令や業種で変わるので、ここでは“決め方”だけ示します。

契約・請求・人事など重要領域を洗い出す
社内規程や取引先要件を確認（なければ暫定で年数を決める）
「期限後に消すのか、残すのか」を決める
運用できる形に落とす（担当・手順・監査）

実務で効く“最低限”の運用

重要な役割アドレス（billing@ 等）は、保管ルールを個人より長めにする
退職者メールは「消す」より先に、保管/引き継ぎの要否を判断する
“移行”や“解約”の前に、エクスポート（保存）手段があるかを必ず確認

（例として、Google系はVault、Microsoft系はPurviewやExchangeの仕組みで保持・検索・書き出しを扱える設計があります。運用の前提や残存期間など細部は各公式仕様に従ってください。）

重要メールの二重化（共有・転送・別保管）

重要メールは「届いて終わり」ではなく、“見落とされない構造”が必要です。
二重化は“増やしすぎるとカオス”なので、効果が高いところだけに絞ります。

二重化すべきメール（優先度が高い順）

請求・支払い（billing@）
契約・法務（legal@ 等）
顧客問い合わせ（support@）
重大アラート（障害・セキュリティ通知）

別保管（最後の砦）の作り方

重要アドレスは、定期的に 書き出し／保管庫への保存を検討
「誰が」「いつ」「どこに」保管するかを決め、手順を固定
- ここが曖昧だと、いざという時に探せません

セキュリティ基本（2要素認証・端末紛失・権限最小化）

セキュリティは難しそうに見えますが、効果が大きいのは“いつも同じ4点”です。

1）2要素認証（MFA）を必須にする

まずはここが最重要です。

管理者アカウント：必須
共有受信箱を扱う人：必須
外注・短期メンバー：原則必須（無理なら権限を絞る）

加えて、管理者の2要素認証はプラットフォーム側で強制・推奨が進む傾向があります。
「あとでやる」は一番危ないので、導入時に終わらせるのが得策です。

2）端末紛失に備える（“リモートで止められる”状態）

スマホやPCがなくなるのは珍しくありません。備えは次の通り。

端末に画面ロック（PIN/生体）
会社アカウントのログイン端末を把握
紛失時の手順を決める
- パスワード変更
- セッション強制ログアウト
- 端末のリモートワイプ（可能なら）

3）権限最小化（必要な人に必要な範囲だけ）

ありがちな事故は「便利だから全員管理者」です。

管理者は最小人数にする
共有受信箱は “閲覧だけ／返信だけ” など必要に応じて分ける
外注には「閲覧不可」「期間限定」「特定アドレスのみ」などで範囲を切る

4）パスワード運用を“強制しやすいルール”にする

人は複雑すぎるルールを守れません。現実的には次が効きます。

長めのパスフレーズ（覚えやすい文章型）
使い回し禁止
漏えいが疑われる時は即変更
可能ならパスワードマネージャー利用

トラブル解決：届かない／送れない時の切り分け手順

メールの不具合は、やみくもに設定を触るほど長引きます。
まずは 「どこで止まっているか」 を切り分けるのが最短ルートです。

送信側（あなたの端末・アプリ）
送信サーバー（SMTP）
経路（DNS・MX・中継）
受信側（相手の迷惑メール判定・ポリシー）
受信箱（容量・アカウントの有無）

症状別チェック（まずここから）

最初に「受信できない」「送信できない」「迷惑メール行き」のどれかを決め、該当のチェックだけ進めます。
同時に全部見ないのがポイントです。

受信できない：MXの向き先・優先度・古いレコード

最初の5分で確認すること（順番どおり）

MXが“今の受け皿”を向いているか
- ドメインのDNSで、MXがメールサービスの指定値になっているかを確認します。
- 可能なら自分のPCで確認すると早いです。
  - nslookup -type=mx example.com
  - dig mx example.com +short
MXが複数ある場合、優先度が意図どおりか
- 数字が小さいほど優先です。
- 古い受け皿（以前のサーバー等）が低い優先度のまま残っていると、メールが分散して「届いたり届かなかったり」になります。
“古いMX”や“テスト用レコード”が残っていないか
- 旧プロバイダ移行後にありがちです。
  残骸があると、原因が見えにくいので整理対象です。
受信箱は本当に存在するか（アカウント未作成・停止）
- info@ を使うつもりでも、受け皿側で メールボックス（アカウント）を作っていないと届きません。
- 共有受信箱・グループ配信の設定ミスもここで起きます。
容量オーバー・一時障害で弾かれていないか
- エラーメール（後述）で「mailbox full」「quota」などが出ます。
- 受け皿がサーバー付属の場合、容量が小さく詰まりやすいので注意です。

よくある落とし穴

WebのDNS設定（A/CNAME）と、メールのDNS設定（MX/TXT）を混同している
「ネームサーバーを変更した」結果、MXが丸ごと消えた（DNSゾーン移行ミス）

送信できない：SMTP認証・ポート・送信制限

「受信はできるのに送れない」は、だいたいSMTP設定が原因です。
以下を上から潰せば、多くは解決します。

1) SMTP認証（ユーザー名・パスワード）が正しいか

ユーザー名が「メールアドレスそのもの」なのか「アカウント名」なのかはサービスで違います。
パスワードは、コピペの空白混入も多いので一度入れ直します。

2) ポートと暗号化（TLS/STARTTLS）の組み合わせ

送信（Submission）は 587（STARTTLS） が一般的です。
サービスによっては 465（暗黙TLS） を案内する場合もあります。
ここがズレると、典型的に「認証エラー」「接続できない」が出ます。

3) “送信サーバー名”が正しいか

smtp.example.com のような見た目でも、実際はサービス指定のホスト名（例：smtp.サービス名）が必要なことがあります。

4) 送信制限に引っかかっていないか

短時間に大量送信、同報、添付が重い、宛先が多い、などで一時ブロックされることがあります。
4xx（後述）が出る場合は「時間を置いて再送」で戻るケースもあります。

5) ネットワーク側のブロック

公衆Wi-Fiや社内ネットワークで、特定ポートが塞がれていることがあります。
その場合は、別回線（テザリング等）で試すと切り分けできます。

迷惑メール行き：SPF/DKIM/DMARC未整備・差出人の整合性

「送信はできるし相手にも届くが、迷惑メールに入る」なら、まずは認証と整合性を見ます。

最短で効く順番

SPFまたはDKIMが通っているか
DMARCが最低限入っているか（p=noneでも可）
From（見えている差出人）と、認証で使っているドメインが整合しているか

ありがちな“見た目だけ独自ドメイン”問題

送信自体は別の無料メールから行い、Fromだけ独自ドメイン風にしている
→ 受信側から見ると不自然で、迷惑判定されやすくなります。

もう一歩踏み込むなら

件名の煽り、URL短縮、添付の実行形式、画像だけ本文などはスパム判定の定番要素です。
ただし、初心者の段階ではまず 認証（SPF/DKIM/DMARC） を整えるのが先です ✅

設定変更が反映されない（TTL・伝播・キャッシュ）

DNS変更で多いのが「設定は合ってるのに、届いたり届かなかったり」です。
これは キャッシュ（TTL） と伝播が原因で起きます。

覚えておくべき現実

DNS変更は即時反映とは限らず、サービスによっては 最大48時間程度かかるケースもあります。

安全に切り替えるコツ

変更前に可能なら TTLを短くしておく（数時間〜半日など、無理のない範囲で）
切り替え直後は、旧受け皿もすぐ解約せず 並行運用する
反映待ち中に、MXを行ったり来たり変更しない
→ 状況がさらに読めなくなります

キャッシュを疑うサイン

ある人には届くが、別の人には届かない
自分のスマホではダメだが、別回線では届く

原因特定に役立つ情報の集め方（エラーメールの読み方）

原因特定の鍵は「感覚」ではなく エラーメール（バウンス／NDR） です。
これが取れれば、8割は切り分けできます。

まず拾うべき3点セット

エラーメールの本文・詳細から、次を探します。

3桁コード（例：550 / 451 など）
拡張ステータスコード（例：5.1.1、5.2.2、4.4.7 など）
相手側サーバー名・メッセージ（どこで拒否されたか）

4xxと5xxの読み分け（超重要）

4xx（一時エラー）：時間をおけば送れる可能性あり
例：一時的な負荷、レート制限、接続不安定
5xx（恒久エラー）：設定や宛先が間違っていることが多い
例：宛先不存在、ポリシー拒否、認証NG

よく出る拡張コードの“意味だけ”覚える

5.1.1：宛先アドレスが存在しない（タイプミス、アカウント未作成など）
5.2.2：受信箱がいっぱい（容量不足）
4.4.7：一時的に届かない（ネットワーク・相手側の一時問題など）

迷惑メール／拒否系のときに追加で集めたい情報

可能なら「メールヘッダー」も見ます（Gmailなら「メッセージのソースを表示」など）。

Authentication-Results（SPF/DKIM/DMARCの結果が出る）
Received-SPF（SPFの判定）
どのドメインで署名されているか（DKIMのd=）

相手に問い合わせるときのテンプレ（最低限）

送信日時（タイムゾーン含む）
送信元（あなたのアドレス）
宛先（相手のアドレス）
エラー全文（スクショよりコピペが望ましい）
可能ならヘッダー（個人情報は伏せてOK）

引っ越し・乗り換え：ドメインはそのまま、メールだけ移す方法

「ドメインは維持したまま、メールの受け皿（サービス）だけ乗り換える」場合、やることは大きく4つです。

事前準備（止めない段取り）
旧メールの移行（コピー／保管）
本番切り替え（MX変更）
解約前の最終確認（取りこぼしゼロへ）

ここを順番どおりに進めれば、初心者でも事故が起きにくくなります。

移行計画（止めないための段取りと期限管理）

最初に決めるべきは「いつ切り替えるか」ではなく、“止めないために何を先に終わらせるか”です。

1）移行の方式を選ぶ（最短で判断）

運用規模で、現実的なルートが変わります。

個人・1人運用
- 旧→新へメールを取り込み（同期 or エクスポート）
- MXを切り替え
- 旧側はしばらく残して様子見
小規模（数人）
- 「アカウント作成→移行→MX→確認→解約」の王道
- 共有窓口（info@ / support@）だけは特に慎重に
チーム（退職者対応・監査あり）
- “誰のメールをどう保管するか”を先に確定
- バックアップ／アーカイブ（保管）の設計が先

2）移行の前に「新しい受け皿」を完成させる

MXを変える前に、最低限これを終わらせます。

新サービス側で 必要なメールボックス（全員分／窓口分）を作成
管理者アカウントの保護（2要素認証など）
送信ドメイン認証（SPF/DKIM/DMARC）の“準備”
連絡先や通知先（フォーム・決済・外部SaaS）の洗い出し

重要：受け皿が未完成のままMXを変えると、その瞬間からメールが「行き場なし」になります。

3）期限管理は「3つの締切」で考える

カレンダーにこの3本だけ置くと、管理がラクです。

切り替え日（MX変更）
並行運用の終了日（旧サービスを止めていい日）
完全撤収日（旧側の解約・データ削除を行う日）

並行運用は“余裕”ではなく、伝播や再送（相手側の送信リトライ）でメールが遅れて届くことがある前提の「安全装置」です。

旧メールの取り込み（同期・エクスポート・保管）

移行でよくある誤解は「MXを変えたらメールも全部移る」です。
MXは“これからの配送先”を変えるだけで、過去メールは勝手に移りません。

1）移行対象を分ける（メール／連絡先／カレンダー）

特にIMAP移行は、基本的に「メールのみ」が中心です。連絡先・予定表は別手段が必要になることがあります。

メール：IMAP同期／移行ツール／エクスポート
連絡先：CSVなどで書き出し→取り込み
カレンダー：ICSなどで書き出し→取り込み

2）同期（コピー）で移すときのコツ

初心者がつまずきやすいのは「移行中に受信が増える」ことです。
対策はシンプルで、移行を一回で終わらせようとしないこと。

まず一度、大枠を同期（旧→新へコピー）
本番直前〜本番後に、差分をもう一度同期（取りこぼし防止）
本番後もしばらく旧側を残し、迷子メールを回収できる状態にする

3）エクスポート（書き出し）で保管する考え方

“移行”と“保管”は別です。移行できても、将来の監査や復旧に備えて保管が必要なことがあります。

重要アカウント（請求・契約・窓口）は、別保管も検討
退職者メールは「消す」より先に、保管要否を判断
新サービス側の保存容量（上限）も事前に確認

切り替え本番（MX変更の安全な進め方）

MX変更は「操作」自体より、前後の運用で成否が決まります。

安全な進め方（チェックリスト）

変更前に、DNSの現状をメモ（特にMXとTXT）
可能ならTTLを短めに（できる範囲で）
新サービスの指定どおりにMXを設定
反映を待つ（すぐに結果が出ないことがある）
テスト送受信（外部ドメイン→自ドメイン／自ドメイン→外部ドメイン）
問題がなければ、旧側のMXや中途半端な設定を整理

反映待ちの間に起きる“ややこしい現象”と対策

反映待ち中は、送信者側のキャッシュ等で

旧受け皿に届くメール
新受け皿に届くメール

が混在することがあります。

混在を事故にしないために、次を守るのが安全です。

旧サービスを止めない（最低でも一定期間は稼働）
旧側に来たメールを回収できる（ログインできる／転送設定がある）状態にする
重要窓口は担当者が両方を見られる体制にする（短期間だけでもOK）

解約前チェック（取りこぼし防止リスト）

「もう新しい方で送受信できる」だけで解約すると、後から困りやすいです。
解約前は、このリストで“取りこぼし”を潰します。

1）配送の確認（最低限）

新受け皿で、複数の外部宛先から受信テスト済み
自分から外部へ送信テスト済み
迷惑メールに入りやすい相手（Gmail等）でも到達を確認

2）サービス通知・ログイン系の付け替え（見落としがち）

「どこにメールが届くか」が変わると、ログインに影響するものがあります。

お問い合わせフォームの通知先
決済・請求サービスの通知
広告・ASP・銀行・SaaSの登録メール
重要アカウントの2要素認証メール（必要な場合）

3）認証まわり（SPF/DKIM/DMARC）の再点検

“受信”だけでなく、“送信”の信頼性も切り替え後に重要です。

SPFが新しい送信元に合っている
DKIMが有効化されている
DMARCが最低限動いている（監視からでもOK）

4）データと権限の最終処理

旧メールの保管（必要ならエクスポートやアーカイブ）
旧側の共有アドレスの引き継ぎ確認
旧側アカウントの停止・削除の手順確認（いきなり削除しない）

目安として「旧側に届く可能性がゼロになった」と判断できるまで、旧サービスの契約を残す方が安全です。

用語集：この記事で出てくる言葉だけ最短理解

「ドメイン　メールアドレス」で混乱しやすい用語は、“何を決める仕組みか”が分かれば一気に整理できます。
ここでは、記事内で出てくる言葉だけを 最短で使えるレベルにまとめます。

ドメイン／DNS／MX／TTL

ドメイン

インターネット上の「住所（名前）」です。メールでは @以降 がドメインになります。

例：info@example.com の example.com
役割：
- Web：どのサーバーへアクセスするか
- メール：どのメール受け皿へ配送するか
  を決める“起点”になります

DNS

ドメイン（例：example.com）を、実際の行き先情報（IPアドレス、メールサーバー名など）に変換する仕組みです。
ざっくり言うと 「住所録」。

Web：example.com はこのIPへ
メール：example.com 宛のメールはこのサーバーへ
認証：このドメインはSPF/DKIM/DMARCをこう設定している

MX

「このドメイン宛のメールを、どのメールサーバーへ届けるか」を示すDNSレコードです。
メール配送の“宛先指定”の中心がMXです。

例：example.com のMXが mail.example.net を指す
ポイント
- 優先度（Priority）：数字が小さい方が優先
- 複数設定：バックアップや冗長化で使うことがある
- 古いMXが残ると事故：届いたり届かなかったり、分散したりします

TTL

DNSの情報を「どれくらいキャッシュしてよいか（有効期限）」を示す値です。
DNS変更後に反映が遅く見えるのは、このTTL（キャッシュ）が関わります。

TTLが長い：反映が遅く見えやすい（安定寄り）
TTLが短い：切り替えは早いが、問い合わせ回数が増える（運用設計次第）

SPF／DKIM／DMARC

この3つは、送信元の“正しさ”を示す 送信ドメイン認証の基本セットです。
最近は受信側の判定が厳しくなり、未整備だと迷惑メール入り・拒否が増えやすくなります。

SPF

「このドメインから送っていいサーバーはこれです」と宣言する仕組みです。DNSのTXTレコードで設定します。

何が分かる？：送信元IPが“許可リスト内”か
つまずきポイント
- TXTが複数になって衝突（基本は1つに集約）
- フォーム通知・メルマガなど、送信元が増えたのにSPFへ追加し忘れる

DKIM

メールに“署名”を付け、受信側がDNS上の公開鍵で検証する仕組みです。
改ざんやなりすましを減らす方向に働きます。

何が分かる？：メールが途中で改変されていないか／送信者が署名できる立場か
つまずきポイント
- DNSにレコードを入れただけで終わりだと思う（多くは管理画面で署名ONが必要）

DMARC

SPF/DKIMの結果をもとに「失敗したメールをどう扱うか」を受信側へ指示する仕組みです。DNSのTXTレコードで設定します。

何ができる？
- 認証が失敗したメールを 受け入れる／隔離（迷惑メールへ）／拒否 など段階的に方針化できる
- どこから送られているかの レポート を受け取れる（運用の見える化）
つまずきポイント
- From（見える差出人ドメイン）と、SPF/DKIMで使うドメインの 整合性（アラインメント） が取れていない

IMAP／POP／SMTP

これらは、メールを「受け取る」「送る」ための通信方式（プロトコル）です。

IMAP

サーバー上のメールを、複数端末で同期しながら扱う方式です。
初心者には基本 IMAPが無難です。

向いている：スマホ・PCなど複数端末で同じ受信箱を使う
特徴
- サーバーにメールが残る前提
- 端末を変えても同じ状態に近づけやすい

POP

サーバー上のメールを端末へ“取り込む”方式です（設定次第でサーバーに残さない運用も可能）。

向いている：基本1台で管理したい、同期より軽さ重視
注意点
- 端末が壊れると復旧が大変になりやすい
- 端末が複数あると「片方にしかメールがない」事故が起きやすい

SMTP

メールを“送る”ときに使う方式です。送信（SMTP）だけ設定で詰まるケースが多いです。

送信でよくある詰まりポイント
- ポート番号（例：587/465）
- 暗号化（TLS/STARTTLS）
- SMTP認証（ユーザー名・パスワード）

よくある質問（「ドメインメールアドレス」で検索されやすい疑問）

ドメインのメールアドレスは無料で作れる？

結論から言うと、“完全無料”はほぼ難しく、最低でもドメイン維持費はかかるのが基本です。
ただし「メールの受け皿」をどうするか次第で、無料〜低コストで始められるケースはあります。

無料〜低コストになりやすい例

転送だけ：info@あなたのドメイン → いまのGmail等に転送
- ✅ すぐ使える／費用が増えにくい
- ⚠️ 送信（返信）を独自ドメインで自然にやるには工夫が必要
サーバー付属のメール：レンタルサーバーのメール機能を利用
- ✅ 月額内で済むことが多い
- ⚠️ 容量・迷惑メール対策・共同利用のしやすさはサービス差が出る

“無料に見える”ときの注意点

独自ドメインで送信する場合、SPF/DKIM/DMARCなどの整備が必要になりやすい
転送運用は便利ですが、状況によっては認証が崩れて迷惑メール判定が不利になることがあります

Webサイトと同じドメインでメールも使える？

はい、同じドメインでWebとメールは両立できます。
混乱しやすいですが、WebとメールはDNSで使う情報が違うだけです。

ざっくり整理

Webサイトの行き先：A / AAAA / CNAME など
メールの行き先：MX
送信の信頼性：SPF / DKIM / DMARC（TXT/CNAME）

よくある設計パターン（初心者向け）

Web：www.あなたのドメイン をWeb用にする
メール：あなたのドメイン のMXでメール受け皿を指定する
→ こうすると「Webとメールが絡まって壊れる」事故が減ります

つまずきポイント

ネームサーバーを変更して、MXやTXTが消える（DNS移管で起きがち）
DNS設定を「どこで管理しているか」分からなくなり、二重管理になる

今使っているWebメールの画面で独自ドメインを使える？

結論：“何をしたいか”で答えが変わります。

1）Gmailの画面で「独自ドメインっぽく送る」だけなら可能

個人のGmailでも、設定次第で 差出人を独自ドメインにして送信できます。
ただし、これは「見た目」だけで成立する場合があり、運用や到達率の面では注意が必要です。

✅ いつもの画面で送信できる
⚠️ 受信側から見ると不自然になり、迷惑メール判定が強まることがある
⚠️ 本格運用なら、送信ドメイン認証まで整える前提で考えるのが安全

2）Gmailの画面で「独自ドメインを本命アカウントとして受信・運用」したいなら

基本は Google Workspace のような“独自ドメイン対応のメール基盤”を使うのが確実です。
これなら独自ドメインのメールをGmail同等の画面で使えます。

3）「外部メールをGmailに取り込んで一括管理」は今後注意

Gmailには外部メールを取り込む仕組み（POP等）がありますが、仕様変更・縮小が起きやすい領域です。
今後も安定して一括管理したいなら、最初から「受け皿を統一する」「転送＋正規の受信箱設計にする」など、揺れない設計がおすすめです。

メールアドレスは何個まで作れる？おすすめの作り方は？

結論：ドメイン自体が上限を決めるわけではなく、“メールの受け皿サービス”の仕様で決まります。

上限を左右するもの

メールボックス（実体の受信箱）の作成数
エイリアス（別名アドレス）の数
共有受信箱／グループの仕組み
転送設定の上限
容量（上限に達すると受信不能になるケースも）

初心者におすすめの作り方（増やしすぎない）

ポイントは、「人に紐づくアドレス」と「役割に紐づくアドレス」を分けることです。

スクロールできます

種類	例	役割	おすすめ度
個人アドレス	`name@`	個人のやり取り	高
役割アドレス	`info@` `support@` `billing@`	問い合わせ・請求・採用など	高
共有受信の箱	`support@` を複数人で見る	引き継ぎ・対応漏れ防止	高
エイリアス	`contact@` → `info@` へ	表記ゆれ吸収・窓口統一	中
むやみな個別箱	`tanaka-support@` など	属人化しやすい	低

最初に作ると運用が楽になる“鉄板セット”

info@（総合窓口）
support@（サポート）
billing@（請求）
privacy@（個人情報窓口が必要な場合）
recruit@（採用）

ドメインを更新し忘れたらどうなる？復活できる？

結論：放置するとメールもWebも止まるので、気づいたら最優先で対応します。
復活できるかどうかは、ドメイン種別（gTLD/.com等、JP等）と事業者の運用で変わります。

一般的に起きること（よくある流れ）

有効期限を過ぎる
Webが表示されない／メールがバウンスし始める
しばらくは「更新・復活」ができる期間がある
さらに放置すると削除され、第三者に再取得される可能性が出る

すぐやるべきこと（最短ルート）

まず ドメイン管理会社（レジストラ）の管理画面で状態確認
更新できるなら即更新（支払い方法も見直す）
更新できない／削除に入っていそうなら、復活（リストア）手続きを問い合わせる
- この段階は追加費用がかかることが多いです

JPドメインの注意（復活受付に期限がある）

JP系は「状態遷移」や「回復受付期間」が決められていることがあり、気づいた日が勝負になりやすいです。

急に届かなくなった時、最優先で見るべき点は？

迷子メールの原因は色々ありますが、初心者が最短で切り分けるなら この順番が堅いです。
（上から順に“致命度が高い”ものを並べています）

最優先チェックリスト（5分で確認）

ドメインが失効していないか
- 失効するとメールもWebもまとめて止まり得ます
- 管理画面で有効期限・支払い状況を確認
DNS（特にMX）が変わっていないか
- ネームサーバー変更やDNS移行で、MXやTXTが消える事故が多いです
- 直近で「サーバー移転」「CDN導入」「DNSサービス変更」をしていないか確認
受け皿側の容量・停止
- 容量上限で受信停止になっていないか
- 共有受信箱・グループ設定が壊れていないか
相手側要因（相手サーバーの一時拒否／遅延）
- 一時的な遅延は時間差で届くことがあります
- エラーメール（NDR）があるなら、まずそこに答えが書かれています
迷惑メール判定・認証の崩れ
- SPF/DKIM/DMARCの未整備・整合性崩れで、迷惑メールや拒否になることがあります
- 特に「転送運用」「送信経路を増やした」タイミングで起きやすいです

追加で取ると特定が速い情報

エラーメール（バウンス）の本文（4xx/5xxや 5.x.x が重要）
いつから起きたか（日時）
どの宛先だけか（特定の相手だけ／全部）
直前に変えたこと（DNS、メールサービス、フォーム、メルマガ等）

今日やるチェックリスト（最短で失敗しない）

今日やる（必須）

目的は1つ：メールが「届く／送れる／止まらない」状態を最短で作ること。
迷ったら、下から順に “できたか” だけ確認してください。

ドメインの更新・支払いを固定する
- 自動更新をON、支払い方法（カード・請求先）を最新にする
- 期限通知メールの受信先を「確実に見れるアドレス」にする
「メールの受け皿」を決める（転送／サーバー／クラウド）
- 個人・副業：まずは転送 or サーバー付属でもOK
- 複数人・共有前提：クラウド型が安定（引き継ぎ・監査も楽）
必要最小限のアドレス設計をする（増やしすぎない）
- まず作る：info@（総合窓口）／billing@（請求）／support@（問い合わせ）
- “人名アドレス”より 役割アドレス を優先（引き継ぎが楽）
DNSで「届く」状態にする（MX）
- MXが新しい受け皿を指しているか
- 古いMXが残っていないか（混在すると事故の元）
送信ドメイン認証の最低ラインを入れる（SPF／DKIM／DMARC）
- SPF：送信元を宣言（1レコードに集約）
- DKIM：署名を有効化（DNS設定＋管理画面のONまで）
- DMARC：まずは監視（p=none）で開始してOK（いきなり強化しない）
管理者と主要アカウントのセキュリティを固める
- 2要素認証（MFA）を必須化
- 管理者権限は最小人数にする
- 共有受信箱（窓口）の権限を整理（閲覧のみ／返信可など）
最終テスト（この2通だけで十分）
- 外部→自ドメイン：受信できるか
- 自ドメイン→外部：送信できるか（迷惑メールに入らないかも確認）

今週やる（安定運用）

“今日”で動いたら、今週は 止まらない仕組み を作ります。

アカウント棚卸し台帳を作る（1枚でOK）
- アドレス／用途／所有者／権限／関連サービス／最終利用日を記録
- 退職・外注の出口（停止手順）もメモしておく
重要メールの見落とし防止を仕組みにする
- 窓口メールは「共有受信箱」または「グループ」で複数人が見られる状態に
- 個人宛の転送だけに頼らない（属人化しやすい）
バックアップ／保管の方針を決める
- 誤削除や乗っ取りに備えた“復旧手段”を用意
- 請求・契約などは保管期間の目安を決める（社内ルール化）
DMARCレポートを受け取れる状態にする
- まずは「誰がどこから送っているか」を見える化
- 想定外の送信元（フォーム、メルマガ、外部ツール）を洗い出す
トラブル時の最短手順を決めておく
- “届かない”→ まずMX／容量／ドメイン失効
- “送れない”→ SMTP認証／ポート／送信制限
- “迷惑メール”→ SPF/DKIM/DMARC と差出人整合性
- 連絡先（ドメイン管理会社／メール提供元）をすぐ辿れる場所にまとめる

半年ごとに見直す（事故防止）

メールは「いつの間にか設定が古くなる」タイプのインフラです。半年ごとに点検すると事故が激減します。

ドメイン管理の点検
- 自動更新・支払い方法・通知先が生きているか
- 管理者が退職していないか（引き継ぎ済みか）
アカウントの棚卸し
- 使っていないアドレス／不要な権限／外注のアクセス権を整理
- 管理者権限の人数が増えていないかチェック
送信ドメイン認証の健全性チェック
- SPFに“今の送信元”が全て入っているか（追加したツール分が漏れやすい）
- DKIMが全送信経路で付いているか
- DMARCレポートで異常（なりすまし・未認証送信）がないか
- 可能なら段階的にDMARCを強化（監視→隔離→拒否）
復旧できるかのテスト
- バックアップから戻せるか（「取ってる」だけでは不十分）
- 端末紛失時に、強制ログアウト・パスワード変更がすぐできるか
“届きやすさ”の健康診断
- 主要宛先（例：Google系／Yahoo系／Microsoft系）にテスト送信し、迷惑メール入りが増えていないか確認
- 変更点（フォーム追加、配信ツール導入、転送ルール変更）があれば特に要注意