## この記事でわかること

- SPF・DKIM・DMARC の「3 点セット」を補完する周辺項目（MX、MTA-STS、TLS-RPT、BIMI）の役割
- それぞれが実務でどんな意味を持ち、いつ導入を検討すべきか
- 周辺項目のうち今すぐ確認すべきものと、ブランド成熟度に応じて検討すべきものの線引き

## メール認証の「3 点セット」と「周辺項目」の関係

中小企業のメール対策というと、SPF・DKIM・DMARC の 3 点セットが話の中心になりがちです。実際この 3 つは 2024 年 2 月の Google 送信者ガイドライン強化以降、事実上の必須条件になっています。一方で、3 点セットだけでは「送ったメールが届くか」「届いたメールが安全か」を完全には担保できません。

3 点セットを支える周辺項目が、本記事で扱う **MX レコード**、**MTA-STS**、**TLS-RPT**、**BIMI** の 4 つです。それぞれ役割が違うので、まずは全体像を整理しておきます。

![メール認証3点セットと周辺項目の関係](/blog/email-extras-overview/email-auth-landscape.svg)

ざっくり整理するとこうなります。

- **MX レコード**: 自社宛のメールを「どのサーバーが受け取るか」を宣言。設定ミスで受信不能になる
- **MTA-STS**: 送信元のメールサーバーが「自社宛に送るときは必ず TLS 暗号化を使え」と指示する仕組み
- **TLS-RPT**: 暗号化に失敗した送信があった場合に、レポートを受け取るための連絡先設定
- **BIMI**: 受信側メーラーで自社のロゴを送信者欄に表示するための設定

これらは 3 点セットを「導入済み」にした上で、配送経路の暗号化（MTA-STS / TLS-RPT）やブランド表示（BIMI）を上乗せする位置付けです。基本的な認証の仕組みは [メール認証 SPF・DKIM・DMARC の違い](/blog/spf-dkim-dmarc-difference) で整理しています。

## MX レコード｜メール受信の入り口

MX レコード（Mail Exchanger）は「このドメイン宛のメールを、どのサーバーで受け取るか」を宣言する DNS レコードです。RFC 5321 で標準化されており、すべてのメールサービスで必須となります。

Google Workspace を使うなら `smtp.google.com.`、Microsoft 365 なら `テナント名.mail.protection.outlook.com.` のように、各サービスが指定する値をそのまま設定します。優先度（数値）を付けて複数指定でき、数字が小さい方から順に試されます。

注意点は 2 つあります。**設定ミスで自社宛のメールが届かなくなる**こと、そして**メールサービス乗り換えのタイミングで切替忘れが発生しやすい**ことです。実際、メール移行直後に「取引先からメールが届かない」というトラブルの大半は MX レコードの古い値が残っていることが原因です。

DNS レコード全般の整理は [DNS レコードの種類をわかりやすく](/blog/dns-record-types) を参照してください。

## MTA-STS と TLS-RPT｜配送経路の暗号化を担保する

メールが SMTP で送られる際、送信側と受信側のサーバー間は通常 STARTTLS という仕組みで暗号化されます。ところが STARTTLS は「相手が対応していたら暗号化する、対応していなければ平文で送る」という日和見的な動作なので、攻撃者が間に入って「私は TLS に対応していません」と返せば、暗号化を剥がせる弱点があります（ダウングレード攻撃）。

これを防ぐ仕組みが **MTA-STS**（RFC 8461）と **TLS-RPT**（RFC 8460）です。

![MTA-STSポリシーで配送経路の暗号化を強制する](/blog/email-extras-overview/mta-sts-flow.svg)

### MTA-STS の役割

MTA-STS は「自社ドメイン宛にメールを送るときは、必ず TLS で暗号化してください。暗号化できない場合は配送を諦めてください」という方針を、HTTPS で公開するポリシーファイルとして発信する仕組みです。送信側のメールサーバーは事前にこのポリシーを取得し、ダウングレード攻撃を受けても暗号化を強制できます。

### TLS-RPT の役割

TLS-RPT は、暗号化に失敗した送信が発生した場合に「日次の集計レポートを、この URL またはメールアドレスに送ってください」と指定するための DNS レコードです。MTA-STS と組み合わせることで、「ポリシーを設定した結果、配送が落ちていないか」を継続的に監視できます。

### どう考えるべきか

MTA-STS と TLS-RPT は、Google や Microsoft は対応済みですが、すべてのメール送信元が対応しているわけではありません。導入の判断は以下のように考えると整理しやすくなります。

- 機密性の高い業界（医療・士業・金融周辺など）でメール経路の暗号化を担保したい → 導入推奨
- 取引先に大企業が多く、相手側がポリシーを参照する → 導入によるブランド面のメリットあり
- 一般的な中小企業で、まずは 3 点セットを固めたい → 後回しで問題なし

## BIMI｜送信ドメインのロゴ表示

BIMI（Brand Indicators for Message Identification）は、Gmail や Yahoo メールなどの受信メーラーで「送信者欄にあなたの会社ロゴを表示する」仕組みです。RFC 9092 と業界仕様で定義されており、2023 年以降に Gmail を含む主要メーラーが順次対応を進めています。

BIMI を使うには 3 つの条件を満たす必要があります。

1. DMARC を `p=quarantine` 以上の強いポリシーで運用していること（`p=none` では不可）
2. ブランドロゴを定められた SVG 形式（SVG Tiny PS）で公開していること
3. **VMC**（Verified Mark Certificate）または **CMC**（Common Mark Certificate）という有料の証明書を取得していること

VMC・CMC は商標登録などを基にロゴの所有権を検証する証明書で、年額 100 〜 200 ドル前後が相場です。中小企業にとっては、BIMI 導入の主な障壁はこの証明書のコストになります。

DMARC のポリシー強化手順は [DMARC とは？中小企業が今すぐ対応すべき理由](/blog/what-is-dmarc) で解説しています。BIMI 導入を検討する前に、まず DMARC が `p=reject` または `p=quarantine` で安定運用できているかを確認するのが先決です。

## まとめ｜どの順番で取り組むか

中小企業が周辺項目に取り組む際の優先順位は、以下のように整理できます。

- **最優先**: MX レコードの正しさ確認。これが間違っていると受信そのものができない
- **3 点セットの完了後**: MTA-STS と TLS-RPT。コスト負担なく追加可能で、配送経路の安全性を担保できる
- **DMARC 強化が安定したら**: BIMI。ブランド成熟度と予算次第で判断する

無理にすべてを揃える必要はありませんが、自社のドメインがどこまで対応できているかを把握しておくことは、メール基盤の健全性を理解する上で重要です。

## まずは現状を把握しましょう

[無料のドメイン診断](/diagnose) では、SPF・DKIM・DMARC に加えて MX・MTA-STS・TLS-RPT・BIMI の設定状況もまとめて確認できます。何が設定されていて、何が未設定なのかを数秒で把握できるので、対策の優先順位を考える出発点としてご活用ください。

設定状況を見ても判断に迷う場合は、[お問い合わせ](/contact) から専門家にご相談いただけます。各項目の必要性をビジネス視点で整理した上で、現実的な進め方を一緒に考えます。