# DMARCを30日で p=none から p=reject へ移行する手順

正規URL：https://brew.new/ja/blog/dmarc-p-none-to-reject-in-30-days
執筆：Thomas Park
公開日：2026-10-04
更新日：2026-10-04

DMARCは、`_dmarc.<your domain>` に置くTXTレコードです。From ヘッダーに自社ドメインを使っていながら、アライメントの取れたSPFにもDKIMにも合格しなかったメールを受信側がどう扱うか、そしてレポートをどこに送るかを指定します。`p=none` はレポートを求めるだけです。`p=quarantine` はそうしたメールを疑わしいものとして扱うよう、`p=reject` は受け取りを拒否するよう、受信側に求めます。

Gmail、Yahoo、Microsoft は一括送信者の `p=none` を認めているため、多くのドメインは `p=none` を公開したところで止まり、なりすましを報告させるだけで、ブロックはしていません。[2026年4月](https://redsift.com/blog/email-authentication-bespinlabs-redsift)に引用された Red Sift の分析では、7,330万ドメインのうち、何らかのDMARCポリシーを設定していたのは14.9%、`p=reject` を適用していたのは2.5%でした。同じくDMARCベンダーの EasyDMARC は、DMARCを導入している Fortune 500 企業の62.7%が `p=reject` を使っているのに対し、Inc. 5000 企業では15.2%にとどまると[2025年に報告しています](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/)。

ここでは、業務用メール、1〜2つのESP、ヘルプデスク、請求ツールから送信しているドメインを想定し、`p=reject` までの30日間の計画をレコードごとに紹介します。30日という期間は、送信用のサブドメインに向いています。従業員が日常のメールに使うドメインには、もっと時間が必要です。

## この記事のポイント

- 1日目に `v=DMARC1; p=none; rua=mailto:...` を公開します。`rua` がなければ、受信側は集約レポートを送ってはいけないことになっています。
- 正規の送信元はすべて、From ドメインとアライメントの取れたSPFかDKIMに合格する必要があります。ほとんどのツールでは、自社ドメインでDKIM署名するということです。
- SPFでDNSルックアップを伴う項目は、ネストされた include も含めて10個以内に抑えます。超えると、すべてのメールが `permerror` になります。
- 15日目に `p=quarantine`、22日目に `p=reject` に移行します。どちらも、問題のないレポートが1週間続いてからにしましょう。従業員が日常のメールに使うドメインについては、RFC 9989 は最初の2つの段階にそれぞれ1か月かけるよう求めています。
- RFC 9989（2026年5月）は、`pct` を廃止扱い（historic）にしました。`pct=10`、`pct=50` と段階的に上げるやり方は使わないでください。
- BIMIには、組織ドメインでの `p=quarantine` または `p=reject`、`sp=none` を使わないこと、SVG Tiny PS形式のロゴ、そして Gmail の場合はVMCかCMCが必要です。

## 2026年にDMARCで変わったこと

2026年5月、IETFは、2015年の Informational（情報提供）文書であるRFC 7489 をDMARCbisに置き換えました。DMARCbisは、RFC 9091 も廃止する Proposed Standard（標準化提案）の[RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) と、集約レポートを定める[RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) からなります。ここで重要な変更は3つです。

- **`pct` は廃止扱い（historic）に**。付録A.6には、`pct` は「指定された値が0か100でない限り、たいてい正確には適用されていなかった」とあります。
- **`pct=0` に代わる `t=y`**。受信側は、設定したポリシーより1段階弱い処理を適用するため、`p=reject; t=y` は quarantine として機能します。テスト用のスイッチです。
- **新しい `np`**。DNSに存在しないサブドメインを対象とするタグで、古い受信側はこれを無視することになっています。

また、組織ドメインを判定する方法も、パブリックサフィックスリストからDNSツリーウォークに変わりました。

## DMARCを支える3つのレコード

DMARCに合格するのは、SPFかDKIMが合格し、**かつ**合格したドメインが From ドメインとアライメントしている場合です。アライメントの取れた合格が1つあれば十分です。

### SPFとルックアップ10回の上限

SPFは、エンベロープ（`MAIL FROM` またはリターンパス）のドメインについて、送信を許可するサーバーを指定します。DMARCが使う識別子はこれだけで、HELOは使いません。[RFC 7208 の4.6.4節](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4)は、DNSルックアップを伴う項目（`include`、`a`、`mx`、`ptr`、`exists`、`redirect`）を、ネストされたすべての include を含めて10個までに制限しています。`ip4`、`ip6`、`all` は数に入りません。上限を超えると、結果は `permerror` になります。同じ節では、「void lookup」（結果が空になるルックアップ）も2回までしか認めていません。たいていは、もう存在しないホスト名への include が原因です。

```dns
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"
```

これだけで、各ベンダーがネストしている分を数える前に、すでに4回のルックアップを使っています。`dig +short TXT <name>` でチェーンをたどり、ひとつずつ解決して確かめましょう。10回以内に収めるには、使っていないツールを外すか、`bounce.example.com` のような専用のリターンパス用サブドメインを各ESPに割り当てます。サブドメインごとに、10回の枠が別に確保されます。Microsoft の[SPF設定ガイド](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)は、DKIMとDMARCも運用しているドメインでは、`-all` で終えることを推奨しています。

多くのESPは、デフォルトでESP自身のリターンパス用ドメインを使います。これはあなたのドメインとアライメントしません。カスタムのリターンパスを設定するか、DKIMに頼りましょう。

### DKIM：2048ビットの鍵、セレクター、ローテーション

DKIMは、ドメイン `d=` とセレクター `s=` を使って各メッセージに署名し、受信側は `<selector>._domainkey.<d domain>` から鍵を取得します。`d=vendor-mail.example` で署名するツールは、DKIMには合格しても、DMARCには不合格になります。

[RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) は、署名者は少なくとも1024ビットのRSA鍵を使わなければならず、2048ビットを使うべきだとしています。[Google の送信者ガイドライン](https://support.google.com/mail/answer/81126)も、個人の Gmail アカウント宛てについて同じことを求めています。2048ビットの鍵はTXT文字列の上限である255文字を超えるため、1つのレコードの中で、引用符で囲んだ複数の文字列に分けて登録します。ほとんどのDNSホスティングでは、この分割を自動で行ってくれます。

```dns
s202610._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
    "...remainder-of-the-2048-bit-key...IDAQAB" )
```

送信システムごとに専用のセレクターを割り当て、名前は決して使い回さないでください。`s202610` のように日付を使うと、履歴が読みやすくなります。M3AAWGの[鍵のローテーションに関するベストプラクティス](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf)は、少なくとも6か月ごとにローテーションするよう勧めています。

1. 新しいセレクターを公開し、反映されるのを待ちます。
2. 署名を新しい鍵に切り替えます。
3. 配送途中のメールも検証できるよう、古い公開鍵を7〜30日間DNSに残します。
4. 古いセレクターは、`p=` を空にして無効化します。削除はしないでください。

### アライメント：relaxed か strict か

RFC 9989 は2つのモードを定めています。

| モード | タグ | 合格したSPF/DKIMのドメイン | From ドメイン | アライメント |
|---|---|---|---|---|
| relaxed（デフォルト） | `aspf=r`、`adkim=r` | `bounce.example.com` | `mail.example.com` | 取れる（組織ドメインが同じ） |
| strict | `aspf=s`、`adkim=s` | `bounce.example.com` | `mail.example.com` | 取れない（名前の完全一致が必要） |
| どちらでも | | `vendor.example.net` | `example.com` | 取れない |

RFC 9989 は、「ほぼすべてのドメイン所有者が、relaxed のアライメントで十分だと判断している」と述べています。`aspf` と `adkim` は指定しないでおきましょう。SPFのアライメントを strict にすると、サブドメインに置く一般的なリターンパスが機能しなくなります。

## 30日間の計画

![4段階で進める30日間のDMARCのタイムライン：1〜7日目は rua のレポートを受け取りながら p=none、8〜14日目は送信元の修正、15日目に p=quarantine、22日目に p=reject、30日目以降はBIMI。各段階の正確なTXTレコード付き。](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png)

*各段階のレコード。問題のないレポートが1週間続いてから、次の段階に進みます。*

| 日数 | ポリシー | やること | 次に進む条件 |
|---|---|---|---|
| 1〜7日目 | `p=none` | `rua` 付きで公開し、すべての送信元を洗い出す | Google、Yahoo、Microsoft からのレポートが7日分そろう |
| 8〜14日目 | `p=none` | DKIMとSPFを修正し、使っていない送信元を廃止する | すべての正規の送信元が、アライメントの取れたSPFかDKIMに合格する |
| 15〜21日目 | `p=quarantine` | 隔離された正規のメールがないか監視する | 認証に失敗する正規の送信元がない状態が7日間続く |
| 22〜30日目 | `p=reject` | レポートの確認を続け、`np=reject` を追加する | 1週間安定している |
| 30日目以降 | `p=reject` | BIMIに着手する | 証明書が発行される |

2週目に、誰にも修正できない送信元が見つかったら、`p=none` のままにしておきましょう。自社の請求書のメールを拒否してしまうのは、ポリシーの適用が遅れるより悪い事態です。

### 1〜7日目：レポート付きで p=none を公開する

```dns
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
```

レポートは gzip で圧縮されたXMLで、受信側ごとに少なくとも1日1通届きます。そのため `rua` の宛先は、人ではなくレポート解析サービスにしましょう。アドレスが別の組織ドメインにある場合、RFC 9990 では、`example.com._report._dmarc.<report domain>` で許可されていない限り、受信側はそのアドレスを無視します。レポート解析サービスであれば、このレコードはサービス側が公開しています。自社の別ドメインを宛先にする場合は、自分で追加してください。

公開するDMARCレコードは、必ず1つだけにします。設定ウィザードのせいで `_dmarc.example.com` に `v=DMARC1` のレコードが2つ残っていると、受信側は両方とも破棄します。

`ruf` は設定しなくてかまいません。RFC 9989 によると、プライバシーを重視する受信側は、失敗レポートの内容を大幅に伏せるか、そもそも送りません。また、Microsoft の[送信量の多い送信者向けの発表](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730)にあるFAQでは、`rua` のレポートは送るものの、`ruf` を送る予定はないとしています。

### 集約レポートの読み方

RFC 9990 は、ポリシードメインごとに1つずつ、「毎日（またはそれ以上の頻度で）」送られるXMLレポートについて説明しています。以下は、そのサンプルをもとにしたレコードの例です。

```xml
<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>
```

`policy_evaluated` の `dkim` と `spf` は**アライメント**の結果で、`disposition` は受信側が実際に行った処理です。`auth_results` には、生の認証結果とそのドメインが入っています。この例では、どちらも `vendor.example` で合格しているため、アライメントはどちらも不合格です。つまり、ベンダーがあなたの名前で送信しているのに、あなたのドメインで署名していない状態です。そのベンダーのカスタムDKIMかドメイン認証を有効にしましょう。

### 1〜7日目：不明な送信元を見つける

`source_ip`、`envelope_from`、DKIMの `domain` と `selector` の組み合わせでグループ化し、`count` で並べ替えてから、次のように分類します。

| レポートに見られるパターン | 考えられる原因 | 対応 |
|---|---|---|
| アライメントの取れたDKIMかSPFが合格 | 正しく設定されている | 不要 |
| ベンダーのドメインでDKIMとSPFが合格 | SaaSツールがツール自身のドメインを名乗っている | カスタムDKIMを有効にする |
| アライメントの取れたDKIMは合格、SPFは不合格、メールボックスプロバイダーかメーリングリストのIP | 転送またはメーリングリスト | 通常は不要。アライメントの取れたDKIMは転送後も維持される |
| DKIMなし、SPFは不合格、送信元を特定できないIP | なりすまし | 不要。`p=reject` で止めるのはこれ |

IPの送信元を特定するには、`dig -x 192.0.2.123 +short` を実行し、セレクターも確認します。セレクターにはベンダー名が入っていることがよくあります。そのうえで、経理、サポート、営業の各チームに、会社の名前で何がメールを送っているかを確認しましょう。請求、ヘルプデスク、カレンダーの招待、オフィスのスキャナーなどです。

転送メールやメーリングリストのメールは、修正しようのない形で失敗します。Google の[送信者向けのよくある質問](https://support.google.com/mail/answer/14229414)でも、こうしたメールにはアライメントを求めていないので、その解決を待つ必要はありません。

### 8〜14日目：すべての正規の送信元を修正する

`count` の多いものから順に対応します。

1. **業務用メール**（Google Workspace、Microsoft 365）：管理コンソールでDKIMを有効にし、選べる場合は2048ビットにします。プロバイダーの include がSPFに入っていることも確認します。
2. **ESPとマーケティングツール**：自社の `d=` で署名されるようにドメイン認証を設定し、可能ならカスタムのリターンパスも設定します。
3. **ヘルプデスク、請求、CRM**：ESPと同じです。自社ドメインで署名できないツールには、そのツールが署名できるサブドメインか、ツール自身のドメインを使わせます。
4. **使っていないツール**：その include とセレクターを削除します。

最後に、SPFのルックアップ数を数え直しましょう。

### 15日目：p=quarantine

```dns
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
```

quarantine は、通常は迷惑メールフォルダーへの振り分けを意味します。`disposition` が `quarantine` になっている正規の送信元がないか注意しましょう。予行演習をしたい場合は、`p=quarantine; t=y` とすると、RFC 9989 に対応した受信側には `none` を適用するよう求めることになります。ただし、このRFCは公開から数か月しかたっておらず、まだすべての受信側が `t` に対応しているわけではありません。

### 22日目：p=reject

```dns
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com"
```

`p=reject` に従う受信側は、認証に失敗したメールをSMTPセッションの中で拒否します。ただしRFC 9989 は、判断の根拠がポリシーしかない場合には quarantine にするよう受信側に求めているため、一部は迷惑メールフォルダーに入ります。

同じRFCは、`p=reject` のドメインは「SPFだけに頼ってはならない（MUST NOT rely solely on SPF）」とし、DKIMで署名しなければならないと定めています。転送でSPFは壊れても、DKIMは壊れないからです。先に、すべての送信元でアライメントの取れたDKIMを確認しておきましょう。

`rua` はずっと残しておきましょう。来四半期に導入される新しいツールは、サポートへの問い合わせより先に、レポートに現れるはずです。

### 計画を延ばすべきとき

RFC 9989 の7.4節は、ユーザーがメーリングリストに投稿するドメインは `p=reject` を公開すべきではない（SHOULD NOT）としています。公開する場合も、まず `p=none` で「少なくとも1か月」、`p=quarantine` で「同じくらいの期間」を過ごすべきだとしています。多くの企業のルートドメインがこれに当てはまるため、そうしたドメインでは最初の2つの段階にそれぞれ1か月かけましょう。ESPだけが使うサブドメインにはメーリングリストのトラフィックがないので、30日のペースのままで問題ありません。

### サブドメインのポリシー：sp= と np=

`p` は、そのドメインとサブドメインに適用されます。`sp` は存在するサブドメインについて、`np` は存在しないサブドメインについて、`p` の設定を上書きします。独自のレコードを持つサブドメインではそのレコードが使われ、RFC 9989 ではそこでの `sp` は無視されます。

`mail.example.com` のような送信専用のサブドメインを1つのESPだけが使っていて、SPFとDKIMが認証済みなら、初日から `p=reject` を公開できます。ルートドメインに `p=none; sp=reject` を設定すると、メインのドメインの作業を終えるまでの間サブドメインを守れますが、BIMIは使えなくなります。

メールを送らないパークドメインでは、Microsoft のSPFガイドに従って `v=spf1 -all` を公開し、さらに `_dmarc` に `v=DMARC1; p=reject;` を公開しましょう。

## 30日目以降：BIMI

BIMIに対応した受信トレイでは、認証済みのメールの横にブランドのロゴが表示されます。

| 要件 | 詳細 | 出典 |
|---|---|---|
| DMARCポリシー | 組織ドメインと From ドメインの両方で `p=quarantine` または `p=reject` | BIMIのドラフト |
| サブドメインのポリシー | `sp` を公開している場合は `none` 以外 | BIMIのドラフト |
| 適用率 | quarantine の場合、`pct` を100未満にしない | BIMIのドラフト |
| ロゴ | SVG Tiny PS：`baseProfile="tiny-ps"`、`version="1.2"`、`<title>` を含み、スクリプトや外部参照はなし、ルート要素に `x=` や `y=` はなし | BIMI Group |
| 証明書 | Gmail ではVMC（登録商標が必要、チェックマークあり）かCMC（商標不要、チェックマークなし）が必要 | Google |

[BIMIのドラフト](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/)は第14版（2026年5月）で、いまもRFC 7489 を前提に書かれた Internet-Draft です。`pct` が出てくるのはそのためです。`pct` は指定せず、`t=y` も設定しないでください。

組織ドメインについてのルールには、サブドメインから送信している場合も引っかかります。`mail.example.com` が `p=reject` でも、`example.com` が `p=none` なら、受信側はロゴを表示してはいけません。ルートドメインでも、この計画を最後までやり遂げる必要があります。

[BIMI Group のSVGガイダンス](https://bimigroup.org/creating-bimi-svg-logo-files/)は、単色の背景の中央に配置した正方形のロゴで、32KB未満にすることを推奨しています。Google は[2024年9月にCMCへの対応を追加しました](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html)。[BIMI Group の実装ガイド](https://bimigroup.org/implementation-guide/)に沿ったレコードは次のとおりです。

```dns
default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"
```

商標登録には数か月かかるので、VMCを取得するなら今すぐ準備を始めましょう。

## Gmail、Yahoo、Microsoft の要件

3社とも、ポリシーの適用までは求めていません。求めているのは、DMARCレコードとアライメントだけです。

| | Gmail | Yahoo | Outlook.com |
|---|---|---|---|
| 対象 | 個人の Gmail アカウント宛てに1日5,000通近く（プライマリドメイン単位）。一度達すると恒久的に対象 | 一括送信者（具体的な数値なし） | outlook.com、hotmail.com、live.com 宛てに1日5,000通超（From ドメイン単位） |
| SPFとDKIM | 両方 | 両方 | 両方とも合格が必要 |
| DMARC | レコードが必要。`p=none` で可 | 最低でも `p=none`。`rua` を強く推奨 | 最低でも `p=none` |
| アライメント | SPFかDKIM | SPFかDKIM。relaxed で可 | SPFかDKIM |
| 要件を満たさない場合 | 2025年11月から、一時的な拒否と恒久的な拒否 | 記載なし | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` |

出典：[Google の送信者ガイドライン](https://support.google.com/mail/answer/81126)と[よくある質問](https://support.google.com/mail/answer/14229414)、[Yahoo の送信者向けベストプラクティス](https://senders.yahooinc.com/best-practices/)、Microsoft の[2025年4月の発表](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730)と[5.7.515 のサポートページ](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com)。Microsoft は2025年5月5日に適用を開始しました。その前の4月29日の更新で、要件を満たさないメールへの対応が、迷惑メールフォルダーへの振り分けから拒否に変わっています。

Google のよくある質問には、SPFとDKIMの両方でのアライメントは「いずれ送信者の要件になる」とあります。2週目に、両方ともアライメントを取っておきましょう。配信停止や迷惑メール率については、[エージェントがメールを送る場合にも変わらないこと](/ja/blog/agent-email-deliverability)と[到達率ガイド](/ja/blog/email-deliverability)をご覧ください。

## Brew の送信ドメインでのDMARC

Brew の[ドメイン設定](https://docs.brew.new/get-started/verify-your-sending-domain)では、次のレコードを求められます。

- **DKIM**：送信ドメイン配下の `._domainkey` セレクターに置くTXTレコード。必須です。
- **SPF**：Brew のリターンパスである `send.<your sending domain>` に置くMXレコードとTXTレコード。必須です。
- **DMARC**：`_dmarc.<your sending domain>` に置くTXTレコード。任意ですが、推奨します。
- クリックトラッキング用の**CNAME**：独自のトラッキング用サブドメインを使う場合のみ。

SPFとDKIMが認証されればそのドメインから送信でき、Brew はそれに合わせたDMARCの値を提案します。

```dns
; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"

; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
```

専用のサブドメインに `p=reject` が提案されるのは、Brew のSPFとDKIMが認証されるまで、そこから送信されるものが何もないからです。ルートドメインに `p=none` が提案されるのは、ほかのツールもそのドメインで送信している可能性が高いからです。その場合は、上の計画を実行しましょう。アライメントが relaxed のままなのは、`send.<domain>` のリターンパスが relaxed モードでしかアライメントしないためです。

Brew は、ドメインの追加時、認証時、そして再確認のたびに、公開中の `_dmarc.<sending domain>` レコードを読み取ります。結果は **ドメイン** に表示され、MCPの `get_domain_health` や `GET /v1/domains/{domainId}/health` でも確認できます。

- **`dmarc_missing`**：追加すべき正確なレコードを示す警告です。
- **`dmarc_invalid`**：同じ名前にDMARCレコードが2つある場合や、バージョンやポリシーが不正な場合、タグが重複している場合に表示されます。削除すべきレコードも示されます。
- **認証済み**：有効なレコードがちょうど1つ見つかった状態です。

DNSの自動設定は、DMARCレコードがない場合にだけ書き込むため、レコードが重複することはありません。チェックは親ドメインではなく送信ドメインで行われるので、送信用のサブドメインにはそれぞれ専用のレコードを用意しましょう。ドキュメントで勧めているとおり[トランザクションメール](/ja/blog/transactional-emails)を分けている場合は、そのサブドメインにも必要です。レポートを読み、reject に移るタイミングを判断する場所は、`rua` の宛先にしたレポート解析サービスです。

## よくある質問

### quarantine に移行する前に、p=none をどのくらい続けるべきですか？

すべての正規の送信元がアライメントの取れたSPFかDKIMに合格していることを、丸1週間分のレポートで確認できるまでです。送信用のサブドメインなら、通常は1〜2週間です。従業員が日常のメールに使うドメインについては、RFC 9989 は少なくとも1か月を求めています。誰もレポートを読まないまま `p=none` を2年続けても、何の意味もありません。

### DMARCの pct タグは非推奨になったのですか？

はい。RFC 9989 は `pct` を「historic（廃止扱い）」とし、確実に機能していた値だけを `t` に置き換えています。`t=y` は `pct=0` と、`t=n` は `pct=100` と同じ動作です。古い受信側はまだ `pct` を読み取るかもしれませんが、中間の値が一貫して適用されたことはないので、段階は丸ごと切り替えましょう。

### p=reject にすると、転送したメールがブロックされますか？

単純な転送では、通常SPFは壊れてもDKIMは壊れないため、アライメントの取れたDKIMはそのまま合格します。件名やフッターを書き換えるメーリングリストではDKIMが壊れますが、その埋め合わせとして From ヘッダーを書き換えるリストもあります。すべての送信元でアライメントの取れたDKIMを使うことが、最善の対策です。

### Gmail と Yahoo は p=reject を必須にしていますか？

いいえ。どちらも一括送信者にDMARCの公開を求めていますが、`p=none` で問題ありません。Outlook.com 宛てに1日5,000通を超えて送る送信者に対する Microsoft の要件も同じです。ポリシーの適用はなりすましを防ぎ、BIMIにも必要ですが、3社とも必須にはしていません。

### BIMIにはVMCが必要ですか？

Gmail では、VMCかCMCのどちらかが必要です。VMCには登録商標が必要で、チェックマークが表示されます。CMCでは、チェックマークなしでロゴが表示されます。[BIMI Group](https://bimigroup.org/understanding-bimi-certificate-types/) によると、Yahoo や Fastmail など一部のプロバイダーでは、証明書のない自己申告のロゴも表示されます。