メール送信にサブドメインを使用すべき理由

June 1, 2026 by メーラートゥゴー

送信サブドメインを使用するとメールが別のドメインから送信されているように見えるのではないかと心配ですか?そうではありません — 受信者には依然としてルートドメインが表示され、配信可能性が向上します。その理由と mtg.yourdomain.com のセットアップ方法をご紹介します。

トランザクショナルメールは mtg.yourdomain.com のようなサブドメインから送信します。ルートドメインからではなく、既にCNAMEであるホスト名からでもありません。小さなDNS変更ですが、配信性を大幅に向上させます。

「メールが別のドメインから送られているように見えるのでは？」

誰もが最初に心配することなので、あらかじめ解決しておきましょう。いいえ、見えません。 送信にサブドメインを使用しても、受信者が目にするものは何も変わりません。受信箱の From: アドレスは依然として you@yourdomain.com です。ルートドメイン、あなたのブランド、現在のままです。

サブドメインは背後で、受信ボックスプロバイダー（人間ではなく）が検査する認証レイヤーで機能します。実際に変わるのは、メールが SPF、DKIM、DMARC をクリーンに通過する ようになることで、より多くのメールが迷惑フォルダーではなく受信箱に到達します。つまり、お客様には見える変化はなく、メールがより多く到達するようになります。

つまり、受信者はルートドメインを引き続き見ており、配信が改善されます。これが全てです。記事の残りは単に理由と方法についてです。

（技術版：サブドメインは envelope-from / Return-Path で、SPF がチェックするドメインです。受信者が目にする From: ヘッダーはアプリケーションで設定され、ルートドメインのままです。詳細は以下を参照してください。）

問題を理解する

ルートドメインがCNAMEの場合、それを使用できないのはなぜですか？

多くのホスティングプロバイダー（Heroku、Build.io、Cloudflare、Netlify など）は、ドメインを CNAME レコードで指すよう求めています。これにより、SSL を終了し、トラフィックをルーティングできます。これはウェブサイトには素晴らしく機能します。しかし、メールには難しい競合を作成します。

DNS には RFC 1034 §3.6.2 で定義されたルールがあります。名前に CNAME レコードがある場合、他のタイプのレコードは 何もない ことができます。CNAME は「この名前はその他の名前のエイリアスに過ぎません。すべてをそこで探してください」を意味します。その同じ名前で SPF ポリシーを保持する TXT レコード、または MX レコードの余地はありません。

したがって、yourdomain.com がホストを指す CNAME である場合、文字通り SPF を追加することはできません。DNS がそれを許可しません。

CNAME 競合とは何ですか？また、DNS がこのように機能するのはなぜですか？

CNAME は DNS レイヤーでのリダイレクトです。リゾルバーが yourdomain.com を検索して CNAME を見つけると、元の名前を放棄し、ターゲットを追跡します。CNAME 横に他のレコードを許可すると、曖昧さが生じます。どちらの答えが優先されますか？仕様は組み合わせを完全に禁止することで曖昧さを解決します。これはプロバイダーの制限ではなく、DNS がどのように定義されているかです。

自分のサイトはドメインで正常に機能します。メールが異なるのはなぜですか？

ウェブトラフィックには CNAME のみが必要です。ブラウザーが「yourdomain.com はどこですか？」と尋ね、エイリアスをたどり、接続します。メールには、ドメインに追加レコードが必要です。SPF（TXT レコード）、多くの場合 DKIM、および DMARC ポリシーも必要なため、受信サーバーはメールが認可されていることを確認できます。ウェブサイトを機能させる CNAME は、それらのレコードを正確にブロックするものです。同じ名前、異なる要件。

SPF なしで送信する場合、実際に何が壊れますか？

SPF は、受信ボックスプロバイダーがあなたがあなたであることを決定するために使用する主要なシグナルの 1 つです。SPF レコードがない場合：

メールボックスプロバイダー（Gmail、Outlook、Yahoo）はメールをスパムに送るか、拒否する可能性がはるかに高くなります。
DMARC を通過できません。これは受信箱を増やしています。
メッセージは、スパマーが送信する認可されていないメールのように見えます。

メールは引き続き送信されるかもしれませんが、意味のあるスライスは到達しません。

サブドメインソリューション

どのサブドメインを使用する必要がありますか？名前は重要ですか？

mtg.yourdomain.com をお勧めします。正確なラベルは配信性に影響しません。email. または notifications. も機能します。しかし、mtg.yourdomain.com は明確で、覚えやすく、MailerToGo 送信をきれいに名前空間化します。重要なのは、直接制御する名前（サードパーティへの CNAME 自体ではない）なので、SPF、DKIM、送信レコードを追加できることです。

`mtg.example.com` から送信する場合、受信者はそれを `example.com` の代わりに見ますか？

いいえ。そしてこれは、トップで答えた心配です。今、メカニズム付きです。すべてのメールには 2 つの異なる「from」アドレスがあります：

Envelope-from（MAIL FROM または Return-Path とも呼ばれる）：送信インフラストラクチャが使用するアドレス。これは SPF がチェックするドメインであり、サブドメインが存在する場所です。
Header From:：受信者が実際に受信箱で見るアドレス。これはアプリケーションによって独立して設定され、送信ドメインとは関係ありません。

したがって、mtg.example.com（envelope-from）経由で送信しますが、受信者は From: 行で hello@example.com または Acme Support <support@example.com> を見ます。サブドメインは認証します。ブランドアドレスは表示のままです。

返信はサブドメインまたは実際のアドレスに送信されますか？

返信は From: ヘッダー（または設定する明示的な Reply-To:）に従います。envelope-from ではありません。From: または Reply-To: を実際の監視対象メールボックス（例：support@example.com）に設定すると、返信は期待どおりにそこに到着します。サブドメインはメールを受信する必要はありません。

サブドメインの使用は、自分のドメイン評判に影響しますか？

はい。あなたに賛成で。サブドメインから送信すると、トランザクショナル/マーケティングメールの評判がルートドメインから分離されます。キャンペーンが問題にぶつかった場合、example.com（従業員の日々のメール）をドラッグダウンするのではなく、mtg.example.com に含まれています。評判の分離は副作用ではなく、機能です。

トランザクショナルメールとマーケティングメールの両方に同じサブドメインを使用できますか？

できます。しかし、通常は分離する方が良いです。例えば、トランザクショナル（領収書、パスワードリセット）用の mtg.example.com とマーケティング用の news.example.com です。トランザクショナルメールは高信頼度で低苦情です。マーケティングメールは当然、より多くの苦情と配信解除を引き付けます。それらを分割すると、重要な領収書とリセットがマーケティング評判の変動から隔離されます。

設定する

MailerToGo でサブドメインを使用するようにどのように構成しますか？

MailerToGo ダッシュボードでサブドメイン（ルートドメインではなく）を送信ドメインとして追加してから、それが提供する DNS レコードを公開します。MailerToGo はサブドメインの正確なレコードを表示します。

どの DNS レコードが必要ですか？

サブドメインで SPF と DKIM を追加し、ルートで DMARC ポリシーを推奨します。典型的なセットは以下のようです：

; SPF — MailerToGo がサブドメインのために送信することを許可する
mtg.yourdomain.com.   TXT   "v=spf1 include:_spf.mailertogo.net ~all"

; MX — サブドメインのバウンス/return-path を MailerToGo にルーティングします
mtg.yourdomain.com.   MX    10 smtp.us-west-1.mailertogo.net.

; DKIM + DMARC — MailerToGo ダッシュボードに表示される正確なレコードを公開してください
; （DKIM はセレクタあたりのアカウント CNAME です。サブドメイン DMARC ポリシー
;  あなたのために提供されます。例：p=reject）

ダッシュボードからの正確な値を使用してください。DKIM セレクタと SMTP リージョン（smtp.<region>.mailertogo.net）はアカウント固有です。

アプリケーションコードで何かを変更する必要がありますか？

2 つの小さなことです。まず、MailerToGo にサブドメイン認証情報を使用して指してください。Rails で：

# config/environments/production.rb
config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = {
  address:         ENV["MAILERTOGO_SMTP_HOST"],   # smtp.<region>.mailertogo.net
  port:            ENV.fetch("MAILERTOGO_SMTP_PORT", 587).to_i,
  user_name:       ENV["MAILERTOGO_SMTP_USER"],
  password:        ENV["MAILERTOGO_SMTP_PASSWORD"],
  authentication:  :plain,
  enable_starttls: true   # ポート 587 で TLS を強制する
}

2 番目。そしてこれはサブドメインを機能させる部分です。受信者が見て返信する From: および Reply-To: をルートドメインに保つ一方で、envelope-from（return_path）をサブドメインに設定します：

class NotifierMailer < ApplicationMailer
  def welcome(user)
    mail(
      to:          user.email,
      from:        "Acme <hello@yourdomain.com>",   # 受信者が見るもの
      reply_to:    "support@yourdomain.com",        # 返信が送られる場所
      return_path: "bounces@mtg.yourdomain.com"     # envelope-from：SPF がチェックするもの
    )
  end
end

Rails（Mail gem 経由）は return_path を envelope-from として使用するため、SPF は mtg.yourdomain.com に対して検証されます。SPF レコードが存在する場所です。From:/Reply-To は yourdomain.com に留まります。同じブランド受信者、整列 DMARC、より良い配信性。

サブドメインが機能していることを確認するにはどうすればよいですか？

レコードが解決することを確認してください：dig TXT mtg.yourdomain.com（SPF）、dig MX mtg.yourdomain.com、およびダッシュボードからの DKIM CNAME。
Gmail アカウントにテストメッセージを送信し、Show original を開き、SPF と DKIM の両方が PASS を表示し、DMARC が整列を表示することを確認します。
MailerToGo ダッシュボード内のドメイン状態が検証済みにフリップするのを見てください。

高度および信頼シグナル

DMARC 整列はサブドメインで機能しますか？

はい。DMARC はデフォルトで organizational alignment をサポートしています。mtg.example.com から送信されたメッセージは example.com で公開された DMARC ポリシーと整列します。なぜなら、彼らは同じ組織ドメインを共有しているからです。ルートで 1 回 DMARC を公開し、サブドメインは整列を継承します。別のポリシーは必要ありません。

DKIM はサブドメインまたはルートドメインで署名しますか？

DKIM は、キーを公開するドメイン（ここではサブドメイン（mtg.yourdomain.com））で署名します。これはあなたが望むことです。DKIM シグネチャ、envelope-from、およびサブドメインはすべて並ぶ、その組み合わせはあなたのルート DMARC ポリシーと整列します。

Google Workspace / Microsoft 365 のために既にルートに SPF を持っています。サブドメインはまだ必要ですか？

はい。サブドメインはきれいに保ちます。SPF には 10 DNS ルックアップ のハード制限があります。すべての送信者（Google、Microsoft、ESP、MailerToGo）を 1 つのルート SPF レコードにスタックすると、それを超えて すべての SPF を破壊するリスクがあります。アプリメールをサブドメインから独自の SPF レコード付きで送信することで、制限を回避し、企業メール（Google/Microsoft）とアプリメールを独立させます。

短いバージョン

mtg.yourdomain.com のようなサブドメインを送信に使用します。受信者はルートドメインアドレスを引き続き見ています。彼らに見える変化は何もなく、配信性が向上します。これは大型送信者がどのように行うかです（GitHub、Stripe、AWS はすべてサブドメインからトランザクショナルメールを送信します）。CNAME 競合を回避し、SPF/DKIM/DMARC をクリーンに保ち、ルートドメインの評判を保護します。