SPF設定ガイド

ZendeskのSPF・DKIM・DMARC設定。

Zendeskは、チケットへの返信、通知、自動処理のメールをサポート用アドレス（support@yourdomain.com）から送信します。認証を行うことで、これらのメールが顧客の迷惑メールフォルダーに振り分けられたり、「via zendesk.com」のタグが付いたりするのを防げます。認証の作業は、DNSホストとZendesk Admin Centerに分かれています。SPFは本物の共有includeで、ドメインにある1つのSPFレコードにinclude:mail.zendesk.comを追加します。DKIMは2つのCNAME「digital signature」レコードで、公開したうえでChannels → Talk and email → Emailからオンにします。DMARCは3つ目の独立したレコードで、Zendeskが作成することはありません。前提条件が1つあります。DNS認証が適用されるのは、自社の外部メールドメインから送信する場合のみです。デフォルトのyourbrand.zendesk.comドメインのアドレスはすでにZendeskが署名しているため、設定は不要です。

SPFのinclude

Your DNSAdd the CNAME / TXT records

ZendeskSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Zendeskを認証すべき理由

Zendeskの認証は形式的な作業ではなく、サポートの返信が顧客に届くかどうかを左右します。対応件数の多いサポート窓口は、1日あたり5,000通というしきい値を簡単に超えます。2024年2月以降、GmailとYahooは、これを超える大量送信者に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、大量送信者に対して同様のルールの適用を始めました。外部サポートドメインを認証するまで、Zendesk経由の返信と自社との結び付きは弱いままです。受信者には「via zendesk.com」の表示が見え、Fromアドレスは暗号的に自社のものとは証明されず、DMARCにも成功できません。さらに、迷惑メール報告は自社のレピュテーションとして蓄積されず、Zendeskの共有インフラに集まります。Zendesk固有の事情として、DKIMが欠かせない理由がもう1つあります。Zendeskは独自のzendesk.comのReturn-Pathでバウンスを処理するため、SPFは自社ドメインとアライメントが一致しません。そのためGoogle WorkspaceやMicrosoft 365とは異なり、DMARCの成功をSPFに任せることはできず、アライメントが一致するメカニズムはDKIMだけです。SPFのinclude、2つのDKIM CNAME、DMARCポリシーを設定すれば、返信は自社ドメインの署名付きで送信され、「via」タグは消え、DMARCに成功し、獲得したレピュテーションは自社のものになります。

ZendeskにおけるSPFの実情

Zendeskは本物の「include」型サービスです。ドメインにある1つのSPF TXTレコードに、実在する共有メカニズムのinclude:mail.zendesk.comを1つ追加します。Zendeskが公式に推奨するレコード全体はv=spf1 include:mail.zendesk.com -allです（なりすまし対策を最も強くするため、-allのhard failを推奨しています）。実際のDNSで確認したところ、mail.zendesk.comはip4:の範囲と独自の~allのみを含むフラットなレコードに解決され、ネストされたincludeはありません。そのため、10回のSPF DNSルックアップのうち消費するのはちょうど1回です。ほとんどのチュートリアルが触れていない点ですが、ZendeskのSPFについて最も重要なのは、成功してもアライメントは一致しないということです。Zendeskはデフォルトで、エンベロープのReturn-Path（受信側が実際にSPFチェックを行うMAIL FROM）をZendesk独自のzendesk.comのバウンス用ドメインに置いて送信します。利用者側の自社ドメインには置かれず、このReturn-Pathをそこへ移す仕組みもZendeskにはありません。その結果、SPFはZendeskのインフラに対して認証され成功しますが、チェック対象はFromドメインではなくzendesk.comのサブドメインなので、アライメントは一致しません。DMARCがSPFを評価するのはアライメントが一致した場合だけです。つまり、include:mail.zendesk.comだけではDMARCの成功につながりません。それでも追加する価値はあります。Zendeskが推奨していること、一部の受信側が表示上のFromドメインに対してアライメントなしのSPFチェックを行うこと、SPFに関連するバウンスや迷惑メールフォルダーへの振り分けを防げることが理由です。ただし、ZendeskでDMARCを実際に成功させるのはSPFではなく、DKIMのアライメントです。SPFレコードはドメインに必ず1つだけにしてください（すでにGoogle Workspace、Microsoft 365などから送信している場合は、includeをまとめます）。そのレコードではinclude:mail.zendesk.comを第1階層のメカニズムとして残し、他の正当な送信者をすべて洗い出すまでは-allではなく~allから始めてください。

2つの設定方法

推奨

外部メールドメイン：SPFのinclude + DKIM（推奨）

返信はzendesk.comのアドレスではなく、自社ブランド（support@yourdomain.com）から送信されます
DKIMがd=yourdomain.comで署名するため、DKIMのアライメントでDMARCに成功します
DNSにinclude:mail.zendesk.comと、zendesk1/zendesk2の2つのDKIM CNAMEを追加します
SPFのDNSルックアップを1回消費します。CNAMEが有効になれば鍵は自動でローテーションされます

従来方式

デフォルトのyourbrand.zendesk.comアドレス：設定不要

Zendeskが独自のzendesk.comドメインをすでに認証し、署名しています
公開すべきSPF、DKIM、DMARCレコードはありません
ただし、顧客には自社ブランドではなく、汎用のzendesk.comのFromアドレスが表示されます
レピュテーションは管理できず、他のすべてのテナントとZendeskのドメインを共有します

設定手順

Zendeskで

1
外部サポートアドレスを追加して確認
Admin CenterでChannels → Talk and email → Emailを開き、自社ドメインのサポートアドレス（例：support@yourdomain.com）を追加して確認します。確認方法は、そのメールボックスの受信メールをyourbrand.zendesk.comのアドレスに転送するか、Google Workspace / Microsoft 365を接続するかのいずれかです。SPFのincludeとDKIM CNAMEによるDNS認証は外部ドメインにのみ適用されるため、この手順が必要です。デフォルトのyourbrand.zendesk.comドメインのアドレスは、すでにZendeskが署名しています。

DNSホストで

2
SPFのincludeを追加（既存なら1つにまとめる）
ルートドメインに、v=spf1 include:mail.zendesk.com -allのTXTレコードを追加します（Zendeskは-allのhard failを推奨しています）。SPFレコードがすでにある場合は2つ目を公開せず、既存のv=spf1の行にinclude:mail.zendesk.comをまとめ、第1階層のメカニズムとして残します。他の送信者をすべて記載するまでは~allを使ってください。
3
2つのDKIM CNAMEレコードを追加
2つのCNAMEレコードを作成します。ホストzendesk1._domainkey.yourdomain.comはzendesk1._domainkey.zendesk.comを指し、ホストzendesk2._domainkey.yourdomain.comはzendesk2._domainkey.zendesk.comを指します。2つあるのは、ZendeskがセキュリティのためにDKIM鍵をローテーションするからです。Zendeskがこれらのホスト名の背後で鍵を保持しているため、TXTではなく必ずCNAMEレコードにしてください。
4
DMARCレコードを公開
_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comのTXTレコードを追加します。p=noneは監視のみで、ZendeskのメールがDKIMに成功し自社ドメインとアライメントが一致していることを確認する間、配信には何も影響しません。_dmarcレコードはドメイン全体で1つだけにしてください。
5
レコードの反映を待つ
次の手順に進む前に、DNSの反映まで数時間（場合によっては最大1日）待ちます。この時点ではまだZendeskでDKIM署名を有効にしないでください。CNAMEが解決される前にオンにすることが、Zendeskの配信エラーの最も多い原因です。

Zendeskで

6
DKIM署名をオンにする（必ず最後の手順）
Admin Center → Channels → Talk and email → Emailに戻り、DKIM / digital-signatureの設定を見つけてCustom domain for DKIMを選択し、Saveをクリックします。Zendeskは、これを最後に行う必要があると明言しています。ドメインのCNAMEレコードが有効になる前にオンにすると、配信エラーが発生します。

確認

7
テスト返信を送信してヘッダーを読む
テストチケットに返信してZendeskから実際のメールを送信し、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASSでyourdomain.comの署名（セレクターはzendesk1またはzendesk2）があり、DMARC: PASSであることを確認します。SPFはpassと表示されますがアライメントは一致しません（Return-Pathはzendesk.comのドメインです）。これは想定どおりで問題ありません。DMARCの成功を担っているのはDKIMです。
8
ブランドとサポートドメインごとに手順を繰り返す
別のドメインにある外部サポートアドレスには、それぞれ専用のSPFのinclude、zendesk1/zendesk2のDKIM CNAME、DMARCレコードが必要で、Custom domain for DKIMのトグルも有効にします。1つのドメインを認証しても、他のドメインには適用されません。

追加するレコード

正確な値はZendeskのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。

タイプ	ホスト	値
TXT	@	v=spf1 include:mail.zendesk.com -allルートドメインのSPF：SPFレコードは1つだけにし、include:mail.zendesk.comをそこにまとめます。ZendeskのReturn-Pathはzendesk.comのドメインのため、成功してもアライメントは一致せず、これだけではDMARCの成功につながりません。DNSルックアップを1回消費します。
CNAME	zendesk1._domainkey	zendesk1._domainkey.zendesk.comDKIM鍵1。このターゲットはすべてのZendesk顧客に共通で（アカウントごとの値ではありません）、自社のものはホストのドメインだけです。背後の鍵はZendeskが自動でローテーションします。
CNAME	zendesk2._domainkey	zendesk2._domainkey.zendesk.comDKIM鍵2。Zendeskが鍵をローテーションするため、両方とも必要です。こちらも全顧客に共通の共有ターゲットです。
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCレコードはドメインごとに1つです。ZendeskではこのレコードがDKIMのアライメントを通じてDMARCの成功をもたらします。p=noneから始め、DKIMを確認できたらquarantine/rejectへ引き上げます。

ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。

DNSルックアップの10回制限

SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Zendeskの設定がこの上限のうち何回を消費するかは、次のとおりです。

SPF 10-lookup budget1 used · 9 free

Zendeskは10回のルックアップのうち1回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。

DKIM

ZendeskのメールがDMARCに成功できるのはDKIMのおかげです。そのため、最も重要なレコードはDKIMです。zendesk1._domainkey.yourdomain.com → zendesk1._domainkey.zendesk.comとzendesk2._domainkey.yourdomain.com → zendesk2._domainkey.zendesk.comの2つのCNAMEレコードを公開してから、Admin Centerで署名を有効にします。Zendesk固有の注意点がいくつかあります。1つ目に、これらは貼り付けるTXT鍵ではなくCNAMEです。Zendeskが秘密鍵を保持し、zendesk1._domainkey.zendesk.comとzendesk2._domainkey.zendesk.comの背後で公開鍵を提供しています。そのため、DNSを再度編集しなくても、Zendesk側で鍵を（およそ四半期ごとに）ローテーションでき、CNAMEのルックアップは常に現在の鍵に解決されます。2つ目に、どちらのホスト名もすべての顧客に共通のzendesk.comのターゲットを指します。アカウントごとの値はないため、ターゲットを独自の値に変えたり、アカウントIDを貼り付けたりしないでください。セレクターが2つ（zendesk1とzendesk2）あるのは、まさにこのローテーションを途切れなく行うためで、一方が有効な間、もう一方が待機します。3つ目に、DKIMが機能するのは外部メールドメインのみです。yourbrand.zendesk.comのアドレスから送信するメールに、自社ドメインとしてDKIM署名することはできません。最後に、CNAMEを公開しただけでは、署名をオンにするまで何も起こりません。Admin Center → Channels → Talk and email → Emailを開き、Custom domain for DKIMを選択してSaveをクリックします。ただし、必ずCNAMEが反映された後に行ってください。早く有効にすると配信エラーの原因になります。有効になるとZendeskはd=yourdomain.comで署名し、Fromドメインとアライメントが一致してDMARCに成功します。

DMARC

DMARCは独立したポリシーレコードで、Zendeskが作成することはありません。_dmarc.yourdomain.comに、自分でTXTレコードとして公開します。値の先頭はv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comです。p=noneは監視のみで、配信には何も影響せず、受信側に集計レポートをメールで送るよう求めます。これにより、ZendeskのメールがDMARCに成功していることを確認できます。Zendesk固有の注意点は、DMARCの成功が完全にDKIMに依存することです。Return-Pathがzendesk.comのバウンス用ドメインにあるため、ZendeskのSPFはアライメントが一致しません。そのため、ポリシーを引き上げる前に、ruaレポートで、ZendeskがDKIMのアライメントが一致して成功している送信元として表示されることを確認してください。DKIMの設定に誤りがあるままp=quarantineやp=rejectに進むと、SPFでは補えず、サポートの返信が隔離または拒否され始めます。1～2週間レポートを確認し、Zendeskと他の正当な送信者すべてのアライメントが一致していることを確かめてから、p=quarantine、最終的にp=rejectへ進みます。送信者がいくつあっても、_dmarcレコードはドメイン全体で1つだけにしてください。Zendeskのためだけに2つ目を追加してはいけません。

正しく設定できたか確認する

Admin Centerのステータスだけで判断せず、実際のメールで確認してください。テストチケットに返信してZendeskに外部サポートアドレスからメールを送信させ、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASSとsigned-by: yourdomain.com（セレクターはzendesk1またはzendesk2）、そしてDMARC: PASSと表示されていれば成功です。SPFはpassと表示されますがアライメントは一致せず、mailed-by/Return-Pathはzendesk.comのドメインになります。これはZendeskでは想定どおりで設定ミスではないため、SPFのアライメントを一致させようとする必要はありません。生のレコードは、dig CNAME zendesk1._domainkey.yourdomain.com（zendesk.comまで解決されるはずです）とdig TXT _dmarc.yourdomain.comで確認できます。その後、Qualisendのドメイン診断でドメインをチェックし、すべてのレコードが解決され、SPFがDNSルックアップの10回制限内に収まっていることを確認します。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップしてください。SPFのアライメントは一致しなくても、ZendeskはDKIMのアライメントが一致して成功している送信元として表示されるはずです。

ドメイン診断 DMARCレポート解析

よくある注意点

DNS設定
DKIMは最後に有効にします。Zendeskは、zendesk1/zendesk2のCNAMEが反映される前にCustom domain for DKIMを選択すると配信エラーが発生すると明言しています。先に公開してDNSが落ち着くまで（数時間～1日）待ってから切り替えてください。
適用範囲
SPFのアライメントは仕様上一致しません。Zendeskは独自のzendesk.comのReturn-Pathでバウンスを処理するため、include:mail.zendesk.comでSPFのチェック自体は成功しても、自社ドメインとアライメントは一致せず、これだけではDMARCの成功につながりません。アライメントが一致するのはDKIMです。SPFのアライメントを一致させる手段はZendeskにないので、無理に一致させようとして時間を費やさないでください。
適用範囲
DKIMが機能するのは外部メールドメインのみです。yourbrand.zendesk.comのアドレスから送信するメールに自社ドメインとして署名することはできないため、先に自社ドメインのサポートアドレス（support@yourdomain.com）を追加して確認する必要があります。
DNS設定
DKIM CNAMEのターゲットは固有ではなく共有です。どちらもすべてのZendesk顧客でzendesk1._domainkey.zendesk.com / zendesk2._domainkey.zendesk.comを指します。アカウントIDを追加したりターゲットを「独自の値に変更」したりせず、TXTレコードとして公開しないでください。
認証失敗の原因
SPFレコードは必ず1つだけにし、includeは第1階層に置きます。すでにGoogle Workspace、Microsoft 365などから送信している場合は、include:mail.zendesk.comをその1つのv=spf1の行にまとめてください。SPFレコードが2つあるとPermErrorになり、ネストされたルックアップの中にincludeを埋め込むと第1階層で解決されなくなる場合があります。
適用範囲
-allと~allの違い。Zendeskは-allのhard failを推奨していますが、SPFに正当な送信者がすべて記載されていない段階で-allにすると、他のメールがhard failになります。すべての送信者を洗い出すまでは~allを使い、その後-allに引き上げてください。
DNS設定
ホスト欄のドメイン重複。多くのレジストラはドメインを自動で付加するため、zendesk1._domainkey.yourdomain.comと入力するとzendesk1._domainkey.yourdomain.com.yourdomain.comになります。管理画面がドメインを付加する場合は、ラベルのzendesk1._domainkeyだけを入力してください。
DNS設定
複数のブランドやドメインには、それぞれすべての設定が必要です。外部サポートドメインごとに専用のSPFのinclude、2つのDKIM CNAME、DMARCレコードが必要で、Custom domain for DKIMも有効にします。1つのドメインの設定は他のドメインには適用されません。

SPFレコードを作成

以下ではZendeskがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。

送信元

メールの送信に使っているサービスを検索して、それぞれチェックを入れてください。

選択済み

Zendeskinclude:mail.zendesk.comガイド →

このドメイン自身のサーバー

ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。

a（ドメイン自身のAレコード）mx（ドメインのMXホスト）

その他の送信元・IP

リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。

追加のinclude

接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。

IPv4アドレス

IPv6アドレス

その他すべての送信元へのポリシー

上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。

-all (fail)厳格：記載されていないサーバーからのメールを拒否するよう受信側に求めます。~all (softfail)推奨の初期設定：記載されていない送信元のメールは受け付けられますが、疑わしいものとして扱われます。?all (neutral)判定なし：保護効果はほとんどありません。テスト中のみ使用してください。

生成されたSPFレコードDNSルックアップ1/10回

v=spf1 include:mail.zendesk.com ~all

ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。

送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。

リストを検証

ZendeskのSPFに関するよくある質問

はい。Zendeskはv=spf1 include:mail.zendesk.com -allを公式に推奨しており、SPFに関連するバウンスや迷惑メールフォルダーへの振り分けを防げます。ただし、できることとできないことを理解しておいてください。SPFのチェック自体は成功しますが、Zendeskは独自のzendesk.comのReturn-Pathを使うため、SPFは自社ドメインとアライメントが一致せず、includeだけではDMARCに成功できません。ZendeskでDMARCの成功を担うのはDKIMです。

いいえ。Zendeskでは想定どおりです。送信メールのバウンスはzendesk.comのReturn-Pathで処理されるため、SPFは自社ドメインではなくZendeskのドメインに対して認証され、アライメントは一致しません。設定ミスではなく、変更できる設定もありません。DKIM（zendesk1/zendesk2の2つのCNAMEと、Admin CenterのCustom domain for DKIM）を有効にすれば、DKIMのアライメントでDMARCに成功します。

2つのCNAMEレコードです。自社ドメインのzendesk1._domainkeyとzendesk2._domainkeyが、それぞれ対応するzendeskN._domainkey.zendesk.comのホストを指します。TXTではなくCNAMEなのは、Zendeskが秘密鍵を保持し、これらのホスト名の背後でおよそ四半期ごとにローテーションするからです。セレクターが2つあることで、DNSを編集し直さなくてもZendeskが新しい鍵を準備できます。両方とも必要です。

ほとんどの場合、DKIMがまだ自社ドメインとして署名していないことが原因です。「via zendesk.com」のタグが付く原因は2つあります。メールが自社ドメインとしてDKIM署名されていないか、まだデフォルトのyourbrand.zendesk.comアドレスから送信されているかです。自社ドメインのサポートアドレスを追加して確認し、zendesk1/zendesk2のCNAMEを公開して反映を待ってから、Admin Center → Channels → Talk and email → EmailでCustom domain for DKIMを有効にします。Zendeskがd=yourdomain.comで署名するようになると、Gmailの「via」表示は消え、DMARCに成功します。迷惑メールフォルダーへの振り分けが続く場合、たいていはDKIMがまだ有効になっていない、CNAMEが反映されていない、またはDKIMのアライメントが一致する前にDMARCをp=quarantine/rejectに引き上げた、のいずれかです。ZendeskのSPFでは補えないため、ポリシー適用中にDKIMの設定に問題があると、返信は迷惑メールに直行するかバウンスします。

いいえ。Zendeskは独自のzendesk.comのReturn-Pathで送信メールのバウンスを処理します。このエンベロープドメインを利用者側の自社ドメインに移す設定は用意されていません。そのためSPFはZendeskに対して認証され、Fromドメインとアライメントが一致することはありません。これは仕様であり、設定ミスではないので、存在しないカスタムReturn-Pathのオプションを探さないでください。Zendeskでアライメントが一致するメカニズムはDKIMだけです。Custom domain for DKIMを有効にし、DKIMのアライメントのみでDMARCに成功させてください。

はい。外部サポートドメインはそれぞれ個別に認証されます。そのドメインのSPFレコードへのinclude:mail.zendesk.com、専用のzendesk1/zendesk2のDKIM CNAME、専用の_dmarcレコードが必要で、そのアドレスでCustom domain for DKIMも有効にします。1つのブランドのドメインを認証しても他には影響しないため、ドメインごとにすべて設定してください。

送信ドメイン認証：SPF・DKIM・DMARCの解説3つのレコードが連携する仕組みの基本を解説します。Zendeskをドメインに組み込む前に読んでおくと役立ちます。DMARCの設定手順ZendeskのDMARCの成功は完全にDKIMに依存します。_dmarcポリシーを正しく設定し、p=noneからポリシー適用へ安全に移行します。DMARCレポートの読み方quarantineやrejectへ引き上げる前に、集計レポート（rua）でZendeskがDKIMのアライメントが一致した状態で表示されることを確認します。GoogleとYahooの送信者ガイドライン1日5,000通の大量送信者向けルールです。対応件数の多いZendeskのサポート窓口では、認証が欠かせません。ドメイン診断SPFのinclude、2つのDKIM CNAME、DMARCがすべて解決され、SPFがDNSルックアップの10回制限内に収まっていることを確認します。DMARCレポート解析集計レポートをドロップすると、SPFのアライメントが一致していなくても、ZendeskがDKIMのアライメントが一致して成功している送信元であることを確認できます。

ヘルプデスク・CRMの他のサービス

すべてのSPFガイド

ZendeskのSPF、DKIM、DMARCを毎日監視レコードの設定は、最初の一歩にすぎません。ドメイン診断の監視は、SPFのルックアップ数、DKIMキー、DMARCポリシーを毎日再チェックし、どれかが壊れたときにメールでお知らせします。ドメイン診断の監視を見る SPFのDNSルックアップが多すぎる場合：数え方とpermerrorの直し方

Zendesk連携QualisendのZendesk連携で、Zendeskアカウント内のメールアドレスを検証できます。

公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。

認証の次は、リストをクリーンに保つ

SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。

検証を始める

Zendeskの​SPF・DKIM・DMARC設定。