BLOG DI ICHIRO

メール送信者のガイドライン強化に伴い、独自ドメイン（今回は example.com を例にします）から配信するメールのセキュリティ対策（SPF・DKIM・DMARC）が必須となっています 。

この記事では、Amazon Route 53 と Google Workspace を組み合わせて設定を行った際の一連の流れや、ハマりやすい落とし穴、レポート解析とポリシー引き上げ（p=none → p=quarantine → p=reject）のステップをまとめて解説します 。

1. なぜSPF/DKIMだけでなく「DMARC」まで必要なのか？

「SPFとDKIMを設定しておけば十分なのでは？」と思われがちですが、これら単体では防げないセキュリティ上のリスクが存在します 。

• 「表示上の差出人（Header From）」のなりすましを防げない SPFは配送用アドレス（Envelope From）、DKIMは署名ドメインをチェックしますが、受信者が目にする「表示用差出人（From:）」の偽装までは防げません 。
• 認証失敗時の対応を指定できない SPF/DKIMだけでは、認証失敗したメールを「迷惑メールにするか」「拒否するか」の判定が相手のメールサーバー任せになります 。
• 悪用状況の把握ができない 自社ドメインが第三者にフィッシング詐欺などで不正利用されていても、それに気付ける仕組みがありません 。

DMARC（Domain-based Message Authentication, Reporting, and Conformance）を設定することで初めて、「なりすましメールを拒否・隔離させる指示」と「不正利用状況の集計レポート（RUA）の受信」が可能になります 。

2. STEP 1：SPFレコードの設定（Route 53）

まずは基本となる SPF レコードを登録します 。

• ホスト名（レコード名）: 空白（ルートドメイン example.com）
• レコードタイプ: TXT
• 値:Plaintextv=spf1 include:_spf.google.com ~all

💡 はまりポイント＆注意点

• 同一ホスト名の既存TXTレコードがある場合 Google のドメイン所有権確認（google-site-verification=...）などが既にルートドメインに存在する場合、Route 53 では改行を入れて複数行で同一 TXT レコード内に併記することができます 。
• ダブルクォーテーションの扱い "google-site-verification=..." と "v=spf1 ..." のようにダブルクォーテーションが付いている・付いていないが混在しても、Route 53 側で自動調整して処理されます 。

3. STEP 2：DKIMレコードの設定と「255文字制限」の解決法

次に、電子署名によりメールの改ざんを防ぐ DKIM レコードを設定します 。

• ホスト名（レコード名）: google._domainkey （※空白にしてはいけません。右側に .example.com が自動補完されます）
• レコードタイプ: TXT

💡 はまりポイント：CharacterStringTooLong エラーの回避

Google Workspace で生成される 2048 ビットの DKIM 鍵は文字列が非常に長いため、Route 53 にそのまま貼り付けると「1つの文字列が255文字を超えている」エラーが出ます 。

【解決策】 鍵の文字列を半角スペースまたは改行を挟み、ダブルクォーテーション " で2つに分割して入力します 。

Plaintext

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
"前半の続き〜〜後半のキー文字列..."

※分割して記述しても、DNS側で自動的に1つの鍵として連結されて認識されます 。

4. STEP 3：DMARC初期設定（監視モード：p=none）

SPF・DKIMの設定完了後、いきなりメールを拒否する設定にはせず、まずは自社からの正規メールに影響が出ないよう「監視モード」でスタートします 。

• ホスト名（レコード名）: _dmarc （※DMARCの仕様上、必ず _dmarc の指定が必要です）
• レコードタイプ: TXT
• 値:Plaintextv=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;
• TTL: 初期検証時は 300（5分など短めにしておくと変更の反映が早いため安全です）

5. STEP 4：DMARC集計レポート（RUA）の活用と確認方法

rua=mailto: で指定したアドレス宛に、Gmail や Docomo などの受信側サーバーから1日〜数日に1回、XML形式の集計レポートが届くようになります 。

レポートの読み方とツール

添付されている .xml （または .zip / .gz）ファイルは機械処理向けのため、目視での解読は困難です 。

• 無料ウェブ可視化ツール（MxToolbox, DMARCian XML Parser など）に XML ファイルをアップロードして確認する 。
• 専用の解析 SaaS サービス（Postmark DMARC などの無料/有料サービス）にレポート送付先アドレスを切り替えてグラフ可視化する 。

レポートで確認すべき点

• 自社で利用している正規の送信元（Google Workspace 等）が PASS（認証成功）になっているか 。
• 第三者によるなりすまし送信（FAIL）が発生していないか 。
• ※自社からの送信メールが問題なく PASS している通知もレポートには含まれます 。

6. STEP 5：DMARCポリシーの段階的強化（quarantine → reject）

レポートを確認し、正規メールの認証漏れ（メルマガツールや別Webサーバーからの送信漏れなど）がないことを確認できたら、段階的にセキュリティレベルを引き上げます 。

第1段階引き上げ：隔離モード（p=quarantine）

認証に失敗したサードパーティ等のなりすましメールを、受信者の「迷惑メールフォルダ」に隔離させます 。

Plaintext

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;

最終段階引き上げ：拒否モード（p=reject）

認証に失敗したなりすましメールを受信側サーバーで完全に拒否（受取拒否/ブロック）し、相手にすら届けさせない最高レベルのセキュリティにします 。

Plaintext

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

まとめ

1. SPF：ルートドメイン（空白）の TXT に記述。複数設定は改行で併記 。
2. DKIM：google._domainkey の TXT に記述。255文字制限は " で分割して回避 。
3. DMARC：_dmarc の TXT に記述。p=none から始めてレポート（RUA）を確認し、p=quarantine → p=reject へ安全に引き上げる 。

正しいステップを踏むことで、自社ドメインのなりすまし被害を防ぐとともに、大切なメールが相手に届く確率（到達率）を最大限に高めることができます 。