FrontのSPF・DKIM・DMARC設定。
Front（front.com）は共有受信トレイとカスタマーコミュニケーションのプラットフォームであり、メールホストではありません。そのため、Front経由で「自社ドメインとして送信する」ことには特有の意味があります。カスタムSMTPチャネルを接続すると、Frontは基盤のメールインフラであるSendGrid経由で送信メールをリレーします（古いアカウントはMandrill経由でリレーしていたため、従来の「via mandrillapp.com」タグを見たことがあるかもしれません）。この経路を認証するまで、受信者にはFromアドレスに「via sendgrid.net」という注記が表示され、メールが迷惑メールに振り分けられる可能性も大幅に高くなります。FrontのDeliverability設定には、MXレコード、SPFレコード（TXT）、DKIMレコード（TXT）の3つのDNSレコードが表示されます。これらを専用の送信用サブドメインfront-mailに追加します。レコードはルートドメインではなくサブドメインに置かれるため、既存のSPFレコードに手を加えず、受信メールの配信先も変えることなく、SendGridに自社ドメインとしての送信を許可し、「via」タグを消し、DMARCのアライメントを自社ドメインと一致させられます。
Frontを認証すべき理由
Frontの送信ドメインを認証するかどうかで、返信が受信トレイに届くかどうかが決まります。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、大量送信者に同じ要件の適用を始めました。Frontを使うサポートチームやカスタマーサクセスチームは、こうした送信量を日常的に超えています。レコードを追加するまで、FrontはSendGridの共有インフラでメールを送信します。受信者には「via sendgrid.net」タグが表示され、Fromアドレスは自社ドメインとアライメントが一致せず、DMARCはSPFでは成功できません。送信レピュテーションも、そのプラットフォーム上の未認証テナントすべてと共有されます。認証すれば、これらはすべて一度に解決します。SendGridの署名に使うDKIM鍵はfront-mailサブドメインの下に公開されるため、署名は自社ドメインとアライメントが一致します。エンベロープのReturn-Pathも同じサブドメインに置かれるため、SPFは緩和モードでアライメントが一致します。「via」タグは消え、DMARCに成功し、築いたレピュテーションは共有プールではなく自社ドメインに蓄積されます。
FrontにおけるSPFの実情
Frontはサブドメインに委任する方式で、includeを追加するサービスではありません。ルートドメインに貼り付けるinclude:sendgrid.netは存在しません。認証された経路全体は、Frontがfront-mailと名付けた専用の送信用サブドメインに置かれます。このサブドメインには、FrontのDeliverabilityパネルに表示される3つのレコードを追加します。MXレコードは、SendGridがバウンスを処理できるよう、SendGridのメールホスト（mx.sendgrid.net）を指します。SPFのTXTレコード（v=spf1 include:sendgrid.net ~all）は、このサブドメインのみを対象とします。DKIMのTXT公開鍵は、同じサブドメイン配下のセレクターに置きます。組織ドメイン自体のSPFレコードはそのままです。Frontのincludeはfront-mail.yourdomain.comに置かれるので、ルートドメインのSPFレコードでは、10回のDNSルックアップのうち1回も消費しません。DMARCには引き続き成功しますが、Front固有の注意点があります。エンベロープのReturn-PathとDKIM鍵の両方がfront-mailサブドメインに置かれるため、SPFとDKIMはどちらも緩和モードで組織ドメインとアライメントが一致します（このサブドメインは組織ドメインと同じ登録可能ドメインに属するためです）。厳格モードではどちらも一致しません。DMARCのデフォルトは緩和モードなので、Frontは初期設定のままで成功します。このドメインで厳格なアライメント（aspf=sまたはadkim=s）を強制しないようにしてください。最後に、これが当てはまるのはFrontのSMTPチャネルだけです。FrontのチャネルがGmailまたはMicrosoft 365の接続済み受信トレイの場合、Frontはそのサービス自体のサーバーから送信するため、認証はGoogle/Microsoft側で行います。front-mailのレコードはいずれも該当しません。
2つの設定方法
FrontのSMTPチャネル：SendGridのレコードを追加（このガイド）
- カスタムSMTPチャネルの場合に該当します。Frontは送信メールをSendGrid経由でリレーするため、認証が必要です。
- FrontのDeliverabilityパネルからMXレコード、SPFレコード（TXT）、DKIMレコード（TXT）をコピーし、専用の送信用サブドメインfront-mailに追加します。
- 3つのレコードはすべてサブドメインに置かれるため、ルートドメインのSPFレコードには影響がなく、SPFの10回のルックアップを1回も消費しません。
- FrontでレコードがVerifiedと表示されるまで、メールは共有プールから「via sendgrid.net」付きで送信され、迷惑メールフォルダーに入るおそれがあります。
接続済みのGmail / Microsoft 365チャネル：そちらで認証
- GoogleまたはMicrosoft 365の連携で受信トレイをFrontに追加した場合に該当します。FrontはSendGridではなくそのサービス経由で送信します。
- 認証はGoogle WorkspaceまたはMicrosoft 365のSPF、DKIM、DMARCを引き継ぎます。これらの設定はそのサービス側で行ってください。
- front-mailサブドメインも、mx.sendgrid.netを指すMXレコードもなく、SendGridのSPF/DKIMレコードはいずれも該当しません。
- 送信経路にSendGridが含まれないため、「via sendgrid.net」タグは表示されません。
設定手順
- 1
チャネルがSMTPチャネルであることを確認
これらのレコードが該当するのは、FrontのSMTPチャネル（SendGrid経由でリレーされるメール）だけです。チャネルが接続済みのGmailまたはMicrosoft 365の受信トレイの場合、Frontはそのサービス経由で送信します。ここで手順を終え、Google/Microsoft側で認証してください。チャネルの種類はSettings → Channelsで確認できます。
- 2
Deliverability設定を開く
全社のチャネルの場合は、Settingsの歯車 → Company settings → サイドバーのSecurity → Deliverabilityタブの順にクリックします。このページは、共有SMTPチャネルが1つ以上あるときに会社の管理者にのみ表示されます。個々のチームメイトのチャネルの場合は、Settings → そのチームメイトのSMTPチャネル → Settingsタブ → 「Improve delivery rates - SPF / DKIM」セクションを開きます。
- 3
送信ドメインを選択
Domainsで、送信に使うドメインを選びます。SPF/DKIMが未設定のドメインには黄色の警告アイコンが表示されます。続いてFrontが、追加するMXレコード、SPFレコード（TXT）、DKIMレコード（TXT）の3つについて、NameとValueを表示します。セレクター、ホスト、鍵の正確な値はアカウントごとに異なるので、コピーできるようこのパネルを開いたままにしてください。
- 4
front-mailサブドメインにMXレコードを追加
MXレコードを作成します。Host/NameはFrontに表示されるサブドメインのラベル（例：front-mail）、Value/TargetはSendGridのメールホスト（例：mx.sendgrid.net）、Priorityは表示どおりです（Frontでは一般に10）。これはSendGridのバウンス処理用としてサブドメインに追加する新しいMXであり、メインのMX（ホスト@）や受信メールの配信先は変わりません。
- 5
SPF（TXT）レコードを追加
TXTレコードを作成します。Host/Nameはfront-mail、ValueはFrontの表示どおりです（例：v=spf1 include:sendgrid.net ~all）。このSPFレコードの対象は送信用サブドメインのみです。ルートドメインのSPFレコードにはinclude:sendgrid.netを追加しないでください。
- 6
DKIM（TXT）レコードを追加
Frontに表示されるセレクターのホスト（例：s1._domainkey.front-mail）でTXTレコードを作成し、Frontの長い公開鍵の値を、スペースや改行を加えずそのまま貼り付けます。FrontはSendGridのclassic whitelabelを使うため、これは最新のSendGridのドメイン認証にある自動ローテーションのCNAMEではなく、静的なTXT鍵1つです。
- 7
ホストはラベルのみ入力し、既存のレコードには触れない
ラベル（front-mail、s1._domainkey.front-mail）のみを入力します。ほとんどのレジストラはドメインを自動で付加するため、front-mail.yourdomain.comと入力すると名前が重複し、解決されません。追加するのはこの3つの新しいレコードだけです。既存のDNSレコードを編集または削除しないでください。配信に支障が出るおそれがあります。
- 8
DMARCポリシーを公開（未設定の場合）
ルートドメインの_dmarcにTXTレコードを追加します。値はv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comです。_dmarcレコードはドメイン全体で1つだけにしてください。アライメントはデフォルトの緩和のままにします。Frontのfront-mailサブドメインでは、SPFとDKIMの両方のアライメントが緩和モードで一致するので、aspf=sやadkim=sは設定しないでください。いずれもFrontの認証に支障が出ます。
- 9
Frontで「Check DNS settings」をクリック
FrontのDeliverabilityパネルに戻り、Check DNS settingsをクリックすると、SendGrid経由の確認が実行されます。レコードが解決されると、それぞれVerifiedに変わり、チャネルの黄色い警告アイコンが消えます。DNSの反映は通常数分ですが、最大24～48時間かかることがあります。
- 10
実際にテスト送信してアライメントを確認
Frontのチャネルから自分宛てにメールを送り、Gmailで開いて⋮ → Show originalを使います。SPF: PASS、DKIM: PASS（signed-by front-mail.yourdomain.com）、DMARC: PASSであること、Fromの行から「via sendgrid.net」タグが消えていることを確認してください。
追加するレコード
正確な値はFrontのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| MX | front-mail | mx.sendgrid.net送信用サブドメインのReturn-Pathです。SendGridのバウンス用ホストで、優先度はFrontの表示どおりです（一般に10）。正確なサブドメインとホストはFrontのDeliverabilityパネルで確認できます。これはメインのMXレコードではなく、受信メールには影響しません。 |
| TXT | front-mail | v=spf1 include:sendgrid.net ~all送信用サブドメイン専用のSPFレコードです。ルートドメインには追加しないため、ルートドメインのSPFレコードの10回のルックアップは1回も消費しません。正確な値はFrontからコピーしてください。 |
| TXT | s1._domainkey.front-mail | k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…DKIM公開鍵です（静的なTXTレコード1つ）。正確なセレクターと鍵はFront/SendGridが提供します。ホストと値はアカウントごとに異なり、これは例です。鍵がfront-mail配下にあるため、署名のd=はサブドメインとなり、緩和モードで自社ドメインとアライメントが一致します。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCポリシーです。ルートドメインごとに1つです。Frontはfront-mailサブドメインのみで認証するので、アライメントはデフォルトの緩和のままにしてください。厳格（aspf=sまたはadkim=s）にするとFrontの認証に支障が出ます。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Frontの設定がこの上限のうち何回を消費するかは、次のとおりです。
Frontの推奨設定はルックアップを消費しません。10回すべてを、includeが必要な他の送信元に使えます。
DKIM
FrontのDKIMは、静的なTXT公開鍵レコード1つです。FrontがSendGrid経由で生成し、Deliverabilityパネルに表示します。このレコードを送信用サブドメインのセレクター（s1._domainkey.front-mail.yourdomain.comのような形式）に公開してください。対応する秘密鍵はSendGridが保持し、Frontがリレーするすべてのメールに署名します。鍵がfront-mail配下にあるため、DKIM署名はd=front-mail.yourdomain.comとなり、DMARCのデフォルトである緩和モードで組織ドメインとアライメントが一致します。SPFのReturn-Pathと同じ仕組みです。厳格モードでは一致しないので、このドメインではadkim=sを設定しないでください。FrontのDKIMが最新のSendGridのドメイン認証と異なる点は2つあります。1つ目は、自動ローテーションするCNAMEではなく静的なTXT鍵であることです。FrontはSendGridのclassic whitelabelを使うため、鍵は1度貼り付けるだけで、自動ではローテーションしません（再解決のために委任されるものはありませんが、鍵をローテーションしてくれる仕組みもありません）。2つ目は、TXTの値が完全な公開鍵であるため、255文字の単一文字列の上限を超える場合があることです。ほとんどのDNS管理画面では自動的に分割された1つのレコードとして保存されますが、後でチェックツールが鍵を無効と報告した場合、通常の原因は値の破損や切り詰めです。Frontの表示どおりに貼り直してください。SendGridが割り当てるセレクターは、Google（google）やMicrosoft（selector1/selector2）のDKIMセレクターと衝突しないため、FrontのDKIMはメールプロバイダーのDKIMと共存できます。DKIMとSPFのうち、転送に強いのは引き続きDKIMで、SPFが失敗する転送でも維持されます。ただしDMARCのアライメントについてはSPFと同じ緩和モードに依存するので、ポリシーのアライメントは緩和のままにしてください。
DMARC
DMARCは、ルートドメインに設定する別のポリシーレコードです。Frontが作成することはありませんが、Frontの到達率に関するドキュメントでは、両者の関係が説明されています。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを追加します。p=noneは監視のみのため、Frontのメールが認証されることを確認している間、配信には影響しません。Front固有の注意点はアライメントです。SendGridはエンベロープのReturn-PathとDKIMのd=ドメインの両方にfront-mailサブドメインを使うため、Frontのメールは、SPFとDKIMのどちらも緩和モードでは組織ドメインとアライメントが一致し、厳格モードではどちらも一致しません。DMARCのデフォルトは緩和モードなので、標準的なポリシーであれば、Frontのメールは初期設定のまま成功し、追加の設定は不要です。問題が起きるのは、既存のDMARCポリシーが厳格なアライメントを強制している場合だけです。aspf=sにするとFrontのSPFアライメントが、adkim=sにするとDKIMアライメントが一致しなくなり、両方を厳格にするとFrontの認証は完全に失敗します。アライメントは緩和のままにしてください（aspf=r; adkim=rで明示することもできます）。送信者（Front、メールボックスサービス、マーケティングツール）がいくつあっても、_dmarcレコードはドメイン全体で1つだけにし、Front用に2つ目のDMARCレコードを追加しないでください。集計レポートでFront/SendGridが正しく認証されていることを確認できたら、p=noneからp=quarantine、最終的にp=rejectへと段階的に引き上げます。
正しく設定できたか確認する
FrontのVerifiedのバッジだけで判断せず、実際のメールで確認してください。Check DNS settingsでレコードがVerifiedと表示されたら、Frontのチャネルから自分宛てにメールを送り、Gmailで開いて⋮ → Show originalを選びます。SPF: PASS（mailed-by front-mail.yourdomain.com）、DKIM: PASS（signed-by: front-mail.yourdomain.com）、DMARC: PASSと表示され、Fromの行から「via sendgrid.net」タグが消えていれば成功です。レコードそのものは、dig MX front-mail.yourdomain.com（mx.sendgrid.netが返れば正常）、dig TXT front-mail.yourdomain.com（v=spf1 include:sendgrid.netの行が返れば正常）、dig TXT s1._domainkey.front-mail.yourdomain.com（DKIM鍵が返れば正常）、dig TXT _dmarc.yourdomain.comで個別に確認できます。次にQualisendのドメイン診断でドメインをチェックし、すべてのレコードが正しく解決され、ルートドメインのSPFレコードが10回の上限内に収まっていることを確認します。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。Frontは、アライメントが一致して成功している送信元（自社ドメイン名義で署名するSendGridのインフラ）として表示されるはずです。
よくある注意点
- 適用範囲
Frontが求めるMXレコードはメインのMXではありません。front-mailサブドメインに置かれ、SendGridがFrontの送信メールのバウンスを処理するためだけのものです。受信トレイへの経路や受信メールの配信先は変わりません。ホスト@の既存のMXにも影響しません。
- 適用範囲
ホストにはfront-mail.yourdomain.comではなく、ラベルのみ（front-mail、s1._domainkey.front-mail）を入力します。ほとんどのレジストラはドメインを自動で付加するため、重複した名前（front-mail.yourdomain.com.yourdomain.com）は解決されず、Check DNS settingsが失敗します。
- 適用範囲
追加するのは3つの新しいレコードだけです。Frontは、この作業中に既存のDNSレコードを編集または削除しないよう明示的に警告しています。現在のSPF、MX、DKIMのいずれかを変更すると、配信に支障が出るおそれがあります。
- DNS設定
ルートドメインのSPFレコードにinclude:sendgrid.netを追加しないでください。FrontのSPFの対象はfront-mailサブドメインなので、ルートドメインのincludeは冗長で、SPFの10回のルックアップのうち1回を無駄に消費するうえ、SendGridがFrontについて確認する対象でもありません。
- 適用範囲
DMARCを厳格なアライメントにすると、Frontの認証に支障が出ます。エンベロープのReturn-PathとDKIM鍵の両方がfront-mailサブドメインに置かれるため、SPFとDKIMはいずれも緩和モードでのみ自社ドメインとアライメントが一致します。aspf=sにするとFrontのSPFアライメントが、adkim=sにするとDKIMアライメントが一致しなくなり、両方を厳格にするとFrontの認証は完全に失敗します。デフォルトは緩和なので、アライメントは変更しないでください。
- 適用範囲
接続済みのGmail / Microsoft 365チャネルでは、これらのレコードは一切使いません。FrontがSMTPチャネルではなくGoogleやMicrosoftのメールボックスから送信する場合、front-mailサブドメインもviaタグもありません。そのサービス側で認証してください。
- DNS設定
MXレコードとTXTレコードはプロキシできないため、Cloudflareでもオレンジのクラウド/グレーのクラウドの手順はありません（CNAME方式のSendGridドメイン認証とは異なります）。別のタイプではなく、MXとTXTで作成したことだけ確認してください。
- 適用範囲
SMTPの送信ドメインとチャネルは、それぞれ個別に認証します。1つのドメインを設定しても、他のドメインはカバーされません。Deliverabilityパネルでは、レコードが未設定のドメインに黄色の警告アイコンが表示されます。
SPFレコードを作成
Frontでは、ルートドメインに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:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証FrontのSPFに関するよくある質問
関連記事
ヘルプデスク・CRMの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。