TitanのSPF・DKIM・DMARC設定。
Titanはホスティング型のメールサービスです。導入すると、自社ドメインで送受信できる実際のメールボックスを利用できます。多くのホスティング会社やレジストラ（Hostinger、hosting.com、Bluehost、A2 Hosting、Crazy Domainsなど）がホワイトラベルで再販しているため、ダッシュボードには購入元のブランドが表示されている場合があります。すべてのメッセージは自社ドメインの代理としてTitanのサーバーから送信されるので、Gmail、Yahoo、Outlook、Appleの受信側は、自社ドメインのDNSに公開されたSPF、DKIM、DMARCレコードに照らしてメールを評価します。Titanでの設定はシンプルです。Titanは共有のSPFのincludeを1つ公開し、アカウントごとのDKIM鍵をControl Panel内で生成します。DMARCは自分で追加します。このガイドでは、Titanの正確なレコード形式、DKIMを設定するControl Panel内の経路、各レコードの確認方法を含め、3つの設定を最初から最後まで説明します。
Titanを認証すべき理由
2024年2月以降、GmailとYahooはすべての送信者に有効なSPFまたはDKIMレコードを求めており、大量送信者にはドメインのアライメントを伴うDMARCも必要です。要件を満たさないメールは、迷惑メールフォルダーに振り分けられるか、そのまま拒否されます。Titanのメールボックスを数個運用するだけの小規模な事業者でも、認証の未設定は、正当なメールが迷惑メールに振り分けられたりバウンスしたりする最も多い原因です。SPFは、自社ドメインのメールをTitanのサーバーから送信してよいことを受信側に伝えます。DKIMは各メッセージに暗号署名を付け、偽造や改ざんを防ぎます。DMARCはこの2つを結び付け、失敗したメールの扱いを受信側に指示するとともに、自社ドメインを名乗って送信している相手がわかるレポートを届けます。3つすべてを公開することで、「Titanから届いたメール」が「自社ブランドから届いた、信頼できる認証済みのメール」に変わります。
TitanにおけるSPFの実情
Titanは正規の共有のSPFのincludeを公開しており、これが推奨の方法です。ルートドメインにある1つのSPFのTXTレコードに`include:spf.titan.email`を追加してください。この1つのincludeの先で、`spf.titan.email`は3つのネストされたinclude（`_spf1.titan.email`、`_spf2.titan.email`、`_spf3.titan.email`）とインラインの`ip4:`範囲に展開されます。そのため、`include:spf.titan.email`メカニズム1つで、SPFで許可される10回のDNSルックアップのうち実際には約4回を消費します。Titanはマーケティングツールのような補助的な送信経路ではなくメールボックスサービスです。また、送信時のエンベロープ送信者には、利用者である自社のドメインが使われます。このためincludeはサブドメインではなく主要ドメインのSPFレコードに追加します。これにより、DMARCの判定でSPFのアライメントが自社ドメインと一致します。SPFレコードは1つのドメインにつき1つだけ公開してください。別の送信者用のSPFがすでにある場合は、2行目の`v=spf1`を作らず、既存のレコードにTitanのincludeをまとめます。2行目を作るとSPF全体が機能しなくなります。
設定手順
- 1
ドメインでTitanが有効になっていることを確認
ホスティング会社やレジストラのダッシュボードからTitan Control Panelにログインします。入口は、メール製品の横にある「Admin login」や「Manage」ボタンであることが一般的です。ドメインが未確認と表示されている場合は、Titanでメールを受信できるよう、先にTitanのMXレコードを追加します。SPF/DKIM/DMARCによる認証はMXとは別のものですが、DKIMを生成するにはTitanが有効になっている必要があります。
- 2
TitanのMXレコードを追加（受信の前提条件）
ドメインのDNSゾーンで、ルートのホスト（@）に2つのMXレコードを作成します。mx1.titan.emailは優先度10、mx2.titan.emailは優先度20、TTLは1時間です。これらは受信メールをTitanへ振り向けるレコードで、メールボックスの動作に必要です。送信メールの認証には関係しませんが、以降のレコードと同じDNSゾーンで設定します。
- 3
SPFレコードを公開
ルートのホスト（@）に、値がv=spf1 include:spf.titan.email ~allのTXTレコードを1つ追加します。TTLは1時間です。レコードタイプにはTXTを使ってください（廃止されたSPFタイプは使いません）。別のサービス用のv=spf1レコードがすでにある場合は、2つ目を追加してはいけません。既存のレコードの~all/-allの前にinclude:spf.titan.emailを挿入し、SPFレコードを1つだけにしてください。
- 4
Titan内でDKIM鍵を生成
Titan Control Panelで（アカウントのManage / Admin loginから）Email Reputationを開き、DKIMを見つけてクリックし、鍵を追加・生成します。Titanは公開鍵と秘密鍵のペアを作成し、秘密鍵を保持して送信メールに署名します。画面にはHost Name（通常はtitan1._domainkey）と、v=DKIM1; k=rsa; p=…で始まる長いTXT Valueが表示されます。両方を正確にコピーしてください。値はアカウントごとに固有で、推測はできません。
- 5
DNSホストにDKIMのTXTレコードを公開
Titanから提示されたホスト（例：titan1._domainkey）でTXTレコードを作成し、v=DKIM1; k=rsa; p=…の値全体を貼り付けます。ホストは表示どおりに入力してください。ほとんどのレジストラではtitan1._domainkeyだけを入力すればドメインが自動で付加されるので、ドメイン全体を重ねて入力しないよう注意します。公開鍵が非常に長くてもそのまま貼り付けてください。管理画面によっては255文字ごとに自動で分割されます。
- 6
Control PanelでDKIMを確認
TitanのEmail Reputation / DKIM画面に戻り、「I've added TXT records in my DNS control panel」にチェックを入れてVerify changesをクリックします。DNSレコードがすでに正しくても、この再確認が成功するまでTitanはその鍵で署名を始めません。ステータスはVERIFIEDに変わるはずです。その前にDNSの反映を待つ必要があるため、TTLの時間（最大で数時間）を見込んでください。
- 7
DMARCレコードを追加（p=noneから開始）
ホスト_dmarcに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comのTXTレコードを作成します。p=noneは配信に影響を与えずに監視するため、その間にSPFとDKIMの両方が成功し、自社ドメインとアライメントが一致していることを確認できます。ruaアドレスには、自社ドメインを名乗って送信しているすべての送信元を示すXML形式の集計レポートが届きます。実際に読むメールボックスを指定してください。Titanではデフォルトの緩和されたアライメントで成功するため、adkim=s/aspf=sを追加する必要はありません。
- 8
確認してからDMARCポリシーを引き上げる
すべてのレコードが解決されることを確認し（下記の確認方法を参照）、Gmailアカウントにテストメールを送って、「Show original」でSPF=PASS、DKIM=PASS、DMARC=PASSと表示されていることを確認します。レポートでアライメントの一致が1～2週間続いたら、DMARCをp=quarantine、最終的にp=rejectへと引き上げ、なりすましを積極的にブロックします。
追加するレコード
正確な値はTitanのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| MX | @ | mx1.titan.email優先度10。受信専用で、メールボックスには必要ですが、送信メールの認証には関係しません。 |
| MX | @ | mx2.titan.email優先度20。セカンダリのメールエクスチェンジャーです。 |
| TXT | @ | v=spf1 include:spf.titan.email ~allSPFレコードは1つのドメインにつき1つです。他のサービスからも送信する場合は、~allの前にそれらのメカニズムをこの1つのレコードにまとめてください。 |
| TXT | titan1._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC… (unique key from your Control Panel)例です。セレクターのホストと公開鍵は、TitanのEmail Reputationパネルでアカウントごとに生成されます。Titanに表示される正確なホストと値をコピーしてください。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comp=noneで監視から始め、その後quarantine、rejectへと進めます。ruaは実際に読むメールボックスに向けてください。_dmarcレコードは1つのドメインにつき1つです。Titanではデフォルトの緩和されたアライメントで成功します。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Titanの設定がこの上限のうち何回を消費するかは、次のとおりです。
Titanは10回のルックアップのうち4回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
TitanのDKIMでは、アカウントごとの鍵をControl Panel内で生成します。CNAMEによる委任はなく、鍵を公開してTitanで再確認するまでは何も署名されません。TitanアカウントのManage / Admin loginからEmail Reputationを開き、DKIMを見つけて鍵ペアを生成します。Titanは秘密鍵を保持して送信メールに署名し、Host Name（通常はtitan1._domainkey）と、v=DKIM1; k=rsa; p=…で始まるTXTの値を表示します。表示されたホストをそのまま使い、DNSホストにTXTレコードとして公開してください。その後Titanに戻り、追加したことを確認してVerify changesをクリックすると、ステータスがVERIFIEDに変わります。鍵はアカウントごとに固有のため、他のドメインやドキュメントからコピーすることはできません。ドメインのDNSがCloudflareにある場合は、TXTレコードをDNS-onlyのままにしてください（TXTにプロキシは適用されませんが、古いゾーンではなく、Titanのネームサーバーが解決する権威を持つゾーンを編集していることを確認してください）。
DMARC
TitanはDMARCを作成しません。_dmarcホストにTXTレコードを手動で追加してください。配信に影響を与えず監視できるよう、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comから始め、ruaは確認しているメールボックス（またはレポート解析サービス）に向けてください。DMARCの成功条件は、SPFまたはDKIMのいずれかが成功し、かつFromドメインとアライメントが一致することです。Titanはその両方に対応しています。include:spf.titan.emailの経路ではエンベロープ送信者が利用者である自社のドメインになるためSPFのアライメントが一致し、鍵の生成と確認が済めばDKIM署名にd=yourdomain.comが入るためDKIMのアライメントも一致します。通常は両方の成功を確認できます。Titanはルートドメインそのもので送信するので、デフォルトの緩和されたアライメントで問題なく成功します。厳格なアライメント（adkim=s/aspf=s）を強制する必要はなく、後でサブドメインや別のツールから送信する際に壊れやすくなるだけです。問題のない集計レポートが1～2週間続いたら、p=quarantine、続いてp=rejectへと引き上げ、自社ドメインのなりすましを積極的に阻止します。送信元がいくつあっても、_dmarcレコードはドメイン全体で1つだけにしてください。
正しく設定できたか確認する
コマンドラインでDNSを確認します：dig TXT yourdomain.com（SPF）、dig TXT titan1._domainkey.yourdomain.com（DKIM）、dig TXT _dmarc.yourdomain.com（DMARC）。Windowsではnslookup -type=TXTを使えます。MXはdig MX yourdomain.comまたはmxtoolbox.comで確認します。Titanでは、Email ReputationパネルでDKIMがVERIFIED、Domain Verificationが完了と表示されているはずです。最も確実なテストは、TitanのメールボックスからGmailアカウントへメールを送り、「Show original」を開いて、SPF: PASS、DKIM: PASS、DMARC: PASSと自社ドメインが表示されていることを確認する方法です。3つのレコードとアライメントを1つのレポートにまとめて確認するには、Qualisendの送信ドメイン認証チェックとドメイン診断でドメインをチェックしてください。
よくある注意点
- 認証失敗の原因
DKIM鍵は最初にTitanで生成する必要があります。鍵を推測したり使い回したりはできません。値はアカウントごとに固有で、公開後に「Verify changes」をクリックするまでは、DNSレコードがすでに有効でもTitanはメールに署名しません。
- 認証失敗の原因
SPFレコードを2つ公開してはいけません。別のサービス用のv=spf1行がすでにある場合は、その1つのレコードにinclude:spf.titan.emailを追加してください。2つ目のSPFのTXTレコードがあると、SPFはpermerrorで失敗します。
- 認証失敗の原因
Titanのincludeだけで、SPFの10回のルックアップのうち約4回を消費します（spf.titan.emailは_spf1/_spf2/_spf3をネストし、インラインのip4範囲も含みます）。他のツールからも送信する場合は10回の上限に注意してください。超えるとSPFがpermerrorになります。
- 適用範囲
~allを早まって-allに変更しないでください。Titanのデフォルトは~all（softfail）です。-allに強化するのは、Titanとその他を含め、正当な送信者がすべて含まれていると確信できてからにしてください。そうしないと自社のメールがバウンスします。
- DNS設定
ホスト欄でのドメインの二重付加：ほとんどのレジストラはドメインを自動で付加するため、DKIMのホストはtitan1._domainkey.yourdomain.comではなくtitan1._domainkeyと入力します。ドメインが二重になると、気づかないうちにレコードが機能しなくなります。
- 適用範囲
Control Panelは、ホスティング会社（Hostinger、Bluehost、hosting.com、A2、Crazy Domains）によってホワイトラベル化されている場合があります。メニューのブランド表示は異なることがありますが、流れ（Manage/Admin login → Email Reputation → DKIM → Verify changes）は同じです。
- 認証失敗の原因
MXレコードは認証ではありません。mx1/mx2.titan.emailを追加すればメールを受信できますが、SPF/DKIM/DMARCには何の効果もありません。送信メールがGmailとYahooで認証に成功するには、3つのレコードすべてが別途必要です。
- 適用範囲
権威を持つゾーンを編集してください。ドメインがレジストラのデフォルトDNSではなく外部のネームサーバー（Cloudflareなど）を使っている場合は、ネームサーバーが実際に解決する場所にレコードを追加します。そうしないとTitanの確認は失敗し続けます。
SPFレコードを作成
以下ではTitanがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証TitanのSPFに関するよくある質問
関連記事
ワークスペース・メールボックスの他のサービス
- Yandex 360
- Zoho Mail
- Apple iCloud+ Custom Email Domain
- Fastmail
- Google Workspace
- mailbox.org
- Microsoft 365
- Microsoft 365 (GoDaddy / IONOS)
公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。