ベアメールブログ

先進認証（モダン認証）とは？ OAuth 2.0の仕組みや基本認証との違いを解説

菱沼憲司 — Thu, 18 Jun 2026 15:00:00 GMT

近年、Microsoft 365をはじめとするクラウドサービスでは、セキュリティ強化のため、基本認証（レガシー認証）から先進認証（モダン認証）への移行が進んでいます。しかし、両者の違いや、OAuth 2.0など関連する用語の意味を整理できていないという方もいるのではないでしょうか。

本記事では、先進認証と基本認証の違いや、メール送信における認証方式について解説します。

先進認証（モダン認証）とは
- OAuth2.0を利用したトークンベースの認証方式
基本認証（レガシー認証）とは
- ID・パスワードを利用した認証方式
先進認証と基本認証の違い
メール送信における認証方式
- SMTP AUTHとは
- 先進認証への移行が求められるケース
まとめ

先進認証（モダン認証）とは

先進認証（モダン認証）は、クラウドサービスなどへのアクセスをより安全に管理するための認証方式です。

異なる種類の認証要素を2つ以上組み合わせて本人確認を行う「多要素認証（MFA）」や、ユーザや端末、アクセス元などの条件に応じてアクセスを制御する「条件付きアクセス」と組み合わせることで、不正アクセスのリスクを抑えられます。

OAuth2.0を利用したトークンベースの認証方式

先進認証では、OAuth 2.0を利用してサービスへのアクセスを制御します。

OAuth 2.0は、本人確認を行う「認証（Authentication）」ではなく、ユーザやアプリに対してサービスを利用する権限を与える「認可（Authorization）」のためのフレームワークで、RFC 6749で定義されています。

OAuth 2.0では、ユーザ認証や同意が完了すると、クライアントアプリにアクセストークンが発行されます。アプリは、サービスへアクセスする際に、ユーザのパスワードではなく、発行されたアクセストークンを提示します。サービス側は、トークンに紐づくアクセス権限や有効期限を確認し、利用を許可します。

このように、先進認証ではアプリがパスワードを直接扱わず、トークンを利用してサービスへアクセスします。そのため、アクセス権限の範囲や有効期限を制御しやすい点が特徴です。

基本認証（レガシー認証）とは

基本認証（レガシー認証）は、先進認証が普及する以前から利用されてきた従来の認証方式です。設定が比較的容易で、多くのアプリや機器で利用されてきました。

ID・パスワードを利用した認証方式

基本認証では、アプリがサービスへ接続する際に、ユーザIDとパスワードを送信します。サービス側は、受け取った情報が正しいかを確認し、認証に成功した場合にアクセスを許可します。

メール送信においては、メールソフトや業務システム、複合機などにユーザIDとパスワードを設定し、SMTPサーバーへ接続する方法が利用されてきました。先進認証とは異なり、アプリがユーザのパスワードを直接扱う点が特徴です。

Microsoft 365など一部のクラウドサービスでは、ユーザIDやパスワードの漏えいによる不正利用のリスクを考慮し、基本認証から先進認証への移行が進められています。

Exchange Onlineの基本認証廃止については、以下の記事で詳しく解説しています。

先進認証と基本認証の違い

先進認証と基本認証の主な違いは、以下の通りです。

項目	先進認証	基本認証
サービスへのアクセスに使用する情報	アクセストークン	ユーザID・パスワード
パスワードの取り扱い	サービスへのアクセス時に、アプリがパスワードを直接送信しない	サービスへのアクセス時に、アプリがパスワードを直接送信する
セキュリティ機能との連携	多要素認証や条件付きアクセスと組み合わせられる	多要素認証や条件付きアクセスに対応できない場合がある
アクセス権限の制御	トークンごとにアクセス先や権限の範囲、有効期限を設定できる	パスワード自体には、アクセス先や権限の範囲を限定する仕組みがない
導入・対応のしやすさ	アプリやサービス側の対応が必要	対応している機器・システムが多く、導入しやすい

基本認証では、アプリがユーザIDとパスワードを直接扱うため、認証情報が漏えいすると、第三者に不正利用されるおそれがあります。

一方、先進認証では、パスワードの代わりにアクセス権限や有効期限が設定されたアクセストークンを使用します。また、多要素認証や条件付きアクセスとも組み合わせられるため、基本認証単体で利用する場合と比べて、不正アクセスのリスクを抑えやすくなります。

ただし、先進認証を利用するには、接続元のアプリやシステムがOAuth 2.0に対応している必要があります。既存の業務システムや複合機などでは対応が難しい場合もあるため、実際の運用では、セキュリティ要件とシステムの対応状況を踏まえて認証方式を選ぶことが重要です。

メール送信における認証方式

ここまで、クラウドサービス全般における先進認証と基本認証について紹介してきました。

メール送信においても、Exchange Onlineでは、基本認証の一つであるSMTP AUTHの段階的な廃止と、先進認証（OAuth 2.0）への移行が進んでいます。こうした環境を利用している場合は、移行のスケジュールを把握し、適切に対処する必要があります。

SMTP AUTHとは

SMTP AUTHは、IDとパスワードを使用した基本認証の一つで、メールソフトや業務システムなどのSMTPクライアントが、SMTPサーバーへメールの送信を依頼する際に認証を行うための仕組みです。クライアントが認証情報を提示し、サーバーはその情報を検証したうえで、メール送信を許可します。

SMTP AUTHには、幅広い環境で利用しやすいというメリットがあります。多くのメールソフト、業務システム、複合機、監視ツールなどがSMTP AUTHに対応しており、既存システムからメールを送信する際に導入しやすい方式です。

また、OAuth 2.0への対応が難しいシステムでも、SMTP AUTHであれば比較的少ない改修でメール送信を継続できる場合があります。また、送信元のシステムやネットワークを自社で管理できる環境では、SMTP AUTHを利用しながら、IPアクセス制限やTLSによる通信経路の暗号化、送信専用アカウントの利用、ログ監視などを組み合わせることで、セキュリティを強化できます。

先進認証への移行が求められるケース

一方、Exchange Onlineでは、セキュリティの観点からSMTP AUTH廃止の方針が示されており、OAuth 2.0による先進認証への移行が求められています。SMTP AUTHを利用してメールを送信している場合は、メールソフト・業務システムなどの先進認証への対応状況を確認し、適切に対処する必要があります。

なお、先進認証への対応が難しいシステムでは、Exchange Onlineへ直接接続する代わりに、外部のメールリレーサービスへ送信先を変更し、メール配信を中継させる方法もあります。

「ベアメールメールリレーサービス」は、既存のメールサーバーや業務システムから送信されるメールを中継し、宛先へ配信するサービスです。送信先のSMTPサーバーをベアメールに変更することで、現在のシステムを活用しながらメール配信環境を整備できます。

先進認証への対応が難しい既存システムからのメール送信にお悩みの方は、ぜひベアメールへご相談ください。

Exchange OnlineにおけるSMTP AUTH廃止の詳細や具体的な移行スケジュールについては、以下の記事で詳しく解説しています。

まとめ

本記事では、先進認証と基本認証の概要や、両者の違い、メール送信における認証方式について解説しました。先進認証は、OAuth 2.0を利用したトークンベースの認証方式です。アプリが直接パスワードを扱わず、基本認証と比べて認証情報の漏えいによる不正アクセスのリスクを抑えやすい点が特徴です。

メール送信においては、利用しているサービスやシステムの対応状況、求められるセキュリティレベルを踏まえて、適切な認証方式を選ぶことが重要です。SMTP AUTHの廃止が進められているExchange Onlineを利用している場合は、影響範囲を確認し、先進認証への対応やメールリレーサービスの利用など、適切な対策を検討しましょう。

SPF Softfailとは？ Hardfailとの違いや発生する原因、~allと-allの選び方を解説

菱沼憲司 — Tue, 16 Jun 2026 15:00:00 GMT

SPF認証の結果が「Softfail」となっていて、「問題がある状態なのか」「Hardfail（Fail）とは何が違うのか」と疑問に思ったことはないでしょうか。

SPF Softfailは、SPFレコードで許可されていないIPアドレスからメールが送信された際に返される認証結果の一つです。ただし、Hardfailとは異なり、直ちにメールを拒否すべきであることを意味するものではありません。Softfailは、送信元IPアドレスの登録漏れやメール転送、ドメインのなりすましなど、様々な原因によって発生します。

本記事では、SPF Softfailの意味やHardfailとの違い、発生する主な原因と対処法、SPFレコードの「~all」と「-all」の違いやそれぞれが適したケースについて紹介します。

SPF Softfailとは
SPF Softfailが発生する主な原因と対処法
SPFレコードは「~all」と「-all」どちらを設定すべき？
- 「~all」が適しているケース
- 「-all」が適しているケース
まとめ

SPF Softfailとは

SPF Softfailは、SPF認証結果の一つです。まず、SPF Softfailの意味やSPFレコードの「~all」との関係、Hardfailとの違いについて理解しておきましょう。

SPF Softfailの意味

SPF Softfailは、メールの送信元IPアドレスがSPFレコードで許可されていないものの、ドメイン所有者がそのメールを強く拒否する意思までは示していない状態を意味します。

Softfailとなったメールは、必ずしも受信拒否されるわけではありません。受信サーバーは、DKIMやDMARCの認証結果、送信元IPアドレスやドメインのレピュテーションなども考慮しながら、メールを受信するか、迷惑メールとして扱うかを判断します。

SPF認証結果の確認方法については、以下の記事で詳しく解説しています。

SPFレコードの「~all」との関係

SPF Softfailは、SPFレコードの末尾に「~all」が設定されており、レコードに登録されていない送信元からメールが送信された場合に返されます。

例えば、以下のようなSPFレコードが設定されている場合を考えてみましょう。

v=spf1 ip4:192.0.2.1 ~all

この例では、「192.0.2.1」からのメール送信を許可しています。「all」は、それまでに記載された条件に一致しないすべての送信元を意味し、「~」はそれらの送信元を明確には拒否しないことを表します。

そのため、「192.0.2.1」以外のIPアドレスからメールが送信されると、SPF認証結果はSoftfailとなります。

SPFレコードの書き方については、以下の記事で詳しく解説しています。

Hardfail（Fail）との違い

Hardfail（Fail）は、SPFレコードの末尾に「-all」が設定されている場合に返される認証結果です。Softfailと同様に、SPFレコードで許可されていないIPアドレスからメールが送信された場合に返されますが、ドメイン所有者がそのメールを許可しないことを明確に示している点が異なります。

SoftfailとHardfailの主な違いは、以下の通りです。

項目	Softfail	Hardfail
SPFレコードの末尾	~all	-all
意味	正規の送信元ではない可能性が高いが、強く拒否する意思は示していない	正規の送信元ではなく、許可しないことを明確に示している
表示される認証結果	Softfail	Fail
受信側での扱い	他の認証結果やレピュテーションなども考慮して判断される	より厳しく扱われる可能性がある

ただし、実際にメールを受信するかどうかは受信サーバー側の判断によって決まります。そのため、Hardfailとなったメールが必ず受信拒否されるわけではありません。

SPF Softfailが発生する主な原因と対処法

SPF Softfailが発生する原因は、設定ミスだけではありません。メール転送やドメインのなりすましなどが原因となる場合もあるため、まずは発生要因を正しく把握することが重要です。

本章では、SPF Softfailが発生する主な原因と対処法を解説します。

IPアドレスがSPFレコードに登録されていない

SPF Softfailが発生する原因として多いのが、実際にメールを送信しているIPアドレスがSPFレコードに登録されていないケースです。

例えば、新しいメール配信サービスを導入した場合は、そのサービスが案内するSPFレコード（include設定など）を追加する必要があります。この設定が漏れていると、正規のメールであってもSPF Softfailとなる可能性があります。

まずはメールを送信しているサービスやサーバーを確認し、利用している送信元がすべてSPFレコードに登録されているかを確認しましょう。設定漏れが見つかった場合は、サービス提供事業者の案内に従ってSPFレコードを修正してください。

転送によりIPアドレスが変更されている

メール転送によって、SPF Softfailが発生することもあります。

SPF認証では、メールを送信したサーバーのIPアドレスをもとに認証を行います。しかし、メールが転送されると、転送サーバーのIPアドレスからメールが再送信されるため、元の送信元ドメインのSPFレコードと一致しなくなる場合があります。

その結果、送信元ドメインのSPFレコードに問題がなくても、SPF Softfailとなることがあります。

転送によるSPF認証失敗の可能性を考慮して、DKIMを併用し、DMARCによって認証結果を評価できるようにしておくことが重要です。

DKIMとDMARCについては、以下の記事で詳しく解説しています。

なりすましメールが送信された

SPF Softfailは、第三者が自社ドメインになりすまして、SPFレコードに登録されていないIPアドレスからメールを送信した場合にも発生します。

この場合、SPF Softfailは設定ミスによるものではなく、SPFが正常に機能した結果です。自社が送信した正規のメールでない場合は、SPFレコードを修正する必要はありません。

ただし、Softfailは受信拒否を保証するものではないため、受信サーバーによってはメールが受信される可能性があります。なりすましメールへの対策を強化するためには、DKIMやDMARCもあわせて導入することが推奨されます。

SPFレコードは「~all」と「-all」どちらを設定すべき？

SPFレコードの末尾には、「~all」または「-all」を設定できます。どちらもSPFレコードに登録されていない送信元からメールが送信された場合の扱いを示すものですが、意味や用途が異なります。

ここでは、「~all」と「-all」の違いを整理したうえで、それぞれが適しているケースを解説します。

「~all」が適しているケース

「~all」は、SPFレコードに登録されていない送信元からメールが送信された場合に、SPF認証結果としてSoftfailを返す設定です。「正規の送信元ではない可能性が高いが、明確には拒否しない」という意思を示します。

送信元の洗い出しが完了していない場合や、正規メールの不達リスクを抑えたい場合には、「~all」が利用されることがあります。

送信元の洗い出しが完了していない

様々な部署からメールを送信しており、送信元のメールサービスやメールサーバーを把握しきれていない場合などには、「~all」が適しています。送信元の登録漏れがある状態で「-all」を設定すると、正規メールがFailとなり、受信側の判断によっては届かなくなる可能性があります。

送信環境の追加・変更が多い

メール配信サービスやMAツール、CRMなどの追加・変更が頻繁に発生する場合は、SPFレコードの管理が複雑になりがちです。送信元を把握できていても、設定変更時のSPFレコードの更新漏れによって認証に失敗するリスクを考慮して、「~all」で運用するケースがあります。

メールの転送が多い

前述したように、SPFはメール転送によって認証に失敗することがあります。転送が多い送信環境では、正規メールが意図せず迷惑メール扱いや受信拒否されるリスクを軽減するため、「~all」を選択する場合もあります。ただし、認証結果がSoftfailであっても、メールを最終的にどう扱うかの判断は受信側に依存するため、根本的な解決策にはならない点に注意が必要です。

メール不達の影響が大きい

ECサイトの注文確認メールや会員登録メール、パスワード再設定メールなど、メールが届かないことによる影響が大きい場合は、「~all」が適していることがあります。セキュリティと到達率のバランスを考慮しながら、自社の運用方針に合わせて設定を選択しましょう。

「-all」が適しているケース

「-all」は、SPFレコードに登録されていない送信元からメールが送信された場合に、SPF認証結果としてFailを返す設定です。SPFレコードに登録されていない送信元を許可しないことを明確に示します。

送信元を適切に管理できており、なりすまし対策をより強化したい場合は、「-all」の利用を検討するとよいでしょう。

すべての送信元を把握できている

利用しているメール配信サービスやメールサーバーを把握できており、SPFレコードへ適切に反映できている場合は、「-all」が適しています。

なりすまし対策の強化が求められる

SPFによるなりすまし対策をより強化したい場合は、「-all」が適しています。SPFレコードに登録されていない送信元からのメールを許可しないという意思を明確に示すことができます。

まとめ

本記事では、SPF Softfailの意味やHardfail（Fail）との違い、発生する主な原因と対処法、「~all」と「-all」の違いや適したケースについて解説しました。

SPF Softfailは、設定ミスだけでなく、メール転送やドメインのなりすましによって発生する場合もあります。原因を正しく把握したうえで、適切に対処することが重要です。

また、SPF認証に失敗したメールを最終的にどう扱うかの判断は受信側サーバーに依存するため、SPFだけではなりすましメールを完全に防ぐことはできません。DKIMやDMARCもあわせて導入し、適切に運用する必要があります。

ただし、SPFやDKIMの認証は受信側で行われるため、送信者自身が設定不備や認証失敗を把握するには、受信メールのヘッダ確認などが必要になり、対応に手間と時間がかかります。

ベアメールの「迷惑メールスコアリング」では、テストメールを送信するだけで、SPF・DKIM・DMARCの設定状況や認証結果を確認できます。問題のある送信元を把握し、送信環境を整えることが可能です。送信ドメイン認証の設定に不安がある場合は、ぜひご活用ください。

ハードバウンスとは？原因・対処法とソフトバウンスとの違いを解説

菱沼憲司 — Mon, 01 Jun 2026 15:00:00 GMT

メール配信サービスのレポートで「Hard Bounce」と表示されたものの、「何が原因なのかわからない」「どう対処すればよいか知りたい」とお困りではありませんか。

ハードバウンスを放置していると、該当のメールが届かないだけでなく、送信元の信頼性が低下し、正常なメールまで届きにくくなるおそれがあります。そのため、原因を特定して適切に対処することが重要です。

本記事では、ハードバウンスの意味やソフトバウンスとの違い、主な原因と対処法、発生を防ぐためのポイントをわかりやすく解説します。

ハードバウンスとは
- ハードバウンスの意味
- ソフトバウンスとの違い
ハードバウンスが発生する主な原因
ハードバウンスが発生した場合の対処法
ハードバウンスの発生を防ぐためのポイント
まとめ

ハードバウンスとは

まず、ハードバウンスの意味とソフトバウンスとの違いについて理解しておきましょう。

ハードバウンスの意味

ハードバウンスは、メール送信時に恒久的なエラーが発生し、宛先に送信できない状態を意味します。

例えば、存在しないメールアドレスへ送信した場合や、送信ドメイン認証の不備により受信側でメールが拒否された場合などに発生します。基本的に、ハードバウンスは時間を置いて再送しても解決しないため、原因を特定して対処する必要があります。

メール送信時にエラーが発生すると、エラーの原因を示すエラーコードやエラーメッセージが記載されたバウンスメールが返されます。一般的に、エラーコードのうち5から始まるもの（5xx）は恒久的なエラーを表します。例えば、「550 5.1.1 User unknown」は宛先メールアドレスが存在しないことを示す代表的なエラーです。

多くのメール配信サービスでは、こうした恒久的なエラーをまとめて「Hard Bounce」と表示しています。

エラーコードの意味については、以下の記事で詳しく解説しています。
メールのエラーコード一覧｜意味・原因・対処法をわかりやすく解説｜ベアメールブログ

ソフトバウンスとの違い

ソフトバウンスは、一時的な原因によってメールを配信できない状態を示します。ハードバウンスが恒久的なエラーであるのに対し、ソフトバウンスは時間を置いて再送することで解消される可能性があります。

ソフトバウンスが発生する原因としては、受信者のメールボックス容量超過やサーバー障害などが挙げられます。このようなケースでは、原因が解消されれば、正常にメールを配信できるようになります。

一般的に、4から始まるエラーコード（4xx）は一時的なエラーを表し、多くのメール配信サービスでは「Soft Bounce」と表示されます。

ハードバウンスとソフトバウンスの主な違いは、以下の通りです。

項目	ハードバウンス	ソフトバウンス
エラーの種類	恒久的なエラー	一時的なエラー
主な原因	無効なメールアドレス、送信ドメイン認証の不備、スパム判定による受信拒否など	メールボックス容量超過、サーバー障害など
再送による効果	期待できない	解消される可能性がある
主なエラーコード	5xx	4xx

ハードバウンスが発生する主な原因

ハードバウンスは、無効なメールアドレスへの送信や、送信ドメイン認証の不備、ブラックリスト登録、スパム判定など、様々な要因によって発生します。バウンスメールに記載されているエラーメッセージは、エラーの原因を特定するための重要な手がかりとなります。

ここでは、ハードバウンスが発生する主な原因を5つ紹介します。

エラーメッセージについては、以下の記事で詳しく解説しています。
【エラーメッセージ別】メールエラーの原因と対策｜ベアメールブログ

宛先メールアドレスが無効である

ハードバウンスが発生する原因の中でも特に多いのが、宛先のメールアドレスが無効であることです。例えば、メールアドレスの入力ミスや、削除されたメールアドレスへの送信などが考えられます。こうした場合、受信サーバーは宛先が存在しないと判断し、メールを拒否します。

エラーメッセージの例

User unknown（ユーザが存在しない）
No such user here（該当するユーザが存在しない）
User does not exist（ユーザが存在しない）
Recipient not found（宛先が見つからない）

送信ドメイン認証に問題がある

送信ドメイン認証に問題がある場合、受信側でメールが正当な送信者から送られたものであることを確認できず、ハードバウンスが発生することがあります。

送信ドメイン認証は、メールが正規の送信元から送られていることや、内容が改ざんされていないことを確認するための仕組みです。代表的なものとして、SPF・DKIM・DMARCがあります。

SPF：メールが許可されたIPアドレスから送信されているかを確認することで、送信元の正当性を検証する仕組み
DKIM：メールに電子署名を付与し、改ざんされていないことを検証する仕組み
DMARC：SPFやDKIMの認証結果を基に、それぞれの認証で使用されるドメインがヘッダFromのドメインと一致しているか（アライメント）を確認し、なりすましを防ぐ仕組み

特に、DMARCポリシーが厳しく設定されている受信環境では、認証に失敗したメールが拒否されるケースがあります。

エラーメッセージの例

SPF Check Failed（SPF認証に失敗した）
This message was blocked because it didn’t pass DKIM authentication（DKIM認証に失敗したため、メッセージが拒否された）
This message was blocked because the sending domain doesn’t have a DMARC record or the DMARC record doesn’t specify a DMARC policy（送信ドメインにDMARCレコードの設定がされていないか、DMARCポリシーが設定されていないため、メッセージが拒否された）
Access denied, sending domain does not pass DMARC verification（送信ドメインのDMARC認証に失敗したため、アクセスが拒否された）

SPF・DKIM・DMARC認証が失敗する原因については、以下の記事で詳しく解説しています。
SPF failの原因と解決法｜認証失敗の仕組みとケース別対策｜ベアメールブログ
 DKIM認証が失敗する原因は？認証結果の見方とDKIM fail時の確認ポイントを解説｜ベアメールブログ
 DMARC認証が失敗する原因は？ DMARC failの修正方法を解説｜ベアメールブログ

ブラックリストに登録されている

メールの送信元IPアドレスやドメインがブラックリストに登録されている場合、受信サーバーによってメールが拒否され、ハードバウンスが発生することがあります。ブラックリストには、スパムメールの送信元として報告されたIPアドレスやドメインなどが登録されており、受信側はこれらの情報を、メールの受信可否を判断する際の一つの材料として利用しています。

エラーメッセージの例

Your IP is listed in Spamhaus …（IPアドレスがSpamhausのブラックリストに登録されている）
Mail from IP [x.x.x.x] was rejected due to listing in Spamhaus …（IPアドレスがSpamhausのブラックリストに登録されているため、メールが拒否された）
Service unavailable; Client host [x.x.x.x] blocked using bl.spamcop.net（送信元ホストがSPAMCOPのブラックリストに登録されているため、送信できない）

スパムと判定され受信拒否されている

メールがスパムと判断された場合、受信サーバーによってメールが拒否され、ハードバウンスが発生することがあります。スパム判定の要因としては、短縮URLの使用や、過度に不安や緊張を煽る表現、不自然な日本語、多数のURLの記載などが挙げられます。また、画像のみで構成されたメールや不審な添付ファイルも、スパム判定の原因となる可能性があります。

エラーメッセージの例

This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked（迷惑メールの可能性があるため、メッセージがブロックされた）
This message was blocked because its content presents a potential security issue（コンテンツにセキュリティ上の問題が潜んでいる可能性があるため、メッセージがブロックされた）

受信側のポリシーや設定により拒否されている

メールサービス事業者では、独自のセキュリティポリシーにもとづいてメールの受信可否を判断しています。そのため、送信ドメイン認証やブラックリスト、スパム判定に問題がなくても、受信側のポリシーに抵触した場合はメールが拒否され、ハードバウンスが発生することがあります。

また、受信者側で特定のIPアドレスやドメインからのメールを受信拒否する設定などが行われている場合にも、ハードバウンスが返されるケースがあります。

エラーメッセージの例

Message rejected due to local policy（受信側のローカルポリシーにより、メッセージが拒否された）
Access denied, banned sender（送信者が受信拒否リストに登録されている）
Message not allowed – Email not accepted for policy reasons（ポリシー上の理由により、メールが受け付けられなかった）

ハードバウンスが発生した場合の対処法

ハードバウンスが発生した場合は、原因に応じて適切に対処することが重要です。エラーを放置して送信を続けると、送信元の信頼性が低下し、問題のないメールも届きにくくなるおそれがあります。本章では、ハードバウンスが発生した場合の対処法を解説します。

原因	対処法
宛先メールアドレスが無効	宛先メールアドレスの有効性を確認、無効なアドレスを削除
送信ドメイン認証の不備	送信ドメイン認証の設定を見直し
ブラックリスト登録	ブラックリスト登録状況を確認、解除申請
スパム判定による受信拒否	メールの内容・配信方法を見直し
受信者側の設定による拒否	受信者に設定の確認と受信許可リストへの追加を依頼

宛先メールアドレスが有効か確認する

まず、宛先メールアドレスが有効か確認してください。メールアドレスの入力ミスや、削除されたメールアドレスへの送信が原因となっている可能性があります。該当するメールアドレスへの送信を停止し、必要に応じて登録情報を修正しましょう。

メールアドレスの有効性を確認する方法については、以下の記事で詳しく解説しています。
【メールアドレスの存在確認方法】安全に検証できるおすすめツールも紹介｜ベアメールブログ

送信ドメイン認証の設定を見直す

送信ドメイン認証は、一度設定したら終わりではありません。メール配信サービスの追加やサーバー移行、DNS設定の変更などを行った際に、認証に必要な設定が正しく引き継がれず、認証エラーが発生することがあります。

オンラインツールやコマンドラインを使うと、SPF・DKIM・DMARCの設定内容や認証結果をチェックできます。定期的に設定を見直し、正しく認証できているか確認しましょう。

SPF・DKIM・DMARCの設定を確認する方法については、以下の記事で詳しく解説しています。
SPFの確認方法は？設定の確認手順や認証結果の見方、失敗する原因を解説｜ベアメールブログ
 DKIMの確認方法は？設定の確認手順や認証結果の見方、失敗する原因を解説｜ベアメールブログ
 おすすめのDMARCチェッカーは？ DMARCの設定をチェックできるサイトと確認ポイントを紹介｜ベアメールブログ

ブラックリスト登録状況を確認する

ブラックリストの登録状況は、Spamhausなどのブラックリスト登録確認サイトを利用して確認できます。登録されていた場合は、スパム判定の原因となったメール内容や配信方法を見直したうえで、各ブラックリスト事業者の案内に従って解除申請を行う必要があります。

ブラックリスト登録の確認・解除方法については、以下の記事で詳しく解説しています。
ブラックリスト登録されたメールの確認・解除方法について｜ベアメールブログ

メールの内容や配信方法を見直す

メールがスパムと判定されている場合は、内容や配信方法の見直しが必要です。mail-testerなどのツールを使うと、送信ドメイン認証の設定状況やブラックリスト登録状況、メールのフォーマットなどの観点から、スパム判定につながる問題がないかを確認できます。

また、短時間での大量送信や、長期間利用していない配信リストへの一斉送信は、不審な送信と判断されることがあるため、配信方法にも注意が必要です。

迷惑メール判定の原因や確認方法については、以下の記事で詳しく解説しています。
迷惑メール判定サイト・ツール紹介｜自社メールが迷惑メールになる原因と確認方法も解説｜ベアメールブログ

受信側に設定の確認を依頼する

特定の宛先のみでハードバウンスが発生している場合は、受信者側の設定によってメールが拒否されている可能性があります。必要に応じて、自社のIPアドレスやドメインを受信許可リストに追加してもらうなどの対応を依頼しましょう。

ハードバウンスの発生を防ぐためのポイント

ハードバウンスは、発生後に対処するだけでなく、日頃から発生を防ぐための対策を行うことも重要です。無効なメールアドレスへの送信やスパム判定を防ぐことで、送信元の信頼性低下や到達率悪化のリスクを抑えることができます。

ここでは、ハードバウンスの発生を防ぐために押さえておきたいポイントを紹介します。

配信リストのクリーニングを行う

配信リストのクリーニングは、ハードバウンスを防ぐうえで重要な対策の一つです。無効なメールアドレスに対して送信を続けると、バウンス率が上昇し、送信元IPアドレスやドメインの信頼性低下につながるおそれがあります。

定期的に配信リストを見直し、ハードバウンスが発生したアドレスや、長期間反応のないアドレスは削除するようにしましょう。

リストクリーニングの方法については、以下の記事で詳しく解説しています。
メールのリストクリーニングとは？具体的な実施方法、宛先リストの品質を保つポイントを解説｜ベアメールブログ

ダブルオプトインを実装する

会員登録などの際に、ユーザが間違ったメールアドレスを入力してしまうことを防ぐためには、「ダブルオプトイン」の仕組みを取り入れることも有効です。

ダブルオプトインとは、メールアドレスを入力して仮登録をした後、そのアドレスに確認メールが送信され、メール内の登録用URLからアクセスすることで登録が正式に完了する方式です。メールアドレスの有効性を事前に確認できるため、宛先の間違いを防ぐ効果が期待できます。

配信前にスパム判定リスクを確認する

スパム判定によるハードバウンスの発生を防ぐためには、送信前に迷惑メール判定のリスクを確認することが重要です。

しかし、迷惑メール判定にはメール本文の問題や送信ドメイン認証の不備、ブラックリスト登録など様々な要素が関係するため、リスクを網羅的に把握することは容易ではありません。

ベアメールの「迷惑メールスコアリング」では、テストメールを送信するだけで、迷惑メール判定につながる問題がないかを多角的に診断できます。

本文診断
メール本文の文脈や使用されている単語を分析し、迷惑メールと判定される可能性を診断します
送信ドメイン認証診断
SPF・DKIM・DMARCの認証結果を確認できます
SPAMエンジン診断
ブラックリスト登録状況やメールフォーマット、DNS設定などを確認できます
キャリア到達度診断
国内外の主要キャリアごとの到達度を確認できます

診断結果はスコアとして可視化されるため、現在の状況を直感的に把握できます。また、検出された問題に対する改善アドバイスも確認できるため、迷惑メール判定やメール不達のリスク低減に役立ちます。

無料トライアルもご用意していますので、ぜひお気軽にご相談ください。
ベアメール迷惑メールスコアリング｜無料トライアルはこちら

まとめ

本記事では、ハードバウンスの意味やソフトバウンスとの違い、主な原因と対処法、発生を防ぐためのポイントについて解説しました。

ハードバウンスの原因は、無効なメールアドレスへの送信だけでなく、送信ドメイン認証の不備、ブラックリスト登録、スパム判定など多岐にわたります。ハードバウンスが発生した場合は、バウンスメールのエラーメッセージを確認し、原因に応じて適切に対処することが重要です。また、配信リストの管理や送信ドメイン認証設定の定期的な見直しなど、日頃から配信環境を整備しておくことも、ハードバウンスの抑制につながります。

ベアメールの「迷惑メールスコアリング」では、送信ドメイン認証の認証結果やブラックリストの登録状況、メール本文の問題点などを確認できます。「メールが届かない」「不達の原因がわからない」とお悩みの方は、ぜひご活用ください。

ベアメール｜迷惑メールスコアリングの詳細はこちら

550 5.7.1エラーが発生する原因は？エラーメッセージ別の意味と対策を解説

菱沼憲司 — Mon, 01 Jun 2026 15:00:00 GMT

メール送信の際に「550 5.7.1」エラーが発生し、相手に届かず困った経験はないでしょうか。

550 5.7.1は、メール送信時に認証やポリシー上の理由で送信が拒否されたことを示すエラーです。放置すると不達が続く可能性があるため、適切な対処が求められます。

550 5.7.1エラーの原因は、SPF・DKIM・DMARCなどの送信ドメイン認証の不備や、送信元IPアドレスの評価低下、スパム判定、受信側ポリシーへの抵触など、多岐にわたります。原因を特定するには、エラーコードだけでなく、エラーメッセージの内容もあわせて確認することが重要です。

本記事では、550 5.7.1エラーの意味や主な原因、エラーメッセージごとの確認ポイント、再発防止のための対策について、わかりやすく解説します。

550 5.7.1エラーとは
- エラーコード「550」の意味
- 拡張ステータスコード「5.7.1」の意味
550 5.7.1エラーが発生する主な原因
【エラーメッセージ別】550 5.7.1エラーの意味
Gmailでよく見られる550 5.7.1エラーメッセージ
550 5.7.1エラーの発生を防ぐための対策
まとめ

550 5.7.1エラーとは

550 5.7.1は、メール送信時に返されるSMTPエラーコードで、3桁のエラーコード「550」と拡張ステータスコード「5.7.1」で構成されています。まずは、それぞれのコードの意味について解説します。

エラーコード「550」の意味

エラーコードは、3桁の数字で構成されており、それぞれの数字に意味があります。1桁目は、処理結果の大まかな状態を示します。

エラーコード	処理結果	意味
4xx	一時的なエラー	一時的な問題により、処理に失敗した
5xx	永続的なエラー	永続的な問題により、処理に失敗した

「5xx」は、永続的な問題によりメール送信処理に失敗したことを示します。一時的な問題を表す「4xx」とは異なり、時間をおいて再送しても解決しないため、原因を確認したうえで適切に対処する必要があります。

「550」は、宛先アドレスの不備や受信側ポリシーによる拒否、スパム判定など、様々な理由で返されます。原因を特定するには、後述する拡張ステータスコードやエラーメッセージを確認する必要があります。

エラーコードの仕組みについては、以下の記事で詳しく解説しています。
メールのエラーコード一覧｜意味・原因・対処法をわかりやすく解説｜ベアメールブログ

拡張ステータスコード「5.7.1」の意味

拡張ステータスコードは、3桁のエラーコードだけではわからないエラーの詳細な理由を示すためのコードです。

「5.7.1」は、認証やセキュリティポリシーに関連する問題によって、メールが拒否されたことを意味します。例えば、SPF・DKIM・DMARC認証の失敗や、送信元IPアドレスの評価低下、スパム判定、受信側ポリシーへの抵触などが原因として考えられます。

550 5.7.1エラーが発生する主な原因

550 5.7.1エラーが発生した場合、原因に応じて確認すべきポイントや対処法が異なります。まずは代表的な原因を見ていきましょう。

SPF・DKIM・DMARC認証に問題がある

送信ドメイン認証に失敗した場合や、設定に不備がある場合、550 5.7.1エラーが返されることがあります。

SPF：メールが許可されたIPアドレスから送信されているかを確認することで、送信元の正当性を検証する仕組み
DKIM：メールに電子署名を付与し、改ざんされていないことを検証する仕組み
DMARC：SPFやDKIMの認証結果を基に、それぞれの認証で使用されるドメインがヘッダFromのドメインと一致しているか（アライメント）を確認し、なりすましを防ぐ仕組み

DNSレコードの設定ミスなどがあると認証に失敗し、メールが拒否されることがあります。また、SPFやDKIMが認証に成功していても、DMARCのアライメント要件を満たしていない場合はDMARC認証に失敗します。特にDMARCポリシーを「quarantine」や「reject」に設定している環境では、メールが拒否されて550 5.7.1エラーが返されることがあります。

送信元IPアドレスやドメインの評価が低い

受信側のメールサービス事業者は、送信元IPアドレスやドメインの信頼性（レピュテーション）を評価し、メールを受信するかどうかの判断に利用しています。この評価が低い場合、550 5.7.1エラーによってメールが拒否されることがあります。

レピュテーションには、過去の送信実績や、苦情率（迷惑メール報告率）、バウンス率、ブラックリスト登録の有無などが影響します。例えば、存在しないメールアドレスへの継続的な送信はバウンス率の上昇につながり、送信元の評価を低下させる要因となります。

レピュテーション向上のポイントについては、以下の記事で詳しく解説しています。
IPレピュテーションとドメインレピュテーションとは？レピュテーション向上のポイントを解説｜ベアメールブログ

メールの内容がスパムと判定された

メールの内容がスパムメールと類似していると判断された場合、メールが拒否され、550 5.7.1エラーが返されることがあります。

具体的には、短縮URLの使用や、過度に不安や緊急性を煽る表現、不自然な日本語、多数のURLの記載などが挙げられます。また、画像のみで構成されたメールや不審な添付ファイルも、迷惑メールと判定される原因となる可能性があります。

受信側ポリシーに抵触している

受信側のメールサービス事業者では、不審なメールの受信を防ぐため、送信元やメールの内容、添付ファイルなどに関する独自のルール（ポリシー）を設けています。これらのポリシーに抵触した場合、550 5.7.1エラーが返され、メールが拒否されることがあります。

また、事業者のポリシーとは別に、受信者側で特定のIPアドレスやドメインからのメールを拒否する設定や、添付ファイルの種類を制限する設定がされている場合にも、550 5.7.1エラーが発生する可能性があります。

【エラーメッセージ別】550 5.7.1エラーの意味

50 5.7.1エラーの原因を特定するためには、エラーコードだけでなく、あわせて表示されるエラーメッセージを確認することが重要です。エラーメッセージは、メールが拒否された具体的な理由を知る手がかりとなります。

ここでは、代表的なエラーメッセージとその意味を紹介します。

エラーメッセージ	意味	主な原因
Recipient address rejected: Access denied	受信側サーバーがメールの受信を拒否した	受信側ポリシーへの抵触、低いレピュテーション、送信ドメイン認証の不備など
Message rejected as spam	スパムメールと判定された	スパムに類似したメール内容、低いレピュテーション
Authentication required	認証が必要なため送信できない	SMTP認証の未実施、認証情報の誤り、設定不備
Unauthorized sender	送信者として許可されていない	送信権限設定の不備、送信ドメイン認証の不備
Client host rejected	送信元サーバーからの接続が拒否された	低いレピュテーション、ブラックリスト登録
Relay access denied	SMTPリレーが許可されていない	SMTP認証の未実施、リレー設定の不備

Recipient address rejected: Access denied

受信側サーバーがメールの受信を拒否したことを示します。受信側のポリシーによって、送信元IPアドレスやドメインからのメールが制限されている場合などに返されることがあります。また、送信元IPアドレスやドメインのレピュテーション低下や、送信ドメイン認証の不備が原因となるケースもあります。

Message rejected as spam

受信側のメールサーバーやメールサービス事業者によって、スパムメールと判定されたことを示します。短縮URLの使用や過度な煽り表現、不自然な日本語などにより、メール内容がスパムと類似していると判断された場合に返されることがあります。また、送信元IPアドレスやドメインのレピュテーション低下が影響しているケースもあります。

Authentication required

SMTP認証が必要なため、メールを送信できないことを示します。SMTP認証を行わずにメールを送信しようとした場合や、ユーザ名・パスワードの誤りにより認証に失敗した場合などに返されます。

Unauthorized sender

送信元メールアドレスやドメインが、送信を許可されていないことを示します。SMTPサーバーで許可されていない送信元メールアドレスを使用している場合や、送信ドメイン認証に問題がある場合などに返されることがあります。

Client host rejected

送信元サーバーからの接続が、受信側サーバーによって拒否されたことを示します。送信元IPアドレスやドメインがブラックリストに登録されている場合や、レピュテーションが低下している場合などに返されることがあります。また、逆引きDNS（PTRレコード）の設定不備が原因となるケースもあります。

PTRレコードの書き方や確認方法については、以下の記事で詳しく解説しています。
PTRレコードは何のために設定するの？ DNSの逆引きとメール送信の関係について｜ベアメールブログ

Relay access denied

SMTPサーバーによるメールの中継（リレー）が許可されていないことを示します。SMTP認証を行わずに送信しようとした場合や、送信元IPアドレスがリレー許可の対象外となっている場合などに返されることがあります。

Gmailでよく見られる550 5.7.1エラーメッセージ

550 5.7.1はRFCで定義されている共通のエラーコードですが、実際に表示されるエラーメッセージやメールが拒否される条件は、メールサービス事業者によって異なります。

Gmailでは、認証やレピュテーション、スパム判定などの原因に応じて、独自のエラーメッセージが返されます。ここでは、代表的なエラーメッセージとその意味、主な原因を紹介します。

エラーメッセージ	説明	主な原因
The user or domain that you are sending to (or from) has a policy that prohibits the email that you sent.	送信先（または送信元）のユーザまたはドメインが使用しているポリシーによりメールを送信することができません。	受信側ポリシーへの抵触（送信元IPアドレス・ドメインの受信制限など）
This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.	このメールは迷惑メールの可能性があります。Gmail に送信される迷惑メールの数を減らすため、このメールはブロックされています。	スパム判定、送信元IPアドレス・ドメインのレピュテーション低下
This message does not meet IPv6 sending guidelines regarding PTR records and authentication.	送信元 IP が、ポインタ（PTR）レコードで指定されたホスト名の IP アドレスと一致しません。	IPv6環境における PTRレコードや送信ドメイン認証の設定不備
This message is likely suspicious due to the very low reputation of the sending IP address. To best protect our users from spam, the message has been blocked.	送信元IPアドレスの信用評価が非常に低いため、これは不審なメッセージと思われます。迷惑メールからユーザを保護するため、このメッセージはブロックされました。	送信元IPアドレスのレピュテーション低下
This message is likely suspicious due to the very low reputation of the sending domain. To best protect our users from spam, the message has been blocked.	送信元ドメインの信用評価が非常に低いため、これは不審なメッセージと思われます。迷惑メールからユーザを保護するため、このメッセージはブロックされました。	送信元ドメインのレピュテーション低下

参考：Google Workspace「GmailのSMTPに関するエラーとコード」https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes?hl=ja&visit_id=639101722723304513-1828388966&rd=1（2026/5/25確認）

550 5.7.1エラーの発生を防ぐための対策

安定したメール配信を行うためには、エラーが発生してから対処するのではなく、日頃から送信環境を適切に管理することが重要です。ここでは、550 5.7.1エラーの発生を防ぐために、送信者が実施しておきたい主な対策を紹介します。

SPF・DKIM・DMARCを適切に設定する

IPアドレス・ドメインの評価を維持する

送信元IPアドレスやドメインのレピュテーションが低下すると、受信側サーバーでメールが拒否され、550 5.7.1エラーが返されることがあります。

レピュテーションを維持するためには、配信リストを定期的にクリーニングし、存在しないメールアドレスへの送信を避けてバウンス率を抑えることが重要です。また、配信停止の方法をわかりやすく案内し、配信停止希望者への送信を速やかに停止することで、迷惑メール報告による苦情率の上昇を防ぐことができます。

新しいIPアドレスやドメインからメールを送信する場合は、一度に大量配信を行わず、少しずつ配信量を増やしていく「ウォームアップ」を実施しましょう。

リストクリーニングとIPウォームアップの方法については、以下の記事で詳しく解説しています。
メールのリストクリーニングとは？具体的な実施方法、宛先リストの品質を保つポイントを解説｜ベアメールブログ
 IPウォームアップとは？ IPレピュテーションを向上させるためのポイントと具体的な手順｜ベアメールブログ

送信前に迷惑メール判定リスクを確認する

メール本文の内容やDNS設定などに問題があると、迷惑メールと判定され、550 5.7.1エラーが返されることがあります。そのため、送信前に迷惑メール判定のリスクを確認することが重要です。

本文診断
メール本文の文脈や使用されている単語を分析し、迷惑メールと判定される可能性を診断できます
送信ドメイン認証診断
SPF・DKIM・DMARCの認証結果を確認できます
SPAMエンジン診断
ブラックリスト登録状況やメールフォーマット、DNS設定などを確認できます
キャリア到達度診断
国内外の主要キャリアごとの到達度を確認できます

無料トライアルもご用意していますので、ぜひお気軽にご相談ください。
ベアメール迷惑メールスコアリング｜無料トライアルはこちら

まとめ

本記事では、550 5.7.1エラーの意味や主な原因、エラーメッセージごとの確認ポイント、発生を防ぐための対策について解説しました。

550 5.7.1エラーは、送信ドメイン認証の不備やレピュテーションの低下、スパム判定、受信側ポリシーへの抵触など、様々な要因によって発生します。エラーを防ぐためには、送信環境を整備するとともに、送信前に迷惑メール判定のリスクを確認することが重要です。

日頃から適切な運用を心掛け、安定したメール配信を実現しましょう。

メールマーケティングの始め方完全ガイド｜失敗しない手順と運用の注意点

菱沼憲司 — Wed, 27 May 2026 15:00:00 GMT

メールマーケティングは、SNS全盛期の現代において古い手法と思われがちです。しかし、SNSのアルゴリズム変更や仕様変更に左右されにくいため、直接顧客へアプローチして信頼関係を築ける手法として再評価されています。

本記事では、メールマーケティングの基礎知識やメルマガとの違い、具体的な実施手順、失敗しないツールの選び方から、効果測定の指標の具体的な目安数値までを網羅して解説します。

メールマーケティングとは？
- メルマガとの違い
- 【SNS全盛の今、なぜ有効？】メールマーケティングが重要視される背景
メールマーケティングを始める5つのメリット
始める前に押さえておくべき4つの注意点
メールマーケティングの主な種類5つ
メールマーケティングを実施する5ステップ
メールマーケティングに役立つツールの選び方
- 手作業による運用とツール検討の分岐点
- 失敗しないツールの選び方5つのポイント
メールマーケティングに関するよくある質問
メールマーケティングの効果を高めるセキュリティ規格
まとめ

メールマーケティングとは？

メールマーケティングとは、電子メールを活用して顧客との関係を深め、購買や問い合わせなどの行動を促す取り組み全般を指します。登録者全体へ一斉に同じ内容を送るメルマガとは異なり、顧客の興味や関心に合わせて適切な情報を届けることで、中長期的な信頼関係を築ける点が特徴です。

SNSのようなプラットフォームの仕様変更やアカウント凍結による影響を受けにくく、蓄積した顧客データを自社の資産として活用しながら接点を維持しやすい施策として再評価されています。

メルマガとの違い

メールマーケティングとメルマガは混同されやすい言葉ですが、その本質には明確な違いが存在します。両者の違いは、位置づけ、配信対象と内容、目的、運用の特徴という4つの観点で整理できます。

観点	メルマガ	メールマーケティング
位置づけ	メールマーケティングの一手法	メールを活用した顧客育成・行動促進の取り組み全般
配信対象・内容	登録者に定期的な情報を届ける一斉配信型が中心	属性・行動履歴・検討フェーズに応じて配信内容を設計
目的	認知拡大、情報提供、関係維持	購買、問い合わせ、資料請求などの行動促進
運用	定期配信を中心に改善する	配信対象・内容・タイミング・成果指標を設計し、継続的に改善する

位置づけ：メルマガはメールマーケティングという全体構造の中に含まれる一つの手法に位置づけられます。
配信対象と内容：メルマガが登録者に対して定期的に情報を届ける一斉配信型の手法として用いられることが多いのに対し、メールマーケティングは顧客の属性や過去の行動履歴に応じて個別に最適化した内容を配信します。
目的：メルマガが定期的な情報提供による認知や関係の維持を主目的とするのに対し、メールマーケティングは購買意欲を段階的に喚起し、商品の購入や資料請求といった具体的な成果へ繋げることを目的とします。
運用の特徴：メルマガが定期配信の維持とコンテンツの改善を中心に運用されるのに対し、メールマーケティングは配信の目的や個々の顧客状態に応じて、対象や内容、タイミング、および成果指標を設計し、継続的な改善を行います。

【SNS全盛の今、なぜ有効？】メールマーケティングが重要視される背景

SNS全盛の今、なぜメールマーケティングが重要視されているのか、その背景には大きく4つの理由があります。

メールはビジネスにおける主要な連絡インフラ

SNSが台頭した現在も、メールは全世代に深く根付いたインフラです。特にビジネスシーンの社外コミュニケーションにおいては未だにメールが主流であり、時間を選ばずに情報を届けられる強みを持っています。

非対面で顧客育成しやすい

現代の顧客は、営業担当者と接触する前にネットで自ら情報を集めて比較検討します。そのため、対面での売り込みではなく、顧客の検討フェーズに合わせて有益な情報を提供し、中長期的に購買意欲を高めていく顧客育成の手段として有効です。

MAツールの進化により高度な運用が可能

MAツールの発展により、顧客一人ひとりの行動履歴に合わせた最適化や正確な効果測定が容易になりました。それによりデータに基づく確実なPDCAサイクルを回せるようになったことが、再評価される理由のひとつです。

プラットフォーム変更の影響を受けにくい

SNSマーケティングは、アカウント凍結やプラットフォームの閉鎖、あるいはアルゴリズムの変動によって、フォロワーとの繋がりが失われるリスクを抱えています。一方で、メールマーケティングの土台となる顧客のメールアドレスは、自社のデータベースに直接蓄積・保管できます。もちろんメールにおいても、メールプロバイダによる迷惑メール判定基準の変更による不達リスクは存在します。しかし、SNSのように、これまで集めた顧客リストを失うリスクは低くなります。

メールマーケティングを始める5つのメリット

メールを活用したマーケティング施策は、限られた予算とリソースの中で最大の成果を引き出したい場合、心強い施策となるでしょう。この章では、メールマーケティングにおける5つのメリットを解説します。

低コストで始められ、費用対効果が高い

メールマーケティングの利点は、コストパフォーマンスの高さにあります。紙のダイレクトメールのような印刷代や郵送費、あるいは高額なWeb広告費は発生せず、基本的には配信システムなどのランニングコストのみで実施できるため、低予算で実施できます。さらに、自社が保有しているハウスリストを活用するため、他の施策に比べて投資対効果が非常に高くなりやすい施策です。

効果測定が容易で、データに基づいた改善がしやすい

実施した施策の反響を、詳細なデータとして可視化できる点も大きなメリットです。テレビCMや看板広告、あるいは従来の営業活動とは異なり、到達率・開封率・クリック率をシステム上で正確に把握できます。結果が数値として表れるため、課題の特定が容易になり、データに基づいたPDCAサイクルを回すことで施策の精度を継続的に高められるため、成果を生み出しやすくなります。

顧客の検討フェーズに合わせたアプローチが可能

メールマーケティングでは顧客の属性や興味関心、過去のWeb行動履歴に合わせて「誰に・何を・いつ送るか」を柔軟にコントロールできます。顧客の検討フェーズに合わせた最適なコミュニケーションをとることで、機会損失を防ぎ、効率的に顧客育成を促すことができます。

顧客との信頼関係を継続して築ける

メールマーケティングは顧客と中長期的に接点を持ち続けることができます。有益な情報やノウハウを定期的に届け続けることで、顧客に特定の課題が生じた際、自社を想起してもらう関係性を構築できます。潜在顧客との繋がりを維持し、信頼関係を自社主導で深めていける点は、この施策の強みと言えるでしょう。

自社が望むタイミングで、顧客へ能動的に届けられる

WebサイトやSEO、SNSなどの施策は、顧客が自ら検索を行ったり、タイムラインを閲覧したりするまで情報を届けられないプル型の側面が強い手法です。そのため、企業側が告知したいタイミングと、顧客が情報を目にするタイミングを一致させることが困難です。

一方、メールマーケティングは、企業側の設定したタイミングで顧客のメールアドレス宛に情報を届けられるプッシュ型の施策です。送られてきたメールを読むかどうかは顧客の判断に委ねられますが、検索やSNSのように顧客の行動を待つのではなく、企業側から接触の機会を創出できる点が特徴です。

始める前に押さえておくべき4つの注意点

メールマーケティングを実施するにあたっては、事前に理解しておくべき4つの注意点があります。これらは回避できないデメリットではなく、適切な対策を講じることでクリアできる課題です。

配信リストの確保と管理

メールマーケティングを継続するには、新たな送付先を増やす「確保」と、登録された情報を定期的に見直す「管理」の双方が求められます。

新規獲得のアクションが滞ると、アプローチできる対象が広がらず施策の成果が頭打ちになります。一方で、変更や廃止によって使われなくなった無効なメールアドレスを放置すると送信エラーの原因になり、最終的に正常なアドレス宛てのメールまで届かなくなるおそれがあります。

対策：新しいリストは、Webサイトでの資料請求や展示会などを通じ、事前に配信同意を得た連絡先を獲得します。不達となった無効なアドレスの除外や、配信停止希望のシステム反映を定期的に行い、リストの品質と到達率を維持します。

継続的なコンテンツ制作の体制

専用ツールの活用により、メールの送信や効果測定は自動化できますが、読者のニーズに適合するコンテンツ制作やシナリオ設計には、継続的な工数が発生します。制作リソースが不足してコンテンツの質が低下すると、本文内のクリック率の低下や配信停止の増加の恐れがあります。

対策：コンテンツ制作の属人化を防ぐため、あらかじめ社内での役割分担や進行管理の仕組みを明確にします。コンテンツの構成をテンプレート化して作成工数を削減するほか、社内リソースが不足する場合は外部の専門業者へ業務を委託することも考えましょう。

運用フェーズに応じた段階的な目標（KPI）の設定

メールマーケティングでは、配信目的やリストの状態によって重視すべき指標が異なります。運用初期から資料請求や問い合わせなどの最終成果だけで施策を評価すると、途中のプロセスにある課題や改善すべきポイントを見誤るおそれがあります。

対策：短期的な成果のみを評価基準とせず、運用のフェーズに合わせた中長期的な目標を設けます。初期フェーズでは開封率の安定を目指し、次のフェーズでクリック率や資料請求数の増加を狙うなど、状況に合わせたKPIを設定します。

情報漏洩や誤送信によるセキュリティリスク

個人情報を取り扱う上で、誤送信による情報漏洩は重大なリスクです。特に、通常のメールソフトを用いた手作業でのBCC一斉配信は人為的ミスが発生しやすく、企業の社会的信用を失墜させる要因となります。

対策：配信前のダブルチェックといった確認フローや宛先管理のルールを整備し、誤送信や不正アクセスを防ぐ運用体制を構築します。あわせて、アクセス権限の制限や二段階認証、送信前チェックなどの機能を備えたシステムを活用することで、担当者の注意だけに依存しない安全な管理体制を整えます。

メールマーケティングの主な種類5つ

メールマーケティングの手法は、目的やターゲットの状況に応じて使い分ける必要があります。自社の課題を解決するために、各手法の特徴を理解して、適切に手法を選びましょう。実務において基本となる5つの手法を、利用目的別に解説します。

メールマガジン｜全登録者へ一斉に情報を届けて認知を広げたいとき

新製品の発表やキャンペーン情報を、全登録者へ広く周知する場合に適した手法です。保有するリスト全体へ一度にアプローチできる特性を活かし、自社や製品の認知を広げ、Webサイトへのアクセス総数を確保する上で効果を発揮します。

ただし、配信対象の絞り込みを行わずに一斉送信する特性上、個々の読者がその時に求める内容に乖離が生じやすくなります。その結果、特定の属性に基づいて最適化を行う手法と比較すると、本文内のリンクを押すクリック率や最終的なコンバージョン率といった反応の割合は低くなる傾向があります。

ターゲティングメール｜特定の属性や行動に絞ってアプローチしたいとき

自社が保有している顧客リストの中から、役職、業界、過去の行動履歴などの特定の条件に合致する層を抽出して配信する手法です。あらかじめ特定の条件で受信者を絞り込んでいるため、個々の読者のニーズに合致しやすくなります。

イベントやセミナー後のフォローアップ、特定の課題を持つターゲット層への限定案内など、個別のコミュニケーションを目的とする場合に有効です。

ステップメール｜スケジュールに沿って段階的に顧客を育成したいとき

資料請求、会員登録などといった顧客の特定のアクションを起点として、あらかじめ設定したシナリオとスケジュールに沿って、複数のメールを段階的に自動配信する手法です。具体的には、アクションがあった翌日にお礼メール、3日後にお役立ち情報や事例紹介、1週間後に限定キャンペーン案内といった形式で情報を届けます。アクションから最終的な購買検討に至るまでの、情報ニーズの変化に合わせてコンテンツを自動で提供できます。

リターゲティングメール｜行動に合わせてタイムリーに購入を促したいとき

顧客がWebサイト上で取った特定の行動を検知し、システムが自動で送信する手法です。代表例として、ECサイトで商品を買い物かごに入れたまま離脱した顧客への買い忘れ防止の通知や、特定の製品ページを複数回閲覧している顧客へ個別にアプローチする手法です。

顧客の行動を起点にメールを配信するため、商品への注目度や検討度合いが進捗している段階に絞ってメッセージを届けることができます。アクションの直後にアプローチを仕掛ける構造上、コンバージョンが期待できます。

休眠発掘メール｜過去に接触があり動きのない顧客を再アクティブ化したいとき

特定の条件で対象を絞り込んで送るターゲティングメールの一種で、過去に購入や名刺交換などの接点があり、その後の活動が途絶えている顧客を対象とします。通常のメールマガジンとは異なる切り口の件名や、限定オファーを用意して、顧客の関心を再喚起することが目的です。この配信によって反応を示した顧客を、ステップメールやターゲティングメールの運用ラインへ移行させ、営業活動の再開に繋げることができます。

メールマーケティングを実施する5ステップ

メールマーケティングを成功に導くためには、手順を踏むことが重要です。この章ではメールマーケティングの実施手順を5ステップに分けて説明します。

ステップ1：目的とKPIの設定

最初のステップは、施策の最終目的（KGI）を明確にすることです。新商品の売上増加や、展示会後の商談獲得、あるいは休眠顧客の掘り起こしなど、目的に応じて最適なアプローチは変わります。目的が定まったら、それを達成できたか客観的に測るための中間目標を具体的な数値目標として設定します。

ステップ2：目的に応じた配信手法の選択と対象の特定

設定した配信目的に合わせ、メールマガジン、ターゲティングメール、ステップメールなどから最適な配信手法を選択します。手法の決定に伴い、全登録者へ一斉に届けるのか、あるいは特定の属性や行動履歴に基づいて送付先を抽出するのかといった、今回の配信対象者を確定させます。

ステップ3：ターゲットに合わせたメールコンテンツの作成

配信手法と対象者が確定したら、読者のニーズに合う件名と本文を作成します。一斉配信のメルマガであれば汎用性の高いノウハウ、特定のターゲット層であればその課題に特化した案内など、手法に応じた文章構成が求められます。また、目的に応じてシンプルなテキストメールと、視覚的アピールがしやすいHTMLメールを使い分けることもポイントです。

ステップ4：配信作業の実施とエラー管理

コンテンツの作成後は、本配信の前にテストメールを社内宛てに送信し、各種デバイスでの表示崩れ、リンクエラー、誤字脱字がないかを確認します。問題がなければ、ターゲット層の行動パターンに合わせた曜日・時間帯を指定して本番配信を実行します。配信後は、不達となったエラーアドレスを特定し、次回の配信対象から必ず除外します。

ステップ5：効果測定と改善策の検証

メール配信後は、到達率、開封率、クリック率、コンバージョン率などの数値を測定し、KPIと比較します。目標未達の指標がある場合は、データをもとにボトルネックを特定します。

たとえば、開封率が低い場合は件名や配信日時に原因があると仮定し、複数の件名でA/Bテストを実施するなど、具体的な検証を行って有効な要因を特定します。

メールマーケティングに役立つツールの選び方

メールマーケティングの具体的な実施手順や運用サイクルは、これまでに解説した通りです。配信規模が小さく、限定的な一斉配信であれば手作業での運用も可能です。しかし、配信数の拡大や、顧客の状態に合わせた高度な施策を展開する場合、手作業での管理は困難になります。本章では、自社の配信規模や運用目的に応じたツールの重要性を整理し、自社に最適なシステムを選定するための基準を紹介します。

手作業による運用とツール検討の分岐点

メールマーケティングは、既存のメールソフトを活用して小規模な一斉配信から手軽に始めることができます。しかし、運用の規模が広がるにつれて管理すべき項目が増大し、以下のような課題が生じやすくなります。

管理工数の増加：リストの更新や配信設定の手間が増え、担当者の業務負担が大きくなります。
誤送信対策の複雑化：配信頻度が大きくなるほど、BCC設定などの人為的ミスを防ぐ管理体制の維持が難しくなります。
効果測定の手間：配信数や開封率などのデータを手動で集計・分析する場合、多くの工数が必要となります。
施策の高度化への対応：属性に応じた切り分けやステップメールなど、成果を高めるための複雑な配信の実施が困難になります。

このように、運用の拡大に伴って生じる課題を解決するためにツールの利用が有効な選択肢となります。次章からは、自社の運用目的や配信規模に適したツールを選定するための具体的な基準を解説します。

失敗しないツールの選び方5つのポイント

メールマーケティングにおいて、大量の配信処理や属性ごとの送り分け、効果測定の自動集計などをスムーズに行う上で、ツール活用は有効な手段です。しかし、機能や対応範囲はツールごとに異なります。この章では機能の不足による運用の形骸化を避けるために、確認すべき5つの選定基準を解説します。

導入目的を明確にする

ツール選びで最も重要なのは、まず自社がメールマーケティングで何を達成したいかを明確にし、それに合ったツールを選択することです。シンプルなメルマガ一斉配信や属性絞り込みが中心なら、低コストで機能が絞られているメール配信ツールで十分に目的を果たせます。一方で、顧客のWeb行動履歴と連動した複雑な自動シナリオ配信や、高度な顧客育成を行いたい場合は、MAツールを選択するといいでしょう。

分析しやすいレポート機能の充実度

施策の改善を円滑に進めるには、必要な指標が自動で集計されるレポート機能の有無が重要です。到達率、開封率、クリック率からコンバージョン率に至るまでの重要指標が、手作業を挟まずに自動で算出され、把握しやすく可視化されるツールは、分析業務の工数削減と正確な状況把握に役立ちます。

既存システムとの連携性

利用しているCRMや、Webサイトのアクセス解析データとスムーズにデータ連携できるかが重要です。社内で顧客データが分断されるのを防ぎ、一元管理することで、より精度の高いターゲティング配信が可能になります。

自社の配信ボリュームとコストの適合性

多くのツールは、登録するアドレス総数や月間の配信通数によって月額費用が変動する料金体系を採用しています。そのため、自社の現在のハウスリスト数や将来的な増加見込み、月間の配信頻度を事前に算出し、自社のボリュームに対して最もコストパフォーマンスが高くなる料金体系を備えたツールを選びましょう。

個人情報を扱うための十分なセキュリティ体制

メールアドレスという重要な個人情報を預けるため、安全性の確認は企業の信頼維持に直結します。データの暗号化や二段階認証、アクセス権限管理、第三者機関によるセキュリティ認証の取得状況など、厳格な安全基準を満たしたツールが推奨されます。

メールマーケティングに関するよくある質問

メールマーケティングを実際に導入・運用するにあたって、よくある質問とその回答を紹介していきます。

Q.成果を出すための最適な配信頻度はどれくらいですか？

A. 最初は週1〜2回のペースを目安に始めるのが推奨されます。

メールの配信頻度に絶対的な正解はありませんが、あまりに頻繁に送りすぎると、読者に不快感を与えて配信停止や迷惑メール報告のリスクが急増します。逆に月に1回程度では、自社の存在を忘れられてしまい中長期的な関係構築に繋がりません。まずは週1回、決まった曜日・時間帯での配信からスタートし、自社のリソースの負担や、配信後の解除率などのデータを見ながら最適な頻度を探っていくのがいいでしょう。メルマガの適切な配信時間については次の記事を参考にしてみてください。

メルマガの最適な配信時間は？ BtoB・BtoC別に効果的な曜日と時間帯を解説｜ベアメールブログ

Q.BtoBとBtoCで、メールマーケティングの施策に違いはありますか？

A. 対象の行動パターンや購買心理によって、アプローチが大きく異なります。

BtoB（企業向け）：読者は業務中のビジネスパーソンです。そのため、論理的なデータや導入事例、課題解決に直結するコンテンツが好まれ、配信タイミングも平日の就業時間内（火曜〜木曜の午前中や昼休み明けなど）が最も開封されやすい傾向にあります。

BtoC（一般消費者向け）：読者は個人です。感情を動かすビジュアル（HTMLメール）や、クーポン・セールといったお得なキャンペーン情報が効果を発揮します。開封されやすい時間帯は、通勤・通学時間、帰宅後のリラックスタイム、あるいは休日など、ターゲットのライフスタイルに合わせる必要があります。

Q.メールマーケティングを始めるにあたり、実務で最低限守るべき法律のルールを教えてください。

A. 企業の信頼維持と法令遵守のために、実務では配信前に必ず以下の3項目がクリアできているか確認してください。

事前同意の獲得：あらかじめ受信の同意を得た相手以外に、広告や宣伝を目的としたメールを送信することは法律で原則禁止されています。名刺交換をした相手や、自社サイトから資料請求・問い合わせのあった顧客など、「配信の同意」が明確に確認できるリストのみを対象にしてください。
送信者情報の明記：メールの本文内には、送信者の「会社名」「住所」「問い合わせ先」を読者が分かりやすい場所に必ず記載しなければなりません。一般的には、メールの最下部にこれらの情報をまとめて掲載します。
配信停止導線の設置：読者が「もうメールを受け取りたくない」と思ったときに、いつでも簡単に配信を停止できる仕組みを提供することが義務付けられています。「配信停止はこちら」といった手続きページへのリンクを、メール内の目立つ場所に必ず常設してください。配信停止に関する法律の詳細については次の記事をご確認ください。

メルマガ配信停止に関する法律とは？具体的な実装方法や注意点を解説｜ベアメールブログ

これらを手作業のメーラーですべて管理しようとすると、配信停止の反映漏れなどのミスが起きやすくなります。しかし、専用のメール配信ツールやMAツールを導入すれば、フッターへの自動記載や、配信停止リンクをクリックした顧客の自動除外など、システム側で法律に準拠した安全な運用を自動でカバーすることが可能です。

Q.開封率やクリック率の一般的な目安はどのくらいですか？

A.業界やターゲットによって変動しますが、実務で指標となる一般的な目安は以下の通りです。

到達率： 90%〜95%以上
開封率： BtoBでは15%〜20%、BtoCでは10%〜15%程度
クリック率（CTR）：メール全体の配信数に対して1.5%〜2.5%程度（開封者数を基準にする場合は8%〜12%程度）
コンバージョン率（CVR）：リンクをクリックしてサイトを訪れた人のうち1.0%〜3.0%程度

自社の運用データがこの目安を大きく下回っている場合は、件名を工夫して開封率を改善したり、本文の導線やボタン配置を見直してクリック率を改善し、具体的なボトルネックを発見するための判断材料として活用してください。業界別の開封率の平均値や、開封率の改善方法は次の記事を参考にしてください。

メルマガ開封率を上げるには？業界平均値から低下の原因、改善方法まで徹底解説！｜ベアメールブログ

クリック率の改善方法については次の記事を参考にしてください。

メルマガのクリック率を改善する方法｜平均値と原因別の改善方法をわかりやすく解説｜ベアメールブログ

メールマーケティングの効果を高めるセキュリティ規格

メールマーケティングを実施しても、送信したメールが開封されず、迷惑メールに振り分けられてしまうケースがあります。その背景には、なりすましメールの増加に伴う受信側のセキュリティ強化があります。送信元の安全性を証明できないメールは、システムに自動で排除されたり、受信者から不審なメールと見なされたりするリスクが高まります。

そのため、現在の配信環境においてメールの到達率や信頼性を確保するには、正規の送信元であることを客観的に証明する対応が求められています。

この課題を解決する最新のセキュリティ規格として注目されているのがBIMI（ビミ）です。これは、DMARCなどの送信ドメイン認証に対応したメールに対して、受信画面に企業の公式ロゴマークを表示させる仕組みです。読者は開く前に一目で送信元を確認できるため、安心して開封できるようになります。

ベアメールでは、メールマーケティングの信頼性を高め、企業の資産を守るためのセキュリティ規格を解説した、BIMI導入ガイドブックを無料で提供しています。技術部門への共有マニュアルや、社内の検討材料としてご活用ください。

BIMIの詳しい仕組みや導入のメリットについては、下記の記事で詳しく解説しています。

メールにロゴを表示するBIMIとは？導入のメリットや設定方法を解説｜ベアメールブログ

BIMI導入にかかる費用は？｜VMC・CMCの違いや導入効果も解説｜ベアメールブログ

まとめ

メールマーケティングは、施策の設計次第で即座に効果が出るケースもありますが、基本的には顧客との信頼関係を丁寧に積み重ねていく施策です。正しい手順と適切なツール選び、そして顧客にとって有益な情報提供を継続すれば、中長期的に利益を生み出し続ける強力な仕組みへと育ちます。まずは自社がメールを通じて、誰にどうなってほしいのかを整理することから始めてみましょう。

Postfix設定逆引きガイド集｜基本から応用まで実践解説

菱沼憲司 — Tue, 26 May 2026 15:00:00 GMT

Postfixと聞いて、具体的にどのような仕組みを想像されるでしょうか？

「名前は知っているが、詳しくは分からない」「単にメールを送るためのツール」といった漠然としたイメージをお持ちの方も多いかもしれません。

本記事では、Postfixをセキュアかつ安定して動作させるための必須設定から、現場の難題を解決する高度なリレー制御の方法まで、実務に即した「main.cf」での設定例を逆引き形式で紹介します。

Postfixの基本構造と設定のルール
【基本設定】自サーバーのホスト名とドメインを設定したい
【共通ルール】外部ファイル参照とテーブルタイプの基本
【配送・リレー制御】メールの行き先や中継ルートをコントロールしたい
【アドレス変換・転送】送信元や宛先のアドレスを書き換えたい
【セキュリティ強化】安全にメールを送受信するための対策を行いたい
【高度な制御】防御・宛先検証・代替配送を設定したい
【保守・管理】現在の設定やメールキューを操作したい
まとめ

Postfixの基本構造と設定のルール

Postfixは、Linuxサーバー環境でデファクトスタンダードとなっているメール転送エージェント（MTA）です。高い安全性と、大規模な配送基盤にも対応可能な堅牢性を兼ね備えています。

他のMTA（SendmailやExim等）に対する最大の優位性は、そのモジュール構造にあります。各処理を独立したプロセスに分離することで、万が一の障害時も影響範囲を最小限に抑え、優れた保守性と拡張性を実現しています。

導入前に知っておくべきこと

導入にあたってまず理解すべきは、Postfixの役割が「メールを配送すること」に特化していることです。そのため、メールを受信して手元の端末で読むには、別途DovecotなどのPOP/IMAPサーバーを組み合わせる必要があります。

なお、PostfixはWindowsネイティブ版が存在しません。検証目的などでWindows環境を使用する場合には、WSL2（Windows Subsystem for Linux）などを活用する構成が一般的です。

Postfixを支える2つの設定ファイル

Postfixの動作は、主に「/etc/postfix/」ディレクトリに格納されている「main.cf」と「master.cf」という2つの設定ファイルによって決定されます。それぞれの違いは以下の通りです。

main.cf：Postfixでどうメールを送るか
- 役割：「どこから、どこへ、どう送るか」という外部的なルールを定義します。
- 内容：ドメイン名、中継ルール、セキュリティ関連、メールサイズの制限などを設定します。日常的な運用では、ほとんどはこのファイルを扱います。
master.cf：Postfixをどう動かすか
- 役割：「どのように、どんな条件で動かすか」という内部的な動作を定義します。
- 内容：Postfix内部の各モジュールの起動方法や引数、並列数などを制御します。SMTPサーバーの起動、SASL認証の有効化など。初期構築時や高度なカスタマイズ時以外は、あまり触れることはありません。

【基本設定】自サーバーのホスト名とドメインを設定したい

まず、Postfixを導入した直後に最低限設定すべき、基本的な設定項目をご紹介します。

特にドメイン関連の設定は、メールの送信元アドレスやヘッダ情報が明確になるため、受信側サーバーでの信頼性が向上します。その結果、メールの到達率にも大きく貢献する重要な設定となりますので、しっかり押さえておきましょう。

自サーバーのホスト名（FQDN）を定義したい｜myhostname

設定例：

myhostname = mail.example.com

メールヘッダの「Received」などに使われ、他のメールサーバーに自身を識別させるために必要な設定です。技術的にはFQDN形式（完全修飾ドメイン名）でなくても動作自体はしますが、受信側への信頼性という意味でも、ここはFQDN形式にしておくことが推奨されています。

使用するメインドメインを指定したい｜mydomain

設定例：

mydomain = example.com

Postfixで中心として扱うドメイン名を指定します。通常は「example.com」のような、みなさんがお持ちの自身のドメインを指すパラメータです。

ドメイン名を省略した際の補完ルールを決めたい｜myorigin

設定例：

myorigin = $mydomain

サーバー内やプログラムからドメイン名を省略してメールを配信した場合に、自動的に補完されるドメイン名を決める設定です。ここで指定した値が、送信元の「From:」ヘッダなどに影響してきます。特別な理由がなければ、上記のように mydomain の値をそのまま参照させる設定（$mydomain）にしておくのがおすすめです。

通信プロトコルをIPv4のみに制限したい｜inet_protocols

設定例：

inet_protocols = ipv4

例では「xxx.xxx.xxx.xxx」のようなIPv4形式のみを有効にしています。

デフォルトのままだとIPv6も動こうとしますが、環境によってはあえてIPv6を無効化することで、IPv4のみを使用している環境での動作安定性が向上する場合があります。「なぜかメールの配送が遅いな」と思ったら、ここを見直してみると解決するかもしれません。

【共通ルール】外部ファイル参照とテーブルタイプの基本

次の章からは、メールの行き先をコントロールする「配送・リレー制御」をはじめ、アドレスの書き換えやセキュリティ対策など、少し複雑で実務的な設定に入っていきます。

これから先の章では、共通して外部に別のテキストファイルを用意して、Postfixにそれを読み込ませて動かすという設定がたくさん登場します。そこで、具体的な設定に入る前に、Postfixで外部ファイルを扱うときの超重要ルールである「テーブルタイプ」と「postmapコマンド」の前提知識について、ここで先にお話ししておきます。これを理解しておくと、この先のすべての章の設定がスムーズに頭に入ってくるようになりますよ！

Postfixの設定では、ここから先「alias_maps = hash:/etc/aliases」のように外部ファイルを参照するケースが頻繁に出てきます。その際、検索を高速化するためにテキスト形式のマップファイルを「postmap」コマンドでバイナリデータベース形式(.db)に変換する必要があります。

外部ファイルを更新した際には「postmap」コマンドを実行し、バイナリデータベースも一緒に更新しないと設定内容が反映されませんので注意してください。

両方の設定を更新したら「postfix reload」や「systemctl reload postfix」のコマンドで設定を反映させる必要があります。小難しいことは置いといて、別ファイルを参照する設定の場合は「postmap」が必要で、変更した設定を反映させるには「reload」が必要になると覚えておきましょう。

例）

postmap /etc/postfix/sender_relay

本記事では明確に「hash:」等のテーブルタイプを指定していますが、「hash:」を指定しなくても内部的には「hash:」として解釈されます。使用可能なテーブルタイプは下記の通りです。

テーブルタイプ	postmap	意味・用途
hash:	必要	Berkeley DB のハッシュマップ。最もよく使われる。
btree:	必要	B-Tree 形式。hash: よりも範囲検索に強いがあまり使われない。
cdb:	必要	Constant Database。読み込み専用で高速だが変更不可。
lmdb:	必要	Lightning Memory-Mapped DB。最近のPostfixで利用可能な高速DB。
(接頭辞省略)	必要	default_database_type に従う（多くは hash）。
regexp:	不要	POSIX正規表現マッチ。
pcre:	不要	Perl互換正規表現マッチ。regexp: より柔軟性が高い。
cidr:	不要	CIDR表記によるIPレンジマッチ。
inline:{…}	不要	main.cf に直接キー=値を書き込むインラインマップ。
static:…	不要	常に固定の値を返す。static:OK などで「常に許可」のような使い方。
mysql:	不要	MySQLデータベースを直接クエリ。
pgsql:	不要	PostgreSQL を直接参照。
sqlite:	不要	SQLite を直接参照。
ldap:	不要	LDAP ディレクトリを直接参照。
memcache:	不要	memcached によるキャッシュ参照。

【配送・リレー制御】メールの行き先や中継ルートをコントロールしたい

ここでは、メールの配送経路や中継（リレー）に関する設定を紹介します。受け取ったメールを適切な宛先へ届けるために、要件に応じた配送経路をコントロールする方法を見ていきましょう。

外部へのメール中継先（リレーホスト）を指定したい｜relayhost

設定例：

relayhost = [smtp.example.com]:25

受け取ったメールをどこに中継（リレー）して送信するかを指定します。

ここで一つ細かいポイントなのですが、設定値のサーバー名に [ ] をつけるかどうかで動きが変わります。[ ] がある場合は「MX解決をスキップしてAレコードに直接接続」し、ない場合は「MXレコードの引き先」に送るという違いがあります。有無によって動作が異なるため注意して下さい。

自サーバーが最終目的地となるドメインを指定したい｜mydestination

設定例：

mydestination = $myhostname, localhost.$mydomain, localhost

このPostfixが「最終受信者（自分宛てのメール）」として扱うドメイン名のリストを指定します。簡単に言うと、ここで指定したドメイン宛のメールは外部へ中継されずに、ローカルのメールボックスに格納されます。この指定を間違えると、自分宛てのメールなのに外部へ転送しようとしてループしてしまう、といったトラブルの原因になるので注意が必要です。

宛先ドメインごとに配送ルートを強制分岐させたい｜transport_maps

設定例：

transport_maps = hash:/etc/postfix/transport

ファイルの中身（/etc/postfix/transport）：

example.com smtp:[relay.example.com]

ドメインやメールアドレスごとに、配送先（配送手段やリレー先）を個別に指定できる設定です。例では「/etc/postfix/transport」というファイルを用意して、「example.com宛のメールは、relay.example.comにSMTPで転送する」という設定を入れています。特定の宛先ドメインに対して、デフォルトの配送経路（MX参照や relayhost の設定）を上書きしたい場合にすごく便利です。

ちなみに、転送先（リレーホスト）を指定せずに「example.com smtp」とだけ書いた場合は、「example.com」の通常のMXレコードを参照して転送する動きに戻すことができます。

送信元ドメインに応じてリレー先のSMTPサーバーを切り替えたい｜sender_dependent_relayhost_maps

設定例：

sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay

ファイルの中身（/etc/postfix/sender_relay）：

@example.com    [smtp.relay1.local]:587
@sample.org     [smtp.relay2.local]:25

「送信元アドレス（envelope from）によって転送先を変える」機能です。Postfixが外部にメールを配送するとき、Fromのドメインごとに別のリレー先を指定することができます。特定の送信者や部署からのメールだけ別のSMTPサーバーを経由させたい、といった現場の要件でよく使われます。

もし通常の relayhost も一緒に設定されていた場合は、この sender_dependent_relayhost_maps の設定が優先されます。ここに記載されていない送信元ドメインのメールは、通常の配送（または relayhost の設定通り）となります。

メールサイズの上限を設定したい｜message_size_limit

設定例：

message_size_limit = 26214400

メールサイズの上限をバイト（byte）単位で指定し、この制限値を超えた場合は送受信を拒否する設定です。大きすぎるメールをそのまま許可してしまうと、ネットワークやサーバーのストレージを圧迫して、システム全体に大きな負荷がかかってしまうので注意してくださいね。

設定例では「26214400」と指定して25MBまでのメールを許容していますが、もし何も設定をしない場合のデフォルト値は「10MB（10240000バイト）」が上限になっています。運用の要件や、社内で扱うファイルの大きさに合わせて調整してみてください。

【アドレス変換・転送】送信元や宛先のアドレスを書き換えたい

Postfixの基本設定を終え、運用を始めると「特定の条件下で挙動を変えたい」と考えることは少なくありません。ここでは、送信元や宛先のアドレス変換、別アドレスへの転送など、運用の現場でよく求められるカスタマイズ例を紹介します。

送信元アドレスを代表アドレスなどに書き換えたい｜sender_canonical_maps

設定例：

sender_canonical_maps = hash:/etc/postfix/sender_canonical

ファイルの中身（/etc/postfix/sender_canonical）：

root@localhost  admin@example.com
@old.example.com  @new.example.com

(※rootユーザから送信されるメールを admin@example.com として送信 )

(※@old.example.com を @new.example.com として送信 )

送信元アドレスのエンベロープFromとヘッダーFromを、任意の形式に書き換えることができる設定です。

Linuxのユーザ名やローカルドメインのままメールを送信してしまうと、受信側で迷惑メールと判定されたり、ブランドの印象が損なわれる恐れがありますよね。メール送信側が正しいアドレスを名乗れない場合の「最終防衛ライン」として、Postfix側でアドレスを整形して組織の代表アドレスなどに統一したいときに役立ちます。ユーザ単位やドメイン単位、正規表現での一括変換など、用途に応じて細かいコントロールが可能です。

ただ、注意点として、書き換え後のドメインでSPFレコードやDKIM署名が正しく設定されているかなど、送信ドメイン認証（特にDMARC）への影響を考慮して慎重に設定しましょう。

宛先アドレスを内部的に別のアドレスへ変換したい｜recipient_canonical_maps

設定例：

recipient_canonical_maps = hash:/etc/postfix/recipient_canonical

ファイルの中身（/etc/postfix/recipient_canonical）：

support_aaa@example.com  support@example.com
support_bbb@example.com  support@example.com

(※「support_aaa@example.com」や「support_bbb@example.com」宛のメールを「support@example.com」宛に変換 )

受信メールを処理する際に、宛先アドレス（エンベロープTo）を内部的に別のアドレスへ変換するための設定です。複数のエイリアスアドレスを一つのユーザに統合したい場合に有効で、配送処理の前に適用されるため、最終的な配送先の正規化・簡略化に役立ちます。

Postfix内部の配送処理に影響するものなので、エンベロープToは書き換えられますが、メールヘッダの表示自体は基本的に変わらないのが特徴です。ちなみに、以下のように「regexp:」を使えば、ワイルドカード的なパターンマッチも可能になります。

/^support_[^@]+@example\.com$/ support@example.com

もし、変換するだけでなく配送先そのものを完全に変更・転送したい場合は、次に紹介する virtual_alias_maps の利用が適しています。

ローカルユーザ宛のメールを別のアドレスへ転送したい｜virtual_alias_maps

設定例：

virtual_alias_maps = hash:/etc/postfix/virtual

ファイルの中身（/etc/postfix/virtual）：

support@example.com      user@example.net
sales@example.com        user@example.net

(※「support@example.com」、「sales@example.com」宛のメールを「user@example.net」に集約 )

宛先アドレスを別のアドレスに転送・変換するための設定です。仮想ドメインのメール転送や、複数の別名アドレスを1つの実アドレスに集約する場合などに使用されることが多いのではないでしょうか。この設定は、さきほどの recipient_canonical_maps と違って「配送先を完全に書き換える」ため、実際にどのメールボックスに届けるかを制御できます。変換前のアドレス宛には届かなくなってしまうので、正しくマッピングができていないとメールを紛失してしまう恐れがある点には注意してくださいね。

特定ユーザにBCCで監査・保存したい｜sender_bcc_maps / recipient_bcc_maps

設定例：

sender_bcc_maps = hash:/etc/postfix/sender_bcc
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc

ファイルの中身（/etc/postfix/sender_bcc）：

test@example.com    archive@example.net

ファイルの中身（/etc/postfix/recipient_bcc）：

bob@example.com      audit@example.net

送信、または受信メールを指定した別アドレスに、BCCとして自動送信する設定です。メールの監査やバックアップ用途で利用されるケースが多いのではないでしょうか。「sender_bcc_maps」の例で言うと、「test@example.com」が送ったメールは、本人が意識していなくても、必ず「archive@example.net」にも自動でBCC配送されるようになります。

【セキュリティ強化】安全にメールを送受信するための対策を行いたい

メールサーバーを安定して運用するためには、外部からの攻撃や不正利用を防ぐ堅牢なセキュリティが不可欠です。ここでは、オープンリレー（踏み台化）の防止をはじめ、通信内容を保護するTLS暗号化、SMTP認証など、セキュリティに関する主要な設定項目と実装方法について解説します。

信頼するネットワークを指定して不正中継（オープンリレー）を防ぎたい｜mynetworks

設定例：

mynetworks = 127.0.0.0/8, 192.168.0.0/24

サーバーから「中継（リレー）送信」を許可する送信元IPの許可リストです。ここで許可されたIP範囲からの送信要求のみ、外部への配送が許可されます。正しく設定すれば不正利用を防止できますが、もしここに「0.0.0.0/0」を指定してしまうと、全ネットワークからの中継を許可することになってしまいます。このような状態を「オープンリレー」と言いますが、オープンリレーになってしまうとメールを送信するための踏み台として世界中から不正利用されてしまいますので、特に注意が必要です。

宛先不明メールをSMTP通信時に拒否してバックスキャターを防ぎたい｜alias_maps / local_recipient_maps

設定例：

alias_maps = hash:/etc/aliases
local_recipient_maps = unix:passwd.byname $alias_maps

ファイルの中身（/etc/aliases）：

postmaster: root
support: user1@example.com

alias_maps はメールの転送先や別名（エイリアス）を定義し、local_recipient_maps はローカルユーザが存在するかどうかをチェックする設定です。設定例にある unix:passwd.byname は /etc/passwd にあるユーザを確認し、$alias_maps はエイリアスファイルに定義されている名前かどうかを確認しています。

これらを明示的に指定して合わせることで、Postfixは「ユーザまたはエイリアスとして定義されたもの」だけをローカル配送可能とみなします。もし、どちらにも存在しない宛先へのメールが届いた場合は、受信時（RCPT TO）の段階でエラーとして拒否してくれます。

もしこの設定を正しく行わないと、存在しない宛先宛てのスパムメールを一旦受け取ってしまい、その後で「宛先がありませんでした」というエラーメールを送信元（大抵は偽装された他人のアドレス）に返すことになります。これは「バックスキャター（バウンス悪用スパム）」と呼ばれ、自分のサーバーがスパムの片棒を担ぐ原因になってしまうため、これを防止する意味でも極めて重要な設定です。ちなみに unix: はUNIXシステムデータベースを参照するテーブルタイプなので、postmap コマンドによるバイナリ化は不要です。

接続元と宛先の制限ルールを定義してオープンリレーを厳格に阻止したい｜smtpd_relay_restrictions

設定例：

smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination
smtpd_recipient_restrictions = reject_unknown_recipient_domain

不正な第三者によるメールの中継（リレー）を防止するための、Postfixのセキュリティの要となる制限設定です。設定しない場合、簡単にスパム中継として悪用される危険性があります。

例のように、permit_mynetworks（信頼するIPからの送信を許可）、permit_sasl_authenticated（認証に成功したユーザからの送信を許可）を並べ、最後に reject_unauth_destination（それ以外の外部宛てメールは拒否）を記述するのが王道の構成です。Postfixはこれらを上から順番に評価していくため、記述する順番を間違えないように注意してください。

送受信時の通信内容をTLSで暗号化して保護したい｜smtpd_tls_security_level / smtp_tls_security_level

設定例：

# 受信側（サーバーとして動作するとき）

smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem
smtpd_tls_key_file = /etc/ssl/private/postfix.key
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_security_level = may

# 送信側（クライアントとして外に送るとき）

smtp_tls_security_level = may
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

パッと見ると似たような設定が並んでいてややこしいですが、smtpd_* は受信時のTLS接続設定（Postfixが受信サーバーとして動く際の設定）となり、送信側（他のサーバーにメールを転送・配送するとき）の設定パラメータは smtp_* となります。

秘密鍵や証明書の設定（cert/key）は、受信サーバーとして自分の身元を証明するために提示するものなので、基本的には smtpd_* 側にしか書きません。ただし、相手のサーバーからクライアント証明書を求められた場合などのために、送信側の smtp_* にもクライアント証明書を設定できるようになっています（smtp_tls_cert_file / smtp_tls_key_file）。

また、security_level の設定値を変えることで、どの程度厳格にTLS（暗号化）を使用するかの方針を決めることができます。設定値の意味は以下の通りです。

値	意味
`none`	TLSを使わない
`may`	相手が対応していればTLS、なければ平文（オポチュニスティックTLS）
`encrypt`	必ずTLSを使用、ただし証明書の検証は甘め
`verify`	必ずTLSを使用し、証明書をしっかり検証する
`secure`	必ずTLSを使用し、証明書に加えて相手名の一致まで厳格に確認する

SMTP認証を導入して正規ユーザのみ送信を許可したい｜Cyrus SASL

連携設定手順と設定例：

1.パッケージのインストール（RHEL8系の場合）

dnf install cyrus-sasl cyrus-sasl-plain cyrus-sasl-lib

2.main.cf の設定

smtpd_sasl_auth_enable = yes
smtpd_sasl_type = cyrus
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination

3.master.cf の設定

submission inet n       -       y       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

4.外部認証設定ファイル（/etc/sysconfig/saslauthd / /etc/sasl2/smtpd.conf）

# /etc/sysconfig/saslauthd
MECH=pam
# /etc/sasl2/smtpd.conf
pwcheck_method: saslauthd
mech_list: plain login

5.設定反映とデーモンの起動

systemctl restart postfix
systemctl start saslauthd
systemctl enable --now saslauthd

通常のSMTPは、標準の仕様だと「誰でも接続できてしまう」仕組みになっているため、そのまま公開するとスパムメールの踏み台に悪用される危険が非常に高いです。この対策として導入するのが、ユーザ名とパスワードでログインさせる「SMTP認証（SMTP AUTH）」です。認証に成功した正規のユーザだけがメールを送信できるようになります。

Postfix単体では認証の仕組みを持たないため、「Cyrus SASL」や「Dovecot」といった外部の認証サービスと連携させて動かすのが基本構成です。本記事ではCyrus SASLを使う例を紹介しています。

このSMTP認証を安全に運用するために、一般的には25番ポートではなく「submissionポート（587番）」を使い、暗号化（STARTTLS）と認証をセットで利用します。25番ポートでも認証自体は有効化できますが、25番は本来「サーバー同士がメールを配送し合うためのポート」ですので、ユーザからの送信用には master.cf で 587番ポートを分けてあげるのが推奨されています。

ヘッダや本文の内容で簡易的にメールを拒否したい｜header_checks / body_checks

設定例：

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

ファイルの中身（/etc/postfix/header_checks）：

/^Subject:.*spammail!/    REJECT 不審な件名を検出しました
/^From:.*example\.com/ DISCARD ローカルポリシーで破棄

ファイルの中身（/etc/postfix/body_checks）：

/スパムメールです！/    REJECT 不審な本文を検出しました

メールのヘッダや本文に対して正規表現による検査を行って、特定のパターンにマッチしたメールを拒否・破棄・隔離できる簡易的なフィルタリング機能です。

例えば、設定例のように「REJECT」と書いておくと、特定のキーワードが含まれるメールを検知した際に「554 5.7.1 不審な本文を検出しました」といったSMTPエラーコードを返して受信を拒否できます。これにより、相手のログに拒否理由を残しつつ、送信者へ届かなかったことをエラー通知することができます。正規表現にマッチした際に使用できるアクションには、以下のような種類があります。

アクション	動作
REJECT	拒否（エラー応答、ログ出力）
DISCARD	黙って破棄（成功応答、ログ出力）
WARN	配送は続行、ログに警告
HOLD	hold キューに隔離
FILTER	外部フィルタに渡す
REDIRECT	宛先を別のメールアドレスにリダイレクト
IGNORE	マッチ部分を削除/無視
PREPEND	新しいヘッダを追加
REPLACE	マッチ部分を置換

【高度な制御】防御・宛先検証・代替配送を設定したい

Postfixは一律的なメール配送だけでなく、送信者や宛先の条件に応じた柔軟な制御や、高度な防御機能が備わっています。ここでは、外部のスパムボットを効率的に遮断する仕組みや、サーバー障害に備えた代替ルートの用意など、実務の運用シーンで一歩踏み込んで役立つ設定を解説します。

postscreenを使って接続前の段階でスパムボットを効率的に遮断したい｜ボット対策

設定手順と設定例：

1.master.cf の設定（変更前）

smtp      inet  n       -       n       -       -       smtpd
#smtp      inet  n       -       n       -       1       postscreen

↓↓↓（変更後）

#sm
tp      inet  n       -       n       -       -       smtpd
smtp      inet  n       -       n       -       1       postscreen

2.main.cf の設定

postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.spamcop.net
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_ttl = 1h
postscreen_dnsbl_cache_cleanup_interval = 12h
postscreen_cache_retention_time = 7d

# ホワイトリスト・ブラックリストを使う場合

postscreen_access_list = cidr:/etc/postfix/postscreen_access.cidr

3.ホワイトリストファイルの中身（/etc/postfix/postscreen_access.cidr）

123.45.67.89/24 permit
98.76.56.43          permit
111.222.33.44      reject

Postfixには「postscreen」という接続前スクリーニングの機能が備わっています。

これは、SMTP接続（メールのやり取り）が本格的に始まる前に、接続元のIPアドレスの信頼性をチェックすることで、スパムメールを大量に送信しているホストサーバーやボットからの接続を入り口で遮断できる仕組みです。もちろん、postscreenのチェックを無事にパスした正常なメールは、通常通りに配信されますので安心してください。

通常のアクセス順：クライアント → smtpd
postscreenを有効にした場合：クライアント → postscreen → smtpd

有効にするには main.cf だけでなく、master.cf の変更も必要になります。設定例のように書き換えることで、本来の smtpd デーモンが受ける前に、postscreen が先頭に立ってSMTP接続を受けるようになります。main.cf で指定しているそれぞれのパラメータの意味は以下の通りです。

設定項目	内容	目的
postscreen_greet_action = enforce	グリーティング遅延違反を拒否	ボットの初期検知
postscreen_dnsbl_action = enforce	DNSBL判定を有効化	スパムIPの拒否
postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.spamcop.net	使用するDNSBLと重み設定 ※「*3」だと重みが「3」	信頼度の高いスパムリスト参照
postscreen_dnsbl_threshold = 3	スコア閾値	Spamhausヒットで即拒否
postscreen_dnsbl_ttl = 1h	結果キャッシュ1時間	DNS負荷軽減
postscreen_dnsbl_cache_cleanup_interval = 12h	キャッシュ整理間隔	古い情報を定期削除
postscreen_cache_retention_time = 7d	PASSキャッシュ保持7日	正常ホストを高速許可

ちなみに、action に設定できる値は以下の3種類があります。

設定値	意味
ignore	ログには残すが拒否はしない。動作確認・テスト向き
drop	応答を返さずTCPセッションを切断。静かに拒否
enforce	SMTPエラー（5xx応答）を返して拒否。RFC準拠

本番環境でいきなり遮断するのは怖いと思いますので、まずは ignore で導入してみて、ログで遮断されるIPやドメインを確認したあとで enforce に変更する、というステップを踏む運用がおすすめです。ただ、運用していると「DNSBL（ブラックリスト）に載ってしまっている相手だけど、どうしてもメールを受信したい」といったケースも出てくるかと思います。そうした場合には、ホワイトリスト機能（postscreen_access_list）を使いましょう。postscreen_access.cidr ファイルで permit に設定したIPアドレスは接続が許可され、reject にしたIPは強制ブロックできます。

ここで一つ大きな注意点なのですが、postscreenはSMTP接続の「最初の最初のTCP接続」のレベル（IPベース）で動作するため、ドメイン情報を利用できません。この時点ではまだSMTPセッションが始まっておらず、メールの送信元ドメインが何であるかをPostfixが知らないからです。そのため、「特定のドメインだけを許可したい」と思ってもドメイン名での指定はできません。許可したい送信元のIPアドレスをすべて調べて登録する必要がある点だけ、忘れないように覚えておきましょう。

相手サーバーに宛先が実在するか確認してから配送処理に入りたい｜address_verify_map

設定例：

address_verify_map = btree:/var/lib/postfix/verify

これから送ろうとしている宛先のメールアドレスが相手側に本当に実在するかどうかを事前に確認し、その結果をデータベース（/var/lib/postfix/verify）にキャッシュしてくれる設定です。これを入れることで、届くはずのない無効なアドレスへメールを送り続け、エラーで戻ってきたメールのせいでメールキューが大量に溜まってしまう、といった事態を防ぐことができます。

ただし、良いことばかりではなく、いくつかトレードオフがあります。まず、受信相手のセキュリティポリシーによってはアドレスの実在性を外から確認できない（教えてくれない）場合がありますので、あくまで「補助的な仕組み」として利用するのが現実的です。

また、メールを送るたびに宛先検証のための通信が裏で発生するため、多少のシステムオーバーヘッドが発生します。さらに、相手サーバーに何度も検証をかける動きが「怪しいスキャン行為」とみなされて、こちらのレピュテーション（サーバーとしての信頼度）が下がり、かえってメールの到達率に悪影響を与えてしまうリスクもある点には注意してください。

ちなみに、指定している /var/lib/postfix/verify はPostfixが検証結果をキャッシュするために自動で扱うデータベースファイルですので、みなさんが手動で生成・更新する必要はありません。必要に応じてPostfixが自動的に作成・更新してくれますし、もしファイルを削除してしまっても、勝手に再生成されるので大丈夫です。

リレー失敗時に備えて代替の配送経路を用意したい｜fallback_relay

設定例：

relayhost = [primary.smtp.example.net]
fallback_relay = [backup.smtp.example.net]

メインとして指定した通常のリレー先（relayhost）に何らかの障害が発生し、メールが配送できなかった場合に、予備として設定した別のSMTPサーバー（fallback_relay）に経路を切り替えて配送を継続してくれる設定です。障害時の自動バックアップ経路として機能してくれるため、メールシステムの可用性をグッと高めるのに役立ちます。

ただし、ここで運用上、非常に重要な注意点があります。もし予備として指定した fallback_relay 側のサーバーで「配送できなかったら primary.smtp.example.net（メイン側）に転送する」といった設定が残っていた場合、メインと予備の間でメールが何度も行き来する「無限ループ」が発生してしまいます。こうなると、送れないメールがぐるぐる回り続けてキューが恐ろしい勢いで膨れ上がってしまうため、両方のサーバーの設定の組み合わせには細心の注意を払ってくださいね。

ちなみに、このパラメータはメインの relayhost を設定していない状態でも使えます。通常のDNS（MXレコード）を参照した直接配送がうまくいかなかったドメインに対してのみ、この fallback_relay で指定したサーバーへリレーする、という動きをしてくれるため、システムの「最後の逃げ道」として機能させることも可能です。

【保守・管理】現在の設定やメールキューを操作したい

Postfixを運用していくうえで、一番お世話になり、かつ強力で便利なのがコマンドによる操作です。ここでは日常のトラブルシューティングやメンテナンス時によく使う管理コマンドを、目的別に逆引き形式で紹介します。

現在の有効な設定値やデフォルト値を安全に確認・変更したい｜postconfコマンド

コマンド	操作内容
`postconf -n`	現在有効になっている設定（デフォルトから変更された値）を確認する
`postconf -d`	すべての設定をデフォルト値も含めて確認する
`postconf <設定項目>`	特定の設定パラメータの現在の値だけを取得する
`postconf -e "項目 = 設定値"`	main.cf に設定を直接追加・変更する（上書き・追記）
`postconf -X relayhost`	指定した設定（例では relayhost）を main.cf から削除する
`postconf -M`	master.cf のサービス一覧を表示する
`postconf -a` / `postconf -A`	利用可能なクライアント認証方式（-a）/ サーバー認証方式（-A）を確認する

Postfixの設定を確認するとき、ついつい vi コマンド等で直接 main.cf を開きたくなりますが、本番環境ではこの postconf コマンドを使うのが絶対に安全でおすすめです。

というのも、ファイルを直接開いてしまうと「間違えてキーボードに触れて変な文字を入れちゃった」といった誤編集の事故が起きかねないからです。postconf を使えば、現在有効になっている値を安全に画面上で確認できます。

また、設定を変更するときも postconf -e “項目 = 設定値” を使えば、指定したパラメータを main.cf に自動で追記や上書きをしてくれます。万が一、タイポなどの構文ミスがあった場合でもコマンドがエラーを返してくれるため、手動でファイルを書き換えるよりも遥かに安全に設定変更が行えますよ。

滞留しているメールキューの確認や再配送、削除などの操作を行いたい｜postqueue / postsuperコマンド

よく使うコマンド一覧：

コマンド	操作内容
`postqueue -p`	現在保持しているメールキューの一覧（キューIDや宛先）を表示する
`postqueue -f` または `postfix flush`	滞留しているメールキューの再配送を強制的に実行する
`postsuper -d <キューID>`	指定した特定のキューIDのメールをキューから削除する
`postsuper -d ALL`	すべてのメールキューを強制削除する（※テスト環境などでの利用限定！）
`postsuper -r <キューID>`	指定した特定のメールだけを再配送（再キューイン）させる
`postsuper -r ALL`	「deferred（保留中）」キューにあるすべてのメールを再配送キューに戻す
`postqueue -s <ドメイン>`	指定した特定の宛先ドメインのメールを優先して再配送する
`postcat -q <キューID>`	メールキューに格納されている、実際のメッセージ内容やヘッダ情報を表示する

Postfixでは、送受信の途中で相手に届かなかったり保留になったりしたメールを「キュー」という形でサーバー内に保持して管理しています。メールが相手に届かないときの調査では、まず postqueue -p を叩いてキューの一覧を見ることから始まります。

「ネットワークの障害が復旧したから、溜まっているメールを一気に再送したい！」というときは、postqueue -f を実行すれば強制的に再配送を試みてくれます。

逆に、宛先間違いなどで滞留してしまった不要なメールを消したい場合は postsuper -d を使います。ちなみに、postsuper -d ALL というすべてのキューを吹き飛ばす強力なコマンドもありますが、これを本番環境でうっかり実行するとユーザの正常なメールまで全部消えて大惨事になるので、あくまで開発中のテスト用など、限定的なシーンだけで使うように細心の注意を払ってくださいね。

Postfixの起動・停止や設定ファイルの再読み込みを制御したい｜systemctlコマンド

CentOS 7 / RHEL 7系以降の環境（systemd）

コマンド	操作内容
`systemctl start postfix`	Postfixサービスを起動する
`systemctl stop postfix`	Postfixサービスを停止する
`systemctl restart postfix`	Postfixサービスを再起動する（プロセスごと完全に立ち上げ直す）
`systemctl reload postfix`	設定ファイル（main.cfなど）の変更内容をプロセスを止めずに再読み込みする
`systemctl status postfix`	Postfixの現在の稼働ステータスや直近のログを確認する

CentOS 6系などの古い環境（SysV init）

コマンド	操作内容
`service postfix start`	Postfixサービスを起動する
`service postfix stop`	Postfixサービスを停止する
`service postfix restart`	Postfixサービスを再起動する
`service postfix reload`	設定ファイルを再読み込みする
`service postfix status`	Postfixのステータスを確認する

最近のLinux環境であれば基本的には systemd の管理下で動いているので、上の systemctl コマンドで制御します。

ここで覚えておいてほしい運用のコツは、main.cf などの設定を書き換えたあと、安易に restart（再起動）をしないことです。再起動すると、一瞬ですがSMTPの受付プロセスが完全に止まってしまうため、タイミング悪く接続してきた他のサーバーとの通信が瞬断されるリスクがあります。新しく設定値を反映させたいだけであれば、プロセスを落とさずに設定の裏読み込みをしてくれる systemctl reload postfix を使うのが、稼働中のサービスへの影響がなくて安全ですよ。

設定変更後の構文エラーやファイルのアクセス権限を診断したい｜postfix checkコマンド

実行コマンド：

postfix check

このコマンドが検査してくれる主な項目：

診断される項目	具体的な内容
`main.cf` / `master.cf` の構文	イコール（=）の付け忘れや、改行、コメントアウトの誤記などを検出する
postmapデータベースの存在確認	hash: などで指定された外部参照ファイルの .db（バイナリ）が存在しない場合に警告を出す
パーミッションの妥当性	/var/spool/postfix 配下のディレクトリの所有権やアクセス権の誤りを検出する
証明書・鍵ファイルの参照	smtpd_tls_cert_file や key_file に指定されたパスが無効（ファイルがない）場合に報告する
キューおよびサブディレクトリ構成	Postfixの各種コマンドが内部で利用する spool の構成が正しいか確認する

Postfixには、設定ファイルの整合性やアクセス権の問題を事前に検証するための便利な診断コマンドが標準で用意されています。設定を変更したあとや、「なんだか新設定がうまく反映されない」「挙動が不安定だな」と感じたときは、サービスを再読込する前にまずこの postfix check を叩く癖をつけておくと、潜在的な記述ミスを早期に見つけることができますよ。

ただし注意点として、このコマンドはあくまで「構文やファイルの権限レベルの検査専用」となっています。コマンドを実行して何もエラーが出なかった（無言で終わった）からといって、実際のSMTPの応答やメールの送受信テストまで保証してくれるわけではないので、最終的なテストはしっかりとメールを流して確認するようにしてくださいね。

まとめ

Postfixは柔軟で強力なMTAであり、シンプルな構成から複雑な配送ルールやセキュリティ設定まで、幅広い要件に対応できるよう設計されています。この記事で紹介した各種設定を適切に活用することで、安定したメール環境を構築し、スパムや不正利用を防止しつつ、効率的なメール配送が実現可能です。

ただし、現在のメール運用において到達率を高く保つには、Postfix単体の設定だけでは不十分です。特に主要なプロバイダーのガイドラインに対応するため、送信ドメイン認証の実装が必須となっています。

安定したシステムを構築するためには、Postfixの基本設定を正しく行うことに加え、これら外部連携やDNS設定、そして継続的なログ監視とトラブルシューティングの体制を整えることが不可欠です。

本記事で紹介した設定はあくまでPostfixの強力な機能の一部に過ぎません。公式のmanページや最新のセキュリティガイドラインを併せて参照し、ご自身の要件に最適な、信頼性の高いメールサーバ環境を構築してください。

【2026年最新】DMARCレポート解析ツール比較｜OSSとSaaSの違いや選び方を解説

菱沼憲司 — Thu, 21 May 2026 15:00:00 GMT

DMARCレポートの解析方法には、オープンソースソフトウェア（OSS）を使って解析環境を自社で構築する方法と、クラウド上で提供されるSaaSを利用する方法があります。導入に必要な作業や運用負担、利用できる機能、コストなどが異なるため、自社の運用体制や目的に合ったものを選ぶことが重要です。

本記事では、無料で利用できるOSSと、手軽に解析を始められるSaaSの違いを解説します。あわせて、代表的なOSSやSaaSを紹介し、サービスを選ぶ際に確認したいポイントについても解説します。

DMARCレポート解析ツールとは
- DMARCレポート解析ツールの役割
OSSとSaaSの違い
無料で使えるOSSのDMARC解析ツール
- parsedmarc
- dmarc-visualizer
SaaS型DMARCレポート解析ツールを選ぶ際の5つのポイント
SaaS型DMARCレポート解析ツール4選
DMARCレポート解析ツールに関するよくある質問
まとめ

DMARCレポート解析ツールとは

DMARCレポート解析ツールとは、受信側のメールサーバーから送られてくるDMARC集約レポート（RUAレポート）を解析し、メールの送信元や認証結果を確認しやすい形に整理するためのツールです。

DMARCレポートの種類や記載されている項目については、以下の記事で詳しく解説しています。

DMARCレポート解析ツールの役割

DMARC集約レポートはXML形式で記載され、複数の受信側メールサーバーから個別に送られてくるため、手動で集計・分析すると負担が大きくなりがちです。DMARCレポート解析ツールの主な役割は、これらのレポートを集約・可視化し、自社ドメインを使用してメールを送信している送信元や、SPF・DKIM・DMARCの認証結果を把握しやすくすることにあります。

解析結果から、正規のメールが認証に失敗していないか、把握していない送信元からメールが送信されていないかを確認し、必要に応じて送信環境や認証設定を見直すことで、正規メールへの影響を抑えながらDMARCポリシーの強化を進めることができます。

OSSとSaaSの違い

DMARCレポートを解析する方法には、OSSを利用して自社環境に解析基盤を構築する方法と、ベンダーがクラウド上で提供するSaaSを利用する方法があります。

OSSの特徴と向いているケース

多くのOSSは、ソフトウェアのライセンス費用をかけずに利用できます。自社の要件に合わせて構成を変更しやすく、DMARCレポートのデータを自社環境内で管理できる点が特徴です。また、特定のベンダーに依存しにくいため、ベンダーロックインのリスクも抑えられます。

一方で、解析環境の構築やアップデート、障害対応、セキュリティ対策などを自社で行う必要があります。そのため、インフラやセキュリティを内製できる専門チームがある場合に適しています。また、セキュリティポリシーやコンプライアンス上の理由から、DMARCレポートのデータを外部のSaaSに保存できない場合にも、OSSは有効な選択肢となります。

SaaSの特徴と向いているケース

SaaSの特徴は、自社で解析環境を構築する手間をかけずに利用を始められることです。多くのサービスには、解析結果を確認するためのダッシュボードや送信元の管理機能が備わっており、アラート通知機能やサポートを利用できるものもあります。

なお、一部のサービスでは個人向けや非商用向けの無料プランが提供されていますが、企業での利用には適していないため、有償プランの利用が一般的です。有償プランの場合でも、導入前に機能や操作性を確認できる無料トライアルが提供されていることがあります。

DMARCに詳しい担当者がいない場合や、解析環境を構築・運用するリソースを確保できない場合は、SaaSが適しています。また、短期間で解析を始めたい場合や、認証エラーの原因調査、送信元の整理、DMARCポリシーの強化についてベンダーの支援を受けたい場合にも有力な選択肢です。

自社で確保できる運用リソースや必要な機能、セキュリティ要件、サポートの必要性を踏まえ、適した方法を選ぶことが重要です。

主なOSS・SaaSの比較表

以下に、本記事で紹介するOSSとSaaSの特徴をまとめました。それぞれの詳細については、後の章で解説します。

名称	提供形態	無償/有償	自社での環境構築	サポート	向いているケース
parsedmarc	OSS	無償	必要	原則なし	Pythonやサーバー運用の知識があり、自社の要件に合わせて解析環境を柔軟に構築したい場合
dmarc-visualizer	OSS	無償	必要	原則なし	ElasticsearchやGrafanaなどを運用でき、OSSを使ってDMARCレポートを可視化したい場合
DMARC/25 Analyze	SaaS	有償、無料トライアルあり	不要	あり	国内ベンダーによる日本語対応や、シンプルな操作性を重視する場合
PowerDMARC	SaaS	有償、無料トライアルあり	不要	あり	DMARCに加え、SPF・DKIM・BIMIも一つのサービスで管理したい場合
dmarcian	SaaS	有償、無料トライアルあり	不要	あり	詳細なデータや高度な機能を活用し、複数ドメインや複雑な運用を管理したい場合
ベアメール迷惑メールスコアリング	SaaS	有償、無料トライアルあり	不要	あり	日本語での個別サポートを受けながら、送信元や認証エラーを確認・整理したい場合

※2026年8月時点の情報です。最新の内容は、各サービスの公式サイトでご確認ください。

無料で使えるOSSのDMARC解析ツール

ここでは、無料で利用できるOSSのDMARCレポート解析ツールとして、「parsedmarc」と「dmarc-visualizer」を紹介します。

parsedmarc

parsedmarcは、DMARCレポートを解析するためのオープンソースのPythonモジュールおよびコマンドラインツールです。

解析対象のレポートは、ローカルに保存したファイルやディレクトリを指定して読み込めます。また、IMAP、Microsoft Graph、Gmail APIを使用して、レポート受信用のメールボックスから添付ファイルを取得し、自動的に解析することも可能です。

解析結果は、JSON形式またはCSV形式で出力できます。さらに、Elasticsearch、OpenSearch、Splunk、PostgreSQLなどに保存し、KibanaやGrafanaなどのダッシュボードと組み合わせて可視化することもできます。parsedmarc単体では、解析結果を継続的に管理するためのWebダッシュボードは提供されないため、レポートの収集・保存・可視化に必要な環境を自社で構築・運用する必要があります。

参考：parsedmarc「parsedmarc documentation – Open source DMARC report analyzer and visualizer」https://domainaware.github.io/parsedmarc/（2026/8/7確認）

dmarc-visualizer

dmarc-visualizerは、複数のOSSを組み合わせて、DMARCレポートを解析・可視化する環境を構築するためのDocker Compose構成です。単体でDMARCレポートを解析するツールではなく、主に以下のコンポーネントで構成されています。

parsedmarc：DMARCレポートの解析
Elasticsearch：解析したデータの保存・検索
Grafana：解析結果の可視化

リポジトリで提供されているDocker Composeの設定を利用することで、これらのコンポーネントをコンテナとしてまとめて起動できます。

各ソフトウェアを個別に構築する場合と比べて、解析からデータ保存、可視化までの環境をまとめて用意しやすい点が特徴です。一方で、DockerやElasticsearch、Grafanaに関する知識が必要であり、アップデートや障害対応、アクセス制御なども自社で行う必要があります。

参考：GitHub「debricked/dmarc-visualizer: Analyse and visualize DMARC results using open-source tools」https://github.com/debricked/dmarc-visualizer（2026/8/7確認）

SaaS型DMARCレポート解析ツールを選ぶ際の5つのポイント

DMARCレポート解析ツールは、サービスによって機能や操作性、サポート内容、料金体系などが異なります。自社の運用に合わないサービスを選ぶと、導入後の運用負担や費用が想定以上に大きくなる可能性があるため、注意が必要です。

ここでは、ツールを選定する際に押さえておきたい5つのポイントを解説します。

項目	確認すべきポイント
機能	送信元IPアドレスの管理、フィルタリング・分析、アラート通知、レポート出力に対応しているか
運用・操作性	必要な情報を把握しやすいダッシュボードか、直感的に操作できるか、無料トライアルで操作性を事前に確認できるか
セキュリティ	自社のセキュリティ要件やチェックシートに対応できるか、データの保存先や管理方法に問題がないか
サポート	問い合わせ方法や対応時間、日本語対応の可否、導入・運用支援の有無
コスト	課金単位や基本料金に含まれる範囲、追加料金、最低契約期間などが自社の運用に合っているか

必要な機能が備わっているか

DMARCレポート解析ツールを選ぶ際は、自社の運用目的に必要な機能が備わっているかを確認しましょう。特に押さえておきたいのは、送信元IPアドレスの管理、フィルタリング・分析、アラート通知、レポート出力の4つです。

送信元IPアドレスの管理

ツール上でIPアドレスの管理ができるか確認します。例えば、IPアドレスにタグを付けて識別できるようにしたり、自社が管理しているIPアドレスのリストをアップロードしたりする機能があると、DMARCレポートの分析を進めやすくなるでしょう。

▶︎ベアメール迷惑メールスコアリングのDMARC分析機能では、送信元IPアドレスにタグを付けて管理することが可能です。

また、ツールが送信元IPアドレスに関する詳細な情報を提供できるかも確認します。例えば、IPアドレスの逆引き情報や、IPアドレスに関連づけられた国・地域情報、ブラックリストへの掲載有無などです。これにより、把握していない送信元や不審な送信元を特定しやすくなります。

フィルタリング・分析

特定の条件に基づいてレポートをフィルタリングできる機能があるかを確認します。例えばドメインやIPアドレス、認証結果などに基づいてレポートを抽出できれば、特定の条件を満たす送信環境の特定や、対応の優先順位の検討に役立つでしょう。

独自の切り口で分析する機能を備えているツールもあります。例えば、送信元IPアドレスの管理機能と組み合わせて、管理している送信環境別のエラー傾向を分析したり、把握できていないIPアドレスの中から送信数の多い環境を特定したりする機能などがあります。分析機能の有無に加えて、どのような切り口で分析できるかも確認することをおすすめします。

▶︎ベアメール迷惑メールスコアリングのDMARC分析機能では、エラーとなる原因、タグ付けした送信元IPアドレス別、把握できていないIPアドレスの3つの切り口でDMARC認証の問題を深掘りすることができます。

アラート通知

特定の条件を満たした際にアラートを通知する機能があるかを確認します。アラートを設定することで、毎日管理画面を確認しなくても、異常が発生した場合に検知することが可能になります。

また、アラートの条件をカスタマイズできる機能があると、特定の認証失敗や送信元からのメールに対して、個別にアラートを設定できるため便利です。

▶︎ベアメール迷惑メールスコアリングのDMARC分析機能では、指定した条件に該当した場合にアラートを通知できます。

レポート出力

解析結果をCSVやPDFなどの形式で出力できるか確認します。定期的な報告や社内共有に利用する場合は、出力できる項目や対象期間、ファイル形式が自社の用途に合っているかも確認しておきましょう。

管理画面が見やすく操作しやすいか

多くのDMARCレポート解析ツールは、分析結果をグラフやチャートなどの視覚的な形式で表示できる機能を備えています。その上で、知りたい情報を簡単に確認できるか、直感的に理解でき操作しやすい管理画面かなどは、実際に活用する上で重要な要素です。

無料トライアルが提供されているかも確認し、可能であれば契約前に実際の管理画面を見て、操作性を試しておくと安心です。

必要なセキュリティレベルを満たしているか

DMARCレポートには、送信元IPアドレスや認証結果など、メールの送信環境に関する情報が含まれます。そのため、ツールが自社のセキュリティ要件を満たしているかを確認することが重要です。

通信や保存データの暗号化、アクセス権限の設定、多要素認証への対応などに加え、データの保存先や保存期間も把握しておきましょう。社内でセキュリティチェックシートによる審査が必要な場合は、必要な情報をベンダーから提供してもらえるか、あらかじめ問い合わせておくとよいでしょう。

サポート体制が整っているか

ツールを活用してDMARCポリシーの強化を進めるためには、サポート体制も重要です。DMARCレポート解析ツールには海外製のサービスも多いため、まずは日本語によるサポートが受けられるか確認しましょう。

あわせて、無償サポートの範囲や問い合わせ方法、DMARCの導入やポリシー強化を支援する有償サービスの有無も確認しておくことをおすすめします。

料金体系が自社の運用に合っているか

ツールの選定にあたっては、コストパフォーマンスも重要な要素です。管理するドメイン数や解析対象となるメール通数、契約期間によって料金が変わり、想定外のコスト増につながることもあるため、課金条件を事前に把握しておきましょう。

ドメイン数

ツールで管理できるドメイン数に制限があるかを確認します。特に注意したいのが、サブドメインの扱いです。サービスによっては、サブドメインが別のドメインとしてカウントされ、追加料金が発生する場合があります。現在管理しているドメインだけでなく、今後追加する可能性も踏まえて比較しましょう。

解析対象となるメール通数

サービスやプランによっては、DMARCレポートに記録され、ツールで解析されるメールの通数に上限が設けられている場合があります。上限を超えると追加料金が発生したり、上位プランへの変更が必要になったりすることもあります。

大量のメールを配信している場合は、自社の配信規模に対応できるか、通数の増加によって料金がどの程度変わるかを確認しましょう。

契約期間

月単位または年単位など、契約期間や更新条件も確認します。年間契約によって料金が割安になるサービスもありますが、最低利用期間や途中解約の条件が設定されている場合があります。

SaaS型DMARCレポート解析ツール4選

代表的なDMARCレポート解析ツールとして、「DMARC/25 Analyze」「PowerDMARC」「dmarcian」「ベアメール迷惑メールスコアリング（DMARC分析機能）」の4つを紹介します。

前章で解説した5つのポイントに基づいて、各ツールの特徴を整理しています。自社に合ったツールを選ぶ際の参考にしてください。

選定ポイント	DMARC/25 Analyze	PowerDMARC	dmarcian	ベアメール迷惑メールスコアリング（DMARC分析機能）
機能	・時系列グラフ、円グラフによる可視化・ドメイン別、送信ホスト別の集計	・SPF・DKIM・BIMIなどをまとめて管理・詳細なフィルタリング・分析	・送信元IPアドレスの自動識別・タスク／イシューリスト	・タグによる送信元IPアドレス管理・エラーパターン、タグ別、なりすまし可能性の分析
運用・操作性	・UIカスタマイズが可能・無料トライアルあり	・高機能だが情報量が多い・操作には慣れが必要・無料トライアルあり	・エンジニア向けの画面設計・操作には慣れが必要・無料トライアルあり	・シンプルで直感的に操作しやすいUI ・無料トライアルあり
セキュリティ	・日本国内でのデータ保存・2段階認証に対応	・海外でのデータ保存・多要素認証、強制MFAに対応	・日本向け環境では日本国内でのデータ保存・二要素認証に対応・IPセーフリスト（Plus以上）/SSO（Enterprise）に対応	・日本国内でのデータ保存・二要素認証に対応（有償オプション）
サポート	・テクニカルサポートあり・導入や分析に関するコンサルティングは有償	・日本語のメールサポート・初期導入支援あり・利用後の分析支援は有償	・代理店による日本語サポート・月次報告や導入・運用支援サービスは有償	・初期導入支援・オンボーディング・プレミアムサポートは有償
コスト	・料金は個別見積もり	Basicプラン・月額：3,500円/年額：35,000円（税別）・対象ドメイン数：1 ・解析対象となるメール通数の上限：50万通/月・データ保存：1年間・サブドメイン課金：原則なし	Basicプラン・初期費用：20,000円/月額：20,000円・対象ドメイン数：2 ・解析対象となるメール通数の上限：10万通/月・データ保存：3ヶ月間・サブドメイン課金：不明	SILVERプラン・初期費用：50,000円/月額：24,000円・対象ドメイン数：1 ・解析対象となるメール通数の上限：無制限・データ保存：1年間・サブドメイン課金：原則なし

※2026年8月時点の情報です。最新の内容は、各サービスの公式サイトでご確認ください。

この記事の解説だけでは紹介しきれなかった、各サービスの費用や機能要件の詳細については、以下の資料で解説しています。DMARCレポート解析ツールを比較・検討する際に、ぜひお役立てください。

【この資料でわかること】

DMARCポリシー強化の必要性と進め方
OSSと有償ツールの違い
DMARCレポート解析ツールの選び方
【比較表付き】主要サービスの料金・機能詳細

「DMARCレポート分析ツールの選び方」ダウンロードページ | お役立ち資料 | ベアメール

DMARC/25 Analyze

DMARC/25 Analyzeは、実務に必要な機能に絞ったシンプルな操作性が特徴の国産ツールです。

機能

時系列グラフや円グラフを用いて、送信ドメイン認証の結果を可視化できます。ドメイン別や送信ホスト別で認証結果を集計することも可能です。

運用・操作性

ダッシュボードには表示されていない集計結果を追加したり、配置を変更したりできるUIのカスタマイズ機能を備えています。1ヶ月間の無料トライアルが用意されているため、導入前に実際の操作性を試すことが可能です。

セキュリティ

パスワード認証に加えて、ワンタイムURLによる2段階認証にも対応しています。データの保存先は日本国内のデータセンターに限定されています。

サポート

テクニカルサポートが提供されています。導入やレポート分析を支援するコンサルティングは、有償オプションとなります。

コスト

StandardプランとProfessionalプランがあり、利用できる機能が異なります。料金は個別見積もりとなります。

参考：twofive「DMARC/25 Analyze」https://www.twofive25.com/service/dmarc25.html （2026/8/7確認）

PowerDMARC

PowerDMARCは、DMARCだけでなく、SPFやDKIM、BIMIまで含めたメール認証をまとめて管理できるプラットフォームです。

機能

送信元や認証結果を条件別に絞り込める、詳細なフィルタリング・分析機能を備えています。プランによっては、SPF・DKIM・DMARCの管理やアラート通知、レポート出力なども利用できます。

運用・操作性

機能や表示される情報量が多いため、使いこなすには一定の慣れが必要です。国内代理店であるMailData版では管理画面が日本語化されており、1ヶ月間の無料トライアルも提供されています。

セキュリティ

多要素認証に対応しているほか、プランによってはSAMLを使用したシングルサインオンも利用できます。データの保存先は海外となります。

サポート

Mail Data版では、日本語による初期導入支援やメールサポートを受けられます。契約後のDMARCレポート分析などは、有償のプロフェッショナルサービスとして提供されています。

コスト

Basic・Plus・Premium・Platinumの4つのプランがあり、それぞれ解析対象となるメール通数や利用できる機能が異なります。データ保存期間は、全プラン共通で1年間です。サブドメインへの個別課金は原則として発生しません。

参考：PowerDMARC「無料DMARCアナライザー｜DMARC監視サービス」https://powerdmarc.com/ja/（2026/8/7確認）

参考：MailData「DMARCレポート分析サービス｜MailData – PowerDMARC国内正規代理店」https://maildata.jp/（2026/8/7確認）

dmarcian

dmarcianは、送信元の分類や認証結果の詳細な分析に対応したDMARC管理プラットフォームです。

機能

送信元IPアドレスの自動識別機能があり、DMARCレポートに含まれる送信元を自動的に分類し、メール通数やSPF・DKIM・DMARCの認証結果を把握できます。また、運用上の課題を可視化するタスクリストやイシューリストも備わっています。

運用・操作性

DMARCの基礎知識があるエンジニア向けの画面設計となっています。30日間の無料トライアルが提供されています。

セキュリティ

二要素認証に対応しています。Plusプラン以上ではアクセス元IPを制限するIPセーフリスト、Enterpriseプランではシングルサインオンも利用可能です。日本向けの環境では、データは日本国内に保存されます。

サポート

国内代理店のBrandKeeperでは、日本語によるサポートを提供しています。DMARCの導入やポリシー強化を支援するコンサルティングサービスは有償となります。

コスト

Basic・Plus・Enterpriseの3つのプランがあり、DMARC分析の対象ドメイン数や月間の解析対象となるメール通数、利用できる機能が異なります。データ保存期間は、Basicプランで3ヶ月間、Plusプランで1年間、Enterpriseプランでは無制限となります。

参考：dmarcian「DMARC管理プラットフォーム：今すぐメールドメインのセキュリティを強化しましょう – dmarcian」https://dmarcian.com/ja/dmarc-management-platform/（2026/8/7確認）

参考：BrandKeeper「DMARCレポート解析ツール Dmarcian – BrandKeeperは日本正規代理店として利用サポートいたします」https://brandkeeper.jp/dmarcian/（2026/8/7）

ベアメール迷惑メールスコアリング（DMARC分析機能）

ベアメール迷惑メールスコアリングのDMARC分析機能は、送信元や認証エラーを確認しやすい管理画面と、専門知識のない担当者でもポリシー引き上げを実現できる手厚いサポートが特徴の国産ツールです。

機能

独自の国内向けデータベースを活用し、送信元IPアドレスから国内のメール配信サービスなどを判別できます。また、タグによる送信元IPアドレスの管理機能や、認証エラーの原因を切り分ける分析機能も備えています。

運用・操作性

専門知識がなくても認証状況を直感的に把握しやすい、シンプルなUI・ダッシュボードを提供しています。無料トライアルも用意されているため、導入前に実際の画面や操作性を確認できます。

セキュリティ

オプションで二要素認証に対応しています。データは日本国内のデータセンターに保存されます。

サポート体制

すべてのプランに、初期導入支援とオンボーディングが含まれています。利用開始後は、メールや電話、管理画面から問い合わせが可能です。また、DMARCレポートから課題を抽出し、ポリシー強化に向けた対応を支援するプレミアムサポートが有償で提供されています。

コスト

SILVER・GOLD・PLATINUMの3つのプランがあり、DMARC分析の対象ドメイン数や利用できる機能が異なります。すべてのプランで、月間の解析対象となるメール通数に上限はなく、データ保存期間は1年間です。また、組織ドメインのDMARCレポートに含まれるサブドメインについては、追加料金は発生しません。

DMARCレポート解析ツールに関するよくある質問

DMARCレポート解析ツールについて、担当者からよく寄せられる質問にお答えします。ツールの選定や社内検討を進める際の参考にしてください。

Q.無料のOSSだけで運用は可能ですか？

自社で解析環境を構築・保守できる体制や、DMARCレポートを読み解く知識があれば、無料のOSSだけで運用するのも一つの選択肢です。ただし、複数ドメインの管理や認証エラーの調査、ポリシー強化を効率的に進めたい場合は、自動分析機能やサポートを備えたSaaSの方が適しているといえるでしょう。

Q.海外製ツールと国産ツールでは、どのような違いがありますか？

海外製ツールは機能が豊富で、グローバルな実績を持つものが多くなっています。一方、国産ツールは日本語でのサポートや、国内企業の運用実態を踏まえた支援を受けやすいという利点があります。

DMARC運用では社内の関係部門との調整が必要になることが多いため、日本語で相談しながら進められることは運用面での負担軽減につながります。どちらが適しているかは、自社の体制や求める支援範囲によって判断することが重要です。

Q.ポリシー強化が完了すれば、ツールは不要になりますか？

DMARCポリシーの強化後も、新たな送信元の追加や設定変更などによって、送信環境は変化します。認証失敗や把握していない送信元を検知するため、ポリシー強化後もDMARCレポート解析ツールを利用し、継続的に監視することが重要です。

まとめ

DMARCレポート解析ツールには、OSSを使って自社で環境を構築する方法と、SaaSを利用する方法があります。それぞれ運用負担や機能、サポート、料金が異なるため、自社の体制や目的に合ったツールを選ぶことが重要です。

導入後は解析結果をもとに認証エラーや送信元を継続的に確認し、DMARCポリシーの強化と安定した運用につなげましょう。

ワンタイムパスワードのメールが届かない原因とは｜受信者・送信者の対策をわかりやすく解説

菱沼憲司 — Thu, 21 May 2026 15:00:00 GMT

ワンタイムパスワードは、Webサービスへのログインや決済時など、本人認証の方法として広く利用されています。ワンタイムパスワードは、通常メールやショートメッセージで通知されますが、そのメールが届かないトラブルが頻発しています。

この記事では、受信者側・送信者側それぞれの視点から、ワンタイムパスワードのメールが届かない原因と具体的な対処法を詳しく解説します。

【受信者向け】ワンタイムパスワードのメールが届かない5つの原因と対処法
【送信者向け】ワンタイムパスワードのメールが届かない4つの原因と対処法
それでもワンタイムパスワードのメールが届かない場合
まとめ

【受信者向け】ワンタイムパスワードのメールが届かない5つの原因と対処法

ワンタイムパスワードのメールが受信トレイに届かない場合、受信設定に問題がある可能性があります。まずは慌てずに、次の5つのポイントを確認してみましょう。

原因1：迷惑メールフォルダや別タブに振り分けられている

迷惑メールの増加に伴い、メールサービスや携帯キャリアは迷惑メール対策を強化しています。それによりワンタイムパスワードのようなメールであっても、迷惑メールフォルダに振り分けられてしまうことがあります。また、Gmailの「プロモーション」タブのように、受信トレイ以外に分類されてしまうケースも少なくありません。まずは受信トレイ以外の場所にメールが届いていないか確認しましょう。

もし迷惑メールフォルダに入っていた場合は、そのメールを開き「迷惑メールではないことを報告」をクリックすることで、次回以降、受信トレイに届きやすくなります。

※詳細な設定は各メールサービスのマニュアルをご覧ください。

原因2：受信拒否の設定によってブロックされている

自分で行った拒否設定や、セキュリティのために設定したメールフィルタの強度が原因で、ワンタイムパスワードのメールが届かないことがあります。

この場合、サービスの送信元ドメイン（例：@example.com）を許可リスト（指定受信リスト）に追加してみてください。これを設定することで、個別の拒否設定やメールフィルタの影響をまとめて回避し、メールを受信できるようになります。

原因3：登録したメールアドレスに誤りがある

サービスに登録したメールアドレス自体が間違っている可能性もあります。特に、「.」（ピリオド）と「,」（カンマ）の打ち間違い、「co.jp」と「ne.jp」の混同、アルファベットの全角・半角の違いなどはよくある入力ミスです。サービスのアカウント情報ページなどで、登録しているメールアドレスに間違いがないか改めて確認してください。

原因4：メールの自動転送が設定されている

設定した自動転送のルールがワンタイムパスワードのメールに適用されてしまい、受信トレイに届かないケースも考えられます。設定画面を確認し、該当する転送設定があった場合は、転送先のメールアドレスにメールが届いていないか確認してください。

原因5：メールボックスの容量が上限に達している

メールボックスの保存容量がいっぱいになっていると、新しいメールが受信できなくなります。特に、同じメールアドレスを長年利用していたり、無料プランのメールサービスを利用していたりすると、容量上限に達しやすい傾向があります。不要なメールや容量の大きいメールを削除して、空き容量を確保してください。

それでも解決しない場合は送信側へ問い合わせる

これまでのポイントを確認しても解決しない場合は、送信者側に問題がある可能性があるため、直接問い合わせてみることをおすすめします。その際、届かなかった日付や時間を具体的に伝えると、原因の調査がスムーズに進みます。

【送信者向け】ワンタイムパスワードのメールが届かない4つの原因と対処法

ユーザにワンタイムパスワードが届かないと、サービス自体の信頼を損なう恐れがあります。ここでは、送信者が確認すべき4つの原因と、その解決策を解説します。

原因1：送信ドメイン認証（SPF・DKIM・DMARC）が設定されていない

SPF・DKIM・DMARCをはじめとする送信ドメイン認証は、送信元メールアドレスの詐称（なりすまし）を防ぐための重要な技術です。これらの設定がされていないサーバーから送られたメールは、受信サーバーから信頼性に欠けるメールと判断され、迷惑メールフォルダに振り分けられたり、受信を拒否されたりする恐れがあります。

特にGmailはすべての送信者にSPFまたはDKIMの設定を、1日あたり5,000通以上のメールを送信する場合はDMARCの設定を必須条件としており、条件を満たしていない環境からのメールの受信を拒否すると発表しています。

対策：自社ドメインのDNSに、SPF・DKIM・DMARCレコードが正しく設定されているか確認し、されていない場合は早急に設定しましょう。SPF・DKIM・DMARCのレコードの確認方法は次のブログをご参照ください。

SPFの確認方法は？設定の確認手順や認証結果の見方、失敗する原因を解説｜ベアメールブログ

DKIMの確認方法は？設定の確認手順や認証結果の見方、失敗する原因を解説｜ベアメールブログ

DMARCレコードの書き方は？設定・確認方法や設定例も解説｜ベアメールブログ

原因2：送信元IPアドレスの評価が低い

ISPや携帯キャリア、メールサービスのプロバイダなどは、メールを受信する際にそのメールの送信者が信頼できるのか確認するため、送信元IPアドレスの信頼性・評判を「レピュテーション」と呼ばれる仕組みを利用してチェックしています。

送信元のIPレピュテーションが低い場合は、疑わしい送信者としてメールが届かない可能性が高まります。IPレピュテーションが低くなってしまうケースと、対策は次のとおりです。

ケース1：クラウドサービスが提供するIPアドレスの再利用に伴う影響

クラウドサービスで割り当てられたIPアドレスは、過去に別の利用者がスパム配信に使用していた可能性があります。自社がそのIPで迷惑メールを送信していなくても、割り当てられたIPアドレスが既に受信サーバー側でブラックリストに登録されていれば、メールが届かないという事態が起こり得ます。

対策：ブラックリストへ解除申請を行いましょう。ブラックリストの解除申請方法については次のブログを参考にしてみてください。

ブラックリスト登録されたメールの確認・解除方法について｜ベアメールブログ

Spamhausの解除申請方法｜ブラックリスト登録の原因と対策も解説｜ベアメールブログ

ケース2：新しい専用IPから急に大量送信している

クラウドサービスで専用の固定IPアドレスを新しく取得した場合や、新しいドメインを使い始めたばかりの場合、IPアドレス自体に過去の送信実績がない、あるいは極めて少ないため、受信サーバー側ではその送信者を安全と判断する材料がありません。このような信頼が確立されていないIPアドレスから突然大量のメールを送られると、受信側はスパム攻撃とみなして配送を制限したり、ブロックしたりします。これはIPアドレスがクリーンであっても発生する仕様上の挙動です。

対策：IPウォームアップ（徐々に配信数を増やしてIPアドレスの評価を高める手法）を実施してください。IPウォームアップの詳細は次のブログを参考にしてみてください。
IPウォームアップとは？ IPレピュテーションを向上させるためのポイントと具体的な手順｜ベアメールブログ

原因3：ドメインの評価が低い

IPアドレスと同様に、送信に使用するドメイン自体も、受信サーバー側で「ドメインレピュテーション」という指標で評価されています。

運用期間が短く送信実績が不足しているドメインや、過去にスパム配信に悪用された履歴があるドメインは、送信元としての信頼性が低いと見なされます。こうしたドメインから一度に大量のメールを送信すると、送信内容の正当性にかかわらず、受信プロバイダ側でスパムとして検知され、ブラックリスト登録や配送拒否を招く原因となります。

対策：新しいドメインを本格運用する前に、まずは少量のメール送信から始め、数週間かけて段階的に送信量を増やしましょう。

原因4：メールの形式や内容がスパムと判定されている

受信サーバーは、メールの件名、本文、HTML構造などを解析し、過去のスパムメールのパターンと照らし合わせて配信の可否を判断しています。ワンタイムパスワードのメールの本文や件名に含まれるキーワードなどが原因で、受信側のサーバーから迷惑メールと判定され、ブロックされることがあります。

緊急性の強調するワードが件名に入っている

「重要」「緊急」「即時」といった緊急性を過度に強調するキーワードは、フィッシング詐欺やスパムメールに多用される傾向があります。そのため、受信サーバーのスパムフィルターに検知されやすく、メールが拒否されたり迷惑メールフォルダに振り分けられたりするリスクが高まります。

対策：サービス名と用途（例：「[サービス名] ワンタイムパスワードの発行」）を具体的に記載し、正当性を担保します。

短縮URLを利用している

短縮URLは、リンク先のドメインを隠すことができるため、悪意のあるサイトへの誘導によく使われます。そのため、短縮URLが含まれているだけで受信拒否されることがあります。

対策：リンク先が明示される独自のドメインURLをそのまま記載してください。

送信者名（From表示名）に不備がある

「info」や「administrator」といった汎用的すぎる名称や、サービス名と無関係な名称を送信者名に設定している場合、受信側で送信元の特定が難しくなり、なりすましメールの疑いを受けやすくなります。

対策：ユーザが事前に認知している正確なサービス名や会社名を送信者名に設定してください。スパム判定のチェックポイントの詳細は次のブログを参考にしてみてください。

迷惑メールだと判定されてしまう理由とは？スパム判定のチェックポイントと回避方法を解説｜ベアメールブログ

それでもワンタイムパスワードのメールが届かない場合

ここまで解説したように、ワンタイムパスワードのメールをきちんと届けるためには、送信ドメイン認証の設定やIPレピュテーションの管理などの対応が必要です。しかし、メールの専門知識が求められるうえ、時間も工数もかかるため、自社のみで完全に対応するのは決して容易ではありません。

そこで、調査や対策にかかるリソースを最小限に抑えるために、「ベアメール迷惑メールスコアリング」を活用して、届かない原因を特定することをおすすめします。

迷惑メールスコアリングにテストメールを送信するだけで、送信環境や本文に対する網羅的な診断を受けられ、メールの問題点を可視化することができます。現在専門家による無料診断・相談会を受け付けていますので、メールの不達にお悩みの方はぜひお申し込みください。

送ったメールが届かない原因を専門家が無料診断 | ベアメール

まとめ

ワンタイムパスワードがメールで届かない問題は、受信者側の設定だけでなく、送信者側の技術的な不備に起因するケースが多々あります。

ワンタイムパスワードの不達は、ユーザ体験の著しい低下や離脱を招くだけでなく、サービスの信頼性そのものを損なう大きなリスクです。自社の配信環境を適切に構築・運用し、常に高い到達率を維持することは、サービス運営における重要な責務と言えます。

もし、不達の原因が特定できずお困りであれば、まずはベアメールの迷惑メールスコアリングで現状を可視化することから始めてみてはいかがでしょうか。

AWS SESのカスタム MAIL FROM設定とは？エンベロープFromを独自ドメインにする方法を解説

菱沼憲司 — Sun, 10 May 2026 15:00:00 GMT

AWS SESを利用すると、サーバーを自前で構築・運用することなくメールを送信できます。ただし、初期状態ではエンベロープFrom（Return-Path）にamazonses.comドメインが設定されるため、SPF認証に使用されるドメインとヘッダFromドメインが一致せず、DMARCにおけるSPFアライメントを満たしにくい状態となります。そのため実運用では、独自ドメインをエンベロープFromとして設定する「カスタム MAIL FROM」の利用が推奨されます。

本記事では、AWS SESの基本設定から、カスタム MAIL FROMを利用したエンベロープFromの設定方法まで解説します。

AWS SES（Amazon Simple Email Service）とは
AWS SESでメールを送信するための基本設定
カスタム MAIL FROMドメインの設定
- 1. カスタムドメインの設定
- 2. 送信テスト
サンドボックスの解除
まとめ

AWS SES（Amazon Simple Email Service）とは

AWS SES（Amazon Simple Email Service）は、AWSが提供するフルマネージド型のメール送信サービスです。SMTPおよびAPI（HTTPS）でメールを送信でき、PostfixなどのMTAを別途構築・運用する必要がありません。

AWSの各種サービスと連携しやすい点が特徴です。また、バウンスや苦情の管理など、メール配信に必要な機能があらかじめ提供されています。

AWS SESでメールを送信するための基本設定

AWS SESはリージョン単位で独立しているため、複数リージョンで利用する場合は、それぞれ設定が必要です。どのリージョンでも、基本的な設定手順は共通しています。

なお、SESは初期状態では「サンドボックス」と呼ばれる制限付き環境で提供されます。この状態では、送信先のメールアドレスやドメイン、送信通数に制限があるため、実運用で外部にメールを送信するには、後述するサンドボックスの解除が必要です。

本章では、AWS SESでメールを送信するための基本設定として、メールアドレスおよびドメインの登録、SMTPアカウントの作成、送信テストの手順を解説します。

1. メールアドレスの設定

まずは、送信元として利用するメールアドレスを登録します。AWSマネジメントコンソールでSESを開き、左側メニューの「ID」を選択し、「IDの作成」をクリックします。

IDタイプで「メールアドレス」を選択し、検証に利用するメールアドレスを入力します。

IDタイプ：メールアドレス
Eメールアドレス：登録するメールアドレス

入力後、「IDの作成」をクリックします。

作成直後は、ステータスが「検証保留中」と表示されます。

登録したメールアドレス宛に、「Amazon Web Services – Email Address Verification Request in region ＜リージョン名＞」という件名のメールが届きます。メール内のURLへアクセスすると、ステータスが「検証済み」に変わります。

これで、登録したメールアドレスをAWS SESで利用できるようになります。

2. ドメインの登録

次に、送信元ドメインを登録します。メールアドレスと同様に、左側メニューの「ID」を選択し、「IDの作成」をクリックします。

IDタイプで「ドメイン」を選択し、利用するドメインを入力します。

カスタム MAIL FROMドメインの設定は後から行うため、「カスタム MAIL FROMドメインの使用」にはチェックを付けずに進めます。

IDタイプ：ドメイン
DKIM の詳細設定：Easy DKIM（※今回は、SESで管理されるDKIM鍵を利用する「Easy DKIM」を使用します）
DKIM 署名キーの長さ：RSA_2048_BIT
DKIM 署名：有効化

入力後、「IDの作成」をクリックします。

作成直後は、メールアドレス登録時と同様に、ステータスが「検証保留中」と表示されます。

ドメインを検証するには、画面に表示されるDKIM用のCNAMEレコードをDNSへ追加する必要があります。

表示されたCNAMEレコードをDNSに登録し、AWS側で確認されると、ステータスが「検証済み」に変わります。早ければ数分で完了しますが、最大72時間程度かかることもあります。

参考：Amazon Simple Email Service デベロッパーガイド「Amazon SES の ID の作成と検証」https://docs.aws.amazon.com/ja_jp/ses/latest/dg/creating-identities.html（2026/5/7確認）

※実運用では、DKIMだけでなく、SPFやDMARCなどの送信ドメイン認証もあわせて設定することを推奨します。なお、カスタムMAIL FROMドメインを利用する場合は、設定したサブドメインに対してSPFレコードの設定が必要です。

3. SMTPアカウントの作成

IDの検証が完了したら、SMTPアカウントを作成します。

AWS SESでは、SMTP認証にIAM（AWS Identity and Access Management）ベースで管理される認証情報を利用します。IAMコンソールから直接設定することも可能ですが、SESにはSMTPアカウントを簡単に作成できる画面が用意されているため、今回はそちらで設定を行います。

左側のメニューから「SMTP設定」を選択し、「SMTP認証情報の作成」をクリックします。

ユーザ名は自動で入力されますが、任意の名前に変更することも可能です。今回はデフォルトのまま、「ユーザーの作成」をクリックします。

作成が完了すると、SMTPユーザ名とSMTPパスワードが表示されます。

これらはSMTP認証に必要な情報です。万が一流出すると、第三者による不正なメール送信などに利用される可能性があるため、取り扱いには十分に注意して下さい。

これで、AWS SESからメールを送信する準備が整いました。

4. 送信テスト

ここまでの設定が完了したら、実際にメールを送信して動作を確認します。

今回は、コマンドラインツール「swaks」を利用して送信テストを行います。SESは接続タイムアウトが早いため、telnetなどで手動入力するよりも、swaksを利用する方がスムーズです。

SMTP接続

※<>の部分はご自身の設定値に置き換えてください。

swaks --server email-smtp.ap-northeast-1.amazonaws.com:587 --tls --auth LOGIN --auth-user "<SMTPアカウント>" --auth-password "<SMTPパスワード>" --from "<送信元メールアドレス>" --to "<宛先メールアドレス>" --header "From: <送信元メールアドレス>"

主なパラメータは以下の通りです。

パラメータ	内容
server	SMTP接続先サーバー
tls	TLS接続を有効化
auth-user	SMTPアカウント
auth-password	SMTPパスワード
from	送信元メールアドレス（エンベロープFrom）
to	宛先メールアドレス

送信に成功すると、以下のように「250 Ok」が表示されます。

250 Ok xxxxxxxxxxxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-xxxxxx

次のようなメッセージが表示される場合は、未検証のドメインやメールアドレスを利用している可能性があるため、コマンドを見直してみてください。

554 Message rejected:

メールが正常に届いたら、受信したメールのヘッダも確認してみます。すると、Return-Pathに以下のようなamazonses.comドメインが設定されていることがわかります。

Return-Path: <0119019d51fa8bfd-55d461f4-c251-4f45-8b36-775a5cd00403-000000@ap-northeast-1.amazonses.com>

Return-Path は、バウンスメールの返送先として利用されるアドレスです。通常は、SMTP通信時に指定したエンベロープFromがReturn-Pathとして利用されます。しかし、AWS SESでは初期状態のままだと、SMTP接続時にエンベロープFromを指定しても、受信時にはamazonses.comドメインへ書き換えられます。

実運用では、DMARCにおけるSPFアライメントの観点から、独自ドメインのエンベロープFromを利用することが推奨されます。そのためには、次章で解説する「カスタム MAIL FROMドメイン」の設定が必要です。

カスタム MAIL FROMドメインの設定

AWS SESでは、「カスタム MAIL FROMドメイン」を設定することで、独自ドメインをエンベロープFrom（Return-Path）として利用できるようになります。

ここでは、カスタム MAIL FROMドメインの設定手順を解説します。

1. カスタムドメインの設定

AWSマネジメントコンソールでSESを開き、左側メニューの「ID」を選択します。登録済みのドメインをクリックすると、詳細画面が表示されます。

画面を下にスクロールし、「カスタム MAIL FROM ドメイン」の「編集」をクリックします。

「カスタム MAIL FROM ドメインの使用」にチェックを入れ、「MAIL FROMドメイン」にサブドメインを入力して、「変更の保存」をクリックします。

※既存のメール運用との競合を避けるため、AWS SESではルートドメインの使用は推奨されておらず、サブドメインを利用する構成が一般的です。

設定を保存すると、ステータスが「保留中」と表示されます。カスタム MAIL FROMドメインを有効化するには、画面に表示されるDNSレコードを追加する必要があります。

表示されたMXレコードおよびTXTレコードをDNSへ登録し、AWS側で確認されると、ステータスが「成功」に変わります。早ければ数分で検証が完了しますが、最大72時間程度かかることもあります。

2. 送信テスト

カスタム MAIL FROMドメインの設定が完了したら、実際にメールを送信し、Return-Pathが指定したサブドメインになっていることを確認します。

ここでも、コマンドラインツール「swaks」を利用して送信テストを行います。実行するコマンドは、基本設定の送信テストで使用したものと同じです。

swaks --server email-smtp.ap-northeast-1.amazonaws.com:587 --tls --auth LOGIN --auth-user "<SMTPアカウント>" --auth-password "<SMTPパスワード>" --from "<送信元メールアドレス>" --to "<宛先メールアドレス>" --header "From: <送信元メールアドレス>"

※<>の部分はご自身の設定値に置き換えてください。

Fromパラメータ（–fromおよび–header “From:”）には、検証済みドメインのメールアドレスを指定します。Return-Path には、カスタム MAIL FROMに設定したサブドメインがSESによって自動的に設定されます。

メールが正常に届いたら、受信したメールのヘッダを開き、「Return-Path:」が指定したサブドメインになっていることを確認してください。

サンドボックスの解除

前述した通り、初期状態のAWS SESは「サンドボックス」と呼ばれる制限付き環境で提供されています。この状態では、メールを送信できる宛先が検証済みのメールアドレスやドメインに限定されます。

実際のユーザなど、任意の宛先へメールを送信するには、AWSマネジメントコンソールからAWSサポートへ「本稼働アクセス（サンドボックスの解除）」をリクエストする必要があります。

リクエスト時には、スパム送信防止の観点から、主に以下のような内容を確認されます。

どのようなメールを送信するのか（ユースケース）
送信先のメールアドレスリストをどのように取得したのか
バウンス（送信エラー）や苦情（迷惑メール報告）へどのように対応するのか

AWS側での審査には時間がかかることがあります。本番稼働のスケジュールが決まっている場合は、設定や送信テストが完了した段階で、早めに解除リクエストを行うことをおすすめします。

参考：Amazon Simple Email Service デベロッパーガイド「本稼働アクセスのリクエスト (Amazon SES サンドボックスからの移行)」https://docs.aws.amazon.com/ja_jp/ses/latest/dg/request-production-access.html（2026/5/7確認）

まとめ

本記事では、AWS SESの基本設定から、カスタム MAIL FROM ドメインを利用したエンベロープFromの設定方法まで解説しました。

AWS SESは、サーバーを自前で構築・運用することなくメールを送信できる便利なサービスです。ただし、初期状態ではReturn-Pathにamazonses.comドメインが使用されるため、実運用ではカスタム MAIL FROMドメインの設定が推奨されます。

カスタム MAIL FROM ドメインを設定することで、独自ドメインをエンベロープFrom（Return-Path）として利用でき、DMARCにおけるSPFアライメントを確保しやすくなります。

AWS SESを利用したメール配信環境を構築する際は、ぜひ参考にしてみてください。

BIMIに商標登録は必要？手順や期間・費用を解説

菱沼憲司 — Sun, 10 May 2026 15:00:00 GMT

BIMIを導入する際、「ロゴの商標登録は必要なのか」「どのような手続きが必要なのか」と疑問に思う方もいるでしょう。

BIMIでは、利用する証明書によって、ロゴの商標登録が必要になる場合があります。商標登録を行う場合、BIMI導入をスムーズに進めるために、登録までにかかる期間や費用を考慮しておくことが重要です。

本記事では、BIMIと商標登録の関係を整理したうえで、VMC取得に向けてロゴを商標登録する手順や、必要な期間・費用、よくある疑問について解説します。

BIMI導入に商標登録は必要？
- VMCを取得する場合は商標登録が必要
- CMCなら商標登録されていないロゴも利用できる
VMC取得に向けてロゴを商標登録する手順
商標登録にはどれくらいの期間が必要？
商標登録にかかる費用
- 特許庁へ支払う費用
- 弁理士へ依頼する場合の費用
VMCと商標登録に関するよくある疑問
BIMIの導入をスムーズに進めるなら
まとめ

BIMI導入に商標登録は必要？

BIMIを導入する際、必ずしもロゴの商標登録が必要になるわけではありません。商標登録の要否は、BIMIで利用する証明書の種類によって異なります。

BIMIで利用される主な証明書には、VMC（Verified Mark Certificate）とCMC（Common Mark Certificate）があります。ここでは、それぞれの証明書を取得するために必要なロゴの要件について解説します。

BIMIの仕組みや導入手順については、以下の記事で詳しく解説しています。
BIMIとは？仕組みや設定方法、BIMIレコードの書き方を解説｜ベアメールブログ

VMCを取得する場合は商標登録が必要

VMCは、BIMIで表示するロゴと組織との関係を第三者機関が確認して発行する電子証明書です。

VMCを取得するには、対象となるロゴが承認された商標登録機関に登録されている必要があります。そのため、BIMIでVMCを利用したいものの、表示したいロゴをまだ商標登録していない場合は、VMCの申請に先立って商標登録を進める必要があります。

VMCの取得に必要な要件や、申請から発行までの流れについては、以下の記事で詳しく解説しています。
BIMIに必要なVMC（認証マーク証明書）とは？取得方法やCMCとの違いを解説｜ベアメールブログ

CMCなら商標登録されていないロゴも利用できる

CMCも、BIMIで使用するロゴと組織との関係を第三者の認証局が確認して発行する電子証明書です。商標登録がないロゴでも、1年以上使用している実績があることなど、所定の要件を満たせば取得できます。そのため、ロゴを商標登録していない場合でも、CMCを利用してBIMIを導入できる可能性があります。

ただし、VMC・CMCへの対応状況は、受信側のメールサービスによって異なります。2026年9月時点で、VMCにはGmail・au・docomoなどの主要サービスが対応している一方、CMCへの対応を正式に公表しているのはGmailのみです。

BIMIによるロゴ表示をより幅広い受信環境で実現したい場合は、VMCの利用を検討するとよいでしょう。

VMC取得に向けてロゴを商標登録する手順

VMCを取得するためにロゴの商標登録が必要な場合は、BIMIで使用するロゴを決めたうえで、商品・役務の指定や類似商標の調査、特許庁への出願などを進めます。

ここでは、VMC取得に向けてロゴを商標登録する際の基本的な手順を解説します。

参考：特許庁「初めてだったらここを読む～商標出願のいろは～」https://www.jpo.go.jp/system/basic/trademark/index.html（2026/9/4確認）

1. BIMIで使用するロゴを決める

まずは、BIMIで表示するロゴを決めます。

企業やブランドで使用されるロゴには、図形を中心としたものや文字をデザインしたもの、それらを組み合わせたものなどがあります。

ロゴの種類	主な構成要素	説明
シンボルマーク	図形	企業やブランドを象徴する図形・アイコン
ロゴタイプ	文字	社名やブランド名などの文字をデザインしたもの
ロゴマーク	図形＋文字	シンボルマークとロゴタイプを組み合わせたもの

VMCの申請時には、提出したロゴが商標登録機関に登録されているマークと一致しているか確認されます。そのため、BIMIで実際に使用したいロゴをあらかじめ決めたうえで、そのロゴを商標として登録することが重要です。

2. 商品・役務を指定する

商標登録では、ロゴをどのような商品・サービスに使用するのかを指定して出願します。このとき指定する商品を「指定商品」、サービスを「指定役務」と呼びます。

商品・役務は、内容に応じて第1類から第45類までの「区分」に分類されています。商標登録を行う際には、まず区分を選択し、その中から実際に商標を使用する商品・役務を具体的に指定します。

商標権の範囲は、出願時に指定した具体的な商品・役務によって決まります。選択した区分に含まれるすべての商品・サービスについて商標権が認められるわけではありません。そのため、自社がどの商品・サービスでロゴを使用するのかを整理したうえで、適切な商品・役務を指定することが重要です。

また、商標登録の出願料や登録料は区分数に応じて変わります。必要以上に多くの区分を指定すると費用も増えるため、現在の事業内容や今後の使用予定を踏まえて検討しましょう。

指定商品・指定役務や区分の判断が難しい場合は、弁理士などの専門家に相談する方法もあります。

3. 類似する商標がないか調査する

登録予定のロゴと似た商標がすでに出願・登録されていないか、特許情報プラットフォーム「J-PlatPat」を使用して調査します。

似た商標がすでに登録されている場合でも、必ずしも登録できないわけではありません。商標の類似性に加えて、指定商品・指定役務が同一または類似しているかなどを踏まえて判断されます。

そのため、類似する商標が見つかった場合は、商標そのものだけでなく、その商標で指定されている商品・役務も確認することが重要です。J-PlatPatでは、各商標で指定されている商品・役務や区分を確認できます。

類似性の判断が難しい場合は、弁理士などの専門家に相談することも検討しましょう。

4. 特許庁へ出願する

商品・役務の指定や類似商標の調査が完了したら、商標登録願を作成し、特許庁へ出願します。

商標登録の出願方法には、インターネットを利用する「電子出願」と、書類を郵送または特許庁の窓口に持参する「書面出願」があります。

項目	電子出願	書面出願
提出方法	インターネット出願ソフトからオンラインで提出	郵送または特許庁の窓口へ持参
必要なもの	電子証明書、対応するPC、インターネット出願ソフト	所定の様式で作成した書類
電子化手数料	不要	基本料2,400円＋書面1枚につき800円
特徴	入力チェック機能を利用でき、オンラインで手続きを完結できる	電子証明書やインターネット出願ソフトの準備が不要

電子出願では、特許庁が提供する「インターネット出願ソフト」を使用します。事前に電子証明書の取得やソフトのセットアップなどが必要ですが、書面出願で発生する電子化手数料はかかりません。

書面出願では、作成した書類を郵送または特許庁の窓口へ提出します。提出した書類を電子化するための手数料として、基本料2,400円に、書面1枚あたり800円を加えた費用がかかります。

自社の環境や手続きのしやすさを踏まえて、出願方法を選択しましょう。

5. 審査を受け、登録料を納付する

出願後は、特許庁による審査が行われます。審査では、登録要件を満たしているか、先に登録・出願されている商標と類似していないかなどが確認されます。

審査の結果、登録できない理由があると判断された場合は、「拒絶理由通知書」が送付されます。内容に応じて、意見書を提出したり、指定商品・指定役務を修正したりすることで、拒絶理由を解消できる場合があります。

審査を通過すると「登録査定」が送付されます。登録査定を受けた後、30日以内に登録料を納付すると商標が設定登録され、商標権が発生します。

登録料については「商標登録にかかる費用」で後ほど詳しく解説します。

参考：特許庁「商標の拒絶理由通知書を受け取った方へ」https://www.jpo.go.jp/system/basic/otasuke-n/shohyo/kyozetsu/（2026/9/4確認）

参考：特許庁「商標の登録査定を受け取った方へ」https://www.jpo.go.jp/system/basic/otasuke-n/shohyo/satei/（2026/9/4確認）

商標登録にはどれくらいの期間が必要？

商標登録には、出願から登録まで一定の期間がかかります。

特許庁によると、2024年度は、商標登録の出願から最初の審査結果が通知されるまで平均6.8ヶ月、権利化まで平均7.8ヶ月かかっています。

ただし、審査の状況によっては、登録までにさらに時間がかかることもあります。

VMCを取得する場合は、商標登録にかかる期間も考慮し、BIMIの導入時期から逆算して余裕を持って準備を進めることが重要です。

参考：「特許庁ステータスレポート2026」https://www.jpo.go.jp/resources/report/statusreport/2026/document/index/all.pdf（2026/9/4確認）

商標登録にかかる費用

商標登録には、出願時や登録時に特許庁へ支払う費用がかかります。また、出願手続きを弁理士に依頼する場合は、これとは別に弁理士への報酬が必要です。

ここでは、商標登録にかかる主な費用について、特許庁へ支払う費用と弁理士へ依頼する場合の費用に分けて解説します。

特許庁に支払う費用

商標登録を行う際は、出願時の「出願料」と、審査を通過した後に支払う「登録料」が必要です。また、書面で出願する場合は、別途「電子化手数料」がかかります。

主な費用は以下の通りです。

項目	金額	内容	備考
出願料	3,400円＋（区分数×8,600円）	商標登録を出願する際に支払う費用	区分数に応じて費用が増加
登録料	区分数×32,900円	審査通過後に支払う費用	10年分を一括納付する場合（5年ごとの分割納付も可能）
電子化手数料	基本料2,400円＋書面1枚につき800円	書面で出願した場合に発生する費用	電子出願の場合は不要

例えば、1区分で出願し、登録料を10年分一括で納付する場合、特許庁に支払う出願料と登録料は合計44,900円です。書面で出願する場合は、これに電子化手数料が加わります。

なお、商標権の存続期間は設定登録から10年間です。10年を超えて商標権を維持する場合は、別途更新料が必要になります。

参考：特許庁「産業財産権関係料金一覧」https://www.jpo.go.jp/system/process/tesuryo/hyou.html（2026/9/4確認）

弁理士へ依頼する場合の費用

商標登録の手続きを弁理士へ依頼する場合は、特許庁へ支払う出願料や登録料とは別に、弁理士への報酬が必要です。

報酬金額は、依頼する事務所や手続きの内容によって異なります。依頼する際は、料金体系に加え、商標の事前調査や出願手続き、登録時の手続き、拒絶理由通知への対応など、料金に含まれる業務の範囲も確認しておきましょう。

VMCと商標登録に関するよくある疑問

最後に、VMCと商標登録に関するよくある疑問に回答します。

商標登録が完了する前にVMCを申請できますか？

VMCを申請するには、BIMIで使用するロゴが、承認された商標登録機関に有効な状態で登録されている必要があります。そのため、商標登録が完了していない場合は、先に商標登録を行います。

商標登録には一定の期間がかかるため、VMCを利用してBIMIを導入する場合は、余裕を持ったスケジュールを立てましょう。

文字商標だけでもVMCを取得できますか？

文字のみで構成されたロゴであっても、その文字商標が承認された商標登録機関に登録されており、VMCの要件を満たしていれば、VMCを取得できます。

ロゴの軽微な変更を行った場合、商標の再登録やVMCの再取得は必要ですか？

VMCで使用するロゴは、原則として登録商標のロゴと一致している必要があります。そのため、BIMIで表示するロゴのデザインを変更し、変更後のロゴが既存の登録商標と一致しないと判断される場合、そのロゴでVMCを取得するには、改めて商標登録を行ったうえで、新しいロゴに対応するVMCを取得する必要があります。

ただし、登録商標に加えられた変更が一定の範囲内であれば、「Modified Registered Mark（修正登録商標）」として、商標を新たに登録せずにCMCを取得できる場合があります。

変更の程度によって必要な対応が異なるため、ロゴを変更する場合は、事前にVMC・CMCを発行する認証局や弁理士などの専門家へ確認するとよいでしょう。

BIMIの導入をスムーズに進めるなら

商標登録以外にも、BIMIでロゴを表示するためには、DMARCの導入とポリシー強化、VMC／CMCの取得、BIMIレコードの設定などが必要です。そのため、メール配信環境の整備も含め、計画的に対応を進めることが重要です。

ベアメールでは、DMARC運用からBIMI導入までをワンストップで支援する「BIMI導入支援パッケージ」を提供しています。また、既にDMARCポリシー強化済みのお客さまには、BIMIに必要なロゴデータの作成やVMCの取得・管理をサポートする「BIMI/VMCマネージドサービス」もご用意しています。

お客さまの状況に合わせた柔軟な対応が可能ですので、BIMI導入をご検討の際はぜひお気軽にご相談ください。

まとめ

本記事では、VMC取得に向けてロゴを商標登録する手順や、登録にかかる期間・費用について解説しました。VMCを利用したBIMI導入を検討されている場合は、早めに準備を進めることが重要です。

ベアメールブログ

先進認証（モダン認証）とは？ OAuth 2.0の仕組みや基本認証との違いを解説

先進認証（モダン認証）とは

OAuth2.0を利用したトークンベースの認証方式

基本認証（レガシー認証）とは

ID・パスワードを利用した認証方式

先進認証と基本認証の違い

メール送信における認証方式

SMTP AUTHとは

先進認証への移行が求められるケース

まとめ

SPF Softfailとは？ Hardfailとの違いや発生する原因、~allと-allの選び方を解説

SPF Softfailとは

SPF Softfailの意味

SPFレコードの「~all」との関係

Hardfail（Fail）との違い

SPF Softfailが発生する主な原因と対処法

IPアドレスがSPFレコードに登録されていない

転送によりIPアドレスが変更されている

なりすましメールが送信された

SPFレコードは「~all」と「-all」どちらを設定すべき？

「~all」が適しているケース

送信元の洗い出しが完了していない

送信環境の追加・変更が多い

メールの転送が多い

メール不達の影響が大きい

「-all」が適しているケース

すべての送信元を把握できている

なりすまし対策の強化が求められる

まとめ

ハードバウンスとは？ 原因・対処法とソフトバウンスとの違いを解説

ハードバウンスとは

ハードバウンスの意味

ソフトバウンスとの違い

ハードバウンスが発生する主な原因

宛先メールアドレスが無効である

送信ドメイン認証に問題がある

ブラックリストに登録されている

スパムと判定され受信拒否されている

受信側のポリシーや設定により拒否されている

ハードバウンスが発生した場合の対処法

宛先メールアドレスが有効か確認する

送信ドメイン認証の設定を見直す

ブラックリスト登録状況を確認する

メールの内容や配信方法を見直す

受信側に設定の確認を依頼する

ハードバウンスの発生を防ぐためのポイント

配信リストのクリーニングを行う

ダブルオプトインを実装する

配信前にスパム判定リスクを確認する

まとめ

550 5.7.1エラーが発生する原因は？ エラーメッセージ別の意味と対策を解説

550 5.7.1エラーとは

エラーコード「550」の意味

拡張ステータスコード「5.7.1」の意味

550 5.7.1エラーが発生する主な原因

SPF・DKIM・DMARC認証に問題がある

送信元IPアドレスやドメインの評価が低い

メールの内容がスパムと判定された

受信側ポリシーに抵触している

【エラーメッセージ別】550 5.7.1エラーの意味

Recipient address rejected: Access denied

Message rejected as spam

Authentication required

Unauthorized sender

Client host rejected

Relay access denied

Gmailでよく見られる550 5.7.1エラーメッセージ

550 5.7.1エラーの発生を防ぐための対策

SPF・DKIM・DMARCを適切に設定する

IPアドレス・ドメインの評価を維持する

送信前に迷惑メール判定リスクを確認する

まとめ

メールマーケティングの始め方完全ガイド｜失敗しない手順と運用の注意点

メールマーケティングとは？

メルマガとの違い

【SNS全盛の今、なぜ有効？】メールマーケティングが重要視される背景

メールマーケティングを始める5つのメリット

低コストで始められ、費用対効果が高い

効果測定が容易で、データに基づいた改善がしやすい

ハードバウンスとは？原因・対処法とソフトバウンスとの違いを解説

550 5.7.1エラーが発生する原因は？エラーメッセージ別の意味と対策を解説

ステップ4：配信作業の実施とエラー管理

Postfix設定逆引きガイド集｜基本から応用まで実践解説