メール認証について

推定 1 分で読めます

更新日 2026年1月17日 0:00 EST

このページで学べること

送信者の評判の構築、メールが正当な送信者から送信されていることの検証、メールの不正使用からの保護に使用されるメール認証プロトコルについて学びましょう。

ほとんどの受信トレイプロバイダーは、一括送信者に対して送信者要件を適用しています。DMARC 認証の設定は、これらの要件を満たすための重要な要素であり、特に大量送信者にとっては不可欠です。参考として、Google は Gmail 受信者に 1 日あたり 5,000 通以上のメールを送信する人を「一括送信者」とみなします。

メール認証について

[メール認証] は、メール送信者の身元の確認を可能にする技術標準を指します。最も一般的に使用されるメール認証標準は SPF、DKIM、DMARC です。メールサーバーは、これらの認証プロトコルを使用して受信メールが正当な送信者からのものであることを確認し、悪意のある行為者からブランドと顧客を保護します。フィッシングやなりすましの試みを防ぐことに加えて、これらのプロトコルを実装すると、メールボックスプロバイダーが送信者の身元を確認できるようになるため、デリバビリティの向上にも役立ちます。

SPF

Sender Policy Framework（SPF）は、メール配信時に送信者アドレスのなりすましを検出するために設計されたメール認証方法です。SPF により、受信側メールサーバーは、特定のドメインから送信されたメールが、そのドメインの管理者によって承認された IP アドレス経由で送信されたものかを確認できます。

許可されていない SPF 経由の IP アドレスからメールが送信された場合、受信側のメールサーバーがそのメールを拒否したり、メインの受信トレイではなく別の場所に振り分けたりする可能性があります。SPF レコードがない場合、送信ドメインを使用して IP を認証できず、悪意のある行為者が容易にブランドになりすますことが可能になります。

Klaviyo の共有送信ドメインでは、メールは SPF を通じて自動的に認証されます。Klaviyo で独自のブランド送信ドメインを使用している場合、必要な SPF レコードは、設定時に追加した CNAME または NS レコードを通じて自動的に追加されます。

DKIM

DomainKeys Identified Mail（DKIM）は、送信者の身元をさらに検証するためにメールのヘッダーに追加されるデジタル署名として機能します。メールを受信するサーバーは、署名用ドメインに対して公開されている公開鍵を使用して署名を検証します。DKIMは、署名されたコンテンツが署名を無効にする形で変更されない限り、メールが転送されても有効なままでいられます。

Klaviyo の共有送信ドメインでは、メールは DKIM によって自動的に認証されます。Klaviyo で独自のブランド送信ドメインを使用している場合、必要な DKIM レコードは、設定時に追加した CNAME または NS レコードを通じて自動的に追加されます。

DMARC

DMARC は、ドメインベースのメッセージ認証、レポート作成、および適合性を表します。SPF と DKIM を使用してメールの真正性を判断するプロトコルであり、ドメイン所有者が不正使用からドメインを保護できるようにします。

DMARCは、受信サーバーに対して、受信したメールをどのように処理するかの指示を提供します。DMARCに合格するには、メッセージがSPFまたはDKIM認証に合格し、かつその方法で認証されたドメインがfrom-address内のドメインと一致している必要があります。DMARCでは両方の方法に合格する必要はありませんが、受信トレイプロバイダーによっては、SPFとDKIMの両方を設定することを求められる場合があります。DMARCチェックに失敗したメッセージは、ドメインのポリシーと受信サーバーのルールに応じて、許可、拒否、または迷惑メールフォルダへの振り分けが行われます。

ドメインに DMARC ポリシーを実装すると、なりすましから保護し、詐欺的で有害となり得るメッセージにブランドと受信者がさらされるリスクを抑えるのに役立ちます。

DMARC ポリシーの例

DMARC は、メール認証、ポリシー、レポート作成のプロトコルであり、Klaviyo に限らず、ブランドから送信されるあらゆるメールに影響します。ブランドのニーズに最適な DMARC ポリシーを実装するには、IT チームまたはサードパーティの専門家と連携することが重要である点にご注意ください。

以下は、シンプルな DMARC レコードがどのように見えるかの例と、さまざまなレコードがメール配信に与える影響です。

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbrand.com

DMARC レコードでは sp タグが省略されることが一般的であり、その場合、sp タグは p タグの値がデフォルトとして適用されます。

DMARC ポリシーには機能の異なる複数のタグが含まれる場合がありますが、Klaviyo とメールマーケティングにおいて最も重要なのは p と sp のポリシータグです。

これら2つのタグの値は、整合性チェックが失敗した場合に受信トレイプロバイダがどのように対応すべきかを示します。送信元メールアドレスで使用する場合、pタグはルートドメイン（例：@yourbrand.com）に適用されます。一方、spタグはサブドメイン（例：@shop.yourbrand.com）に適用されます。サブドメインに独自のDMARCレコードがある場合、そのレコードのポリシーが、そのサブドメインから送信されるメールに対して優先されます。

一方、例の rua タグは、受信トレイの DMARC レポートの送信先を決定します。このタグは推奨されていますが、必須ではありません。

上記のプレースホルダーのメールアドレス（つまり、dmarc-reports@yourbrand.com）は、rua タグを使用する予定がある場合に DMARC レポートを受信できる受信箱に置き換えてください。

p/sp タグの値	DMARCに失敗したメールに対する要求された処理
p=なし	DMARC失敗に基づくアクションは要求しません。他の迷惑メールフィルタリングも引き続き適用されます。
p=quarantine	メールを迷惑メールに振り分けるなど、不審なメールとして扱うようにリクエストしてください。
p=却下	メールが拒否されるようにリクエストします。

DMARC ポリシーは、ドメインの DNS コントロールパネルで TXT レコードとして設定しますが、特定の構文ルールに従う必要があります。

p タグと sp タグが Klaviyo での送信に与える影響

共有送信ドメインで送信する場合、fromアドレス内のドメイン（例：marketing@yourbrand.com）はKlaviyoの送信ドメイン（例：ksdn.klaviyomail.com）と一致しません。DMARCは、fromアドレスのドメインに対するポリシーを使用します。Klaviyoの共有ドメイン上のポリシーは、ブランドのポリシーを上書きしたり、メールをDMARCに合格させたりするものではありません。

ブランド送信ドメインを使用すると、DKIM認証に使用するドメインを差出人アドレスのドメインと一致させることができます。DKIM認証が成功し、そのドメインが差出人アドレスと一致している場合、DMARCは合格となります。デフォルトの緩和された整合性設定では、ドメインはルートドメインを共有できます。厳格な整合性では、完全に一致するドメインが必要です。

rua タグと DMARC レポート作成

DMARC レコードの rua タグを使用すると、関連するメールアドレスで .xmlフォーマット。これらのレポートは解釈が難しく手間がかかるため、DMARC レポート作成に rua タグを使用する予定がある場合は、DMARC サービスプロバイダーと連携することを Klaviyo は推奨します。これらのプロバイダーは .xml の処理に役立ちます。DMARC レポートを提示し、ブランドがより容易にインサイトを得られるようにします。

別のルートドメイン上のアドレスでDMARCレポートを受信するには、レポートを受信するドメインの所有者が、そのドメインのDNSにあるTXTレコードで承認する必要があります。この承認についてはDMARCサービスプロバイダーの手順に従い、ご自身のDMARCレコードのruaタグでレポート作成アドレスを設定してください。

DMARC レポートの例

Klaviyo が推奨する DMARC プロバイダーの例：

メール認証の設定

Klaviyo でメールを送信する場合、独自の SPF および DKIM レコードを追加する必要はありません。Klaviyo の共有送信ドメインで送信している場合、必要なレコードはすでに設定されており、認証に合格するようになっています。ブランド送信ドメイン（専用送信ドメインとも呼ばれます）では、セットアップ中に追加した Klaviyo の NS または CNAME レコードによって DKIM と SPF の認証が自動的に有効になります。

DMARCでは、ドメインのDNSに別途TXTレコードが必要です。ブランド送信ドメインの設定中に、ドメインにDMARCレコードがまだない場合、KlaviyoにはDMARCレコードを追加が表示されます。これによりv=DMARC1; p=noneが生成されます。対応しているDNSプロバイダーの場合はEntriに接続でレコードを自動的に公開できます。または、手動で設定を選択し、DNSプロバイダーで追加してください。

ブランドで現在DMARCポリシーが設定されていない場合、p=noneを構成することは、受信トレイプロバイダーの要件を満たすための第一歩です。DMARCポリシー要件は満たしますが、プロバイダーが定める他の送信者要件も満たす必要があります。ruaタグを追加することで、p=noneでDMARCレポートを受信できます。Klaviyoでは、なりすましから保護するため、より厳格なポリシーに移行する前に、ITチームまたはサードパーティの専門家と連携することを推奨しています。

Entriを介して自動セットアップを承認する場合を含め、レコードを公開するには、ドメインのDNS設定にアクセスできる必要があります（ご自身またはチームの誰か）。ITチームまたはDMARCサービスプロバイダーと一緒にポリシーを選択してください。これは、Klaviyo以外からもドメインから送信されるメールに影響するためです。

DNS で DMARC を設定する

DMARCレコードを手動で追加するには、DNSプロバイダーの設定を使用してください。以下の手順では一般的なプロセスを説明しています。フィールド名と手順はプロバイダーによって異なります。

ドメインのDNS設定にログインし、_dmarc.yourbrand.comに既存のTXTレコードがあるか確認してください（yourbrand.comをドメインに置き換えてください）。DMARCレコードがすでに存在する場合は、2つ目のレコードを追加したり、ポリシーをp=noneに置き換えたりするのではなく、ITチームまたはDMARCサービスプロバイダーと一緒に内容を確認してください。
DMARCレコードが存在しない場合は、次の情報で新しいレコードを作成してください：
- タイプ：TXT
- ホスト：_dmarc
- 値: v=DMARC1; p=none

rua タグは任意で、DMARCのレポート作成に使用されます。レポートを受け取るには、v=DMARC1; p=none; rua=mailto:email@yourbrand.comを使用してください。email@yourbrand.comを、レポートを受信できるよう準備された受信トレイに置き換えてください。

DNSプロバイダーにレコードを保存してください。DNSの変更が反映されたら、メール認証設定の確認に記載されている手順に従って、レコードを検証し、送信済みメールの認証結果を確認してください。

新しいレコードを作成するためのフィールド、インターフェース、プロセスの名称は、DNS プロバイダーによって異なる場合があります。DNS プロバイダーの例としては GoDaddy や Namecheap がありますが、他にも多数あります。

ドメインで DMARC を設定する方法の詳細については、以下のリソースやサービスを参照するか、DNS プロバイダーに問い合わせることをおすすめします。

Klaviyo Email を DMARC 準拠にする

KlaviyoメールをDMARCに準拠させるには、フレンドリーFromのメールアドレス（つまり、Fromアドレス）のルートドメインと同じルートドメインを共有するブランド送信ドメインを設定して有効化し、ドメインのDMARCレコードを公開してください。たとえば、Fromアドレスとしてsales@yourbrand.comを使用してメールを送信し、yourbrand.comがDMARCで保護されている場合、DMARC要件を満たすには、アカウントでsend.yourbrand.comのようなブランド送信ドメインを使用する必要があります。

送信者メールアドレスを更新して、ブランド送信ドメインに対応させる方法をご覧ください。

内部受信者

共有ドメインを使用して社内の受信者にメールを送信する場合、受信者のメールアドレスが送信元アドレスと同じドメインを使用していると、受信トレイプロバイダーによっては警告メッセージが表示され、メールがスパムに振り分けられることがあります。

例：Gmail の場合：

この社内受信者に関する警告は、受信者のメールアドレスがご自身の送信元アドレスのドメインを使用している場合に適用されます。整合性の取れたブランド送信ドメインは、認証に関連する警告の解消に役立つ場合がありますが、受信トレイへの配信を保証するものではありません。

個人の受信トレイで警告が表示される場合は、メールヘッダーを確認して、DMARCが失敗しているかどうかを確認してください。失敗している場合は、ブランド送信ドメインがアクティブであり、送信者メールアドレス（差出人アドレス）のドメインと一致していることを確認してください。

メール認証設定を確認しています

レコードが正常に公開されたことを確認するには、EasyDMARCが提供するDMARCチェッカーに、送信元アドレスのドメインを入力してください。意図したポリシーを持つ有効なDMARCレコードが見つかることを確認してください。有効なp=noneレコードはDMARCポリシー要件を満たしますが、DNSルックアップだけでは、メールがDMARCに合格していることや、すべての受信トレイプロバイダーの送信者要件を満たしていることは確認できません。EasyDMARCは、p=noneが強制適用ポリシーではないため、警告ステータスを表示します。これは想定どおりであり、DMARCポリシー要件も満たしています。

DNSレコードを確認した後、ブランドから送信されたメールのヘッダーを使用して認証を検証してください。

メールヘッダーには、メールに関するメタデータと、メールがたどったネットワーク経路が含まれます。これには、送信元アドレス、件名、受信者、SPF、DKIM、DMARC がパスしているかどうかなどの主要な認証の詳細といった情報が含まれます。

メールヘッダーを使用してメール認証の設定を確認する方法を確認してください。

より安全な DMARC ポリシーへの移行

DMARCポリシーをp=noneに設定するとDMARCポリシー要件は満たせますが、より安全性の高いポリシーに移行することで、悪意のある攻撃者からビジネスをより確実に保護できます。

より安全なポリシーのメリット

p=quarantineまたはp=rejectを使用する主なメリットは、DMARCに失敗したメッセージを受信者のメインの受信トレイに届かないよう、受信トレイプロバイダーに要求できることです。p=noneはDMARC失敗に基づくアクションを求めないため、ブランドになりすまそうとする悪意のある攻撃者からのメールが受信者に届く可能性があります。ブランドから送信されたように見える偽装メールをユーザーが閲覧すると、ブランドのメールに対する信頼が損なわれる可能性があります。

p=quarantineのポリシーでは、失敗したメールを疑わしいものとして扱うようプロバイダーに求めます（例：スパムに振り分ける）。p=rejectのポリシーでは、それらを拒否するようプロバイダーに求めます。最終的な配信可否の判断は、受信側プロバイダーが行います。

その他の考慮事項

DMARCは、Klaviyo外から送信されるものも含め、ブランドから送信されるすべてのメールに適用される点にご注意ください。p=noneのポリシーでは、DMARCの失敗だけを理由に何らかの対応が求められることはありませんが、他のスパムフィルタリングは引き続き適用されます。ただし、より厳格なDMARCポリシーを適用すると、ビジネス全体のメール送信インフラとユースケース全体でドメインが整合していない場合、メールが配信されない可能性があります。

このため、Klaviyo は IT チームまたは DMARC サービスプロバイダーと連携して、ブランドのニーズに最適なポリシーを実装することを推奨しています。