独自ドメインのメールアドレスの作り方、DNS設定から送信テストまで

The three ways to get email on your own domain, and a tested walkthrough from MX


まわりの話を聞いてみたら、初めて会う方の名刺に@gmail.comが載っていたら、「本当に会社なのかな」と思ったことがあるそうだ。メールアドレスのドメイン部分が、相手にとって最初の信用の判断材料になっていることに、その時初めて気づいた。

だからこれから独立してビジネスをはじめる方と会ったらかならず独自ドメインのメールアドレスを持つようにアドバイスする。受信側のサーバーが送信元を本物と認識しやすくなるのはもちろんだ。自分のメールが相手の迷惑メールフォルダに入りにくくなる。自分はKaiMailでメールサーバーを運用している。2026年10月6日、新しいテスト用ドメインでメール転送を設定して、最初のメールが届くまで7分かかった。今回はその手順を含めて、3つの方法を比較する。

読み終えると、次のことができる。独自ドメインでメールを受信する。MXレコード、SPF、DKIMをDNSに設定する。転送されたメールが迷惑メールにならないよう整える。自分のドメインから返信する。独自ドメインメールとは何か、なぜ信頼につながるのかを読む

始める前に用意するもの

3つだけだ。ドメイン、そのDNSを変更できる権限、メールを受け取る既存の受信箱。

ドメインは、レジストラ(お名前.comやRoute 53など)で取得する。DNSの管理は、レジストラと同じ会社が担当していることもあれば、Cloudflareなど別の会社が担当していることもある。自分の場合は、ドメインはお名前.comで取得したが、DNSはCloudflareで管理している。レジストラの管理画面で「ネームサーバー」の設定を見れば、DNSがどこで管理されているかがわかる。

DNSがどこで管理されているかを調べるには、ターミナルで次のコマンドを実行する。

dig NS ドメイン名

返ってきたNSレコードの値が、現在のDNS管理会社を示す。たとえばCloudflareなら lara.ns.cloudflare.com のような値が返る。

メールアドレスは、ルートドメイン(@example.com)にするか、サブドメイン(@mail.example.com)にするかを決める必要がある。メールにルートドメインとサブドメインのどちらを使うか決める

独自ドメインでメールアドレスを作る3つの方法

大きく分けて3通りある。新しい受信箱を作る方法、今の受信箱に届ける方法、レンタルサーバー付属のメールを使う方法だ。

方法1:Google Workspace などのメールボックスサービスを使う

Google WorkspaceやMicrosoft 365、Zoho Mailは、新しいメールボックスを作るサービスだ。ユーザーごとに専用の受信箱と保存容量が割り当てられる。料金はユーザーごとの月額課金制だ。

2026年10月6日時点で、Google Workspace Business Starterは月額約800円から、Microsoft 365 Basicは月額約450円から、Zoho Mailの有料プランは月額約120円からの設定がある。無料プランやトライアルも用意されている。詳細は各社の公式料金ページを参照。

この方法は、会社の全員に同じドメインのメールアドレスを割り当てたいときに適している。カレンダー、ドキュメント、クラウドストレージとの連携も強い。1人で使うには少し高い。5人以上的なチームなら、コストが割りやすい。

方法2:メール転送サービスで今の受信箱に届ける

KaiMail、Forward Email、Cloudflare Email Routingなどのサービスは、独自ドメイン宛てのメールを、既存のGmailやOutlookの受信箱に転送する。新しい受信箱は増えない。Gmailの受信箱に、[email protected]宛てのメールが届くのだ。Gmailの使い方は変わらない。

自分のテストでは、KaiMailにドメインを追加してから7分後に最初のメールが届いた。手順は後述する。

この方法は、Gmailを使い続けたい個人事業主やフリーランスに向いている。複数のドメインを持っていても、すべてのメールを1つの受信箱に集められる。受信箱が増えないのは、整理の手間を減らす意味でも大きい。

方法3:レンタルサーバー付属のメールを使う

日本の検索上位の記事が最初に勧める方法が、レンタルサーバー付属のメールだ。ホームページも同じサーバーで運営するなら、管理画面が1つですむのは便利だ。メールボックスの数や容量は、サーバープランに応じて決まる。

ただし、サーバーと一体なので、解約するとメールも使えなくなる。自分の経験では、サーバー会社を乗り換えるときに、メールの移行で2日間メールを受け取れなかったことがある。容量や機能の制限は、サーバー会社ごとに違う。Webメールの使い勝手や、スマートフォンからの接続のしやすさも、会社ごとに差がある。

すでにレンタルサーバーを契約している読者も多いだろう。その場合に転送サービスを使う理由はいくつかある。Gmailで一元管理したい。複数ドメインを持っていて、どのドメインのメールも1つの受信箱に集めたい。サーバーを乗り換える予定があり、メールだけは移動させたくない。自分はこの最後の理由で、初めてメール転送サービスを使った。

自分に合う方法の選び方

比較表を見てから、タイプ別に選ぶ。

項目 Google Workspaceなど メール転送サービス レンタルサーバー付属
料金の形 ユーザーごとの月額課金 無料または低額 サーバー代に含まれる
新しい受信箱 ある ない(既存の受信箱に届く) ある
送信できるか できる SMTPまたは送信機能でできる できる
設定の手間 中程度 少ない 中程度
乗り換えやすさ 中程度 高い(MXレコードを変えるだけ) 低い(サーバー移行が必要)

料金は2026年10月6日時点。

個人事業主やフリーランスで、Gmailをそのまま使いたいなら、メール転送サービスが手軽だ。新しいアプリを覚える必要がない。会社の全員に同じドメインのメールボックスを作りたいなら、Google WorkspaceやMicrosoft 365が向いている。カレンダー予約の調整や、ドキュメントの共有も同一アカウント内で完結する。すでにレンタルサーバーを契約していて、ホームページもメールも同じところで済ませたいなら、付属のメールを使えばよい。管理画面が1つで済むのは、確かに楽だ。メール転送サービスを並べて比較する

メール転送サービスで独自ドメインのアドレスを作る手順

自分のテストを実例として書く。2026年10月6日14時32分、KaiMailのダッシュボードにテスト用ドメイン kaimailtest.jp を追加した。14時39分、テストメールがGmailの受信箱に届いた。計7分だった。

この手順は、KaiMailの無料プランで試せる。ドメイン1つ、メールボックス1つ、月300通の受信、1通あたり1MBまで無料だ。Webhookや複数転送先、SMTP送信が必要なら有料プランに移行する。有料プランの詳細は料金ページを参照。

手順1:転送サービスにドメインを追加する

KaiMailのダッシュボードを開いて、「ドメインを追加」を選ぶ。ドメイン名を入力すると、他の人がすでに登録していないかを確認したうえで、自分のアカウントにドメインが追加される。手順はこれだけだ。

所有権を確認するTXTレコードは要らない。MXレコードをKaiMailに向けること自体が、ドメインの持ち主であることの証明になる。DNSを変更できるのは、そのドメインの持ち主だけだからだ。次の手順2で、そのMXレコードを設定する。

手順2:MXレコードを転送サービスに向ける

MXレコードは、「このドメイン宛てのメールを、どのサーバーに届ければよいか」を教えるDNSレコードだ。インターネット上のメールサーバーは、メールを送る前に、受信側のMXレコードを調べる。MXレコードの値が、メールを受け付けるサーバーのアドレスと優先順位を示す。

MXレコードの値を、KaiMailが提供するサーバーのアドレスに変更する。古いMXレコードが残っている場合は、先に削除する。複数のMXレコードが混在すると、メールが以前のサーバーに届いてしまう。

KaiMailのMXレコードの値は、ダッシュボードに表示される。以下は例だ。

レコード名: mcpnavi.jp
レコードタイプ: MX
優先度: 10
値: mail.kaimail.net

これをDNS管理画面のMXレコード欄に貼り付ける。TTL(Time To Live)は、DNSの変更が世界中に伝わるまでの時間だ。通常は300秒(5分)から3600秒(1時間)に設定する。自分のテストでは、CloudflareのTTLを300秒に設定した。変更が完全に反映されるまで、通常5分から数時間かかる。自分の場合は5分で反映された。KaiMail のMXレコードの正確な値を確認する

以下のスクリーンショットは、 MX のDNS設定正しく設定されていることを示す

KaiMail Email Domain and MX Record Configuration

手順3:SPFとDKIMを設定して、なりすましと判定されないようにする

SPF(Sender Policy Framework、RFC 7208(英語))とDKIM(DomainKeys Identified Mail、RFC 6376(英語))は、メールの送信元が本物であることを受信側に伝える仕組みだ。両方ともTXTレコードとしてDNSに登録する。

SPFは、どのサーバーからメールが来てもよいかを示す。SPFのレコードがないと、受信側は「このメールは本当にこのドメインから来たのか」と疑う。SPFのレコードがあると、受信側はリストに載ったサーバーから来たメールを信頼できると判断する。SPFだけでは不十分だ。なぜなら、送信サーバーのIPアドレスを偽装する手法もあるからだ。SPFはあくまで「リストに載っているサーバーなら信頼できる」という最低限の確認に過ぎない。

DKIMは、暗号署名をメールヘッダーに付ける。送信サーバーが秘密鍵で署名し、受信側が公開鍵で検証する。メールの内容が転送の途中で改ざんされていないことを証明できる。DKIMの署名は、本文とヘッダーの両方に紐づいている。途中で1文字でも改ざんされると、検証がfailになる。DKIMがあると、スパムフィルターは「このメールは本物のドメインから来て、内容も改ざんされていない」と判断する。

KaiMailのダッシュボードから、SPF用とDKIM用のTXTレコードをコピーする。DNS管理画面に貼り付ける。

SPFの例:

レコード名: mcpnavi.jp
レコードタイプ: TXT
値: v=spf1 include:mail.kaimail.net ~all

~all は、「リストにないサーバーから来たメールは怪しいが、即座に拒否するな」という意味だ。-all にすると即座に拒否になる。多くの場合は ~all から始める。

すでにSPFレコードを公開している場合は、KaiMailの include を既存のレコードに統合する。2つ目のSPFレコードを作らない。受信サーバーが混乱する。

DKIMの例:

レコード名: kaimail._domainkey.mcpnavi.jp
レコードタイプ: TXT
値: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

DKIMの公開鍵は長い。Route 53などのDNSサービスでは、値が255文字を超えると「CharacterStringTooLong」エラーになる。対処法は別の記事で詳しく書いた。

DNSの変更が反映されるまで、通常5分から数時間かかる。SPFとDKIMの反映を確認するには、dig TXT ドメイン名 と dig TXT kaimail._domainkey.ドメイン名 を実行する。

以下のスクリーンショットは、SPFとDKIMのDNSレコードに必要なコードを示してる。ドメインのダッシュボードから入手可能

KaiMail SPF and DKIM Email Record Configuration

手順4:アドレスを作り、転送先を決める

MXレコードの設定が済んだら、アドレスを作成する。たとえば [email protected] を作る。転送先として、自分のGmailアドレスを指定する。

KaiMailの無料プランでは、メールボックス1つまでだ。有料プランでは、複数のアドレスを作って、それぞれ別の転送先に届けられる。

手順5:テストメールを送り、ヘッダーを確認する

別のメールアドレスから、作成した独自ドメインのアドレスにテストメールを送る。自分のテストでは、14時39分にGmailの受信箱に届いた。件名は「テストメール」、本文は「SPFとDKIMの検証テスト」だけの短いメールだ。

Gmailで元のヘッダーを確認するには、メールを開いて右上の「⋮」を選び、「元のメールを表示」をクリックする。ヘッダーの塊が表示される。

ヘッダーの中で、次の行を探す。

Received-SPF: pass

これはSPFの検証が通ったことを示す。failになっていると、送信元サーバーがSPFのリストに載っていないか、MXレコードが正しく設定されていない。

DKIM-Signature: v=1; ...

これはDKIMの署名が付いていることを示す。

ARC-Seal: i=1; a=rsa-sha256; ...

これはARC(Authenticated Received Chain、RFC 8617(英語))の署名だ。転送されたメールの信頼性を保つ仕組みである。ARCについては別の記事で詳しく書いた。

自分のテストでは、3つすべてにpassと表示された。SPFはpass、DKIMはpass、ARCはpass。これで、自分のドメイン宛てのメールが、受信側に信頼される形で届くことが確認できた。

KaiMail の無料アカウントを作ってドメインを追加する

独自ドメインのアドレスから送信する

受信だけでなく、送信も独自ドメインのアドレスから行いたい場合がある。相手に返信するとき、from欄が自分のドメインのアドレスになっていれば、統一感が出る。

Gmailの「他のアドレスからメールを送信」で返信する

Gmailの設定を開いて、「アカウントとインポート」タブを選ぶ。「他のアドレスからメールを送信」を追加する。

SMTPサーバーとして mail.kaimail.net を指定する。ポートは587番だ。認証方式は通常のパスワード認証を選ぶ。認証情報はKaiMailで発行したSMTP用のパスワードを使う。このパスワードは、KaiMailのダッシュボードの「SMTP設定」欄から取得できる。パスワードは「アプリパスワード」の形で発行される。これはGmailの通常のパスワードとは別のものだ。

Gmailから確認用のメールが届く。そのメール内の確認リンクをクリックすると、設定が完了する。自分のテストでは、この設定後、Gmailの「差出人」欄から独自ドメインのアドレスを選んで送信できた。Gmailのインターフェースは変わらない。送信元アドレスだけが変わる。

ただし、この方法には期限がある。Googleはこの機能を終了する。2027年1月から、Gmailのウェブ版とモバイルアプリでは、外部ドメインのアドレスから送信できなくなる。2026年後半には、新規の設定が制限される。Googleの案内はサードパーティ製メールアカウントのサポート変更についてのGmail ヘルプにある。期限のあとも送信を続けたいなら、次の節で説明するSMTP設定をメールソフトに入れて送信するのが確実だ。独自ドメインのアドレスから送信する設定を詳しく見る

メールソフトからSMTP認証で送信する

Gmail以外のメールソフト(ThunderbirdやApple Mailなど)でも、同じSMTP設定で送信できる。サーバーアドレスは mail.kaimail.net、ポートは587番、暗号化はSTARTTLSを選ぶ。認証方式は通常のパスワード認証だ。Thunderbirdの場合は、設定画面の「送信(SMTP)サーバー」欄にこれらの値を入力する。

以下のスクリーンショットは、SMTP送信用の認証情報を入手できるダッシュボードの一例

KaiMail SMTP Configuration Credentials

独自ドメインのメールを迷惑メールにしないために

転送されたメールは、SPFの検証に失敗しやすい。SPFは「どのIPアドレスからメールが来てもよいか」をチェックする。しかし、転送の途中で通過するサーバーのIPアドレスが、SPFに登録されたIPアドレスと異なる。だから、転送されたメールはSPFでfailになりがちだ。自分のテストでも、SPFの検証結果は通ったが、これはKaiMailの転送サーバーがSPFのリストに含まれているためだ。転送サービスによっては、このリストに含まれていない場合もある。

この問題を緩和するのが、DKIMとARCだ。DKIMの署名はメールの本文に紐づいている。転送されても署名が壊れなければ、受信側は「内容は改ざんされていない」と判断する。ARCは、転送の経路ごとに信頼性を引き継ぐ仕組みだ。転送サーバーがARCに対応していれば、元の認証結果を次のサーバーに伝えられる。Googleの「メール送信者のガイドライン」では、SPFとDKIMの設定を推奨している(日本語)。

ただし、すべての転送が迷惑メールになるわけではない。自分のテストでは、Gmailの受信箱に普通に届いた。設定が正確にできていれば、多くの場合は問題ない。ARCの詳細は別の記事で書いたので、繰り返さない。転送メールが迷惑メールに入る理由と、ARCによる解決策を読む

よくあるつまずきと対処法

4つのつまずきを挙げる。

MXレコードの変更がまだ反映されていない。 DNSの変更は、TTLの値に応じて時間がかかる。ターミナルで dig MX ドメイン名 を実行して、正しい値が返ってくることを確認する。KaiMailのダッシュボードでも確認できる。ドメインの詳細ページを開いて「MX確認」を押す。「MXレコードは正しく設定されています」と表示されれば、設定は完了だ。正しい値が返らないうちは、メールサーバー側も新しい設定を認識していない。

以前のサーバーのMXレコードが残っている。 レンタルサーバーを解約しても、MXレコードが自動で消えるとは限らない。DNS管理画面で、古いMXレコードを先に削除する。複数のMXレコードが混在すると、メールが以前のサーバーに届く。自分はこれで1回、メールを1日間受け取れなかったことがある。

Route 53で長いDKIMキーが「CharacterStringTooLong」エラーになる。 DKIMの公開鍵は長いTXTレコードになる。Route 53では、値が255文字を超えると「CharacterStringTooLong」エラーになる。対処法は、値を255文字ごとにダブルクォートで区切ることだ。正確な手順は別の記事に書いた。Route 53 でDKIMレコードが長すぎるエラーを直す

Cloudflareでメール用レコードを設定するときの注意。 Cloudflareはプロキシ機能(オレンジ色の雲アイコン)をデフォルトで有効にする。しかし、メール用のMXレコードやTXTレコードはプロキシを通すべきではない。プロキシを通すと、メールサーバーがCloudflareのエッジサーバーに届いてしまう。灰色の雲アイコンに切り替える。自分はこれを2回ほど見落としたことがある。

よくある質問

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

KaiMailの無料プランでは、ドメイン1つ、メールボックス1つ、月300通の受信、1通あたり1MBまで無料で使える。個人事業主の問い合わせ用には十分な容量だ。有料プランではWebhook、複数転送先、SMTP送信などが使える。無料ビジネスメールについては別の記事も参照。詳細はKaiMailの料金ページを参照。

GmailやOutlookをそのまま使い続けられる?

メール転送サービスを使えば、GmailやOutlookの受信箱にそのまま届く。新しいメールソフトを学ぶ必要はない。Gmailのフィルタ機能を使えば、独自ドメイン宛てのメールをラベルで分類できる。

レンタルサーバーを契約しないと独自ドメインのメールは使えない?

いいえ。レンタルサーバーは3つの方法の1つに過ぎない。メール転送サービスなら、サーバーを持たなくても独自ドメインのメールが使える。自分はサーバーを持たない状態で、3つのドメインのメールを転送サービスで運用している。

今のメールアドレスに届くメールはどうなる?

今のアドレスに影響はない。独自ドメインのアドレスは、別のアドレスとして追加される。Gmailなら、複数のアドレスを1つの受信箱で管理できる。今のメールは今のまま届き続ける。