Zoho DeskのSPF・DKIM・DMARC設定。
Zoho Deskはヘルプデスクプラットフォームです。ここで認証の対象になるのは、support@yourdomain.comのようなアドレスからZohoのサーバーを通じて送信される、チケットへの返信、担当者の回答、通知のメールです。設定の要は、主役のメカニズムと、それを補うものの2つです。Zoho Desk内で有効にするDKIM（Setup → Channels → Email → DKIM Authentication）と、自分で公開するDMARCポリシーです。Zoho Mailとの違いは次の点です。Deskはバウンスを管理するためにReturn-Path（エンベロープ送信者）に独自のドメインを使うので、SPFはFromドメインとアライメントが一致しません。したがって、DeskのメールでDMARCの成功を担えるメカニズムはDKIMだけです。Desk自体のためにルートドメインへ追加すべき共有のSPFのincludeはありません。include:zoho.comが関係するのは、同じドメインでZoho Mailのメールボックスも運用している場合だけです。
Zoho Deskを認証すべき理由
Zoho Deskの認証は、サポートの返信が顧客の迷惑メールフォルダーではなく受信トレイに届くかどうかを左右します。返信がフィルターされてチケットが未回答に見えるなら、到達率だけでなくサポート業務そのものの失敗です。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook.com/Hotmail/Live宛ての大量メールに同じ要件の適用を始めました。Zoho Deskには固有の注意点があります。独自のMail-From（バウンス）ドメインを使うため、SPFは常に自社ではなくZohoのドメインに対して評価され、チェック自体に成功してもアライメントは一致しません。つまり、DMARCに成功する唯一の経路はDKIMです。DKIMを省くと、Deskのメールにはアライメントが一致する認証が何もなくなります。DMARCに失敗し、GmailがZohoの代理で送信されたと表示することがあり、築いた送信者レピュテーションは未認証の他のZohoテナントと共有されます。カスタムドメインのDKIMを有効にすれば、Deskはd=yourdomain.comで署名し、DKIMのアライメントによりp=rejectでもDMARCに成功し、レピュテーションは自社ドメインに蓄積されます。
Zoho DeskにおけるSPFの実情
Zohoは実在する共有include（include:zoho.com）を公開していますが、Zoho DeskはZoho Mailとは異なり、Return-Pathを自ら持つメール配信サービス（ESP）のように動作します。そのためDeskのメールに関しては、ルートドメインのSPFに追加して役立つものは実質的にありません。理由は次のとおりです。Zoho Deskはすべてのメールを、独自のバウンス用ドメインにあるエンベロープ送信者 / Return-Pathで送信します（バウンスを処理するのは自社ではなくZohoです）。SPFは常にこのエンベロープドメインに対してチェックされるので、Zohoのサーバーに対して解決され、組織ドメイン（From）とアライメントが一致することはありません。チェック自体は成功する場合がありますが、DMARCがSPFを評価するのはアライメントが一致した場合だけです。そのため、ルートドメインのSPFにinclude:zoho.comを追加しても、DeskのDMARCアライメントには何の効果もありません。DeskのDKIM Authenticationの手順がDKIMを中心に作られているのはこのためです。ZohoのSPFとDKIMをまとめた「SPF and DKIM」のドキュメントにSPFの値が記載されている場合でも、DeskではそのSPFのアライメントは一致しません。実際にアライメントが一致してDMARCの成功を担うのは、d=yourdomain.comで署名されたDKIMです。include:zoho.comが意味を持つのは、同じドメインでZoho Mailのメールボックスも運用している場合です（Deskの顧客には非常によくある構成です）。Zoho Mailではエンベロープ送信者に自社ドメインが使われるのでSPFのアライメントが一致します。そのメールのために、ルートドメインの1つのSPFレコードにincludeを追加します（例：v=spf1 include:zoho.com ~all）。追加する場合に知っておくべきことが2つあります。1つ目に、include:zoho.comは重いincludeです。Zohoのサブレコードを4つ（spf.zoho.com、zcsend.net、spf.zohomail.com、popspf.zohomail.com）ネストしているため、10回のSPF DNSルックアップのうち約5回を消費します。Zoho Mailのみ（スイート全体ではなく）を運用している場合は、より軽いinclude:zohomail.comでおよそ2回です。2つ目に、このincludeはデータセンターによって異なります。EUのアカウントはinclude:zoho.eu、インドはinclude:zoho.in、オーストラリアはinclude:zoho.com.auを使うので、アカウントのリージョンに合わせてください。また、SPF TXTレコードはドメインに必ず1つだけにし、2つ目を公開せず、すべての送信元をこの1行にまとめてください。
2つの設定方法
DKIM：Deskを認証するメカニズム（必須）
- Zoho Desk内で有効にします：Setup → Channels → Email → DKIM Authentication → Verify
- Deskでアライメントが一致する唯一のメカニズムであり、DeskのメールをDMARCに成功させます
- Zohoがd=yourdomain.comで署名し、秘密鍵を保持してローテーションも行います
- SPFのアライメントが一致しなくても機能し、メーリングリストへの転送後も有効です
SPFのinclude:zoho.com（任意、Zoho Mail用のみ）
- Zoho DeskのメールではSPFのアライメントは一致しません（Return-PathをDeskが持っています）
- 追加する価値があるのは、同じドメインでZoho Mailのメールボックスも運用している場合だけです
- 10回のルックアップ上限に対して約5回を消費する重いincludeです（ZohoのSPFレコードを4つネストしています）
- ルートドメインの1つのSPFの行にまとめ、2つ目のSPF TXTレコードは絶対に公開しないでください
設定手順
- 1
Fromアドレスを追加して確認
Support Administratorとしてサインインし、Setup（歯車アイコン）→ Channels → Emailを開いて、From AddressタブでNew From Addressをクリックします。部署、送信アドレス（例：support@yourdomain.com）、表示名を入力してSaveします。Zohoがそのアドレスに確認メールを送るので、リンクをクリック（またはコードを貼り付け）して確認します。これが完了するまで、そのアドレスの認証も送信もできません。
- 2
DKIM Authenticationを開く
同じくSetup → Channels → Emailで、DKIM Authenticationタブを選択します。一覧で送信ドメインを見つけ、その横のVerifyをクリックします。これらの設定にアクセスできるのはSupport Administratorのみです。
- 3
DKIMレコードをコピー
Zoho Deskに公開するDKIMレコードが表示されます。一般的には2つのTXTタイプのレコードです。それぞれHost/Nameは<selector>._domainkey.yourdomain.comの形式（Zohoの例ではセレクターはzohoです）で、Valueはv=DKIM1; k=rsa; p=<long public key>で始まります。ホストと値はそれぞれ正確にコピーしてください。セレクターと鍵はアカウントごとに生成されます。
- 4
DKIMのTXTレコードを公開
DNSホストで、それぞれをTXTレコードとして作成します。HostはZohoから提示されたセレクターのラベル（例：zoho._domainkey）で、v=DKIM1; k=rsa; p=...の値全体を貼り付けます。レジストラがドメインを自動で付加する場合は、二重にならないよう完全な...yourdomain.comではなくラベルだけを入力します。Zohoに2つ表示された場合は両方追加してください。タイプはTXTのままにします。
- 5
DMARCレコードを公開
ZohoはDMARCを作成しません。ホスト_dmarcに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comのTXTレコードを追加します。p=none（監視のみ）から始めれば、DKIMのアライメントの一致を確認する間も、何も影響を受けません。_dmarcレコードがすでにある場合はこの手順を飛ばしてください。_dmarcレコードは1つのドメインに1つだけです。
- 6
（Zoho Mailも運用する場合のみ）SPFのincludeを追加
この手順はZoho Deskのメールには不要です。同じドメインでZoho Mailのメールボックスも運用している場合にのみ行います。ルートドメインの1つのSPFレコードに、include:zoho.com（またはリージョン別の値：zoho.eu、zoho.in、zoho.com.au）をまとめます（例：v=spf1 include:zoho.com ~all）。10回のSPFルックアップのうち約5回を消費する点に注意してください。Deskのみで送信する場合は、ルートドメインのSPFに手を加えないでください。
- 7
Zoho DeskでVerifyをクリック
TXTレコードが反映されたら（通常は数分、最大24～48時間）、DKIM Authenticationタブに戻ってVerifyをクリックします。ステータスがVerifiedに変わり、ZohoがDeskのメールにd=yourdomain.comで署名を始めます。Zohoは2日ほどごとにDKIM TXTを再チェックするため、レコードは恒久的にそのまま残してください。
- 8
実際のチケットに返信してヘッダーを読む
テストチケットに返信して実際のDeskのメールをGmailのメールボックスに届け、開いて三点メニュー → Show originalを選びます。DKIM: PASSとsigned-by / d=yourdomain.com、そしてDMARC: PASSと表示されていれば成功です。SPFにはZohoのバウンス用ドメインが表示され、アライメントが一致しない、または失敗と表示されます。これはDeskでは想定どおりで問題ありません。DMARCに必要なのはアライメントが一致したメカニズム1つ（DKIM）だけだからです。
追加するレコード
正確な値はZoho Deskのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | zoho._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...(public key from Zoho Desk)例です。正確なセレクターと鍵はZoho DeskがDKIM Authenticationページで生成し、一般的には2つのTXTレコードが表示されます。それぞれ表示どおりに追加してください。DeskでDMARCの成功を担うのはこのレコードです。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com自分で追加します。Zohoが作成することはありません。ドメインごとに1つで、p=noneから始め、DKIMの確認後にquarantine/rejectへ引き上げます。 |
| TXT | @ | v=spf1 include:zoho.com ~all任意：同じドメインでZoho Mailのメールボックスも運用している場合のみ。DeskのメールではSPFのアライメントは一致せず（DeskはZohoのReturn-Pathを使います）、DNSルックアップを約5回消費します。リージョン別のinclude（zoho.eu / zoho.in / zoho.com.au）を使い、SPFレコードは1つだけにしてください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Zoho Deskの設定がこの上限のうち何回を消費するかは、次のとおりです。
Zoho Deskの推奨設定はルックアップを消費しません。10回すべてを、includeが必要な他の送信元に使えます。
DKIM
Zoho DeskではDKIMがすべてを左右します。自社ドメインとアライメントが一致し得る唯一のメカニズムだからです。Return-PathをDeskが持っているため、SPFは一致しません。最初に操作するのはDNSではなく、Zoho Desk内です。Setup → Channels → Email → DKIM Authenticationを開き、ドメインの横にあるVerifyをクリックします。Zohoが鍵を自動で用意し、公開するDKIMレコードを表示します。一般的には2つのTXTタイプのレコードで、ホストは<selector>._domainkey.yourdomain.com（Zohoの例ではセレクターはzohoです）、値はv=DKIM1; k=rsa; p=<public key>です。貼り付けるのはTXTレコードであり、対応する秘密鍵はZohoが保持してDeskの送信メールに署名します。これはZoho Mailの管理コンソールとは少し異なります。Zoho Mailでは自分でセレクターを選び、生成前に1024ビットか2048ビットを選択しますが、Deskではコピーするだけの値が提示されます。手順としては、レコードをコピーし、それぞれをDNSホストでTXTレコードとして公開し（レジストラがドメインを付加する場合はセレクターのラベルだけを入力）、反映を待ってから戻ってVerifyをクリックします。ステータスがVerifiedに変わり、Zohoがd=yourdomain.comで署名を始めます。Desk固有の注意点は2つあります。Zohoは2日ほどごとにDNSのDKIM TXTを再チェックするため、後からレコードを削除したり壊したりすると、Deskは通知なしに署名を止め、メールがDMARCに失敗し始めます。また、DKIMは（SPFと同様に）自社のSMTPサーバー経由で送信するよう設定したFromアドレスには適用されません。その場合はSMTPサービス側で認証してください。
DMARC
DMARCは独立したポリシーTXTレコードで、自分で公開します。Zoho Deskが作成することはありません。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを追加します。p=noneは監視のみで、配信には何も影響しません。その間に集計レポート（rua）で、DeskのメールがDKIMに成功し自社ドメインとアライメントが一致していることを確認できます。これは他の多くの送信者よりもDeskで重要です。SPFのアライメントは一致しない（エンベロープ送信者をZohoが所有している）ため、DMARCは完全にDKIMに依存します。Show originalとレポートの両方でDeskのメールがDKIMのアライメントが一致した状態で成功していることを確認するまでは、ポリシーを引き上げないでください。確認できたら、p=noneからp=quarantine、最終的にp=rejectへと段階的に引き上げます。DKIMが確認済みで署名が続いている限り、Deskのメールはp=rejectでも成功し続けます。_dmarcレコードは組織ドメイン全体で1つだけにしてください。サブドメインは親のポリシーを自動で継承します（サブドメインからDeskのメールを送信する場合は、そのサブドメイン独自の_dmarcレコードまたはsp=タグで上書きします）。なお、レポートではZohoの送信元でSPFのアライメントが一致しないと表示されるはずです。これはDeskでは正常で、修正すべきものではありません。
正しく設定できたか確認する
ZohoのVerifiedバッジだけで判断せず、実際のメールで確認してください。テストチケットに返信して実際のZoho DeskのメールをGmailのメールボックスに届け、開いて三点メニュー → Show originalを選びます。DKIM: PASSとd=yourdomain.com（Zohoから提示されたセレクター）、そしてDMARC: PASSと表示されていれば成功です。SPFにはZohoのバウンス用ドメイン / Return-Pathドメインが表示され、アライメントが一致しない、または失敗と表示されることもあります。これはDeskでは想定どおりで、DMARCには影響しません。DMARCはアライメントが一致したDKIM署名だけで成功するからです。DMARCの集計レポートでは、Zohoの送信元がDKIM=pass/alignedになっていることを確認します。同じメールでSPF=failの行が並んでいても問題ありません。Qualisendのドメイン診断でドメインをチェックしてDKIM TXTとDMARCレコードの両方が正しく解決されることを確認し、DMARCレポート解析に集計レポートをドロップして、Zoho DeskがDKIMのアライメントが一致し、成功している送信元として表示されることを確かめます。
よくある注意点
- 適用範囲
Zoho DeskではSPFのアライメントは一致しません。独自のReturn-Path/バウンス用ドメインを使うので、SPFは自社ではなくZohoのドメインに対して評価されます。DeskでDMARCの成功を担う唯一のメカニズムはDKIMです。レポートでZohoの送信元のSPFがアライメント不一致や失敗と表示されるのは正常で、修正すべき不具合ではありません。
- 認証失敗の原因
ルートドメインのSPFにinclude:zoho.comを追加しても、DeskメールのDMARCアライメントには何の効果もありません。追加するのは同じドメインでZoho Mailのメールボックスも運用している場合だけです。また、これは約5回のルックアップを消費する重いincludeです（spf.zoho.com、zcsend.net、spf.zohomail.com、popspf.zohomail.comをネストしています）。
- 適用範囲
先にFromアドレスを確認してください。確認メールのリンクをクリックするまで、Zoho Deskではsupport@yourdomain.comの認証も送信もできません。省略するとDKIMの手順全体が進まなくなります。
- DNS設定
Zohoは2日ほどごとにDNSのDKIM TXTを再チェックします。後からレコードを削除または編集すると、Deskは通知なしに署名を止め、メールがDMARCに失敗し始めます。恒久的に公開したままにしてください。
- 適用範囲
自社のSMTPサーバー経由で送信するよう設定したFromアドレスでは、DKIMとSPFの認証は使えません。このモードではメールがDeskから自社のサーバーを経由してリレーされるため、そのSMTPホスト側で認証する必要があります。
- DNS設定
ホスト欄のドメイン重複：多くのレジストラはドメインを自動で付加するため、zoho._domainkey.yourdomain.comと入力するとzoho._domainkey.yourdomain.com.yourdomain.comになります。DNS管理画面がドメインを付加する場合は、ラベル（zoho._domainkey）だけを入力してください。
- 適用範囲
データセンターを合わせてください。ZohoアカウントがEU、インド、オーストラリアのリージョンにある場合、SPFのincludeは異なります（include:zoho.eu、include:zoho.in、include:zoho.com.au）。関係するのはZoho Mailも運用している場合だけですが、誤った値を使うとそのSPFが機能しなくなります。
- 認証失敗の原因
SPF TXTレコードは必ず1つだけにしてください。Google Workspace、Microsoft 365などの送信者と併せてZoho Mail用にinclude:zoho.comを追加する場合は、すべてのメカニズムを1つのv=spf1の行にまとめます。SPFレコードが2つあると、それ自体がPermErrorになります。
SPFレコードを作成
Zoho Deskでは、ルートドメインにSPFのinclude:を追加する必要はありません。作成ツールを使って他の送信元用のクリーンなレコードを1つ組み立て、1行に収めてください。
送信元
メールの送信に使っているサービスを検索して、それぞれチェックを入れてください。
上の検索欄で利用中のメールサービスを検索するか、してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
送信元がまだないため、すべてのメッセージに~allポリシーが適用されます。ステップ1で利用中のサービスを追加してください。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証Zoho DeskのSPFに関するよくある質問
関連記事
ヘルプデスク・CRMの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。