DNS ステータスが緑色にならない場合

DNS 検証は、選択した設定に必要なレコードを確認します。TrekMail でメールを受信するドメインには通常、MX、SPF、DKIM、DMARC が必要です。MTA-STS や TLS-RPT などの推奨レコードは別に表示されることがあります。このガイドでは、推測せずにダッシュボードと DNS 事業者を比較する方法を説明します。

ダッシュボードのレコード表から始める

ドメインを開き、対象ドメインと DNS ステータスを選びます。表から種類、ホスト、値、MX の場合は優先度をコピーします。DKIM 値や一部のポリシーレコードはドメイン固有なので、この表が基準です。

レコードを変える前に、別のサービスが既存値を必要としていないか確認します。特に SPF は 1 つだけにし、他の正当な送信サービスが使う include は保持します。

反映にはどれくらいかかりますか？

DNS 更新が表示されるまでの時間は、事業者、以前の TTL、リゾルバーのキャッシュによって異なります。保留は値が間違っている証明ではなく、時間経過も正しい証明ではありません。

次の順序で確認します。

1. 権威 DNS ゾーンをホストする事業者でレコードを保存します。
2. MX 優先度と完全な DKIM 値を含め、保存値をダッシュボード表と比較します。
3. DNS を確認を 1 回実行し、TrekMail の再確認を要求します。
4. 保留のままなら、競合の詳細と独立した検索で現在公開されている値を確認します。

必須レコード

通常のメールホスティングで重要なレコードは次のとおりです。他のドメインの値ではなく、自分のダッシュボードからコピーしてください。

推奨レコードは配送の安全性を高めますが、基本レコードの代わりにはなりません。

任意のクライアント自動設定 CNAME (autoconfig、autodiscover) はアプリ設定を速めますが、配送には影響しません。

確認 1: 重複する SPF レコードを統合する

ドメインのルートで v=spf1 から始まる TXT は 1 つだけにします。2 つあると受信サーバーがポリシーを判断できず、TrekMail も正しく検証できません。

症状: DNS に両方あるのに、TrekMail は SPF 未設定と表示する。

解決方法: 送信者規則を 1 つに統合します。次の 2 行がある場合:

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.trekmail.net -all

次の 1 行に置き換えます。

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

使用する末尾: -all または ~all

片方だけを使います。include:spf.trekmail.net が末尾より前なら、どちらも検証に合格します。選択は TrekMail 以外のサービスからのメールに影響します。

末尾についての助言は検証失敗ではありません。どちらでもドメインを確認できます。

次の末尾は使わないでください。

• ?all は有効な認可ポリシーになりません。
• +all はインターネット上の全送信者を許可します。

SPF レコードで使える DNS 検索は最大 10 回です。外部送信者が多い場合は include を減らすか、該当事業者に対応する統合方法を確認します。

確認 2: Cloudflare のメール CNAME がプロキシされている

Cloudflare は Web トラフィックをプロキシできますが、メール関連 CNAME は DNS のみにします。mta-sts、autoconfig、autodiscover、その他ダッシュボードが要求するホストが該当します。

症状: Cloudflare の DNS 一覧にあるのに、ブロックまたは検証不能と表示される。

解決方法: Cloudflare で DNS を開き、ホストを探してオレンジの雲を灰色の DNS のみに変えます。その後 TrekMail で DNS を確認を実行します。

Web サイトの A または主要 Web CNAME はプロキシのままで構いません。ダッシュボードが示すメールホストだけを変更します。

確認 3: DMARC のホストが違う

DMARC はルートではなく _dmarc.yourdomain.com に置きます。一部の DNS フォームは @ を事前入力するため、誤った場所に保存しやすくなります。

症状: DNS に DMARC があるのに TrekMail が見つけられない。

解決方法: _dmarc に追加します。インターフェイスによって _dmarc または _dmarc.yourdomain.com を要求します。フォームの説明を確認してください。@ の誤ったレコードは、他の用途がないことを確認してから削除します。

確認 4: DKIM が誤って貼り付けまたは分割された

DKIM 値は長いため、DNS 事業者は複数の連結セグメントとして保存できます。ただし公開結果はダッシュボードの完全な値と一致する必要があります。

"p=MIIBIjANBgkqhki..." "...continues here" "...and ends here"

ほとんどは自動処理します。貼り付けの失敗で文字、空白、引用符が増減することがあります。

症状: DNS に DKIM が見えるが、TrekMail が "DKIM key invalid" または "p= does not match" と表示する。

解決方法:

• ダッシュボードの値をそのまま貼り付けます。
• 長い TXT を自動分割する場合、全体を貼って事業者に処理させます。
• 個別セグメントを求められたら事業者の説明に従い、すべての文字を保持します。
• 独立した DNS 検索で、公開 TXT に完全なキーが含まれることを確認します。

確認 5: MTA-STS に対応が必要

MTA-STS は、TrekMail で受信するドメインに推奨される配送セキュリティ機能です。ダッシュボードに表示される場合、示された TXT と mta-sts CNAME が必要です。ダッシュボードが明示しない限り、送信専用ドメインには追加しません。

DNS によるブロック。 mta-sts CNAME がないか別の場所を指しています。現在のダッシュボード宛先で追加または修正します。

Cloudflare によるブロック。 CNAME はありますがプロキシされています。確認 2 のとおり、ホストを DNS のみにします。

以前は動作したが低下。 TXT と CNAME をダッシュボードと比較します。通常は変更または削除が原因です。値を戻し、DNS を確認を実行して新しい状態を確認します。

確認 6: 公開検索とダッシュボードを比較する

変更の反映中は、ローカルネットワークと TrekMail が異なる結果を見ることがあります。公開検索で他のネットワークから見える値を確認できます。

比較手順:

1. dnschecker.org または whatsmydns.net を開きます。
2. 完全なホスト名と種類を入力します。DMARC なら _dmarc.yourdomain.com と TXT です。
3. 返されたホスト、値、MX 優先度をダッシュボード表と比較します。
4. 公開検索は正しいのに TrekMail が不一致を示す場合、結果をサポートチケットに含めます。

確認 7: 古い DNS 値がキャッシュされている

DNS レコードの変更後、古い値が TTL (Time To Live、秒単位) まで中間リゾルバーに残ります。古いレコードでは 24 時間 (86400 秒) の TTL が一般的です。

症状: 1 時間前に変更したが、世界中の検査ツールが古い値を示す。

解決方法: 同じ変更が反映中なら、繰り返し編集しないでください。計画的な移行では、事業者が対応していれば事前に TTL を下げられます。安定後は通常の DNS 管理に適した TTL を選びます。

段階的なデバッグ

1. ドメインページを開いてドメインをクリックします。
2. 競合を表示があれば開きます。修正必須、推奨、情報の項目が分かれています。
3. 期待されるホスト、値、MX 優先度を事業者に保存されたレコードと比較します。
4. 必要最小限の変更を行い、他のサービスが必要とするレコードは保持します。
5. TrekMail で DNS を確認をクリックします。
6. 更新された状態を読みます。選択した設定の必須レコードが有効ならドメインは有効です。推奨レコードは別に表示されます。

自分で確認できるレコードには、ターミナル (Mac/Linux/WSL) で次を使います。

dig +short MX yourdomain.com
dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT dkim._domainkey.yourdomain.com
dig +short CNAME mta-sts.yourdomain.com

出力をダッシュボードにある自分のドメインの値と比較します。例から DKIM キー、MTA-STS ポリシー ID、その他のドメイン固有値をコピーしないでください。

DNS 事業者でよくある問題

• Cloudflare: メール CNAME は DNS のみにします。CNAME 宛先末尾のドットが非表示の場合があるため、重複したドットを加えず解決後の宛先を比較します。
• GoDaddy: ルートに @、DMARC ホストに _dmarc を使います。GoDaddy がドメイン名を追加します。
• Namecheap: Namecheap が権威 DNS の場合のみ Advanced DNS で追加します。ルートには @ を使います。
• Route 53: 実際にドメインへ接続されたホストゾーンを選び、ダッシュボードの完全な値を貼ります。
• サイト作成サービスとレジストラ: ドメインの購入先が DNS を管理しているとは限りません。ネームサーバーを確認し、実際の管理事業者で編集します。

すべて正しいのに赤色のままの場合

ダッシュボードと独立した公開検索が同じ必須レコードを示すのに、TrekMail が不一致を報告する場合、次を添えてチケットを開きます。

• ドメイン名。
• 対象レコードの公開検索結果。
• 競合を表示パネルのスクリーンショット (利用可能な場合)。

アカウントやメールボックスのパスワード、復旧コード、アクセストークンは含めないでください。