Zoho CRMのSPF・DKIM・DMARC設定。
Zoho CRMでは、送信ドメインの認証をSetup → Channels → Email → Email Deliverability → Email Authenticationの1か所で行います。ここでドメインを追加し、メールで届くコードで確認すると、DNSに公開するDKIMレコード（必須）とSPFの値（推奨）がZohoから提示されます。つまずきやすいのは次の点です。Zoho CRMはZoho独自のトランザクションメール基盤（transmail.net）を通じて、Zohoが所有するエンベロープ送信者/Return-Pathでメールを送信するため、SPFは自社ドメインとアライメントが一致しません。そのため、自動生成されたセレクターと公開鍵を持つTXTレコードであるDKIMが、DMARCの成功を実際に担うメカニズムになります。ZohoがDKIMを必須とし、SPFを推奨にとどめているのはこのためです。DMARCは3つ目の独立したレコードで、自分で追加します。DKIMの検証を完了してDMARCを公開すれば、CRMのメールは「via zoho」の注記が付くことなく、自社ドメインとして認証されます。
Zoho CRMを認証すべき理由
Zoho CRMのドメイン認証は、営業・マーケティングメールが受信トレイに届くかどうかを左右します。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook.com/Hotmail/Live宛ての大量メールに同じ要件の適用を始めました。シーケンス、一括メール、ワークフロー通知を送るZoho CRMは本質的に大量送信者であり、これらの要件が直接関わってきます。認証するまでは、Zohoが独自のドメインで送信メールに署名します。そのため受信者には、暗号的には自社ドメインからのメールではないことがわかり、Fromアドレスのアライメントは一致せず、DMARCにも成功できません。Zoho固有の事情として、DKIMが欠かせない理由もあります。Zoho CRMはSMTPのエンベロープ送信者に、Zohoが所有するドメイン（transmail.netの送信基盤上）を使います。そのためSPFは常にZohoに対して評価され、Fromドメインに対して評価されることはなく、アライメントも一致しません。Zoho自身のトラブルシューティング案内にも明記されています。DKIMを設定すればSPFのアライメントが一致しなくてもDMARCに成功し、DKIMを省くとアライメントが一致する認証は何も残りません。DKIMとDMARCポリシーを設定することで、「via」タグが消え、DKIMのアライメントでDMARCに成功し、自社ドメインの送信者レピュテーションを築けます。
Zoho CRMにおけるSPFの実情
ZohoはZoho CRMを「include」型サービスとして案内しています。Email Deliverabilityページに、ルートドメインにある1つのSPF TXTレコードへまとめるZohoのSPF値が表示され、USデータセンターの場合はv=spf1 include:zoho.com ~allです。公開はしてください。ただし、CRMメールに対して何ができて何ができないのかを正確に理解しておく必要があります。Zoho CRMはZohoのトランザクションメール基盤（transmail.net）を通じて、Zohoが所有するエンベロープ送信者/Return-Pathで送信します。そのためCRMメールのSPFチェックはZohoのドメインとZohoのSPFレコードに対して評価され、自社ドメインのSPFは参照すらされず、Fromドメインとアライメントが一致することもありません。一部のZohoの設定でinclude:transmail.netが表示されるのもこのためです。エンベロープは自社ドメインではなくZohoのドメインなので、自社のSPFに追加してもCRMメールには何の変化もありません。EasyDMARCなどが追加の「必要はない」としているのはこのためです。DMARCがSPFを評価するのはアライメントが一致した場合だけなので、CRMメールではSPFは何の役にも立ちません。ZohoがDKIMを必須とし、SPFを「推奨」にとどめているのは、まさにこのためです。では、なぜinclude:zoho.comを公開するのでしょうか。同じドメインでZoho Mailのメールボックス（場合によってはZoho Campaignsも）を運用していることが多いからです。これらのメールではエンベロープが自社ドメインになり、SPFは自社のレコードに対して評価され、アライメントも一致します。そのため、このincludeが正しいSPFであり、必須です。メールボックスがGoogle WorkspaceやMicrosoft 365にある場合は、Zohoではなくそれらのincludeをまとめてください。注意点は2つあります。1つ目はデータセンターです。include:zoho.comはUS用で、EUはinclude:zoho.eu、インドはinclude:zoho.in、オーストラリアはinclude:zoho.com.au、中国はinclude:zoho.com.cn、日本はinclude:zoho.jpを使います。ZohoアカウントのURLのリージョンに合わせてください。2つ目は、include:zoho.comがフラットではない点です。include:spf.zoho.com、include:zcsend.net、include:spf.zohomail.com、include:popspf.zohomail.comをネストしているため、10回のSPF DNSルックアップ（RFC 7208）のうち約5回を消費します。Zoho Mailのみを運用している場合はinclude:zohomail.comのほうがはるかに軽く（約2回）、複数のZohoサービスを運用している場合はinclude:one.zoho.comで1つのincludeにまとめられます。SPF TXTレコードはドメインに必ず1つだけにし、includeを他の送信元と同じレコードにまとめてください。SPFレコードが2つあると、それ自体がPermErrorになります。
2つの設定方法
DKIMによるドメイン認証（必須、DMARCの成功を担う）
- Zoho CRMでは必須：自動生成のセレクターと公開鍵を持つTXTレコードです
- d=yourdomain.comで署名するため、アライメントが一致してDMARCに成功します
- CRMメールでアライメントが一致する唯一のメカニズムです。ここではSPFのアライメントは一致しません
- 公開後、Email Deliverabilityページで検証します
SPFのinclude:zoho.com（推奨、補助のみ）
- ルートドメインのSPFにまとめるv=spf1 include:zoho.com ~allがZohoから提示されます
- CRMメールでは自社ドメインのSPFは評価すらされない（transmail.net上のエンベロープをZohoが所有している）ため、DMARCの成功を担えません
- 同じドメインのZoho Mailのメールボックスにとっては、これがアライメントの一致する正しいSPFです
- 10回のSPFルックアップのうち約5回を消費します。必要に応じてデータセンター別の値や、より軽い値を使ってください
設定手順
- 1
Email Authenticationを開く
管理者としてサインインし、Setup → Channels → Email → Email Deliverabilityに移動し、Email Authenticationタブを開きます。ここでZohoがDKIM（必須）とSPF（推奨）のレコードを生成します。DMARCはここにはなく、DNSホストで自分で追加します。
- 2
送信ドメインを追加して確認
+ Add Domainをクリックし、CRMメールを送信するドメインのFromアドレス（例：sales@yourdomain.com）を入力します。Zohoがそのアドレスに確認コードをメールで送るので、入力して（Enter Code → Verify）ドメインの管理権限を確認します。確認が完了すると、公開するDKIMとSPFのレコードが表示されます。
- 3
DKIMレコードをコピー
ZohoにDKIMのTXTレコードが表示されます。Hostは<selector>._domainkeyの形式（セレクターは機械生成の長い文字列で、1522905413783のような数値やタイムスタンプの値が多い）で、Valueはv=DKIM1; k=rsa; p=…で始まります。両方を正確にコピーしてください。Zohoが表示するSPFの値（include:zoho.comまたはデータセンター別の値）も控えておきます。後でValidate Recordsをクリックするので、このページは開いたままにします。
- 4
DKIMのTXTレコードを公開
DNSホストで、ホストを<selector>._domainkey、値をZohoのv=DKIM1; k=rsa; p=…の文字列にしてTXTレコードを追加します。タイプはTXTのままにしてください（Zoho CRMのDKIMはCNAMEではなくTXTレコードです）。レジストラがドメインを自動で付加する場合は、完全なFQDNではなく<selector>._domainkeyだけを入力します。
- 5
SPFのincludeを追加（既存なら1つにまとめる）
ルートドメイン（ホストは@または空欄）に、v=spf1 include:zoho.com ~all、またはデータセンター別の値（zoho.eu、zoho.in、zoho.com.au、zoho.com.cn、zoho.jp）を公開します。v=spf1のレコードがすでにある場合は、2つ目のSPF TXTを追加せず、その1つのレコードにincludeをまとめてください。このincludeは10回の上限のうち約5回を消費します。そのドメインでZoho Mailのみを運用している場合はinclude:zohomail.com（約2回）を使います。
- 6
DMARCレコードを公開
ZohoはDMARCを作成しません。ホスト_dmarcに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comのTXTレコードを追加します。p=none（監視のみ）から始めれば、DKIMの署名とアライメントの一致を確認する間も、何も影響を受けません。ポリシーは後で引き上げます。
- 7
Validate Recordsをクリック
DNSの反映後（通常は数分、最大24～48時間）、Email Deliverabilityに戻り、そのドメインのValidate Recordsをクリックします。DKIMはvalidatedと表示される必要があり、それまでZohoは、そのドメインの鍵でメールに署名しない場合があります。検証が進まない場合は、セレクターのホストでドメインが二重になっていないか、TXTの値が途中で切れていないかを確認してください。
- 8
テストメールを送信してヘッダーを確認
CRMメールをGmailアカウント宛てに送信して開き、⋮ → Show originalを選びます。DKIM: PASSとd=yourdomain.com、そしてDMARC: PASSと表示されていれば成功です。SPFには通常、自社ではなくZohoのエンベロープドメインが表示されます（アライメントは一致しません）。これはZoho CRMでは想定どおりで、DKIMのアライメントがDMARCの成功を担うので問題ありません。
- 9
確認済みのFromアドレスを使う
ユーザーやワークフローが使うFromアドレスが認証済みドメインのものであり、CRMで確認済みのFromアドレスとして設定されていることを確かめてください。無料アドレス（gmail.com）や未認証ドメインから送信するメールは自社としてDKIM署名されず、この設定の効果を得られません。
追加するレコード
正確な値はZoho CRMのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | 1522905413783._domainkey | v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…(public key from Zoho's Email Deliverability page)必須です。これは例で、セレクター（._domainkeyの前の数字）と鍵は、Zoho CRMがドメインごとに自動生成します。正確なHostとValueはEmail Authenticationからコピーしてください。CNAMEではなくTXTレコードです。 |
| TXT | @ | v=spf1 include:zoho.com ~allルートドメインのSPF：推奨。データセンター別の値（zoho.eu、zoho.in、zoho.com.au、zoho.com.cn、zoho.jp）を使います。SPFレコードは1つだけにし、このincludeをまとめてください。DNSルックアップを約5回消費します。注：CRMから送信するメールでは、自社ドメインのSPFは評価すらされません（transmail.net上のエンベロープをZohoが所有しています）。DMARCの成功を担うのはDKIMで、このincludeのアライメントが一致するのは同じドメインのZoho Mailのみです。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com自分で追加します。Zohoが作成することはありません。ドメインごとに1つで、p=noneから始めます。CRMメールはDKIMのアライメントで成功するため、quarantine/rejectへ引き上げる前にDKIMを検証してください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Zoho CRMの設定がこの上限のうち何回を消費するかは、次のとおりです。
Zoho CRMは10回のルックアップのうち5回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
Zoho CRMで最も重要なレコードはDKIMです。自社ドメインとアライメントが一致する唯一のメカニズムだからです。Email Deliverability → Email Authenticationページで、ZohoがDKIMレコードを生成します。TXTレコード（Google WorkspaceやMicrosoft 365とは異なり、CNAMEではありません）で、Hostは<selector>._domainkey.yourdomain.com、Valueはv=DKIM1; k=rsa; p=<public key>です。セレクターはZohoが割り当てる機械生成の長い文字列（1522905413783のような数値やタイムスタンプの値が多い）で、「zoho」のようなわかりやすい名前ではありません。Zohoに表示されたものをそのままコピーしてください。そのTXTを表示どおりにDNSホストで公開します。レジストラがドメインを自動で付加する場合は、二重にならないよう<selector>._domainkeyのラベルだけを入力します。次に、多くの人が飛ばしてしまう手順ですが、Zohoに戻ってValidate Recordsをクリックします。これでZohoが鍵を確認し、署名を開始します。対応する秘密鍵はZohoが保持してCRMの送信メールに署名するため、検証が完了するとメールにはd=yourdomain.comのDKIM署名が付きます。Zoho CRMは独自のエンベロープ送信者を使いSPFのアライメントが一致しないため、このDKIM署名がDMARCの成功を担います。DKIMの設定を完了すればSPFのアライメントが一致しなくてもDMARCに成功することは、Zoho自身もドキュメントに明記しています。失敗のパターンは2つあります。2048ビットの公開鍵はTXTの1文字列255文字の上限を超えることがあり、引用符で囲んだ分割チャンクとして保存する必要があります（多くの管理画面はこれを自動で処理します）。また、公開したレコードが検証に通らない原因の多くは、鍵が壊れている、または途中で切れていることです。
DMARC
DMARCは独立したポリシーレコードで、自分で公開します。Zoho CRMが作成することはありません。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを追加します。p=noneは監視のみで、配信には何も影響しません。その間に受信側から集計レポート（rua）がメールで届くので、Zoho CRMのメールがDKIMに成功し、自社ドメインとアライメントが一致していることを確認できます。この確認は、他の多くの送信者よりもZohoでは特に重要です。SPFのアライメントが一致しない（エンベロープ送信者をZohoが所有している）ため、DMARCは完全にDKIMのアライメントに依存します。レポートでCRMメールがDKIMに成功していることを確認するまでは、ポリシーを引き上げないでください。1～2週間ruaレポートを確認し、ドメイン上の正当な送信者（Zoho CRM、Zoho Mail、サードパーティツール）がすべて認証されていることを確かめてから、p=quarantine、最終的にp=rejectへと段階的に引き上げます。送信者がいくつあっても、_dmarcレコードは組織ドメイン全体で1つだけにしてください。Zohoのためだけに2つ目のDMARCレコードを追加してはいけません。なお、GoogleとYahooの大量送信者向けルールが最低限求めているのはp=noneだけですが、攻撃者によるドメインのなりすましを実際に防ぐのはp=rejectです。
正しく設定できたか確認する
Zohoの「validated」バッジだけで判断せず、実際のメールで確認してください。CRMメールをGmailアカウント宛てに送信して開き、⋮ → Show originalを選びます。DKIM: PASSとsigned-by / d=yourdomain.com、そしてDMARC: PASSと表示されていれば成功です。SPFには自社ではなくZohoのエンベロープドメインが表示され、アライメントが一致しないと報告されるはずです。これはZoho CRMでは正常で失敗ではありません。DMARCを満たすのはDKIMのアライメントだからです。Zoho側では、Email Deliverabilityページでドメインがvalidatedと表示されていることを確認します。生のレコードは、dig TXT <selector>._domainkey.yourdomain.comとdig TXT _dmarc.yourdomain.comで確認できます。その後、Qualisendのドメイン診断でドメインをチェックし、DKIM、SPF、DMARCのレコードがすべて解決され、SPFがDNSルックアップの10回制限内に収まっていることを確認します（include:zoho.comだけで約5回を消費します）。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップしてください。SPFのアライメントが一致していなくても、ZohoはDKIMのアライメントが一致して成功している送信元として表示されるはずです。
よくある注意点
- DNS設定
DKIMは任意ではなく必須です。Zoho CRMは独自のエンベロープ送信者のドメイン（transmail.net上）で送信するため、SPFは自社ドメインとアライメントが一致しません。DMARCの成功を担う唯一のメカニズムは、d=yourdomain.comで署名されたDKIMです。SPFだけを公開してDKIMを省くと、アライメントが一致する認証は何も残りません。
- 認証失敗の原因
CRMメールだけなら、自社ドメインのSPFは関係ありません。SPFチェックは自社ではなくZohoのエンベロープドメインとZohoのSPFに対して行われるため、include:zoho.com（またはinclude:transmail.net）を追加してもCRMメールには何の効果もありません。意味があるのは、同じドメインでZoho MailやZoho Campaignsからも送信し、エンベロープが自社ドメインになってSPFのアライメントが一致する場合だけです。
- DNS設定
include:zoho.comのDNSルックアップは1回では済みません。include:spf.zoho.com、include:zcsend.net、include:spf.zohomail.com、include:popspf.zohomail.comをネストしているため、10回のSPFルックアップのうち約5回を消費します。Zoho Mailのみ（Zoho Campaignsなし）ならinclude:zohomail.comのほうが軽く（約2回）、複数のZohoサービスならinclude:one.zoho.comでまとめられます。
- 適用範囲
データセンターによってincludeは変わります。USのアカウントはinclude:zoho.comですが、EUはinclude:zoho.eu、インドはinclude:zoho.in、オーストラリアはinclude:zoho.com.au、中国はinclude:zoho.com.cn、日本はinclude:zoho.jpを使います。誤ったリージョンのincludeでは正しいサーバーが許可されません。ZohoアカウントのURLのドメインに合わせてください。
- DNS設定
Zoho CRMのDKIMはCNAMEではなくTXTレコードです。Google WorkspaceやMicrosoft 365（セレクターのCNAMEを使用）とは異なり、Zohoの公開鍵を<selector>._domainkeyのTXTレコードに貼り付けます。CNAMEとして追加すると検証に失敗します。
- DNS設定
ホスト欄のドメイン重複：多くのレジストラはドメインを自動で付加するため、<selector>._domainkey.yourdomain.comと入力すると<selector>._domainkey.yourdomain.com.yourdomain.comになります。管理画面がドメインを付加する場合は、ラベルの<selector>._domainkeyだけを入力してください。
- DNS設定
DKIMレコードは公開するだけでは足りません。ZohoのEmail Deliverabilityページに戻ってValidate Recordsをクリックする必要があります。ドメインがvalidatedと表示されるまで、Zohoはそのドメインの鍵でメールに署名しない場合があります。
- 適用範囲
Fromアドレスは、認証済みドメインの確認済みアドレスでなければなりません。無料アドレス（gmail.com、outlook.com）や別のドメインから送信するメールは自社としてDKIM署名されず、効果を得られません。
SPFレコードを作成
以下ではZoho CRMがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証Zoho CRMのSPFに関するよくある質問
関連記事
ヘルプデスク・CRMの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。