独自ドメインのメール転送：設定ガイド（2026）

ドメインを購入し、hello@yourdomain.com を Gmail で受け取りたい。別の受信箱を管理したくないだけです。独自ドメインのメール転送は五分の作業に見えても、未着や迷惑メールが起こる場合があります。転送が送信経路を変え、受信者を守る認証に影響することがあるためです。

このガイドは 2026 年の設定手順、考えられる DNS の誤り、結果の確認を説明します。SRS と ARC の詳細はメール転送の設定と問題解決ガイドを参照してください。

独自ドメインのメール転送の仕組み

転送はドメイン宛てのメールを Gmail や Outlook など既存のメールボックスへ送ります。業者が中継として受け取り、再送します。永続的なローカルメールボックスは必須でなくても、キューや一時保存が必要な場合があり、即時の転送は保証されません。

主に二つの構成があります。機能、費用、運用条件に合わせて選びます。

業者側の経路設定：MTA 転送

業者のメールサーバーが受信して転送し、必要に応じてフィルターや一時保存を行います。2026 年にも使われるこの構成は、TrekMail の説明にもあります。別のメールボックス、保存費用、数百の別名の利用可否は、現行プランの権限と上限によります。

メールボックスのルールによる転送

Google Workspace や Microsoft 365 の既存メールボックスから転送できます。過去の価格例はユーザー当たり月 $6 から $30 ですが、現在のライセンスと費用は条件によります。ライセンス失効や外部転送方針が影響し得ます。メールボックスや追加フィルターを別の用途でも必要とする場合は、この方法も適しています。

独自ドメインの転送設定を順に行う

設定は四段階です。その後、実際の DNS 応答とキャッシュを確認します。15 分は計画の一例にすぎず、全世界の更新に必要な固定時間ではありません。

手順 1：ドメインの管理権限を確認する

業者はドメインを管理する権限の確認を求めます。例えば次の TXT レコードを使います。

trekmail-verify=abc123def456

これは DNS の制御を示しますが、法的所有権を自動的に証明するものではありません。実際に発行された値を使い、削除前に再確認の必要性を調べてください。

手順 2：MX レコードを設定する

MX はドメインの受信サーバーを指定します。すべての宛先が承認され、調整された受信構成に合う必要があります。調整した環境では複数業者も利用可能です。優先度、代替経路、メールボックスの存在を確認し、切り替え前に旧 MX を一律削除せず、旧業者の経路を計画的に廃止します。

@ MX 10 mx1.trekmail.net
@ MX 20 mx2.trekmail.net

手順 3：転送経路を作る

管理画面で元のアドレスを確認済みの宛先へ対応付けます。

info@yourdomain.com → yourname@gmail.com

ドメインメールを Gmail へ転送する場合も基本は同じです。独立した送信者でも試験してください。宛先 Gmail から転送経路を通って自分へ戻す試験は、表示や重複処理の影響で分かりにくく、唯一の検証には適しません。

手順 4：必要な SPF を確認する

SPF レコードは、実際に確認されるエンベロープ識別子の送信を認めます。自社ドメインの SPF だけで第三者の元の送信者としての転送を認めることにはなりません。MAIL FROM、SRS 書き換え、業者の現行文書の値を確認します。

v=spf1 include:_spf.trekmail.net ~all

例を未確認で貼らないでください。対象識別子について、すべての正当な送信者を含む一つに統合した SPF を維持します。欠落や誤りは評価に影響し得ますが、必ず迷惑メールや拒否になるわけではありません。

転送に影響し得る 5 つの DNS の誤り

次の五項目は確認の出発点になります。DNS、経路、ヘッダー、ログから実際の原因を特定してください。

1. 調整されていない混在 MX

ASPMX.L.GOOGLE.COM など旧宛先を新 MX と残すと、意図しない代替経路が生じ得ます。選択は優先度と到達性によるもので、必ずしも無作為ではありません。宛先にメールボックスや経路がなければ失敗する場合があります。対処：記録され承認された受信先だけを残し、調整して切り替えます。

2. 欠落または誤った SPF

転送は送信 IP を変えるため、受信ドメインだけでなく実際のエンベロープドメインの SPF を確認します。softfail は評価に影響し得ますが、Gmail の表示や迷惑メールへの分類だけでは、その原因や自社 DNS の誤りを証明できません。

3. ドメイン頂点の CNAME

通常の CNAME をゾーン頂点（@）で必要な他のデータと共存させることはできません。RFC 1034を参照し、適切なサイト用レコードと MX を使います。ALIAS や CNAME-flattening は別途確認し、通常の頂点 CNAME の公開と同一視しないでください。

4. 残されたローカル配送設定

Bluehost や GoDaddy など共用ホストから移行しても、cPanel の“Local Mail Exchanger”が当該サーバー内で生成されたメールをローカルへ配送する場合があります。外部送信者の MX 照会前に自動的に横取りするわけではありません。ローカル経路と外部 MX を分けて確認し、旧サーバーからの試験と外部試験の違いを調べます。

5. Catch-all の競合

info@ の専用ルールと *@ の catch-all には明確な優先度と宛先が必要です。誤った戻り経路は 5.4.6 や 554 5.4.14 hop count exceeded のループを起こし得ます。別名と catch-all の実際の経路を調べ、迷惑メールの増加にも備えます。

検証計画：動くと決めつけない

設定後は三段階で試します。エラーがないだけでは正しい配信とは言えません。

段階 1：外部送信者の試験

Yahoo、Proton、知人のアドレスなど独立した第三者から送ります。宛先 Gmail から自分へ戻す試験は表示や重複処理の影響で判断しにくく、それだけでは未着を証明しません。

段階 2：返信先の試験

届いたメールで返信を押します。宛先は正当な Reply-To、なければ元の送信者になるはずです。info@yourdomain.com が出る場合は元と転送後のヘッダーを比較します。意図的な別の Reply-To は正当な場合もあり、必ず業者の誤りとは限りません。

段階 3：ヘッダーの確認

生のメッセージを開き、信頼できる Authentication-Results を確認します。

Authentication-Results: mx.google.com;
  dkim=pass header.i=@original-sender.com;
  spf=pass (domain of SRS0=... designates ... as permitted sender)

SRS0 はSender Rewriting Schemeの手掛かりですが、完全に正しい構成の証明ではありません。spf=softfail や dmarc=fail があれば、対象識別子、署名、整合、経路を確認します。必ず受信ドメインの DNS を直す必要があるわけではありません。

転送が失敗し得る理由と対処

典型的な症状を知ると調査しやすくなります。複数の設定を推測で変える前に、実際の原因を確かめます。

DMARC の両方式が失敗する場合

確認シナリオ #1：p=reject の送信者からのメールで、転送者 IP が SPF を失敗させる場合があります。さらに署名された件名や本文を中継が変えると、DKIM も無効になり得ます。From と整合して成功する SPF または DKIM がなければ DMARC は失敗します。拒否や他の処理は受信側により、不達通知が見えないとは限りません。

Microsoft 365 の送信禁止（5.7.520）

M365 からの転送では、方針が 550 5.7.520 Access denied, your organization does not allow external forwarding を返す場合があります。権限のある管理者が送信スパム対策方針と承認された限定的な例外を確認します。テナント全体で不用意に有効化しないでください。

不在時の自動応答ループ

ユーザー A が B に転送し、B の自動応答が戻り経路で次の応答を起こす場合があります。制御不足では数分に数千のメールが発生し得ます。X-Auto-Response-Suppress は一部のシステムで使われますが、共通の保証ではありません。経路とループ抑制を確認します。

転送における SRS と ARC

SRS と ARC は 2026 年の転送処理を助けますが、配信を保証しません。保持され整合した DKIM は、これらがなくても DMARC を成功させ得ます。

SRS：Sender Rewriting Scheme

SRS はエンベロープ送信者を書き換えます。例えば alice@bank.com が SRS0=hash=timestamp=bank.com=alice@forwarder.com になります。SPF は書き換え先のドメインを確認し、正しい送信認可があれば成功し得ます。不達通知には適切な逆変換が必要で、Alice への到着は自動的に保証されません。

ARC：Authenticated Received Chain

SRS は新しい識別子の SPF を助けますが、元のDMARC の整合を自動で戻しません。ARC は以前の認証結果と処理チェーンに署名します。Google や Microsoft など受信者は検証後、自らの信頼に応じて採用を判断します。RFC 8617はこのチェーンを定め、一般的な配信や DMARC 成功を約束するものではありません。

Catch-all のリスク

*@yourdomain.com の catch-all と転送を組み合わせると、任意のアドレスへの迷惑メールも Gmail や Outlook に送られ得ます。自社の共有送信資源やドメイン評価に影響する場合があります。ブロックリストや正当なメールの未着はリスクであり、必然ではありません。

必要なら転送前のフィルター、用途、容量を確認します。TrekMail は MX レベルの評価確認を説明しますが、現行実装と効果を調べてください。すべての迷惑メールを防ぐ保証はありません。

完全なメールボックスを検討するとき

転送は受信経路を整えますが、すべてのメールボックス機能を置き換えません。次の場合はホストされたメールボックスを検討します。

• 独自ドメインで送信したい。Gmail の“Send As”は適切な設定で使える場合があり、SMTP 認証、送信権限、現行条件を確認します。
• 例えば一日 500 メールを超える。これは評価の例であり、Gmail や Outlook の共通上限ではありません。実際の制限、資源、直接配信を調べます。
• プライバシーや規制への対応が必要。HIPAA や GDPR ではデータ経路、契約、保護策を評価します。処理段階が増えるだけで自動的に違反になるわけではありません。

例えば業務の 90% が既存受信箱への配信なら、転送で足りる場合があります。10 のメールボックスライセンスがなくても、info@、support@、billing@ を一つの Gmail へ送れる場合があります。実際の機能とライセンスを確認します。

TrekMail：独自ドメイン向けの転送

手作業では MX、SPF、必要な SRS 設定、不達コードを管理します。ドメインが多いほど整理された確認手順が重要です。

TrekMail は SRS、ARC、SPF/DKIM/DMARC の設定支援、catch-all フィルター、多ドメイン画面を説明しています。現行機能と必要な設定を確認します。一ドメインと千ドメインが必ず同額とは限らず、次は過去のプラン例です。

• Free Plan：月 $0、10 ドメイン、5GB、自前 SMTP。
• Starter：月 $3.50、50 ドメイン、15GB。
• Pro：月 $10、100 ドメイン、50GB。
• Agency：月 $23.25、1,000+ ドメイン、200GB+。

Nano は無料で試用やカード不要と説明されています。現行の利用資格と、送信や返信に必要な自前 SMTP の費用を確認します。有料プラン例は 14 日試用で、現行料金、上限、カード要件、対象機能、提供を確認してください。TrekMail を確認し、現在の条件と自社の用途を比較しましょう。

結論：独自ドメインの転送を慎重に設定する

転送は動き続ける経路であり、放置できるチェック項目ではありません。調整済み MX、実際の送信識別子の SPF、DKIM、SRS/ARC の対応、独立した外部試験、信頼できるヘッダーを確認します。

上の五つの DNS 項目は出発点ですが、すべての原因を説明しません。TrekMail は管理の一部を助け得ます。無条件の配信を前提にせず、結果と変更を確かめてください。