TrekMailで必須となる4つのDNSレコード設定

ドメインを有効にする際、TrekMailは4つの重要なDNSレコードを確認します。ダッシュボードに表示された値を、DNS事業者の管理画面へ正確にコピーしてください。不足や不一致があれば、TrekMailが修正箇所を示します。

ドメインの受信メールを別の事業者に残し、そのアドレスからの送信だけにTrekMailを使う場合、MXは変更しません。TrekMailでホストしないドメインから送信するを参照してください。この運用方法を選ぶと、ダッシュボードはMXを必須項目から自動的に外します。

対象となる方

• DNSを設定するシステム管理者。
• 配信上の問題や赤いDNS状態を調べている方。

メール用DNSを支える4つのレコード

1. 受信用のMXレコード

ホスト： @またはドメインのルート

値： mail.trekmail.net.

優先度： 10

このレコードによって、受信メールがTrekMailのサーバーへ届きます。

• よくあるミス： GoogleやGoDaddyなどの古いMXを、TrekMailのMXと一緒に残すことです。メールが複数の事業者へ分散し、一部が失われる原因になります。ほかのMXはすべて削除してください。
• 送信だけに使う場合： MXはそのままにします。ドメインを開き、名前の下にある受信メールを選び、現在の事業者で受信を続ける設定にしてください。ダッシュボードが求めるのはSPF、DKIM、DMARCだけになり、検出したMXに対する警告も表示されなくなります。このドメインから送信はできますが、TrekMailにメールボックスを置くことはできません。

2. 送信元を許可するSPFレコード

ホスト： @

必須のinclude： include:spf.trekmail.net

SPFはSender Policy Frameworkの略で、ドメインの名義で送信を許可するIPアドレスやサービスの一覧です。

• SPFがまだない場合： 値がv=spf1 include:spf.trekmail.net -allのTXTを作成します。
• SPFがすでにある場合： 既存のレコードへTrekMailのincludeを加え、現在の終端指定は維持します。
  • 誤り： TXTを2つに分ける。
  • 正しい例： v=spf1 include:spf.google.com include:spf.trekmail.net -all。
  • これも正しい例： v=spf1 include:spf.google.com include:spf.trekmail.net ~all。

終端指定について： TrekMailは-allと~allのどちらも受け付けます。include:spf.trekmail.netが選んだ終端指定より前にあれば問題ありません。正規の送信サービスをまだ洗い出している段階では、~allが慎重な一時設定です。すべてのサービスをSPFに含めた後でのみ-allへ切り替えてください。転送メールは別の問題であり、どちらを選んでもSPFが失敗することがあります。そのためDKIMのアラインメントが重要です。?allと+allは受け付けません。?allはSPFを公開していない状態と同じで、+allはすべての送信元を許可します。

SPF失敗について： DMARCレポートでSPFが失敗していても、DKIMが成功していれば、多くの場合は異常ではありません。Gmailの自動転送などでメールが転送されたか、セキュリティゲートウェイを通った可能性があります。DKIMがアラインメントを満たせばDMARCは引き続き成功します。SPFとDKIMの両方が失敗した場合にのみ調査してください。

3. 電子署名用のDKIMレコード

ホスト： dkim._domainkey

値： v=DKIM1...で始まるドメイン専用の長い文字列

DKIMはDomainKeys Identified Mailの略で、受信サーバーが署名元ドメインと署名対象部分を検証できる仕組みです。

• 鍵の生成： 値に「生成中...」と表示されている場合は、ダッシュボードに鍵が現れるまで待ちます。その後、表示されたホストと値を正確に公開し、DNSを確認を実行してください。
• 書式： Route 53など一部のDNS事業者では、値を引用符で囲んだ複数の文字列に分割します。多くの事業者では文字列全体を入力します。表示どおりに貼り付けてください。
• 同じ名前のレコードがすでにある場合： 別のサービスもこのドメインのメールに署名しています。既存レコードは置き換えないでください。通常の名前が使用中の場合、TrekMailは別のセレクターで鍵を作成し、DNSタブに正確な名前を表示します。2つの鍵は共存できます。
• 外部SMTPを使う場合： 外部事業者が別のセレクターで独自のDKIMを求めることがあります。その事業者から指定されたレコードも公開してください。TrekMailの鍵だけでは、外部事業者のメールはDKIMに合格しません。

4. ポリシーを適用するDMARCレコード

ホスト： _dmarc

値： v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net

DMARCはSPFとDKIMの結果を組み合わせて判定します。

• ポリシー（p）：
  • none：監視のみです。正規の送信元をまだ確認している段階では、ここから始めます。
  • quarantine：検証に失敗したメールを疑わしいものとして扱うよう受信側へ求めます。TrekMailの標準テンプレートです。
  • reject：検証に失敗したメールを拒否するよう受信側へ求めます。レポートを確認し、アラインメントに問題がないと分かってから移行してください。
• TrekMailの確認方法： v=DMARC1を含む有効なレコードであれば検出できます。レポート先を定めるruaなどのタグは、必要に応じて変更できます。

新しいドメインでTrekMailだけが送信する場合、ダッシュボードのp=quarantineテンプレートは実用的な出発点です。Google Workspace、Microsoft 365、ヘルプデスクなども同じドメインから送信する場合は、p=noneから始めます。レポートを確認しながら段階的に強化すれば、正規のメールを誤って隔離せずに済みます。

5. 推奨される高度な配信保護

次のレコードは基本的なメール運用に必須ではありませんが、セキュリティと配信レポートの改善に役立ちます。詳しくは推奨DNSレコードのガイドをご覧ください。

TLSレポート（TLS-RPT）

ホスト： _smtp._tls

値： v=TLSRPTv1; rua=mailto:tlsrpt@trekmail.net

• 目的： ほかのメールサーバーがドメインへ接続するときに起きた暗号化の問題を報告できます。

MTA-STS

MTA-STSポリシー（TXT）：

ホスト： _mta-sts

値： ダッシュボードに表示されたv=STSv1; id=...を正確にコピーします。公開ポリシーが変わるとIDも変わります。

MTA-STS CNAME：

ホスト： mta-sts

値： mta-sts.trekmail.net.

• 目的： 受信メールに厳格なTLS暗号化を適用し、ダウングレード攻撃を防ぎます。

よくあるミスと解決方法

• 症状： SPFの状態が「競合」になっている。
  • 解決方法： v=spf1で始まるTXTが複数ないか確認します。SPFは1つしか公開できません。
• 症状： DNSの変更が反映されない。
  • 考えられる原因： DNS事業者による公開と各リゾルバーのキャッシュ更新には時間がかかります。
  • 解決方法： DNS事業者の画面で種類、ホスト、値、MX優先度を確認します。変更が公開された後に、もう一度確認を実行してください。