IntercomのSPF・DKIM・DMARC設定。
Intercomは、特に送信量の多いチャネルの1つです。Inboxからのサポート返信、Fin AIによる解決、Seriesやアウトバウンドキャンペーン、ライフサイクルメッセージのすべてがIntercomから送信されます。これらのメールを受信トレイに届け、Google、Yahoo、Microsoftの要件を満たすには、intercom-mail.comではなく自社ドメインとして認証する必要があります。Intercomの認証はCNAMEによるドメイン認証です。まず送信アドレスを確認し、次にDKIM署名とReturn-PathをIntercomに委任する少数のCNAMEレコードと、DMARCのTXTレコードを公開します。このガイドでは、ダッシュボード上のパス、各レコードの形式、貼り付けるSPFのincludeがない理由、確認方法まで、現在の設定手順を具体的に説明します。
Intercomを認証すべき理由
認証しないまま自社ドメインのアドレスからIntercomで送信すると、受信側に届くのは、自社から送られたように見えるものの、自社ドメインとアライメントが一致するDKIM署名も、アライメントが一致するReturn-Pathもないメールです。その結果、DMARCに失敗し、迷惑メールに振り分けられるか、そのまま拒否されます。Fromアドレスをデフォルトのintercom-mail.comの送信者のままにすればこの問題は避けられますが、ブランドと信頼をIntercomの共有ドメインに委ねることになります。2024年2月以降、GoogleとYahooは、大量のメール（1日あたり約5,000通以上）を送信するすべての送信者に対し、SPF、DKIM、DMARCを正式に義務付けており、Microsoftもこれに続いています。Intercomでドメイン認証を完了すると、自社ドメインとアライメントが一致するDKIM署名、SPFのアライメントが一致するカスタムReturn-Path、それらを結びつけるDMARCレコードがそろいます。この組み合わせが、受信トレイへの到達につながります。
IntercomにおけるSPFの実情
IntercomはCNAMEで認証するサービスであり、SPFのincludeで認証するサービスではありません。ルートドメインのSPFレコード（v=spf1）に追加する「include:intercom.com」のような共通の文字列はありません。公開しても実質的な意味はなく、DNSルックアップの10回制限を消費するだけです。代わりに、Intercomは送信するすべてのメールにカスタムReturn-Path（エンベロープ送信者/バウンス用ドメイン）を設定します。これは自社ドメインのサブドメインで、CNAMEでIntercomに委任します。このサブドメインはCNAMEでIntercom自身のReturn-Pathホストを指すため、SPFチェックはこの連鎖をたどってIntercomのSPFレコードに到達し、Intercomの許可された送信IPで成功します。また、エンベロープのドメインは自社ドメインのサブドメインなので、Fromドメインに対するDMARCの緩和されたSPFアライメントも満たします。結果として、ルートドメインのSPFレコードはまったく変更せず、IntercomによるDNSルックアップの追加もゼロです。すでにGoogle Workspace、Microsoft 365、またはメール配信サービス（ESP）で送信している場合、それらのincludeはそのままにしてください。Intercomに関わるのは、DKIMとReturn-PathのCNAMEだけです。
設定手順
- 1
使用する送信アドレスを確認
ドメインを認証するには、そのドメインの送信アドレス（例：help@yourdomain.comやhello@yourdomain.com）を利用者が管理していることを、先にIntercomが確認する必要があります。アドレスを追加または編集すると、Intercomからそのメールボックスに確認リンクが届きます。リンクをクリックしてからIntercomに戻ってください。ドメインを認証できるのは、この方法で確認したアドレスのドメインだけです。
- 2
「Authenticate your domain」を開いてレコードを表示する
アドレスの確認が済んだら、ドメインを選択して「Authenticate your domain」をクリックします（古いワークスペースでは「Finish setup」と表示されます）。Intercomが、このワークスペースとドメインに固有のレコードを生成します。内訳は、2つのCNAMEレコード（DKIMとカスタムReturn-Path）と、DMARCのTXTレコード1つです。この画面は開いたままにしてください。各レコードのName/HostとValue/Targetをそのままコピーします。
- 3
DKIMのCNAMEレコードを公開
ホストをIntercomのDKIMセレクターであるintercom._domainkey.yourdomain.comとするCNAMEレコードを作成し、Intercomに表示されるDKIMのターゲットを指定します。これによりDKIM鍵のホスティングがIntercomに委任されるため、署名（d=）のアライメントが自社ドメインと一致し、今後DNSを再度変更しなくても、Intercomが鍵をローテーションできます。レコードの種類はあくまでCNAMEで、TXTレコードではありません。
- 4
カスタムReturn-PathのCNAMEレコードを公開
Intercomの一覧どおりに、2つ目のCNAMEレコードを作成します。自社ドメインのバウンス/Return-Path用サブドメインを、IntercomのReturn-Pathホストに向けるものです。SPFのアライメントが自社ドメインと一致するのは、このレコードがあるためです。Intercomがエンベロープ送信者をこのサブドメインに設定すると、SPFチェックがCNAMEをたどってIntercomの許可されたインフラに到達して成功し、受信側のDMARCチェックでもアライメントが一致したドメインと判定されます。省略すると、認証はDKIMのみになります。
- 5
ルートドメインのSPFレコードは変更しない
v=spf1レコードに、IntercomやSendGridのincludeを追加しないでください。Intercomは顧客ドメインにはincludeを使わず、SPFのアライメントはReturn-PathのCNAMEがすでに処理します。ほかの送信者（Google、Microsoft、ESP）用にルートドメインのSPFレコードがある場合は、そのままにします。見直すのは、ほかの送信者が原因でSPFのルックアップが10回を超えていることが、後からチェックツールでわかった場合だけです。
- 6
DMARCレコードを公開、またはポリシーを引き上げる
DMARCレコードがまだない場合は、_dmarc.yourdomain.comにTXTレコードを追加します。Intercomが提示する初期値はp=none（監視のみ）です。これを公開してレポートの収集を始めてください。集計データを受け取れるよう、rua=のメールボックスを必ず含めます。すでにDMARCレコードがある場合、Intercomの値は不要です。Intercomがアライメントの一致する送信元になった今も既存のポリシーが適切かどうか、確認するだけで十分です。
- 7
DNSプロバイダーごとの癖に対応する
Cloudflareでは、各CNAMEを「DNS only」（グレーのクラウド、プロキシはオフ）に設定してください。そうしないと解決できなくなります。GoDaddyや一部のレジストラでは、Nameの末尾にドットを付けず、管理画面が自動で追加する場合はドメインを重ねて入力しないでください。ほかの管理画面では完全修飾名（intercom._domainkey.yourdomain.com）が必要です。同じホストのレコードがすでにある場合は削除してください。同じ名前に、CNAMEレコードと別のレコードは共存できません。
- 8
Intercomで検証してアライメントを確認
Domains & addressesに戻り、「Validate authentication」をクリックします。DNSの反映には最大72時間かかることがあります（通常はもっと短時間です）。失敗した場合は、正しいレコードを編集し直さず、待ってから再試行してください。緑になったらテストメールを送信し、ヘッダーで、DKIM=pass、SPF=pass（どちらも自社ドメインとアライメントが一致）、dmarc=passを確認します。
追加するレコード
正確な値はIntercomのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| CNAME | intercom._domainkey.yourdomain.com | dkim.intercom-mail.com例です。intercom._domainkeyセレクターによるDKIMの委任です。正確なValueはワークスペース/ドメインごとに生成され、「Authenticate your domain」画面に表示されるので、そのままコピーしてください。リージョンごとにターゲットが異なり、EUのワークスペースはintercom-mail.eu、AUのワークスペースはau.intercom-mail.comに解決されます。 |
| CNAME | <intercom-generated-label>.yourdomain.com | custom-return-path.intercom-mail.com例です。SPFのアライメントを実現する、カスタムReturn-Path（バウンス）のCNAMEレコードです。ホストのラベルとターゲットは、どちらもワークスペース/ドメインごとにIntercomが生成します。ラベルは固定の単語ではないので、この例を入力せず、両方を「Authenticate your domain」画面からそのままコピーしてください。レコードの種類はあくまでCNAMEで、TXT/SPFレコードではありません。 |
| TXT | _dmarc.yourdomain.com | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com補助のDMARCレコードです。Intercomはp=none（監視のみ）をあらかじめ入力します。DMARCがまだない場合は公開し、レポートに問題がなければquarantine/rejectへ引き上げます。すでにDMARCレコードがある場合は、既存のものを使ってください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Intercomの設定がこの上限のうち何回を消費するかは、次のとおりです。
Intercomの推奨設定はルックアップを消費しません。10回すべてを、includeが必要な他の送信元に使えます。
DKIM
Intercomが採用しているのは、利用者が自分でホストするTXTの鍵ではなく、CNAMEで委任する方式のDKIMです。公開するセレクターは1つだけで、intercom._domainkey.yourdomain.comを、IntercomのDKIMホストを指すCNAMEレコードとして公開します。実際の鍵の生成、ホスティング、ローテーションはIntercomが行います。署名ドメイン（d=）は自社ドメインなので、すべてのメールにDKIM署名が付き、アライメントも一致します。これはDMARCの2つのアライメント経路のうち強力なほうで、転送の大半にも耐えます。追加するセレクターは1つだけで、長い公開鍵の文字列を貼り付ける必要も、Intercomが鍵をローテーションしたときに更新する必要もありません。このCNAMEは、Intercomがその時点で公開している鍵に解決されます。
DMARC
DMARCは、IntercomのSPFとDKIMのアライメントをポリシーとして適用し、レポートも受け取れるようにするレコードです。Intercomは、_dmarc.yourdomain.comに設定するp=noneの初期TXTレコードを提示します。DMARCがまだない場合は、これをrua=のアドレスを付けて公開してください。正当なメールを危険にさらすことなく、集計レポートを受け取り始められます。Intercomの検証が緑になり、DKIM署名とReturn-Pathの両方のアライメントが自社ドメインと一致することをレポートで確認できたら、ポリシーを引き上げます。p=noneからp=quarantineへ、ほかの正当な送信者（Google、Microsoft、ESP）も成功するようになったらp=rejectへ移行します。ドメイン全体で1日約5,000通を超えて送信する場合、GoogleとYahooは少なくともDMARCポリシーの公開を求めています。組織ドメインのDMARCレコードは1つで、Intercomとほかのすべての送信者をカバーします。Intercom用に別のレコードを追加する必要はありません。
正しく設定できたか確認する
Intercom > Domains & addressesで「Validate authentication」をクリックします。緑の状態であれば、両方のCNAMEが解決され、DKIM/Return-Pathが有効になっています。次に、別の方法でも確認します。Intercomから自分宛てにテストメールを送信し、原文/ヘッダーを表示します。DKIM=pass（d=yourdomain.com）、SPF=pass（エンベロープ/Return-Pathはyourdomain.comのサブドメイン）、dmarc=passと表示されていれば成功です。SPF/DKIM/DMARCの外部チェックツールでドメインをチェックし、intercom._domainkeyのCNAMEレコードと_dmarcのTXTレコードが公開DNSで確認できることも確かめられます。DNSの反映には最大72時間かかることがあるため、レコードを正しくコピーしたのであれば、初期の失敗は設定ミスではなく「まだ反映されていない」状態とみなしてください。
よくある注意点
- 認証失敗の原因
Intercom用のSPFのincludeは追加しないでください。顧客ドメインにinclude:intercomという文字列はありません。IntercomはカスタムReturn-PathのCNAMEでSPFのアライメントを一致させます。不正なincludeを追加したり、intercom.com自身のSendGrid用includeをコピーしたりしても効果はなく、DNSルックアップの10回制限を消費するだけです。
- DNS設定
送信用のレコードはすべてCNAMEレコードで、TXTレコードではありません。TXTレコードなのはDMARCレコードだけです。DNS管理画面でタイプを選ぶ必要がある場合は、DKIMセレクターとReturn-Pathのホストに対してCNAMEを選んでください。TXTとして貼り付けると検証に失敗します。
- DNS設定
Cloudflareでは、両方のCNAMEでプロキシをオフ（グレーのクラウド/「DNS only」）にしてください。オレンジのクラウドでプロキシが有効なCNAMEレコードは、IntercomのメールホストではなくCloudflareに解決され、DKIMとReturn-Pathのルックアップが機能しなくなります。
- DNS設定
レジストラごとのホスト欄の扱いに注意してください。一部の管理画面（GoDaddy、Namecheap）はドメインを自動で追加するため、intercom._domainkeyだけを入力します。ほかの管理画面では完全修飾のintercom._domainkey.yourdomain.comが必要です。GoDaddyでは末尾にドットを付けないでください。また、ドメインを二重に入力しないでください。
- DNS設定
Return-PathのCNAMEを省略すると、認証はDKIMのみになります。DKIMだけでもDMARCには成功できますが、SPFのアライメントによる冗長性は失われ、DKIMが削除された転送メールは失敗するようになります。CNAMEは両方とも公開してください。
- DNS設定
同じホストに、CNAMEレコードと別のレコードは共存できません。以前の設定や別のツールで作成した古いintercom._domainkeyまたはバウンス用サブドメインのレコードがある場合は、先に削除してください。そうしないと新しいCNAMEレコードを追加できません。
- 適用範囲
IntercomのデフォルトのDMARCはp=noneで、監視のみです。レポートは届きますが、なりすましを防ぐ効果はありません。アライメントを確認できたら、p=quarantine、続いてp=rejectに移行してください。
- DNS設定
リージョンによって違いがあります。US、EU（intercom-mail.eu）、AU（au.intercom-mail.com）のワークスペースでは、CNAMEのターゲットが異なります。ガイドの値を流用せず、必ず自分のダッシュボードから正確なValueをコピーしてください。
SPFレコードを作成
Intercomでは、ルートドメインに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:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証IntercomのSPFに関するよくある質問
関連記事
ヘルプデスク・CRMの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。