カスタムメールアドレス（例：support@yourcompany.com）を接続している際にdomainの検証で問題が発生した場合は、このガイドに従って最も一般的な問題を解決してください。後半ではコストの考慮事項とトラブルシューティングのヒントも紹介します。Intercomでカスタムメールdomainを設定すると、ビジネsdomainからメールを送信でき、配信率、ブランド認知、メールのベストプラクティス遵守が向上します。
開発者用ワークスペースでは送信メールを送ることができません。開発者用ワークスペースを使用している場合、DNSレコードの設定に関わらず送信メール機能は無効になっています。
DKIMの設定と検証
IntercomはDKIM（DomainKeys Identified Mail）を使用して、domainの代理でメールを送信する権限があるかを検証します。この設定はDNSプロバイダーで行います。
追加するDNSレコード
domainを手動で認証する際に、以下が提供されます：
2つのCNAMEレコード（DKIMとカスタムリターンパス用）
1つのTXTレコード（DMARC用）
DNSプロバイダーによってはこれらのフィールド名が異なる場合があります：
ホスト / 名前 → Intercomの「Name」を使用してください
ターゲット / 値 → Intercomの「Value」を使用してください
注意：「Name」フィールドにdomain名が二重に追加されていないことを確認してください。一部のDNSシステムは自動的に追加します。
ヒント： 主要なDNSプロバイダーの手順はこちら。
認証の検証
DNSレコードを追加した後：
変更が反映されるまで待ちます（最大72時間かかる場合があります）。
Intercomのメール設定に戻り、セットアップ完了をクリックしてください。
認証を検証をクリックしてください。
すぐに認証されない場合は、少し待ってから再試行してください。DNSの伝播遅延が最も一般的な原因です。
DNS伝播とは、インターネット上でDNSレコードが更新されるプロセスで、通常数時間から24〜48時間かかります。ただし、場合によっては最大72時間かかることもあります。これは、インターネットサービスプロバイダー（ISP）、domainのレジストリ、DNSレコードのTTL値など複数の要因によって影響されます。
よくある設定の問題とその解決方法
1. DNSレコードの不足または誤り
必要なすべてのレコード（2つのCNAMEと1つのTXT）が正確に追加されていることを確認してください。
2. 間違ったレコードタイプの使用
DKIMとリターンパスの設定にはCNAMEが必要で、TXTではありません。
3. CloudflareまたはGoDaddyのUsers
これらのプロバイダーでは特別な設定が必要な場合があります：
Cloudflare：プロキシをオフにしてください（クラウドアイコンはグレーで、オレンジではありません）。
GoDaddy：末尾のドットなしで「Name」と「Value」を正確に入力してください。
4. CNAMEフラットニングの問題（Cloudflareのみ）
レコードがDNS Onlyに設定されていることを確認し、プロキシされていないことを確認してください。
5. DNS伝播の遅延
DNSの変更がインターネット全体に完全に反映されるまでに数時間かかることがあります。認証に失敗した場合は、再試行する前に時間を置いてください。
設定確認に役立つツール
これらの公開ツールを使ってDKIMレコードが有効か確認できます：
セレクター：
intercomDomain：yourdomain.com
注意：DKIMレコードが有効でも、Intercomで認証を検証をクリックする必要があります。
SPFとDMARCについて
SPFの設定は必要ですか？
いいえ。Intercomは送信するすべてのメールにカスタムリターンパスを設定してSPFを処理します。特別な指示がない限り、独自のSPFレコードを追加する必要はありません。これは上記で追加したリターンパスのCNAMEを介して機能し、別途SPFレコードは不要です。
DMARCを設定すべきですか？
はい、特に以下の場合：
1日に5,000通以上のメールを送信する場合（GoogleやYahooの要件）。
なりすまし対策を強化したい場合。
IntercomはDKIMとリターンパスのレコードが正しく設定されている場合にDMARCを完全にサポートします。少なくともp=noneのDMARCレコードが必要です。より厳しいポリシー（p=quarantine、p=reject）はセキュリティを向上させますが、すべての送信者がDKIM/SPFを通過することを確認してから採用してください。そうしないと正当なメールがブロックされる可能性があります。
送信の問題
「送信者がアプリに属していません」エラー
エラー「送信者がアプリに属していません」が発生した場合、送信者アドレスがワークスペースに正しく設定されていません。
解決策：正しい送信者アドレスがIntercomのワークスペースに送信者アドレスとして設定されていることを確認してください。メッセージを再送信する前にメールチャネルの選択を確認してください。
認証されたdomainからメールが送信されない
domainが認証されていてもメールが送信されないことがあります。これは多くの場合、誤った返信先アドレスの設定が原因です。
解決策：
メール設定に移動してください。
返信先アドレスセクションのチームメイトからの返信タブを見つけてください。
これが受信アドレスに設定されていることを確認し、チームメイトのメールアドレスではないことを確認してください。あるいは、プロフィール設定でチームメイトのエイリアスを設定してください。これはワークスペースの返信設定が「チームメイトのメールアドレス」に設定されている場合のみ送信アドレスを制御し、それ以外の場合は表示名のみを変更します。
送信ボタンがグレーアウトしている
送信ボタンがグレーアウトまたは無効の場合、通常は受信者のメールアドレスがワークスペースの連絡先に登録されていません。
解決策：受信者のメールアドレスをワークスペースの連絡先に追加し、再度メールを送信してください。
メッセージが誤ったチャネルで送信されている
メールとして送信するはずのメッセージがチャットなど別のチャネルで送信されている場合、作成時のチャネル選択が原因の可能性があります。
解決策：メッセージ作成時に明示的にメールをチャネルとして選択してから送信してください。
domainのブロックリストによるメールブロック
domainがSpamhausなどの外部メールブロックリストに掲載されている場合、送信メールがブロックされることがあります。domainを保護し、ブロックリスト登録のリスクを減らすためにSPF/DKIM/DMARC認証を正しく設定してください。
解決策：
主要なブロックリストでdomainが掲載されていないか確認してください。
特定のブロックリストの削除申請フォームから削除を依頼してください。
削除後、テストキャンペーンを送信して修正を確認してください。
一般的なブラウザのトラブルシューティング
メール送信の不具合やUIの問題が不明な場合は、以下のブラウザとネットワークのトラブルシューティング手順を試してください：
ハードリフレッシュ — Mac：Command + Shift + R | Windows：Ctrl + Shift + R
プライベート／シークレットウィンドウ — Mac：Command + Shift + N | Windows：Ctrl + Shift + N。キャッシュやクッキーが原因かどうかの特定に役立ちます。
別のネットワーク — モバイルホットスポットで接続し、ファイアウォールやネットワーク制限を除外してください。
拡張機能の無効化 — ChromeやFirefoxの拡張機能で接続を妨げているものを無効にしてください。
別のブラウザ — 別のウェブブラウザで問題が続くかテストしてください。
まだ問題がありますか？
これらのトラブルシューティング手順をすべて試しても問題が解決しない場合：
少なくとも1つのdomainを使用したメールアドレスがIntercomアカウントで認証されていることを再確認してください。これは設定 > チャンネル > メール > domainとアドレスから、新しいアドレスを追加または既存のものを編集して行えます。メールアドレス設定中に認証メールが送信されます。認証メールを再送信をクリックして新しいメールをリクエストできます。
DNSレコードのタイプミスやフォーマットの違いがないか再確認してください。
同じ名前に対してTXTとCNAMEの競合するレコードを使用していないことを確認してください。
送信CNAME認証にはCNAMEターゲットのホスト名が公開解決可能である必要があります。
DNSレコード設定後、Intercomで認証を検証をクリックしたことを確認してください。
Intercomの検証ボタンを使ってレコードを確認してください。変更の反映が遅れている場合はグローバルDNSチェッカーで伝播を確認できます。
さらなる支援が必要な場合はサポートチームにお問い合わせください。