ドメイン + ビジネスメールの設定：非技術者向けのシンプルガイド
ドメインの購入、DNS接続、ビジネスメールの設定（MX／SPF／DKIM／DMARC）をステップごとに解説。確認ポイント、よくある修正方法、セキュリティの注意点をわかりやすくまとめます。
セットアップするもの（と、なぜ重要か）
あなたが設定するのは2つの連携する要素です：ドメイン名（例：yourcompany.com）と、そのドメインを使うビジネス用メールアドレス（例：[email protected]）。これらを正しくつなぐと、メールが信頼して届きやすくなり、送信時にブランドが表示されます。
設定する内容
- ドメイン：レジストラで購入・管理するドメイン。
- メールサービス：メールボックスが置かれるサービス（一般的には Google Workspace や Microsoft 365 など）。
- プロフェッショナルなメールアドレス：個人用の受信箱（例：
[email protected]）やチーム用アドレス（例：[email protected]）。
ドメインとメールプロバイダの接続は DNS設定（ドメイン管理画面で追加する数個のレコード）を通じて行います。これらのレコードは、あなたのドメイン宛てのメールをどこに配信するか、そしてそのメールが正当であることを証明する方法を示します。
このガイドは誰向けか
このガイドは 非技術者向け です—ソロファウンダー、フリーランス、小規模チームがネットワークやサーバの詳しい知識なしにビジネスメールを動かせるように書いています。
開始前に必要なもの
- ドメインレジストラのアカウント（DNSを編集できるログイン）
- メールプロバイダの管理者アカウント（メールボックス作成やDNSの指示を受け取る）
- 作成したいアドレスの短いリスト（例：各人分 +
info@、billing@、support@）
所要時間の目安（遅くなる要因）
ほとんどのセットアップは 30〜90分 の手作業です。
主な遅延要因は DNSの伝播：DNSを更新してから変更がインターネット上に行き渡るまで、数分〜24〜48時間 かかる場合があります。その間、ある人にはメールが届くが別の人には届かない、という状況が発生します。
すべてが繋がれば、より信頼されるメール環境になり、チームやアドレスを増やしていく基盤が整います。
用語を平易に説明
設定画面をいじる前に、どの会社が何を担っているかを知っておくと安心です。混乱の多くは3つの「場所」が関係しているために起きます。
3つの役割（誰が何をするか）
ドメインレジストラ：ドメイン名（例：yourcompany.com）を購入・更新する会社。所有権管理や更新を扱います。
DNSホスト（DNSプロバイダ）：ドメインの "住所録" が置かれている場所。DNSはドメインの各種サービス（ウェブサイト、メールなど）がどこにあるかを示すレコードの集合です。レジストラがそのままDNSホストを兼ねることもあります。
メールプロバイダ：実際に受信箱を動かし、メールを送受信するサービス（例：Google Workspace、Microsoft 365）。ここで [email protected] のようなメールアドレスが作られます。
どうつながるか（ドメイン → DNS → メール）
分かりやすく言うと：
- あなたの ドメイン は公開名（店名のようなもの）
- DNS はその名に紐づけられた指示書
- メールプロバイダ は実際の郵便局（受信箱）
だから、ドメインはレジストラで買い、DNS（実際に管理されている場所）でレコードを編集して「@yourcompany.com のメールはこのプロバイダに配信してね」と指示します。
簡単な図にすると：
Domain (registrar) → DNS (records) → Email provider (inboxes)
「伝播（プロパゲーション）」とは何か
DNSを変えると、すぐに全世界で反映されるわけではありません。伝播とは、異なるネットワークのキャッシュが更新され、DNS変更が行き渡るまでの時間のことです。
実務では、DNS変更直後にしばらく旧挙動が続くことがあると覚えておいてください—特に最初の数時間はその傾向が強いです。
ドメインの選び方と購入
ドメインはウェブサイトとメールアドレスの基礎になります（例：[email protected]）。長く使うものなので、最初に少し手間をかけておくと後で楽になります。
分かりやすいドメイン名のルール
聞いて一度で分かる、綴りが簡単な名前を目指してください。
実務的ルール：
- 口に出して説明せずに伝えられる1〜2語を優先
- ハイフンや紛らわしい綴り、巧妙すぎる綴りは避ける
- 会社名が長い場合は短いブランド版を検討
- 友人に言ってもらい、綴りを間違えられたら簡略化を考える
TLDの選び方：.com とその他
- .com は人に覚えられやすく信頼感も高い。手頃ならまずはこれがベスト
- .co は代替として使えるが、人が間違って .com と入力することがある
- 国別ドメイン（例：.uk、.ca）は特定地域向けに有効だが、将来の拡大で制約に感じる場合がある
- 新しいTLD（例：.studio、.agency）は覚えやすいが、共有する際に説明が必要になることがある
可能なら主要なバリエーション（.com や地域ドメイン）を押さえてブランドを保護し、1つをメールの「プライマリ」ドメインに選びましょう。
購入先の比較ポイント
レジストラを選ぶときは以下を比べます：
- 初回価格と更新価格（更新時に高くなることが多い）
- WHOISプライバシー（無料のところと有料のところがある）
- DNS編集のしやすさ（メール設定で必要になる）
- サポートの質（チャットがあると助かる）
- 不要なオプションの押し売り（チェックアウトで余計なものが付く場合がある）
所有権とプライバシーの基本
ドメインは事業名義（あるいは信頼できる所有者）で登録し、ログイン、復旧用メール、二要素認証を確実に管理してください。担当者が離職してもドメインが持ち出されないよう、アクセス管理を一箇所にまとめて安全に共有しましょう。
特別な理由がなければ WHOISプライバシー を有効にしておくと、スパムや個人情報公開のリスクを減らせます。
ビジネス用メールプロバイダの選び方
メールプロバイダ選びは、どこでメールサービスを運用するかの判断です。ドメインは一か所に保ったまま、メールだけ別サービスで運用することも可能です。
よくある2つの選択肢
1) ドメインレジストラでメールを使う
多くのレジストラはドメイン購入と一緒にメールプランを提供しています。請求やサポートが一元化される利点がありますが、機能が限定的だったり、将来の移行が面倒だったりすることがあります。
2) 独立したメールプロバイダを使う
成長するチームにはこちらが一般的です。Google Workspace や Microsoft 365 のようなプロバイダは到達性、セキュリティ、生産性ツールに注力しています。ドメインはレジストラに残しておき、DNSレコードでメールを接続します。
無駄に支払わないために見るべき点
実際に使う機能に注目しましょう：
- メールボックス数：各人に必要か、あるいは少数＋エイリアスで足りるか
- ユーザーごとのストレージ容量：大きな添付やメール履歴が多い場合は重要
- エイリアスやチームアドレス：何が含まれているか、追加料金はないか
- 共有受信箱の有無：
support@など複数人で管理する住所向けの機能
管理者機能で重視すべき点
非技術担当者が違いを実感するのは次の辺りです：
- 簡単なユーザー管理（スタッフの追加・削除が簡単）
- 二要素認証（2FA） の有無
- アカウント復旧のオプション（バックアップメール／電話、管理者リセット）
- 監査ログの基本（誰がいつ何を変更したか）
予算感
フル機能のプロバイダは一般にユーザー単位の月額料金があり、レジストラのメールは安価だが機能が限られます。料金体系（メールボックスかエイリアスか、ストレージ量、共有機能の有無）を /pricing などで必ず確認してください。
迷う場合は、エクスポートや移行ツールが使いやすいプロバイダを選ぶと後で助かります。
メールボックス、エイリアス、チームアドレスの作成
ここからが実運用です。個人の受信箱や、顧客対応用のチームアドレスを作り、実際に使える形にします。
まずは主要な受信箱を作る
最初に作るのは通常次のどれかです：
- [email protected]（アカウントの責任者やログイン用に最適）
- [email protected]（小さなチームのフレンドリーな窓口）
- [email protected]（一般的だがスパムを招きやすい）
ソロビジネスなら、you@ をメインの受信箱にして hello@ をそのエイリアスとして受け取るのが手軽です。
チームメンバーと役割アドレスの追加
次に実際の人のアカウント（例：sara@, mike@）を作り、顧客が連絡する役割アドレスを設定します：
役割アドレスの受信方法は、1人に配信する、複数人に配信する、共有受信箱にする、など選べます。
エイリアスと別の受信箱の選び方
エイリアスを使う場合：
- 同じ人が複数の名前で受け取りたいとき（例：
firstname@とyou@） - 複数の入り口が必要だが一つの受信箱で十分なとき
別の受信箱を作る場合：
- 複数人がアクセスする必要があるとき
- パスワードやルール、履歴を独立させたいとき（例：
support@）
命名ルールを今決める（後の手間を減らす）
シンプルなルールを決めて守ってください：
- 個人：first@ または first.last@
- チーム：support@、sales@、billing@
support-team@ と help@ のようにばらばらにしないで、オンボーディングやセキュリティ、トラブルシュートを楽にしましょう。
DNS設定の見つけ方（迷わないために）
DNSはドメインの設定画面です。ウェブサイトやメールがどこにあるかを指示する場所で、ビジネスメールなら主に MXレコード と数個の TXTレコード（SPF、DKIM、DMARC）を編集します。難しいのは正しい画面を見つけることだけです。
DNSがどこにあるか（よくある2箇所）
多くの場合：
- ドメインを買ったレジストラ（GoDaddy、Namecheap、Google Domains／Squarespace Domains など）
- 外部のDNSホスト（Cloudflare、ウェブホスティング会社、マネージドDNSプロバイダ）
ヒント：ドメインがカスタムネームサーバ（例：ns1.cloudflare.com）を使っているなら、DNSはおそらくレジストラではなくそのネームサーバ上にあります。
正しいDNS画面の見つけ方
次のメニュー名を探してください：
- DNS
- DNS Settings / Manage DNS
- Zone Editor
- Domain Settings → DNS Records
適切な画面に入ると、通常は Type、Name/Host、Value/Content、Priority、TTL のような列があるテーブルが見えます。
変更前の注意
誤操作を防ぐために2分だけ確認しましょう：
- 現在のDNSレコードをスクリーンショットに撮る（あるいはエクスポート）
- 複数ドメインを管理している場合は対象ドメインを二重チェック
- DNSがレジストラか別の場所か不明なら、まず ネームサーバ を確認する
メールのために触る項目（触らなくていいもの）
ビジネスメールで通常触るのは：
- MXレコード：受信メールの配信先を示す
- TXTレコード：検証やメールのセキュリティ（SPF、DKIM、DMARC）に使う
ウェブサイト関連の A、AAAA、CNAME は、プロバイダが特に指示しない限りそのままにしておいても大丈夫です。
よくあるDNSミスを避ける
- 誤ったドメインレベルに追加する（サブドメインに入れてしまう、またはルートに入れるべきところを間違える）
- TXT値に余分なスペース を入れる
- ドットの付け忘れ／付け過ぎ：システムによっては
mail.example.comをそのまま入れるか、末尾のドットを自動で付けるか違いがある - 古いレコードの重複：古いMXが残っていると配信が分散して問題になる
正しいDNSホストを見つけ、現状を保存してからメールプロバイダの指示通りに変更すれば、次のMX設定に進めます。
MXレコードで受信をつなぐ
MXはドメイン宛のメール配信先を指し示す看板のようなものです。誰かが [email protected] に送るとき、相手のシステムはDNSのMXレコードを見てどのプロバイダに配信すべきかを判断します。
MXレコードの役割
MX（Mail Exchange）レコードは、あなたのドメイン宛てのメールがどこへ配信されるかを指定します。間違っていたり古いレコードが残っていると、メールがバウンスしたり、古い受信箱に届いたり、行方不明になったりします。
追加／置き換えの安全な手順
ドメインのDNS設定で、メールプロバイダが示すMXエントリ（ホスト／値／優先度）を正確に追加してください。
プロバイダを切り替える場合、多くは「既存のMXレコードを削除してください」と指示します。古いMXを残すと配信が分かれるので、指示に従って削除することが重要です。
ヒント：変更前に現在のMXをメモしておくと、元に戻す必要があるときに安心です。
優先度（Priority）とは
優先度はランク付けです：数値が小さいほど優先されます（例：1 は 5 より優先）。
ほとんどの場合は：
- プロバイダが示す優先度をそのまま使う
- 独自にレコードを増やしたり数値を入れ替えたりしない
MXが動いているか確認する方法
まずプロバイダの管理画面にある「ドメイン検証／DNS確認」ツールを使ってMXが検出されているか確認します。
次に実際のテストを行います：個人のメール（Gmailなど）から新しいビジネスアドレスに送って受信できるか確認し、返信して送信側もチェックしてください（MXは受信に影響します。送信はプロバイダ側で処理されます）。
SPF、DKIM、DMARC の追加（シンプルで安全に）
SPF、DKIM、DMARC は、他のメールシステムがあなたのドメインから来たメッセージを信頼できるか判断するためのDNSレコードです。目的はシンプル：なりすましを減らし、本物のメールが迷惑メール扱いされる可能性を下げることです。
SPF：誰が送れるかを明示する
SPFは、どのサービスがあなたのドメインでメールを送信できるかを列挙する1つのTXTレコードです。
実務上のルール：
- ドメインごとにSPFは1つだけ にする（複数ある場合は結合する）
- プロバイダが示す値を使う（Google Workspace、Microsoft 365、メールホストなど）
例（例示のみ）：
v=spf1 include:_spf.google.com include:servers.mcsv.net -all
include: は送信を許可するサービスを示します。末尾の -all は「それ以外はすべて拒否」を意味します。テスト中は ~all（ソフトフェイル）にしておき、問題なければ後で -all に切り替える運用もあります。
DKIM：改ざんされていないことを示す署名
DKIMは送信側が送るメールに署名を付ける仕組みです。プロバイダからは通常：
- セレクタ（例：
googleやs1） - 追加するDNSレコード（多くは TXT、場合によっては CNAME）
selector._domainkey.yourdomain.com のような名前でレコードを追加したら、管理画面で DKIM/署名を有効化 します。
DMARC：まずは監視モードで始める
DMARCは、SPF/DKIMが失敗したときに受信側にどう扱って欲しいかを伝えます。最初はブロックする設定にするのではなく、レポートを集める 監視（p=none） から始めるのが安全です。
よく使われる開始用DMARCレコードの例：
v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s
p=none はレポート収集のみを意味します。正当な送信が全てパスすることを確認してから、quarantine や reject に段階的に厳しくしていきましょう。
パソコンやスマホでメールを使えるようにする
ドメインメールを作り、DNSが繋がったら、最後に各端末でメールを送受信できるよう設定します：ノートパソコン、スマホ、タブレットなど。
Webメールとメールアプリ（どちらを使う？）
Webメール はブラウザで開く受信箱（例：Gmail、Outlook on the web、プロバイダのウェブポータル）。設定不要で動作確認がしやすいので、まずここで送受信できるか確認しましょう。
メールアプリ は Gmail/Outlook のモバイルアプリ、Apple Mail、デスクトップの Outlook など。通知やオフラインアクセスが便利ですが、正しいサインイン情報やサーバ設定が必要です。
アプリの設定がうまくいかない場合は、まず Webメールにログインしてアカウント自体が正常か確認すると原因切り分けができます。
IMAP と Exchange/ActiveSync の違い
プロバイダによって接続方式が複数あることがあります：
- Exchange / ActiveSync：Microsoft 365 などでよく使われ、メールだけでなく 連絡先やカレンダー も同期されるため、モバイルでの導入が簡単です。共有機能にも強い
- IMAP：広く使われる基本的なメール同期。連絡先やカレンダーは別途設定が必要になることが多い
可能なら Exchange/ActiveSync を選ぶと端末側の設定が楽になります。Exchange が使えない場合は IMAP を利用してください。
2FA とアプリパスワード：ログイン失敗の原因
アカウントに 二要素認証（2FA） が有効だと、古いアプリや一部デスクトップクライアントは2段階認証に対応していないため接続できないことがあります。
よくある対処法：
- 「Google／Microsoftでサインイン」フローを使う（提供されていれば）
- アプリパスワード を発行してそのアプリ用のパスワードを使う
- ユーザー名に
[email protected]のフルアドレスを入力しているか確認する
端末設定の簡単チェックリスト（手動設定時）
手動設定で聞かれたら、通常以下が必要です：
- メールアドレス（ユーザー名）：
[email protected] - パスワード：受信箱のパスワード（2FAのためのアプリパスワードが必要な場合はそれを使う）
- 受信サーバー：IMAP または Exchange のサーバ名（プロバイダの指示に従う）
- 受信ポート：一般的に 993（IMAP）
- 暗号化／SSL：ON（SSL/TLS）
- 送信サーバー（SMTP）：プロバイダのサーバ名
- 送信ポート：一般的に 465（SSL） または 587（TLS/STARTTLS）
- SMTP認証：ON（同じユーザー名／パスワードを使う）
サーバ名が不明なら、プロバイダのサポートページで “IMAP settings” や “Exchange settings” を検索して正確な値をコピーしてください。
設定後は個人アカウント宛にテストメールを送り、返信して両方向が機能するか確認します。
転送、キャッチオール、共有受信箱
チームができると、転送、エイリアス、キャッチオール、共有受信箱のような便利な仕組みが必要になります。似ているようで挙動は異なるので用途に合わせて使い分けましょう。
転送 vs エイリアス vs 共有受信箱（簡単比較）
- 転送：アドレスAに来たメールを自動的にアドレスBへ送る（例：
info@→sarah@） - エイリアス：別名アドレスが同じ受信箱に届く（例：
sarah@がinvoices@も受け取る） - 共有受信箱：複数人でアクセスする受信箱（
support@のようなチーム運用向け）
簡単なルール：個人が複数のアドレスを受け取るならエイリアス、複数人で管理するなら共有受信箱 を使ってください。
転送が向く場合（短期）と問題が出る場合
転送は次の用途で便利です：
- 短期間の移行（プロバイダを変えたがしばらく旧メールを受けたい）
- 一時的なルーティング（例：フォーム通知を特定の人に送る）
長期運用での問題点：
- 返信が混乱する（誤った差出人で返信されることがある）
- 到達性が下がる場合がある（転送によってSPFが失敗するケースがある）
- 担当の追跡が難しい（誰が対応したか分かりにくい）
重要なチーム用アドレスは共有受信箱やヘルプデスクツールで管理するほうが堅実です。
キャッチオール：利点・欠点とスパムリスク
キャッチオール は [email protected] をすべて受け取る設定です。
利点：
- 間違いアドレスへの送信を逃さない
欠点：
- スパムのターゲットになりやすい（スパマーがランダムなアドレスを試すため）
- ミスタイプがバウンスしないので誤送信に気付きにくい
もし使うなら監視用の共有受信箱に集め、スパムフィルタを強化してください。
チームメールを整理する簡単ルールとフィルタ
ほとんどのプロバイダでできます：
billing@とsupport@宛で自動ラベルやフォルダ振り分け- 件名に応じた特定の自動転送（例：「New lead」だけを転送）
- 共有受信箱の自動応答テンプレート（「お問い合わせを受け取りました…」と期待値を示す）
小さな工夫でメールがチャット化して散らかるのを防げます。
旧メールアドレスからの移行
新しいビジネスメールに移行しても古いメッセージや連絡先を失う必要はありません。重要なのは何を移すかを決め、しばらく両方を並行運用することです。
何を移すか決める
範囲を決めて始めてください：
- メールのみ：最も早く済む方法で、多くの場合十分
- メール＋連絡先＋カレンダー：共有カレンダーや連絡先を多用している場合は移行の価値が高い
迷ったらまず メールのみ を移して安定させ、問題なければ連絡先・カレンダーを後から追加移行する方法が安全です。
移行方法の選択肢
プロバイダは一般的に次の方法を提供します：
1) 組み込みインポーター（最も簡単）
Google Workspace や Microsoft 365 には、別プロバイダからメール／連絡先／カレンダーを移すためのツールがあります。非技術者にはこれが最も簡単で確実です。
2）IMAP移行（多くのプロバイダで動作）
古いサービスがIMAPをサポートしていれば、移行ツールでフォルダとメッセージをコピーできます。カレンダーや連絡先は別途エクスポートが必要な場合があります。
3）手動のエクスポート/インポート（最も手間）
自動ツールがない場合は、PST/mbox/CSV などでエクスポートして新しいサービスにインポートします。時間がかかるので余裕を見てください。
切り替えでメールを失わないために
古いアカウントはすぐに停止しないでください。以下を確認してから閉じましょう：
- 新しい受信箱で送受信が正常に動作する
- 重要なメールがコピーされている（いくつかの送信者を検索して確認）
- 新しいアドレスでの返信が問題なく行える
また古いアドレスには自動返信を入れておくと、連絡者に移行を知らせられます。
シンプルなカットオーバープラン
静かな時間（早朝や週末）を選び、次の流れで行います：
- チームに告知（いつ何が変わるか）
- 実メールでのテスト（外部の Gmail/Outlook などから）
- 1アカウントずつ移行（まずは管理者／オーナーを試し、問題なければ残り）
確認が取れたらサインアップ情報、請求先メールなどを更新し、古い箱は短期間保持してから停止します。
トラブルシューティングチェックリスト（よくある問題と対処）
ほとんどの問題は DNS（ドメイン設定）、認証（SPF/DKIM/DMARC）、サインイン／端末設定（パスワード、2FA、アプリ設定）のいずれかに起因します。次のチェックリストで絞り込んでください。
メールが届かない
まず MXレコード を確認：
- MXがプロバイダの指示と一致しているか（ホスト／優先度／値）
- 間違い（例：
@とドメイン名を混同して追加している） - 古いMXが残っていないか（前のプロバイダのレコード）
- 変更直後なら少し待つ（伝播）
メールが迷惑メールに行く
多くは認証や送信元の不一致：
- SPF/DKIM/DMARC が公開され、管理画面で “pass” と表示されているか
- From: フィールドのドメインが一致しているか（別ドメインを使う外部ツールは設定が必要）
- ニュースレターやCRMなど外部送信ツールを使っている場合、そのサービスをSPFに追加するか、DKIMを設定する
ログインや端末接続ができない
- ユーザー名の形式（
[email protected]）が正しいか - 2FAが原因なら アプリパスワード を発行して使う
- 自動設定で失敗する場合は IMAP/SMTP/Exchange の手動設定を確認
サポートに渡すと早く解決する情報
お問い合わせ時は次を添えると早いです：
- DNS（MX/SPF/DKIM/DMARC）のスクリーンショット
- 正確なエラーメッセージ（コピペ）
- 問題のメールのフルヘッダ（SPF/DKIM/DMARCの結果が分かる）
- 影響を受けるアドレス、送信時刻、受信側ドメイン（例：Gmail、Outlook）
新しいプロダクトや内部ツールと一緒にメールを設定する場合は、早い段階で送信元アドレスを統一しておくと、後からDNSや到達性を見直す手間が減ります。Koder.ai のようなチームは、トランザクションメールとサポートメールを最初に分けておくことが多いです。
よくある質問
ドメインメールの設定を始める前に何が必要ですか？
必要なのは次の2つのアカウントへのアクセスです：
- ご自身の ドメインレジストラ／DNS アカウント（DNSレコードを編集するため）
- ご利用予定の メールプロバイダの管理者 アカウント（メールボックス作成や正確なDNS値を確認するため）
また、作成したいメールアドレスの短いリスト（例：you@、hello@、support@）を用意しておくと、一度にまとめて作業できます。
DNS変更後、ビジネスメールが使えるようになるまでどれくらいかかりますか？
通常は作業自体は 30〜90分 程度ですが、DNSの伝播時間がかかります。
伝播は 数分〜24〜48時間 かかることがあり、この間は一部の送信者には届くが他の送信者には届かない、といった現象が起こるのが普通です。
レジストラ、DNSホスト、メールプロバイダはどう違うのですか？
役割は分かれています：
- レジストラ：ドメインを購入・更新する場所
- DNSホスト：DNSレコードが実際に管理されている場所（レジストラと同じ場合もあれば別の場合もあります）
- メールプロバイダ：実際にメールボックスを運用し、送受信を行うサービス
もしカスタムネームサーバ（例：Cloudflare）を使っているなら、DNSはそのネームサーバ上で管理されているため、レジストラではなくそこを編集する必要があります。
MXレコードとは何で、受信にどう関係しますか？
MXレコードは @yourdomain.com 宛の受信メールをどこに配信するかを示すDNSレコードです。
安全に設定するには：
- まず現在のMXをメモしておく
- メールプロバイダが示す通りに（ホスト／値／優先度）正確に追加する
- プロバイダを切り替える場合は、古いMXを削除して配信が分散しないようにする
ドメインメールが正しく動作しているか素早く確認するには？
まずはプロバイダの検証ツールを使い、次に実際のテストをします：
- 個人のアカウント（GmailやOutlookなど）から新しいアドレスへメールを送る
- 受信できたら、そのメールに返信して送信（送信側）も確認する
DNSを更新した直後であれば、伝播を待つ必要があることがあります。
本当にSPF、DKIM、DMARCが必要ですか？それぞれ何をするのですか？
はい。これらはDNSベースの信頼指標で、到達性を改善し、なりすましを減らします：
- SPF：どの送信元があなたのドメインから送れるかを列挙（ドメインにつき 1つ のSPFレコードにする）
- DKIM：送信メールに署名を付け、改ざんされていないことを証明
- DMARC：SPF/DKIMが失敗したときに受信側にどう対応してほしいかを指示。最初は監視モード（
p=none）で始めるのが安全です
support@ のようなチーム用アドレスはエイリアスと別アカウント、どちらが良いですか？
次の基準で選んでください：
- エイリアス：1人が複数のアドレスを受け取りたい場合（例：
hello@を個人の受信箱で受け取る） - 別のメールボックス／共有受信箱：複数人がアクセスする、履歴や所有権を共有したい場合（例：
support@、sales@）
チームでの対応や記録が必要なら、共有受信箱や専用のメールボックスの方が管理しやすいです。
キャッチオールのメールアドレスは有効にすべきですか？
キャッチオールは [email protected] を受け取る設定です。
利点：
- 間違ったアドレス宛でもメールを逃さない
欠点：
- スパムの標的になりやすい
- 誤入力がバウンスしないためミスに気づきにくい
有効にする場合は、監視された共有受信箱へ集め、強力なスパムフィルタを設定することを検討してください。
古いメールアドレスから新しいものに移行するとき、メッセージを失わないには？
新しい環境を安定させてから移行するのが安全です：
- 移行期間中は古い受信箱を有効にしておく
- プロバイダの移行ツールやIMAP移行を使ってメールをコピーする
- 古いアドレスに一時的な自動返信（“新しい連絡先は
[email protected]”）を設定する - 重要なログインや請求先のメールアドレスを更新してから古いサービスを停止する
ドメインメールが「動かない」一般的な原因と対処法は？
問題を上から順に確認してください：
- 受信されない：MXレコードが間違っている、重複している、あるいは伝播中である
- 迷惑メールに行く：SPF/DKIM/DMARCが未設定または失敗している。外部送信ツールを許可しているか確認
- アプリに追加できない：ユーザー名形式が違う（
[email protected]が必要）、2FA のためにアプリパスワードが必要、IMAP/SMTP/Exchange 設定が間違っている
サポートに連絡する際は、DNS設定のスクリーンショットやサンプルメールのフルヘッダ（SPF/DKIM/DMARCの結果が出る）を添えると解決が早くなります。