FreshdeskのSPF・DKIM・DMARC設定。
Freshdeskでは、デフォルトのyourcompany.freshdesk.comのメールボックスではなく、自社のアドレス（support@yourdomain.com）から顧客に返信できます。ただしその時点で、自社ドメインのメールをFreshdeskが送信することになるため、Freshdeskが認可されていることを証明しなければなりません。認証の作業は2つです。1つはFreshdesk内のDKIMの手順で、Admin → Channels → Email → Advanced Settings → Configure DKIMから、自社ドメインとして署名するCNAMEレコードを生成します。もう1つはSPFのincludeで、DNSホストでルートドメインのレコードにまとめられます。FreshdeskがDMARCの値を提示しないので、このポリシーレコードは自分で追加します。DMARCとあわせてDKIMの確認を済ませれば、チケットの返信は「via freshdesk.com」の表示なしで受信トレイに届きます。省略すると、Gmail、Yahoo、Microsoftによって迷惑メールに振り分けられることが増えています。
Freshdeskを認証すべき理由
ヘルプデスクのメールは、迷惑メールに振り分けられると最も困るメールです。パスワードリセットの確認、チケットの返信、SLAの通知など、顧客が届くのを待っているメッセージだからです。ところが、自社ドメインのFreshdeskサポートメールは、GmailとYahooの2024年2月の送信者ガイドライン（およびMicrosoftの2025年の適用）が振り分けの対象とする「第三者が自社になり代わって送信する」メールそのものです。認証を済ませるまで、返信はFreshdeskの共有インフラから送信され、自社ドメインとの暗号的な結びつきがありません。受信者に「via」の表示が見えることがあり、DMARCにも成功できず、チケットのメールは未認証の他のFreshdeskテナントすべてのレピュテーションを引き継ぎます。Freshdesk自身も、こうしたルールを理由に、ドメインベースのサポートメールではDKIMによるドメイン確認を必須のチェックとしています。同社のドキュメントには、DKIMの確認によって、DMARCが依拠するSPFのチェックもカバーされると記載されています。DKIMに加えてSPFとDMARCを設定すれば、メールが組織ドメインに結びつき、「via」の表示が消え、チケットの返信がDMARCに成功し、共有プールではなく自社の名前で送信レピュテーションを築けます。
FreshdeskにおけるSPFの実情
Freshdeskは正真正銘の「include」型サービスです。CNAMEのみのメール配信サービス（ESP）とは異なり、実在する共有メカニズムであるinclude:email.freshdesk.comをドキュメントに記載しており、送信ドメインの単一のSPF TXTレコードに追加できます。ただし、これはFreshdeskの主要な設定手順ではなく、includeも異例なほど重いものです。実際のDNSで確認すると、email.freshdesk.comはv=spf1 include:sendgrid.net include:fdspfus.freshemail.io include:fdspfeuc.freshemail.io include:fdspfind.freshemail.io include:fdspfaus.freshemail.io ~allを公開しています。Freshdeskは一部のメールをSendGrid経由で送信し、地域別のIPプールを4つ（米国、EU、インド、オーストラリア）維持しています。これらのincludeに、sendgrid.net内にネストされたinclude:ab.sendgrid.netを加えると、1つのinclude:email.freshdesk.comで、許容される10回のDNSルックアップ（RFC 7208）のうち7回を消費します。同じドメインでGoogle WorkspaceやMicrosoft 365も重ねると、これは現実の問題になります。PermErrorになり、すべての送信元でSPFの評価が止まるからです。Freshdesk自身の解決策は、データセンターごとのincludeです。fdspfus.freshemail.io、fdspfeuc.freshemail.io、fdspfind.freshemail.io、fdspfaus.freshemail.ioのそれぞれがip4のみのフラットなレコードで、消費するルックアップは1回です。アカウントの地域のincludeだけを使えば、7回から1回に減らせます。正直に言えば、DMARCでSPFのアライメントが実際に一致するかは、Freshdeskが付けるエンベロープ送信者によって決まります。そのため、d=yourdomain.comで署名するDKIMを、DMARCの成功を支える仕組みと考えてください。Freshdesk自身もDKIMを必須のドメイン確認手順とし、DKIMの設定でSPFのチェックにも対応できると記載しているため、SPFのincludeの別途追加は求めていません。念のための保険として、include（上限に近ければ地域別のもの）を追加して認可しつつ、アライメントはDKIMに任せてください。また、ドメインのv=spf1レコードは必ず1つだけにし、2つ目を公開せずにまとめてください。
設定手順
- 1
自社ドメインのサポートメールを追加
管理者としてサインインし、Admin（歯車アイコン）→ Channels → Emailを開きます。New support emailをクリックし、返信アドレスを自社ドメインのもの（例：support@yourdomain.com）に設定します。認証が必要なのはドメインベースのサポートメールだけです。組み込みのyourcompany.freshdesk.comアドレスはFreshdeskがすでに認証しているため、作業は不要です。
- 2
DKIMの設定を開く
引き続きAdmin → Channels → Emailで、Advanced settingsを開き、Configure DKIMをクリックします。Freshdeskがドメイン固有のCNAMEレコード（通常は4つ）を生成し、それぞれ*.domainkey.freshemail.ioの配下を指します。正確なホストと値をDNSにコピーするので、この画面は開いたままにしてください。
- 3
DKIMのCNAMEレコードを公開
DNSホストで、Freshdeskに表示された各レコードを、TXTではなくCNAMEレコードとして追加します。HostとValueは1文字も変えずにそのままコピーしてください。ホスト欄にはサブドメインのラベルだけを入力します（例：fwdkim1）。fwdkim1.yourdomain.comとフルで入力すると、レジストラがドメインを二重に付加します。前後にスペースが入っていないことも確認してください。
- 4
（任意）SPFのincludeを追加（既存なら1つにまとめる）
DKIMだけでドメインの確認は完了しますが、追加の認可として、SPF TXTレコードにinclude:email.freshdesk.comを追加できます（例：v=spf1 include:email.freshdesk.com ~all）。Google、Microsoft 365、その他のサービスからすでに送信している場合は、2つ目のSPFレコードを公開せず、このメカニズムを既存の1行にまとめてください。10回の上限に近い場合は、代わりにデータセンター固有のinclude（例：include:fdspfeuc.freshemail.io）を使うと、消費するルックアップは7回ではなく1回で済みます。
- 5
CNAMEレコードのCloudflareのプロキシをオフにする
DNSがCloudflareの背後にある場合は、Freshdeskの各DKIM CNAMEレコードを「DNS only」（グレーのクラウド）に設定します。プロキシが有効（オレンジのクラウド）なCNAMEはfreshemail.ioに解決されず、DKIMの確認に失敗します。
- 6
DKIMを確認
FreshdeskのConfigure DKIM画面に戻り、Verifyをクリックします。FreshdeskがすべてのCNAMEの解決を確認し、ドメインを確認済みにします。DNSの反映は通常数分ですが、最大24～48時間かかることがあります。すぐに成功しない場合は再度確認してください。
- 7
DMARCポリシーレコードを公開
FreshdeskがDMARCの値を提示しないため、自分で作成します。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを追加します。p=noneは監視のみのため、Freshdeskのメールが自社ドメインとアライメントの一致したDKIMに成功していることを確認する間も、配信には影響しません。_dmarcレコードはドメイン全体で1つだけにしてください。
- 8
実際のチケットに返信してヘッダーを確認
Freshdeskから、管理下のGmailアカウント宛てのテストチケットに返信します。メールを開いて⋮ → Show originalを選び、DKIM: PASS（d=yourdomain.com）、DMARC: PASSを確認します。SPFにはFreshdesk（またはSendGrid）の送信IPが表示されます。Freshdeskの「Verified」バッジだけに頼らず、実際のメールで確認してください。
追加するレコード
正確な値はFreshdeskのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| CNAME | fwdkim1 | spfmx1.domainkey.freshemail.ioDKIM署名レコード：例であり、主要な設定手順です。正確なホストと参照先（通常は4つのCNAME）は、Configure DKIMの画面でFreshdeskがドメインごとに生成するので、そのままコピーしてください。TXTではなくCNAMEとして追加してください。 |
| CNAME | fwdkim2 | spfmx2.domainkey.freshemail.ioDKIMのCNAMEレコードの2つ目の例です。Freshdeskに表示されるレコード（通常は4つ）をすべて追加します。いずれも*.domainkey.freshemail.ioの配下を指し、自社ドメインとして署名します。4つのうち一部のホストには_domainkeyラベルが含まれます。Freshdeskの表示に従ってください。 |
| TXT | @ | v=spf1 include:email.freshdesk.com ~all任意のルートドメインのSPF：Freshdeskの送信IPを認可します。既存の1つのSPF行にまとめ、2つ目のSPFレコードは公開しないでください。この共有includeはDNSルックアップを7回消費します（下記の地域別の代替を参照）。DMARCでアライメントが一致するのは、このincludeではなくDKIMです。 |
| TXT | @ | v=spf1 include:fdspfeuc.freshemail.io ~all地域別の代替（例はEU）：ip4のみのフラットなレコードで、消費するルックアップは7回ではなく1回です。アカウントのデータセンターに合わせて、fdspfus / fdspfeuc / fdspfind / fdspfausから選びます。これと上の行のどちらか一方だけを使い、両方は使わないでください。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com自社のDMARCポリシーです。Freshdeskが値を提示しないため、自分で作成します。ドメインごとに1つとし、p=noneから始めて後で引き上げます。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Freshdeskの設定がこの上限のうち何回を消費するかは、次のとおりです。
Freshdeskは10回のルックアップのうち7回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
DKIMはFreshdeskの必須のドメイン確認手順であり、DMARCの成功を実際に支える仕組みで、CNAMEで委任します。Configure DKIMの画面（Admin → Channels → Email → Advanced Settings → Configure DKIM）で、Freshdeskはドメイン固有のCNAMEレコード（通常は4つ）を生成します。それぞれ*.domainkey.freshemail.ioの配下を指します（例：fwdkim1 → spfmx1.domainkey.freshemail.io、fwdkim2 → spfmx2.domainkey.freshemail.io。ただし、実際のホストと参照先はアカウント固有なので、そのままコピーしてください）。貼り付けるTXT鍵ではなくFreshdeskに委任するCNAMEなので、Freshdeskが秘密鍵を保持し、ユーザーがDNSを再び編集しなくても鍵をローテーションできます。重要なのは、このDKIMが送信するチケットのメールにd=yourdomain.comで署名する点です。Fromアドレスとアライメントが一致し、これだけでDMARCの要件を満たします。FreshdeskがDKIMを必須の確認手順とし、ドキュメントでDKIMの設定によりSPFのチェックもカバーされると記載して、SPFのincludeの別途追加を求めないのはこのためです。CNAMEはすべて、表示どおりに（TXTではなくCNAMEとして）前後にスペースを入れずに追加してください。Cloudflareでは「DNS only」（グレーのクラウド）にし、レジストラでドメインが二重にならないようサブドメインのラベルだけを入力します。その後、FreshdeskでVerifyをクリックします。
DMARC
DMARCは、ドメインに設定する別のポリシーレコードです。Freshdeskが意図的に値を提示しないため、自分で作成します。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを公開します。p=noneは監視のみのため、Freshdeskのチケットメールが自社ドメインとアライメントの一致したDKIMに成功していることを確認する間も、配信には影響しません。1～2週間、集計レポート（rua）を確認します。Freshdeskが、DKIMのアライメントが一致して成功している送信元として表示されるはずです。その後、p=quarantine、最終的にp=rejectへと段階的に引き上げます。利用する送信者の数（Freshdesk、Google Workspace、Microsoft 365など）にかかわらず、組織ドメイン全体で_dmarcレコードは1つだけにしてください。Freshdesk専用のDMARCレコードを追加してはいけません。サポートメールがsupport@help.yourdomain.comのようなサブドメインにある場合も、組織ドメインのDMARCでカバーされますが、SPFとDKIMのレコードはそのサブドメインに置く必要があります。
正しく設定できたか確認する
Freshdeskの「Verified」バッジだけで判断せず、実際のメールで確認してください。Freshdeskから、管理下のGmailアドレス宛てのテストチケットに返信し、返信を開いて⋮ → Show originalを選びます。DKIM: PASS（d=yourdomain.com）、DMARC: PASSと表示されていれば成功です。SPFにはFreshdeskまたはSendGridの送信IPが表示されます（認可はしますがアライメントが一致するとは限らず、アライメントを支えるのはDKIMです）。詳しいレポートが必要な場合は、check-auth@verifier.port25.comにFreshdeskからテストを送ると、内訳がメールで届きます。Qualisendのドメイン診断でドメインをチェックし、すべてのCNAMEとSPF、DMARCのレコードが解決されることを確認することもできます。SPFのルックアップ数にも注意してください。include:email.freshdesk.comだけで10回のうち7回を消費します。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップし、Freshdeskがアライメントの一致した、成功している送信元として表示されることを確認してください。
よくある注意点
- 適用範囲
本当に必要な手順はSPFではなくDKIMです。FreshdeskはドメインベースのサポートメールでDKIMによるドメイン確認を必須のチェックとしており、DMARCでアライメントが一致するのもDKIM（d=yourdomain.com）です。SPFのincludeは任意で、念のための保険です。SPFの1行で足りると考えてDKIMを省略しないでください。
- 認証失敗の原因
このincludeはルックアップを大量に消費します。include:email.freshdesk.comはSendGrid（およびそのab.sendgrid.net）と4つの地域プールすべてをネストしており、この1行だけで、SPFのDNSルックアップ10回のうち7回を消費します。Google WorkspaceやMicrosoft 365と重ねると、PermErrorになることがあり、そうなるとドメイン全体でSPFの評価が止まります。追加するなら、データセンター別のinclude（fdspfus / fdspfeuc / fdspfind / fdspfaus.freshemail.io）を使ってください。それぞれ1回です。
- DNS設定
カスタムメールボックスではすべてが変わります。カスタムメールボックスや独自の送信SMTP（またはGoogle/Microsoftの「send-as」）を設定すると、FreshdeskはFreshdesk自身のサーバーではなく、お使いのサーバーを経由して中継します。この場合、FreshdeskのSPFのincludeとDKIMのCNAMEレコードは適用されません。その送信サービス側で認証してください（例：include:_spf.google.comとGoogleのDKIM）。
- DNS設定
ホスト欄の重複：多くのレジストラ（特にGoDaddy）はドメインを自動で付加するため、fwdkim1.yourdomain.comと入力するとfwdkim1.yourdomain.com.yourdomain.comになり、確認に失敗します。管理画面がドメインを付加する場合は、ラベル（fwdkim1）だけを入力してください。
- DNS設定
CNAMEでありTXTではありません：FreshdeskのDKIMレコードは、freshemail.ioを指すCNAMEレコードとして作成する必要があります。TXTとして貼り付けることが「DKIM not verified」のよくある原因です。前後のスペースも削除してください。Freshdeskは、余分なスペースがあると検証に失敗すると明示的に警告しています。
- DNS設定
Cloudflareのプロキシは解決を妨げます：FreshdeskのDKIM CNAMEレコードはすべて「DNS only」（グレーのクラウド）に設定してください。プロキシが有効（オレンジのクラウド）なCNAMEはfreshemail.ioに解決されず、Verifyが失敗します。
- 認証失敗の原因
SPFレコードは1つだけ：includeを追加する際にv=spf1の行がすでにあるなら、include:email.freshdesk.comをそこにまとめます。SPFのTXTレコードが別々に2つあること自体がPermErrorになります。Freshdeskのメールは、既存のメールボックスサービスに追加される形になることがよくあります。
- DNS設定
FreshdeskはDMARCの値を提示しません：DKIMの画面にも表示されません。_dmarcは自分で公開する必要があります。省略すると、DKIMとSPFには成功してもレポートは得られず、Gmail/Yahooのルール上、ポリシーがないことになります。
- DNS設定
デフォルトのfreshdesk.comメールボックスは作業不要です：これらのレコードが必要なのはドメインベースのサポートメールだけです。また、サブドメインのサポートメールでは、ルートドメインではなくそのサブドメインにSPFとDKIMを公開する必要があります。
SPFレコードを作成
Freshdeskでは、ルートドメインに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:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証FreshdeskのSPFに関するよくある質問
関連記事
ヘルプデスク・CRMの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。