メールドメインとは、メールを受信および送信できるように設定された通常のドメイン名（yourcompany.com）です。設定は四つの DNS レコード、MX、SPF、DKIM、DMARC で構成されます。各レコードには一つの役割があり、四つを組み合わせることで、ウェブサイトしか持たないドメインに安定したメール運用の基盤を加えられます。
メールドメインに関する説明の多くは、レコードごとの手順を省くため、DNS が何か不可解な処理をしているという曖昧な印象を事業者に残します。実際はそれほど複雑ではありません。四つのレコードは特定の構文を持つ単純なテキスト項目で、事業者が DNS ダッシュボードから公開できます。それぞれの役割を理解すれば、残りの設定も分かりやすくなります。
このガイドでは、四つのレコードそれぞれの役割と構文を説明します。より広い観点については、独自ドメインメールをご覧ください。
メールドメインの実際の意味
既存の設定に四つの DNS レコードを追加すれば、どのドメイン名もメールを扱えるように設定できます。MX はメールサーバーを参照します。SPF は承認済みの送信者を列挙します。DKIM は送信メールに暗号署名を付けます。DMARC は認証失敗時の処理を受信側に伝えます。四つを組み合わせることで、空のドメインを適切に機能するメールドメインへ変えられます。
同じドメインのルートでウェブサイトをホストし、そのドメインのアドレスでメールを提供できます。四つのレコードは目的ごとに異なるレコード種別を使用するため、ウェブサイトのレコードと競合しません。実際に運用されるメールドメインの多くはウェブサイトでもあります。二つのサービスは別々の事業者に置かれる場合があり、DNS を通じて連携します。メールを新しいホストへ移す際は、メール関連のレコードだけを更新し、ウェブサイトのレコードはそのまま維持できます。
四つの DNS レコードの概要
四つの DNS レコードが、機能するメールドメインを定義します。各レコードには特定の役割と構文があります。メールボックスホストが正確な値を生成し、利用者が DNS ホストで公開します。表では、各レコードの役割と DNS ツリー内の場所をまとめています。
| レコード | 役割 | 配置場所 | 必須？ |
|---|---|---|---|
| MX | 受信メールをメールボックスホストへ転送 | yourcompany.com（ルート） | はい。なければ受信メールは届きません |
| SPF | 承認済みの送信者を列挙 | yourcompany.com（ルート、TXT として） | はい。なければ送信メールが迷惑メールになる可能性があります |
| DKIM | 送信メールに暗号署名を付与 | selector._domainkey.yourcompany.com（TXT） | はい。なければアラインメントが失敗します |
| DMARC | 認証失敗時の処理を受信側に指示 | _dmarc.yourcompany.com（TXT） | 強く推奨。なければなりすましが報告されない場合があります |
四つのレコード自体には DNS ホスト以外の費用はかかりません。Cloudflare には無料プランがあります。メールボックスホストが値を生成した後の設定は約 15 分です。安定した受信トレイへの到達、目に見えるなりすましレポート、現在の受信側の審査に対応する認証の基盤になります。
レコード 1：MX（メールの送信先）
MX は受信メールを受け取るメールサーバーを参照します。レコードの形式は、優先度の数値とサーバーのホスト名です。優先度が異なる複数の MX レコードでフェイルオーバーを実現できます。受信側は優先度の数値が最も低い値を最初に試し、必要に応じて高い数値へ切り替えます。
TrekMail でホストするメールドメインの一般的な値は、10 mx1.trekmail.net と 20 mx2.trekmail.net です。メールボックスホストが正確な値を提示し、利用者がすべてを DNS ホストで公開します。バックアップなしでプライマリだけを公開すると、まれにプライマリが利用できない場合、再試行キューに入らずメールが拒否される可能性があります。
レコード 2：SPF（送信できる主体）
SPF は、ドメインからのメールであると称して送信できるサーバーを宣言します。ドメインルートに置く単一の TXT レコードで、構文は v=spf1 include:_spf.trekmail.net ~all のようになります。各 include: ディレクティブは別の SPF レコードを参照し、そこに実際の送信 IPs が列挙されます。誤って設定すると、正当なメールが気付かないうちに拒否される可能性があります。
マーケティングプラットフォーム、トランザクション送信サービス、サポートチケットツールなど、ドメインからメールを送るすべての外部サービスを SPF に含める必要があります。IP で直接指定するか、include を使用します。解決ツリー全体は 10 回未満の DNS ルックアップに収めます。正当なメールが拒否され始める前に上限への接近を把握できるよう、SPF レコードを四半期ごとに監査してください。詳しい手順は、メール認証 SPF DKIM DMARCをご覧ください。
レコード 3：DKIM（暗号署名）
DKIM には、受信側が送信メールの署名を検証するための公開鍵が含まれます。メールボックスホストは対応する秘密鍵で各メッセージに署名し、受信側は DNS の公開鍵と照合します。署名の検証に成功すると、送信者がドメインを管理していることを確認できます。
DKIM レコードは、セレクター固有のサブドメインに公開します。TrekMail のセレクターは trekmail._domainkey.yourcompany.com、Mailgun のセレクターは mailgun._domainkey.yourcompany.com となり、他も同様です。それぞれ長い base64 文字列であり、改行のない連続した一つの TXT 値として貼り付ける必要があります。複数のセレクターは共存できます。メールドメインの署名を行うサービスごとに専用のものを用意します。詳しい手順は、DKIM の設定をご覧ください。
多くの事業者は、最初に送信者ごとの方式を見落とします。初期設定から六か月後に追加した新しいマーケティングプラットフォームには、独自のセレクターが必要です。一年後に追加したトランザクション送信サービスにも別のものが必要です。送信者ごとに対応しないと、メールドメイン自体に正しい SPF/DKIM/DMARC 設定があっても、アラインメントが気付かないうちに失敗し、そのサービスのメールが迷惑メールになる可能性があります。対策は、稼働中の送信者ごとに一つの DKIM レコードを設けることです。
レコード 4：DMARC（ポリシーとレポート）
DMARC は SPF または DKIM の失敗時に何をするかを受信側へ伝えます。TXT レコードを _dmarc.yourcompany.com に置き、構文は v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourcompany.com のようになります。p= の値でポリシー（none、quarantine、reject）を設定します。rua= のアドレスで集約レポートを受信します。
二週間の監査に向けて p=none から始めます。レポートには、メールドメインから送信していると称するすべての IP と、アラインメントの成否が表示されます。二週間にわたりレポートに問題がなければ、p=quarantine に強化できます。さらに一か月後、p=reject に強化できます。段階的に導入することで、認証し忘れた送信者が見つかる可能性のある監査中に、正当なメールが拒否されるリスクを抑えられます。
四つのレコードが連携する仕組み
四つのレコードは一つの仕組みとして連携します。MX は受信メールを正しいサーバーへ送ります。SPF は正当な送信者を宣言します。DKIM は暗号署名を受信側が検証できるようにします。DMARC は SPF と DKIM を結び付け、いずれかが失敗した場合の処理を受信側へ伝えます。
この連携によって仕組みが機能します。SPF は DKIM がなければ、送信メールの多くが DMARC アラインメントに失敗します。アラインメントでは通常、DKIM を確認し、SPF は確認しないためです。DKIM は DMARC がなければ、DKIM が失敗した場合の処理が受信側に伝わりません。DMARC を p=reject にした状態で適切な SPF と DKIM の対応がなければ、正当なメールが拒否される可能性があります。四つのレコードはまとめて設定する必要があります。一部だけの対応は、段階的な改善ではなく到達率の低下につながる場合があります。
TrekMail が四つのレコードを生成する方法
TrekMail はドメイン設定時に、四つすべてのレコードの正確な値を生成します。ダッシュボードでドメインを追加すると、TrekMail のメールサーバーを指す MX 値、SPF とそれに含まれる _spf.trekmail.net、新しく生成した鍵を使う TrekMail 固有セレクターの DKIM、DMARC とその p=none および標準レポートアドレスが生成されます。それぞれを DNS ホストのダッシュボードへコピーします。
プラットフォームは事業者によって変わらない部分を処理します。SPF の include パス、DKIM 鍵の生成、鍵のローテーション日程、DMARC レポートの集約です。利用者は変動する部分を処理します。どの DNS ホストでレコードを公開するか、DMARC レポートをどのメールボックスへ送るか、いつ DMARC ポリシーを強化するかです。より広い観点については、ドメインメールをご覧ください。
次のステップ
機能するメールドメインには、管理下の DNS ホストで正しく公開した四つの DNS レコードが必要です。MX は受信メールを転送します。SPF は承認済みの送信者を宣言します。DKIM は送信メールに署名します。DMARC はポリシーとレポートですべてを結び付けます。四つのレコードの公開には約 15 分かかり、四半期監査を続けることで、何年にもわたる安定した受信トレイへの到達を支えられます。
trekmail.net/pricing で TrekMail Nano を無料でお試しください。カードは不要で、トライアル期限もありません。Nano プランは 10 ドメイン × 10 メールボックスに対応します。送信量が Nano の上限を超えた場合、$4/月の Starter は 50 × 100 に拡張します。
四つのレコードには、一度設定して四半期ごとに監査する運用が適しています。MX は設定後ほとんど変わりません。運用にマーケティングプラットフォームやトランザクションサービスが加わるにつれて、SPF には数か月かけて新しい送信者が追加されます。DKIM 鍵は多くのプラットフォームで自動的にローテーションされます。DMARC レポートは継続的に届き、正当な送信者の変化となりすましの試みの両方を明らかにします。四半期監査は負担が軽く、初期設定後にレコードを放置した運用で発生する多くの到達率問題を防ぐ助けになります。
複数のブランドドメインを持つ事業者は、メールドメインごとに四つのレコードの設定を繰り返します。MX 値は同じメールボックスホストを参照し、SPF、DKIM、DMARC レコードはドメインごとに公開します。TrekMail のドメイン一括エンドポイント（一度に最大 500 ドメイン）は、代理店規模の運用でドメインごとの設定を大幅に短縮できます。
四つのレコードの枠組みは、問題発生時の診断手順にもなります。受信メールが届かない場合は MX を確認します。送信メールが迷惑メールになる場合は SPF と DKIM を確認します。なりすましレポートが大量に届く場合は DMARC ポリシーを確認します。各障害モードが特定のレコードを示すため、トラブルシューティングを迅速に進められます。
