GladlyのSPF・DKIM・DMARC設定。
Gladlyはカスタマーサービスのプラットフォームで、大量配信向けのメール配信サービス（ESP）ではありません。Gladlyを導入すると、サポートチームのメールチャネルをGladlyが担い、エージェントの返信は自社のサポートアドレスから送信され、顧客からの受信メッセージは転送で取り込まれます。送信される返信はすべて内部でMailgunを経由します。そのためドメイン認証では、GladlyのEmail設定で生成される2つのDNSレコードを公開します。include:mailgun.orgを含むSPFの行と、DKIM公開鍵のTXTレコードです。両方を送信ドメインのDNSに追加し、Gladlyでドメインの状態がUnverifiedからVerifiedに変わるまで最大72時間待ちます。その後、Gladlyサポートに連絡してreply-toアドレスを設定し、受信メールの転送を構成します。確認が完了すると、返信は未認証のエンベロープに戻ることなく、完全に認証された状態で、自社ドメインとアライメントが一致して送信されます。
Gladlyを認証すべき理由
サポートプラットフォームでは、マーケティングツール以上に認証が重要です。すべてのメッセージは顧客が返事を待っている1対1の返信であり、迷惑メールに振り分けられたりバウンスしたりすれば、開封を逃すだけでは済まず、サポートの失敗になります。2024年2月以降、GmailとYahooは大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook/Hotmail宛ての大量送信者に同様のルールの適用を始めました。このしきい値を下回る場合でも、受信トレイに届くには今や同じチェックが最低条件です。Gladlyのドメインを追加して確認するまで、返信は未認証のエンベロープで送信されます。受信側はメールが本当に自社からのものか確認できず、SPFとDKIMは自社ドメインとアライメントが一致せず、DMARCにも成功できません。サポートメールのレピュテーションも他の送信者全員と共有されます。ドメインを確認すれば、これらはすべて一度に解決します。（Mailgun経由の）Gladlyの送信ではSMTPエンベロープに自社ドメインが使われ、DKIMはd=yourdomainとして署名されるため、SPFとDKIMの両方で組織ドメインとアライメントが一致してDMARCに成功し、築いた送信レピュテーションは自社に蓄積されます。
GladlyにおけるSPFの実情
GladlyはMailgun経由で送信するため、本当にSPFのincludeが必要なサービスです。送信ドメインの1つのSPFレコードにv=spf1 include:mailgun.org ~allを公開します（または既存のv=spf1の行にinclude:mailgun.orgをまとめます）。この正確な値は、GladlyがView SPF and DKIM Values画面で生成します。CNAMEで委任するESP（SendGrid、Klaviyo、Mailchimp）とは異なり、代わりにSPFを満たしてくれるCNAMEはなく、TXTレコードを自分で貼り付けます。重要な注意点は、include:mailgun.orgが異例なほど重いことです。実際のDNSで確認すると、ネストされたルックアップは5回に達します。mailgun.orgがinclude:_spf.mailgun.org（さらに_spf1と_spf2をネスト）とinclude:_spf.eu.mailgun.orgを公開しているためで、この1行でUSとEUの両方の送信リージョンをカバーします。つまり1つのincludeだけで、RFC 7208のルックアップの10回制限の半分を使います。しかもGladlyは実際のサポートアドレス（support@yourdomain.com）から送信するので、この重いincludeは通常、Google WorkspaceやMicrosoft 365と並んで組織ドメインのSPFレコードに入ります。ルートドメインのSPFレコードがすでに混み合っていると10回の上限を超えてPermErrorが発生し、そのレコード上のすべての送信者のSPFが壊れることがあります。すっきり回避するには、Gladly専用の送信用サブドメイン（例：help.yourdomain.com）を用意します。重いMailgunのincludeはサブドメイン自体のSPFレコードに収まり、ルートドメインには影響しません。どのドメインを使う場合も、SPFレコードは1つだけにしてください。2つ目のSPF TXTを公開せず、include:mailgun.orgを既存のv=spf1の行にまとめます（SPFレコードが2つあると、それ自体がPermErrorになります）。もう1つ重要な点があります。Mailgunはデフォルトで自身のドメイン（mailgun.org）をエンベロープ/Return-Pathに使うため、include:mailgun.orgでSPFは認可されますが、SPFのアライメントはFromドメインと一致しません。DMARCのアライメントは、d=yourdomainとして署名するDKIMが担います。これはほとんどのESPと同じモデルです。DMARCの成功はDKIMに依存するので、DKIMが確認されていることを必ず確かめてください。
設定手順
- 1
GladlyでEmail設定を開く
左上のハンバーガーメニューをクリックしてSettingsを選び、ChannelsカテゴリのEmailを選択します。Administratorロールが必要です（Team Managerはサポートリクエストを開けますが、ドメインは編集できません）。送信ドメインを管理するEmail Channelの設定画面が開きます。
- 2
送信ドメインを追加
DomainsタブでAdd Domainをクリックし（まだドメインがない場合はプロンプトに入力）、ドメインを小文字で入力します（例：yourdomain.com、または専用サブドメインhelp.yourdomain.com）。続いてSave and Continueをクリックします。入力は慎重に行ってください。保存したドメインは編集も削除もできず（入力ミスの修正にはGladlyサポートへのチケットが必要です）、小文字しか受け付けません。ルートドメインとサブドメインのどちらにするかは慎重に決めます。ルートドメインのSPFレコードにすでにGoogle Workspace/Microsoft 365とマーケティングツールが重なっている場合は、サブドメインを使い、重いMailgunのincludeがルートドメインのレコードに入らないようにしてください。
- 3
SPFとDKIMの値を表示
ドメインにカーソルを合わせ、View SPF and DKIM Values（Find SPF and DKIM TXT Valuesとも表示されます）をクリックします。include:mailgun.orgを含むSPFの行と、DKIMのTXTレコードをコピーします。DKIMのTXTレコードは、<selector>._domainkeyのホストとk=rsa; p=…の公開鍵で構成されます。値はドメインごとに生成されるので、Gladlyの表示どおりに使ってください。
- 4
SPFレコードを公開（既存なら1つにまとめる）
DNSホストで、送信ドメインにTXTレコードを追加します。ホストは@（またはサブドメインのラベル）、値はv=spf1 include:mailgun.org ~allです。v=spf1のレコードがすでにある場合は2つ目を作らず、include:mailgun.orgをその1行にまとめます（例：v=spf1 include:_spf.google.com include:mailgun.org ~all）。SPFレコードはホストごとに1つだけにしてください。
- 5
DKIMのTXTレコードを公開
Gladlyに表示されるセレクターのホスト（<selector>._domainkey.yourdomain.com形式の名前、例：smtp._domainkey）に、値がk=rsa; p=<long base64 key>のTXTレコードを追加します。2048ビットの鍵はTXTの単一文字列の上限（255文字）を超えることが多いので、引用符付きの2つの文字列に分割します（ほとんどのDNS管理画面では1行で貼り付けると自動で分割されます）。DNSホストがドメインを付加する場合はセレクター部分のみを入力し、レジストラがドメインを二重に付加しないよう注意してください。
- 6
DMARCレコードを追加（Gladlyは追加しない）
GladlyはDMARCを公開しないので、_dmarc.yourdomain.comにTXTレコードを自分で追加します。値はv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comです。まずp=noneでレポートを収集し、Gladlyと他のすべての送信者がアライメントの一致した状態で成功していることを確認してから、p=quarantine、最終的にp=rejectへと段階的に引き上げます。
- 7
Webサイトのないサブドメインの場合のみMXレコードを追加
Gladlyの注意書きによると、Webサイトのない（A/CNAMEがない）メールドメイン（通常はサブドメイン）では、一部の受信側で動作するためにMXレコードが必要な場合があります。送信ドメインがサイトのないサブドメインであれば、受信/メールホストのMXレコードを追加してください。ドメインがすでにWebサイトに解決される場合は不要です。これによってメールの向け先がGladlyに変わることはありません。
- 8
Gladlyで確認し、reply-toと転送を設定
Gladlyに戻り、72時間以内に確認します。DNSが反映されると、SPFとDKIMの状態がUnverifiedからVerifiedに変わります（ケバブメニューのCheck Verification Statusで再確認できます）。Gladlyがテストする時間を確保するため、レコードはローンチの約1週間前に追加してください。その後、Gladlyサポートに連絡してreply-toアドレスを設定し、既存のメールサーバーからGladlyが生成したアドレス（形式はlocalpart@yoursubdomain.inbound.gladly.email）への転送を設定して、顧客からの返信がGladlyに届くようにします。Gladlyは、Gladlyに向けたMXレコードではなく、転送でメールを受信します。
- 9
送信メールのアライメントをテスト
Gladlyから自分の受信トレイ（Gmailが便利です）に実際の返信を送り、Show original / 完全なヘッダーを開きます。dkim=pass（d=yourdomain）とdmarc=passを確認してください。SPFはMailgunのReturn-Pathドメイン（mailgun.org）に対して認証されるため、成功はしますがアライメントは一致しません。アライメントが一致してDMARCの成功を担うメカニズムはDKIMです。GladlyのVerifiedはレコードが解析できることを示すだけで、アライメントを証明するのはヘッダーのチェックです。
追加するレコード
正確な値はGladlyのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 include:mailgun.org ~allGladlyの送信ドメイン用のSPFレコードです（ルートドメインならホストは@、それ以外はサブドメインのラベル）。GladlyのView SPF and DKIM Valuesで生成されます。既存のv=spf1の行があればinclude:mailgun.orgをそこにまとめ、SPFレコードを1つにしてください。include:mailgun.orgはRFC 7208の上限である10回のうち、約5回のDNSルックアップを消費します。 |
| TXT | <selector>._domainkey.yourdomain.com | k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC... (per-account, truncated)DKIMレコードの例です。正確なセレクターのラベル（多くの場合smtp）と2048ビットの公開鍵はドメインごとに異なり、GladlyのView SPF and DKIM Values画面に表示されます。DNSホストで必要なら2048ビットの鍵を引用符付きの2つの文字列に分割し、ホストがドメインを自動で付加する場合はセレクター部分のみを入力してください。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com併せて設定するDMARCレコードです。Gladlyは作成しません。p=noneで始め、レポートを監視してからquarantine/rejectに引き上げます。Gmail/Yahoo/Microsoftの大量送信者ルールを満たすために必要です。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Gladlyの設定がこの上限のうち何回を消費するかは、次のとおりです。
Gladlyは10回のルックアップのうち5回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
Gladlyが提供するのは、自動ローテーションするCNAMEではなく、静的なDKIMのTXTレコードです。ホストは<selector>._domainkey.yourdomain.com（セレクターは多くの場合smtp）で、値はk=rsa; p=<2048-bit base64 public key>です。Gladlyが（Mailgun経由で）鍵ペアを生成して秘密鍵を保持し、貼り付ける公開鍵を表示します。送信メールは送信ドメインをd=として署名されるため、DKIMは緩和されたアライメントで組織ドメインと一致し、DMARCの成功を担います。運用面の注意点は2つあります。1つ目は、2048ビットの公開鍵は通常、TXTの単一文字列の上限（255文字）を超えるため、引用符付きの2つの文字列に分割する必要があることです。ほとんどのDNS管理画面では1行で貼り付けると自動的に分割されますが、自分で引用符を付ける必要がある場合もあります。分割が不正だと、レコード自体は存在していてもdkim=failになります。2つ目は、ローテーションが手動であることです。MailgunのAutomatic Sender Securityの最新のCNAMEとは異なり、この静的な鍵は自動でローテーションしません。Gladlyで再生成するとDNSのTXTの再編集が必要になるので、鍵のローテーションは定期メンテナンス作業として扱ってください。セレクターは表示どおり正確にコピーしてください。「緑」の表示なのにDKIMに失敗する原因で最も多いのは、セレクターの誤りと鍵の切り詰めです。
DMARC
GladlyがDMARCレコードを公開することはありません。自分で追加する必要があり、SPFとDKIMの確認後も、Gmail、Yahoo、Microsoftの送信者ルールを満たすために必要です。ポイントは、ここでDMARCを担うのはDKIMだということです。DKIMはd=yourdomainとして署名してアライメントが一致するので、DMARCレコードが有効になればすぐ、DKIM側で成功します。SPFはinclude:mailgun.orgで認証されますがアライメントは一致しません（MailgunのデフォルトのReturn-Pathはmailgun.orgで、自社ドメインではありません）。DMARCに必要なのはアライメントが一致したメカニズム1つで、それをDKIMが提供するので問題ありません。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:you@yourdomain.comで始まるTXTレコードを公開します。まずp=noneで集計レポートを収集し、Gladlyと他の正規の送信者すべてがアライメントの一致した状態で成功していることを確認してから、p=quarantine、最終的にp=rejectへと段階的に引き上げます。Gladlyを専用サブドメインで運用する場合、サブドメインは組織ドメインのポリシーを継承します。これを変えるには、サブドメインに_dmarcレコードを公開するか、親ドメインでサブドメインポリシーsp=を設定します。
正しく設定できたか確認する
レコードを追加すると、Gladlyは72時間以内にDNSを再チェックし、Domains画面でSPFとDKIMをUnverifiedからVerifiedに切り替えます（ケバブメニューのCheck Verification Statusで強制的に再確認できます）。ただし、ここで終わりにしないでください。Verifiedはレコードが解析できることを示すだけで、メールのアライメントが一致することまでは示しません。Gladlyから自分の受信トレイ（Gmailが最も簡単です）に実際の返信を送り、Show original / 完全なヘッダーを開きます。dkim=pass（d=yourdomain）とdmarc=passが表示されれば成功です。SPFはspf=passと表示され、MailgunのReturn-Path（mailgun.org）に対して認証されます。成功はしますがアライメントは一致しないので、DMARCの成功を担うのはDKIMです。次に、送信ドメインを外部のSPF/DKIM/DMARCチェックツールにかけ、include:mailgun.orgが正しく解決され、SPFのルックアップ合計が10回未満に収まっていることを確認します。混み合ったレコードに重いMailgunのincludeを重ねたことで生じるPermErrorは、このチェックで見つかります。ヘッダーで3つすべてのアライメントの一致が確認できて初めて、そのドメインは本当に本番運用できる状態です。
よくある注意点
- 認証失敗の原因
include:mailgun.orgは重いincludeです。実際に確認すると5回のDNSルックアップに解決されます（mailgun.orgが_spf.mailgun.orgをネストし、それが_spf1/_spf2をネストし、さらに_spf.eu.mailgun.orgで両リージョンをカバー）。1つのincludeでRFC 7208のルックアップの10回制限の半分を消費し、Gladlyは実際のサポートアドレスから送信するため、このincludeは通常、組織ドメインのSPFレコードに入ります。Google Workspace/Microsoft 365やマーケティングツールがすでに入っていると、PermErrorになる可能性があります。Gladlyを専用の送信用サブドメインで運用すれば回避できます。
- 認証失敗の原因
SPFレコードは1つのドメインにつき1つだけにしてください。include:mailgun.orgを既存のv=spf1の行にまとめ、2つ目のSPF TXTは公開しないでください。それ自体がPermErrorになります。Gladly自身の例でもまとめる形になっています（例：v=spf1 include:spf.protection.outlook.com include:mailgun.org -all）。
- DNS設定
DKIM鍵は、自動ローテーションするCNAMEではなく静的なTXTレコードです。2048ビットの鍵はTXTの文字列の上限（255文字）を超えるため、引用符付きの2つの文字列に分割する必要があります（ほとんどのホストは自動で処理しますが、確認してください）。鍵をローテーションするには、Gladlyで再生成し、DNSを手動で再編集します。
- 適用範囲
レコードはローンチの約1週間前に追加してください。DNSの確認には最大72時間かかることがあり、Gladlyには送信ドメインを本番稼働前にテストする時間も必要です。両方のレコードが確認されるまで、状態はUnverifiedのままです。
- 適用範囲
保存したドメインは変更できません。編集も削除もできず、小文字しか受け付けません。入力ミスの修正にはGladlyサポートへのチケットが必要なので、Save and Continueをクリックする前に必ず見直してください。
- 適用範囲
送信と受信は別々の作業です。送信する返信はSPFとDKIMで認証します。顧客からの受信メールは、メールサーバーからGladlyが生成したアドレス（localpart@yoursubdomain.inbound.gladly.email）への転送を設定して初めてGladlyに届き、元のFromは維持されます。転送はドメインがVerifiedになるまで機能しません。また、Gladlyに向けたMXレコードではメールを受信しません。
- 適用範囲
reply-toアドレスはセルフサービスで設定できません。Gladlyサポートに連絡して設定してもらい、そのreply-toアドレスにも転送を設定して、返信がGladlyに戻るようにしてください。
- DNS設定
GladlyがDMARCレコードを作成することはありません。_dmarcのTXTレコードがなければ、SPFとDKIMに成功していても、Gmail/Yahoo/Microsoftの大量送信者要件を満たせません。自分で公開し、p=noneから始めてください。
- DNS設定
Webサイトのない（A/CNAMEがない）送信用サブドメインでは、一部の受信側で動作するためにMXレコードが必要な場合があり、Gladlyも明示的に注意しています。また、レジストラがDKIMのホストにドメインを自動で付加して二重になること（…_domainkey.yourdomain.com.yourdomain.com）にも注意してください。
SPFレコードを作成
以下ではGladlyがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証GladlyのSPFに関するよくある質問
関連記事
ヘルプデスク・CRMの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。