カスタムメールアドレス（例：support@yourcompany.com）を接続している際にdomainの検証で問題が発生した場合は、このガイドに従って最も一般的な問題を解決してください。後半では費用に関する注意点やトラブルシューティングのヒントも紹介します。Intercomでカスタムメールdomainを設定すると、ビジネスdomainからメールを送信でき、配信率、ブランド認知、メールのベストプラクティス遵守が向上します。
Developer workspacesは送信メールを送信できません。Developer workspaceを使用している場合、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を通過することを確認してから採用してください。そうしないと正当なメールがブロックされる可能性があります。
送信の問題
「送信者がアプリに属していません」エラー
エラー「送信者がアプリに属していません」が発生した場合、送信者アドレスがworkspaceに正しく設定されていません。
解決策: 正しい送信者アドレスがIntercomのworkspaceに送信者アドレスとして設定されていることを確認してください。メッセージ再送信前にメールチャネルの選択を確認してください。
認証されたdomainからメールが送信されない場合
domainが認証されていてもメールが送信されないことがあります。多くの場合、返信先アドレスの設定ミスが原因です。
解決策:
メール設定に移動してください。
返信先アドレスセクションのチームメイトからの返信タブを見つけてください。
ここが受信アドレスに設定されていることを確認し、チームメイトのメールアドレスではないことを確認してください。あるいはプロフィール設定でチームメイトのエイリアスを設定してください。これはworkspaceの返信設定が「チームメイトのメールアドレス」の場合に送信アドレスを制御し、それ以外は表示名のみを変更します。
送信ボタンがグレーアウトしている
送信ボタンがグレーアウトまたは無効の場合、通常は受信者のメールアドレスがworkspaceの連絡先に登録されていません。
解決策: 受信者のメールアドレスをworkspaceの連絡先に追加し、再度メールを送信してください。
メッセージが誤ったチャネルで送信されている
メールとして送信するはずのメッセージがチャットなど別のチャネルで送信されている場合、作成時のチャネル選択が原因です。
解決策: メッセージ作成時に明示的にメールをチャネルとして選択してから送信してください。
domainのブロックリストによるメールブロック
domainがSpamhausなどの外部メールブロックリストに載っている場合、送信メールがブロックされることがあります。SPF/DKIM/DMARC認証を正しく設定してdomainを保護し、ブロックリスト登録のリスクを減らしてください。
解決策:
主要なブロックリストでdomainが登録されていないか確認してください。
各ブロックリストの削除申請フォームから解除を依頼してください。
解除後、テストキャンペーンを送信して修正を確認してください。
550 5.7.509 エラー
受信メールサーバーがDMARC検証に失敗したdomainのメールを拒否し、DMARCレコードが未認証メールを拒否に設定されているためメールがブロックされました。
一般的なブラウザのトラブルシューティング
未定義のメール送信失敗やUI問題が発生した場合、以下のブラウザとネットワークのトラブルシューティング手順を試してください:
ハードリフレッシュ — Mac: Command + Shift + R | Windows: Ctrl + Shift + R
プライベート/シークレットウィンドウ — Mac: Command + Shift + N | Windows: Ctrl + Shift + N。キャッシュやクッキーが原因か特定するのに役立ちます。
別のネットワーク — モバイルホットスポットで接続し、ファイアウォールやネットワーク制限の可能性を排除してください。
拡張機能の無効化 — 接続を妨害している可能性のあるChromeやFirefoxの拡張機能を無効にしてください。
別のブラウザ — 別のウェブブラウザで問題が続くか確認してください。
注意: 認証後は「Verify」ボタンが消えます。この場合は代わりに「Edit」ボタンを使用してください。
まだ問題がありますか？
これらのトラブルシューティング手順をすべて試しても問題が解決しない場合:
少なくとも1つのdomainを使用したメールアドレスがIntercomアカウントで認証されているか再確認してください。設定 > チャンネル > メール > domainとアドレスから新しいアドレスを追加または既存のものを編集できます。メールアドレス設定時に認証メールが送信されます。認証メールの再送信をクリックして再送信を依頼できます。
DNSレコードのタイプミスやフォーマットの違いがないか再確認してください。
同じ名前に対してTXTとCNAMEの競合するレコードを使用していないことを確認してください。
送信CNAME認証にはCNAMEターゲットのホスト名が公開解決可能である必要があります。
DNSレコード設定後、Intercomで認証を検証をクリックしたことを確認してください。
IntercomのVerifyボタンでレコードを確認し、変更が遅れている場合はグローバルDNSチェッカーで伝播を確認してください。
さらなる支援が必要な場合はサポートチームにお問い合わせください。