独自ドメインのメールを Gmail に転送する方法

contact@yourdomain.com のメールを Gmail に転送するよう設定しました。顧客が契約書を、銀行がセキュリティ通知を送ってきますが、どちらも見当たりません。

迷惑メールを確認してもありません。自分のアカウントには記録、エラー、通知が見えないという状況です。ただし、元の送信者にも通知がなかったとは限りません。

これは Gmail の使い勝手ではなく、認証上の問題かもしれません。独自ドメインのメールを Gmail に転送すると、別のドメインから届いたメールを自社サーバーの IP で送り直します。エンベロープ送信者を保持した場合、Gmail は元のドメインの SPF を確認し、そのドメインは自社 IP を許可していないことがあります。SPF が失敗し、有効で整合した DKIM もなければ、厳格な DMARC（p=reject）により 550-5.7.26 で拒否される場合があります。SMTP の拒否は元の送信者にエラー通知を返すことがあり、自分に通知がないからといって、両者に通知せず永久に削除されたとは限りません。

リスクを減らすため、SRS（Sender Rewriting Scheme）によるエンベロープ送信者の書き換えと、ARC（Authenticated Received Chain）による過去の認証結果の記録を検討します。両者は補完的な仕組みですが、配送を保証しません。元の有効な DKIM がドメイン整合を満たせば、それだけで DMARC が成功する場合もあります。

このガイドは SRS、ループ防止、Gmail の送信元設定を扱います。転送時の SPF、DKIM、DMARC と SRS の内部動作は、メール転送の設定とトラブル対処の完全ガイドをご覧ください。

Gmail が転送メールを拒否する場合がある理由

転送では、元のドメインが自社サーバーの IP を許可していないため SPF が失敗する場合があります。SRS は転送元のドメインで SPF を確認できるようにしますが、そのドメインでサーバーを許可する必要があります。SRS 単独では DMARC のドメイン整合は復元されず、DKIM、ARC、受信側の方針も重要です。

client@bank.com のメールが you@gmail.com に転送される場合の障害例です。

1. bank.com が転送サーバーに配送する
2. 自社サーバーが Gmail に再送する
3. Gmail がエンベロープ送信者 client@bank.com の SPF を確認する
4. bank.com の SPF は自社 IP を許可していない → この例では SPF FAIL
5. DMARC が p=reject で整合した認証も成功しない → Gmail が 550-5.7.26 を返す場合がある
6. メールは届かない。自分に通知がなくても、元の送信者にはエラー通知が届く可能性がある。

署名対象の本文や件名などを変更しなければ、転送後も DKIM が有効なまま残る場合があります。ウイルス対策のフッター追加や件名の書き換えは避けます。有効で整合した DKIM により、SPF が失敗しても DMARC は成功できます。aspf=s は SPF の整合条件のみを指定し、DKIM の整合には影響しません。署名対象部分の変更は DKIM を無効にする場合があります。SRS は SPF の対策ですが、DMARC や配送の保証ではありません。

Gmail に転送する三つの構成

すべての転送設定が同じリスクを持つわけではありません。用途に合う構成を選びます。

キャッチオールは配送の評判を悪化させる場合があります。迷惑メール送信者は abc123@yourdomain.com、junk@yourdomain.com などの宛先を試します。サーバーが受信すると、フィルターを通過した迷惑メールも転送されます。説明用の例で 90% が迷惑メールなら、IP の評判が悪化し、正当なメールも迷惑メール扱いされるおそれがあります。これは Gmail の公式なしきい値でも自動ブロック条件でもありません。回復には数週間かかることもありますが、期間は一定ではありません。

エイリアスとメールボックスの使い分けは、メールエイリアス転送の利点とリスクをご覧ください。新しいアドレスの選択には、独自ドメインのエイリアスとメールボックスの比較が役立ちます。

SRS が Gmail 転送で重要な理由

SRS（Sender Rewriting Scheme）は、エンベロープ送信者を元のドメインから転送元のドメインに書き換え、SPF の問題を軽減します。このアドレスは Return-Path に記録され、エラー通知に使われます。Gmail は転送元のドメインで SPF を確認できますが、正しい IP 許可が必要で、DMARC や配送は保証されません。

SRS なし（障害例）：
エンベロープ送信者：client@bank.com
送信 IP：203.0.113.10（自社の転送サーバー）
SPF：bank.com のレコード → FAIL（203.0.113.10 は未許可）
DMARC：整合した DKIM がなければ FAIL の可能性（p=reject）→ 拒否と、送信者への通知の可能性

SRS あり（SPF の対策）：
エンベロープ送信者：SRS0=HASH=TT=bank.com=client@yourdomain.com
送信 IP：203.0.113.10（自社の転送サーバー）
SPF：yourdomain.com のレコード → この例では PASS（203.0.113.10 は許可済み）
ヘッダーの差出人：client@bank.com（変更なし。元の送信者を表示）

SRS に使うドメインの SPF レコードは、転送サーバーの IP を直接または適切な仕組みで許可する必要があります。許可がなければ SRS 後も SPF は失敗する場合があります。ホスト名を単に記載するだけでは、有効な SPF 設定になるとは限りません。

転送基盤は ARC（Authenticated Received Chain） ヘッダーも追加できます。ARC は各段階で観測した認証結果を署名付きの連鎖として残します。受信側は転送元への信頼を含めて評価します。正しい ARC 署名と公開鍵が必要ですが、通常の DKIM 署名と同じものではなく、DMARC 整合も変更しません。管理型サービスでは事業者の対応を確認します。

SPF は RFC 7208 で定義されます。複数段階の認証結果を記録する ARC は RFC 8617 で定義されます。

ループ防止：利用開始前の四つの確認

転送ループは 5.4.14 Hop count exceeded などのエラーを生み、正当なメールの配送を妨げる場合があります。本番利用前に次の四項目を確認します。

1. 循環する配送経路がない。you@gmail.com のフィルターが you@yourdomain.com に戻し、さらに Gmail に転送される経路を作っていないか確認します。これはループの原因になります。
2. 自動応答を管理する。業務アドレス（team@domain.com → 複数の Gmail）では、自動応答の停止やサーバーの防止策を検討します。Precedence: bulk を考慮するシステムもありますが、普遍的なループ防止策ではありません。
3. 第三のアカウントから試す。Gmail は重複を排除する場合があります。転送先アカウントからエイリアスへ送るテストは、送信済みにあっても受信箱には見えない場合があります。Yahoo や Outlook など外部アカウントで独立したテストを行います。
4. M365 の送信ポリシーを確認する。転送元が Microsoft 365 なら、権限を持つ管理者が送信スパム対策ポリシーを確認し、承認された場合のみ自動転送を許可します。テナントがブロックしていると 550 5.7.520 が出る場合があります。安全方針を回避しないでください。

初めて Gmail 転送を設定するときによくある問題です。エラー文だけで原因が分かるとは限りません。

TrekMail で独自ドメインのメールを Gmail に転送する

原文では、TrekMail が転送メールに MTA レベルの SRS 書き換えと ARC 署名を適用し、利用者は宛先を設定すると説明しています。現在の対応と文書を確認してください。自動処理でも Gmail の受信は保証されません。

説明される版では、メールボックス転送は Pro と Agency プランにあり、Free と Starter ではこの機能のためにアップグレードが必要です。現在の名称と条件を確認してください。記載される手順は TrekMail のメールボックス転送文書にあります。

1. ダッシュボードでメールボックスを開く
2. 対象のメールボックスで管理を選ぶ
3. 転送を有効化をオンにする
4. 転送先に Gmail アドレスを入力する
5. 初期設定時はコピーを保持をオンにする
6. 転送設定を保存を選ぶ

「コピーを保持」は重要です。説明される動作では、容量とローカル配送が正常であればメールボックスに保存しつつ Gmail への転送を試みます。外部配送やバックアップを保証するものではありません。オフの場合、Gmail に拒否されたメールがローカルに残らない可能性があり、キューやエラー処理にも左右されます。テスト中はオンにし、保存容量と保持方針を確認してください。

原文では、複数のメールボックスを選択し、一括操作で共通の転送先を設定する機能も説明しています。百のドメインに適用する場合も、現在の提供状況、権限、制限を確認し、宛先を検証してから変更してください。

返信も整える：Gmail の送信元設定

転送は受信を扱います。送信元を設定しなければ、返信が独自ドメインではなく個人の @gmail.com から出ることがあります。顧客は ceo@yourdomain.com ではなく Gmail を目にします。

許可された外部 SMTP 認証情報で送信元を設定する方法を検討します。送信経路と「エイリアスとして扱います」の選択を確認してください。このチェックボックスだけで送信サーバーは決まりません。認証が不適切な経路では「via gmail.com」表示や DMARC の問題が生じる場合があります。

現在の Gmail の画面に合わせ、設定 → アカウントとインポート → 名前 → 他のメールアドレスを追加を開きます。「エイリアスとして扱います」は構成に応じて選び、オフが常に必須とは考えないでください。

原文の TrekMail SMTP 設定（Starter、Pro、Agency）：

SMTP Server:  smtp.trekmail.net
Port:         587
Security:     TLS (STARTTLS)
Username:     your-mailbox@yourdomain.com
Password:     Your mailbox password

原文の Nano：自分で用意する SMTP（SES、SendGrid、Mailgun など）：

SMTP Server:  email-smtp.us-east-1.amazonaws.com  (Amazon SES example)
Port:         587
Security:     TLS
Username:     Your SMTP credentials from your provider

SMTP のコードブロックは例です。現在の接続情報と認証情報を各事業者に確認してください。説明される手順では、追加後に Gmail が確認コードをメールボックスへ送ります。コードで確認し、既定の差出人と返信時の動作を設定します。業務用アドレスが実際に表示されるかテストしてください。

動作確認：Gmail の認証ヘッダーを読む

外部アカウントからテストメールを受信したら、本番で信頼する前に元のヘッダーを確認します。

Gmail ではメッセージを開く → 三点メニュー → メッセージのソースを表示を選び、Authentication-Results を探します。

以下は検証成功を示す説明用サンプルですが、DKIM のドメインは転送元です。元の From: との整合や DMARC の成功、将来の受信はこれだけでは証明されません。

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of SRS0=hash=tt=bank.com=client@yourdomain.com
    designates 203.0.113.10 as permitted sender)
    smtp.mailfrom=SRS0=hash=tt=bank.com=client@yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  arc=pass (i=1 spf=pass dkim=pass)

spf=softfail や spf=fail なら、書き換え後の送信者、IP、SPF、DNS 応答を確認し、キャッシュと TTL も考慮します。arc=fail は署名後の変更のほか、鍵、署名、チェーンの不備でも起こります。エンベロープ送信者の扱いは、Google の Gmail 転送に関する公式案内を参照してください。SRS は関連する仕組みの一つです。

自主管理と管理型サービス：実際の違い

自主管理の Postfix では、postsrsd の導入、srs_secret の保護と管理、ローテーション計画、正しい ARC 鍵での OpenARC 連携、利用可能な Google Postmaster Tools での評判確認などが必要になります。更新、誤った鍵交換、新しい送信者ポリシーで対応が必要になることがあり、夜 11 時に認証ヘッダーを調べることになるかもしれません。

原文の TrekMail モデルでは、宛先設定後に MTA が SRS と ARC を処理します。それでも現在の対応、DNS 認証、配送結果は確認してください。管理型サービスもすべての運用確認を不要にはしません。

始めるには

原文の Nano はカードなしでドメインを接続する選択肢であり、転送込みのプランではありません。ドメインを準備し、DNS 検証を待つことから始められます。記載される転送機能と管理型 SRS は Pro で、$10/月からの定額、制限内でユーザー料金なしと説明されています。現在の提供状況と条件を確認してください。

原文では、有料プランにカードが必要な 14 日間の無料トライアルがあります。カード不要の Nano を含む現在の条件は、trekmail.net/pricing で確認してください。

確認する四要素は、SRS の書き換え、ARC の結果記録、転送 IP の SPF 許可、返信用の送信元設定です。これらが配送を保証するわけではありません。整合した DKIM、受信側ポリシー、ローカル保存、ログも確認します。誤設定で受信者が気付けない配送失敗が起こることはありますが、常に両者へ通知がないわけではありません。

丁寧に設定し、ヘッダーを検証し、継続して確認しましょう。