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

- `p=reject` を入れた直後に正規メールが拒否されたときの即時ロールバック手順
- TTL（DNS キャッシュ保持時間）を事前に短くしておくべき理由
- 原因を特定し、段階強化をやり直すためのチェックリスト

## reject 直後に「メールが届かない」と社内が騒ぎ始めたら

DMARC（ディーマーク）の段階強化で `p=reject` まで進めた直後、社内通知や取引先の自動返信が届かない、請求書送付メールが弾かれているという連絡が立て続けに入る。中小企業で実際に起きるトラブルです。

`p=reject` は認証失敗メールを SMTP の段階で拒否させる強力な設定ですが、**自社が把握していない正規の送信経路が 1 つでも認証失敗していると、その経路のメールはすべて拒否される** 副作用があります。段階強化の考え方は [DMARC の p=quarantine 強化｜段階的移行の手順](/blog/dmarc-policy-tightening) で扱っています。本記事は **「すでに reject を入れて事故が起きている」前提の応急対応** です。

![DMARC reject ロールバックの 4 ステップ](/blog/dmarc-reject-rollback/rollback-steps.svg)

## 即時ロールバック：DNS で `p=none` に戻す

被害の連鎖を止めるため、まず DNS の DMARC レコードを `p=none`（監視モード）に戻します。

### ステップ 1: 現在の DMARC レコードを確認する

DNS 管理画面で `_dmarc.example.com` の TXT を確認します。ターミナルなら `dig +short TXT _dmarc.example.com` で取れます。例えば次のような値です。

```
"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com"
```

### ステップ 2: TXT レコードを `p=none` に書き換える

`p=reject` を `p=none` に、`sp=reject` も `sp=none` に書き換えます。アラインメント（`adkim` / `aspf`）が `s`（厳格）なら応急対応として `r`（緩和）に戻します。

```
v=DMARC1; p=none; sp=none; adkim=r; aspf=r; rua=mailto:dmarc@example.com
```

### ステップ 3: TTL 経過を待ち、伝播を確認する

DNS の変更は **TTL（キャッシュ保持時間）** が切れるまで受信側に行き渡りません。TTL が 3,600 秒（1 時間）なら最大 1 時間、86,400 秒（24 時間）なら最大丸 1 日かかります。複数の DNS サーバーから確認します。

```
dig +short TXT _dmarc.example.com @8.8.8.8
dig +short TXT _dmarc.example.com @1.1.1.1
```

両方で `p=none` に変わっていれば、新しいキャッシュへの切り替えが進んでいる状態です。

### ステップ 4: 取引先・社内に状況を伝える

DMARC `p=reject` での拒否は SMTP 5xx 系のエラーになるため、送信側のメールサーバーは通常自動再送しません。重要な相手には別チャネル（電話 / Slack / Chat）でメール障害の発生と再送依頼を明示的に伝える必要があります。

### 事前対策：TTL を短くしておく

ロールバックの **遅さ = 障害の長さ** です。強化期間中は `_dmarc` の TTL を **300 秒（5 分）** に下げておくことを強く推奨します。常時短縮は不要で、**段階強化の前後 1〜2 ヶ月だけ** 短くし、安定後は 3,600 秒以上に戻すのが現実的です。TTL の概念は [DNS 基礎｜中小企業 IT 担当が押さえる用語と仕組み](/blog/dns-basics) で扱っています。

## 何が原因で reject されたかを特定する

応急対応が終わったら、**「なぜ正規メールが認証失敗していたのか」** を特定します。原因が分からないまま再度強化に進むと、同じ事故を繰り返します。`p=none` に戻したあとも rua レポートは届き続けるので、過去 1〜2 週間の XML を見直します。よくある原因パターンは次のとおりです。

- **見落としていた送信経路**: 会計 SaaS の請求書通知、予約システムの自動返信、退職者の旧 SMTP サーバー など
- **DKIM 鍵のローテーション漏れ**: 鍵を更新したが DNS への TXT 公開を忘れていた
- **転送メールでの SPF 失敗**: 取引先の自動転送で SPF が壊れ DMARC 失敗（DKIM が署名されていれば救えた）
- **SPF の include 数が 10 超で permerror**: SaaS 追加後にエラー化（[SPF 設定方法を徹底解説](/blog/spf-setup-guide) 参照）
- **From のアラインメント不一致**: 配信ツールが別ドメインで DKIM 署名していて From と一致しない

集計レポートの読み方は [DMARC レポートの見方｜集計 XML を読み解く](/blog/dmarc-report-reading) で扱っています。レポート上で「認証失敗が集中している IP / ドメイン」を上から順に潰していくのが基本作業です。

## 段階強化をやり直すためのチェックリスト

原因が特定できたら、**次の項目をすべて満たしてから** 再度の強化を進めます。一度事故を起こしているドメインは社内の信用回復のためにも慎重に進めるべきです。

![段階強化やり直しのチェックリスト](/blog/dmarc-reject-rollback/recheck-checklist.svg)

**認証側のチェック**

- 全送信経路（社内メール / SaaS / 配信ツール）が DMARC レポートで把握できている
- 主要送信経路で **SPF と DKIM の両方** が継続して pass している
- SPF の include ルックアップ数が 10 以下に収まっている
- DKIM の鍵長が 1,024 bit 以上で、ローテーション運用が定義されている

**運用側のチェック**

- `_dmarc` の TTL を 300 秒に短縮済み
- ロールバック手順を社内ドキュメントに明記し、当番者が DNS 管理画面にアクセスできる
- DMARC レポートを毎日確認する担当が決まっている
- メール障害時の代替連絡経路（電話 / Slack 等）が確認できている

これらが揃ってから、改めて `p=none` → `p=quarantine` → `p=reject` を段階的に進めます。各段階で `pct` タグを使って 10% → 50% → 100% と上げていく具体手順は [DMARC の p=quarantine 強化｜段階的移行の手順](/blog/dmarc-policy-tightening) を参照してください。

### まとめ

- `p=reject` で正規メールが拒否されたら、DNS の `_dmarc` を `p=none; sp=none` に書き換える。SMTP 5xx は自動再送されないため、別チャネルで再送依頼する
- 段階強化の前後 1〜2 ヶ月は `_dmarc` の TTL を 300 秒に短縮しロールバックを速く効かせる
- DMARC レポートで原因を特定し、チェックリストを満たしてから再度段階強化に進む

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。