メール用DNSの自動設定：単一ドメインはワンクリック、複数ドメインはトークンで

メールのDNS設定では、六つか七つのレコードを登録します。長い文字列を含むものもあり、一文字間違えただけで、入力ミスとは気づきにくい障害につながります。DKIM鍵は数百文字のbase64文字列です。SPFレコードには順序が重要な仕組みが並び、末尾の指定によってポリシーの意味も変わります。DMARCで使うサブドメイン名も、初めて設定するときは間違えがちです。

一つのドメインなら、問題なく設定できるでしょう。顧客の四十ドメインを扱えば、見落としの可能性は高くなります。一か月後、請求書が迷惑メールに入って初めて気づくこともあります。

自動設定なら、値を手作業で転記する必要がありません。方法は二つです。単一ドメインについてDNS事業者の画面で変更を承認し、トークンを渡さずにTrekMailへ戻る方法と、権限を絞ったAPIトークンで百ドメイン規模の設定を複数のバッチに分けて進める方法です。どちらも適用前に変更内容を確認できます。

メールに必要なDNSレコードとは

「多くの送信環境で必要」は、RFCがすべてのドメインにDKIMとDMARCの公開を義務づけている、という意味ではありません。GoogleとYahooは2024年に大量送信者向けの要件を導入しましたが、適用される条件は送信者の区分と現行のルールによって異なります。企業の受信システムにも独自の要件があります。これらのレコードがなくても一切送信できなくなるわけではありませんが、認証や受信側での受け入れに支障が出る可能性はあります。

手動のDNS設定で起きる四つのミス

SPFレコードを二つ公開する。よくある、影響の大きいミスです。評価対象の名前にはSPFレコードを一つだけ公開します。新しい送信サービスのために二つ目を追加しても、ポリシーの拡張にはなりません。仕様に従った評価ではpermerrorになります。仕組みを一つのレコードにまとめてください。詳しくはSPFレコードの例を参照してください。

貼り付け時にDKIM鍵を壊す。2048ビット鍵の文字列表現は、TXTの一文字列あたり255文字という制限を超えます。そのため、一つのレコードに複数の文字列を格納し、読み取り時に連結します。自動で分割するDNS管理画面もあれば、利用者による分割が必要なものや、値を切り詰めてしまうものもあります。不完全な鍵では署名を検証できず、原因もすぐには分かりません。

DMARCの登録名を間違える。登録先は_dmarc.example.comです。ドメインのルートに置いても、そのドメインのDMARCポリシーを検索する受信サーバーには見つかりません。

SPFのDNS検索上限を超える。SPFでは、一回の評価で使うDNS検索を必要とする項の数が十個までに制限されています。評価されたinclude:は、入れ子になった指定も含めて数えます。メール事業者、CRM、マーケティングツール、問い合わせ管理システムを組み合わせると、それぞれのポリシー次第で上限を超えることがあります。その場合はpermerrorです。初期設定から数か月後、別のツールを追加したときに発生することもあります。詳しくはSPFのDNS検索上限を参照してください。

自動化は転記ミスを減らし、競合を検出しますが、結果の確認は必要です。SPFの統合によって二つ目のレコードを作らずに済んでも、完成したポリシーが評価上限内であることまでは証明できません。

方法1：ワンクリックのDNS設定、トークン不要

DNSをCloudflareで管理している単一ドメインなら、この方法が直接的です。TrekMailへAPIトークンやアカウントのログイン情報を渡す必要はありません。

1. ドメインのDNSと状態タブを開きます。
2. DNSを自動設定をクリックします。
3. Cloudflareで、承認前に提案されたレコード変更を確認します。
4. 承認をクリックします。
5. TrekMailに戻ると検証が要求されます。戻ったことだけでは、レコードが正しく公開されたとは確認できません。

この手順では、公開プロトコルのDomain Connectを使用します。サービスが必要なレコードを示し、DNS事業者がドメイン所有者に変更内容を提示して、所有者が承認する仕組みです。再利用可能なAPIトークンは作成も保存もされません。承認は、そのドメインについて提示された操作を対象とします。

ドメインのネームサーバーがCloudflareを指している必要があります。Cloudflareで登録しただけで、DNSは別の事業者が管理している場合、この方法は使えません。レコードは実際にDNSゾーンを管理する事業者側で変更する必要があります。

方法2：権限を絞ったAPIトークンでDNSを設定

複数ドメインを扱う場合やDomain Connectを使えない場合は、トークンでアカウント内の許可されたゾーンを設定できます。

CloudflareでEdit zone DNSテンプレートからトークンを作成し、権限をZone → DNS → Editにします。ゾーンのリソース指定では、全ゾーンならAll zones、限定するならSpecific zoneを選びます。IP制限や有効期間が予定する用途を妨げないか確認し、理由なく変更する必要はありません。表示されたトークンをコピーしてTrekMailへ貼り付けます。

重要なのは、その権限でできることとできないことです。

TrekMailはトークンを暗号化して保存し、その値をログに記録しないようにしています。TrekMailでドメインとの接続を解除するか、Cloudflareでトークンを失効させ、以後の要求を止められます。ただし、一つのドメインを切り離しても、ほかのドメインと共有するトークンまで失効するとは限りません。失効しても、すでに適用した変更は元に戻りません。

接続後は、利用可能なCloudflareゾーンと予定される操作が表示されます。TrekMailアカウントに登録済みのドメインにはDNSを設定、同じ手順で追加と設定を行うドメインには追加 + DNSが表示されます。Cloudflare以外でDNSを管理しているドメインは、この連携で設定できるゾーンには表示されません。

プレビューと五つの状態

適用前に各レコードを確認できます。プレビューでは五つの状態を使います。

各レコードにはチェックボックスがあります。MXとSPFを先に適用してDKIMを後回しにしたり、別の方法で管理するレコードを対象外にしたりできます。チェックを外したレコードは、その操作では適用されません。

競合は内容を読んでから判断してください。DMARCのp=noneは誤りではなく、意図的な監視段階かもしれません。レポートを読む前にp=quarantineへ変更すると、まだ正しく認証できていない正当なメールに影響する可能性があります。必要なら維持し、導入を終えてからポリシーを厳しくします。考え方はDMARCポリシーの選び方で説明しています。

既存のSPFレコードを統合する理由

SPFは一つのポリシーで複数の送信サービスを許可できるため、特に注意が必要です。使っているサービスを確認せずに置き換えると、必要な許可を消してしまうことがあります。

ドメインがすでに次を公開しているとします。

v=spf1 include:_spf.google.com ~all

これはGoogleの送信基盤、たとえばWorkspaceやその経由で送るツールを許可するポリシーです。TrekMailだけを含むレコードへ置き換えても、単に送信者を追加したことにはなりません。以前の許可がなくなり、それに依存するメールはSPFに失敗する可能性があります。

そのため、既存の有効なSPFレコードは通常、次のように統合します。

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

両サービスを一つのレコードで許可し、末尾の修飾子も保持します。これなら以前の許可を消さずにTrekMailを追加できます。ただし「絶対に置き換えない」わけではありません。重複や形式不正のSPFでは競合解消が必要な場合があり、完成したポリシーの確認も必要です。

その後は二点を確認します。追加したinclude:はDNS検索を必要とする十項目の上限に数えられ、入れ子の検索も発生し得るため、ポリシー全体を評価してください。旧事業者が本当に送信しなくなったなら、確認後にその許可を手動で削除します。活動が見られないだけでは、使われなくなった証拠にはなりません。

DNSの一括設定

全ゾーンへの権限を持つトークンなら、ウィザードで対応ドメインを処理し、新規追加、DNS設定、ドメインごとの結果表示を行えます。一バッチは最大50ドメインです。追加したドメインはプランの上限に数えられます。原文の設定ではNanoが10、Starterが50、Proが100、Agencyが1,000です。開始前にアカウントの現在の制限を確認してください。

十数個のドメインを持つ顧客を受け入れる代理店なら、一括処理で手作業を大きく減らせます。その分、プレビューは重要です。十二ドメインのうち二つにDMARCの競合があり、一つのautodiscover CNAMEが2023年に離れた旧事業者を指している場面を考えてみてください。これは確認すべき残存設定の例で、その頻度を保証するものではありません。

変更の影響範囲

アプリにDNSの書き込み権限を与える前に、影響範囲を確認するのは当然です。

連携機能はメール用レコードを管理する設計です。対象はMX、SPF、DKIM、DMARC、MTA-STS、TLS-RPT、メール自動設定用のCNAMEです。Aレコード、ウェブサイトのCNAME、他サービスのTXTは変更しない想定です。ただし、トークンのDNS編集権限は許可したゾーンのレコードに及び、メール用だけには限定されません。他のレコードの保護は、アプリの動作にも依存します。この権限ではネームサーバーを変更できません。

競合レコードの置き換えは以前の設定を失わせることがあるため、確認が必要です。他の変更や、操作に伴う重複レコードの削除も確認してください。残りの操作すべてに影響がないとは言えません。復元が必要なら、変更前の値を保存しておきます。

検証待ちはDNSキャッシュの影響かもしれませんが、値の誤りや操作の未完了でも起こります。原文は最大48時間としていますが、一律の期限ではなく、TTLや事業者の状況によって変わります。検証は自動で繰り返され、DNSを検証から再確認も要求できます。翌日も失敗するなら公開された値を確認し、署名の問題であればDKIMのトラブルシューティングを参照してください。

よくある質問

ワンクリック設定にはCloudflareアカウントが必要ですか？

ドメインのDNSをCloudflareが管理しており、変更を承認できるアカウントへのアクセスが必要です。TrekMailへAPIトークンを渡す必要はありません。Cloudflareの画面で操作を承認し、再利用可能なトークンは保存されません。

DNSがCloudflare以外にある場合は？

この自動連携では別の事業者を設定できません。レコードを手動で登録してください。ドメインのDNSページには値とコピーボタンがあり、事業者ごとの手順は主要DNS事業者での設定方法にまとめています。

自動設定でウェブサイトに影響しますか？

連携はメール用レコードを変更し、Aレコード、サイトのCNAME、無関係なTXTを保持する設計です。ただし、トークンが技術的にそれらを編集できないわけではありません。権限は許可したゾーンのDNSレコードに及びます。提案された変更を確認してください。ここで説明した権限ではネームサーバーは変更できません。

既存のSPFレコードはどうなりますか？

通常は統合され、TrekMailのincludeが追加されて修飾子は維持されます。これにより他の送信サービスの許可を誤って消さずに済みます。重複や形式不正がある場合は、確認を伴う置き換えが必要になることもあります。最終ポリシーの検索上限も確認してください。

一部のレコードだけ適用できますか？

はい。プレビューの各レコードにチェックボックスがあります。別の方法で管理するレコードのチェックを外せば、その操作の対象から除外できます。

一回で何ドメインを設定できますか？

一バッチにつき最大50で、プランのドメイン総数の上限内に限られます。ウィザードで追加する新規ドメインも上限に数えられます。

APIトークンは保護されていますか？

TrekMailは暗号化して保存し、値をログに記録しないようにしています。説明した権限では選択ゾーンのDNSを編集できますが、請求、WAF、ネームサーバー、ドメイン移管は管理できません。Cloudflareで失効させれば以後の要求を止められますが、以前の変更は元に戻りません。必要なゾーンだけを許可してください。

作成した覚えのないレコードが「設定済み」になるのはなぜですか？

以前の事業者が作成したか、過去に承認された設定が実行された可能性があります。公開値と提案値を比較してください。同じなら置き換えは不要ですが、現在の構成にも適しているか確認します。