メルマモ

この記事でわかること

Cloudflare以外のクラウドDNS、主にAWS Route53とGoogle Cloud DNSで、メール送信に必要なDNSレコード（SPF、DKIM、DMARC、MX、PTRに関連する注意点）の設定・運用方法とトラブル対処を、初心者〜中級者向けにわかりやすくまとめます。

結論（まず押さえるポイント）

結論：正しいDNSレコードをDNSサービスのUI/APIで登録し、TTLやレコード形式（TXT/ CNAMEなど）をサービス仕様に合わせて運用すれば、メール到達率とセキュリティを大きく改善できます。Route53とGoogle Cloud DNSは基本概念は同じですが、インターフェースとAPI挙動に違いがあります。

なぜ重要か

メール認証（SPF/DKIM/DMARC）は、なりすまし防止と迷惑メール判定回避に直結します。DNSはその“台帳”なので、誤った入力や形式のミスで機能しないことがよくあります。例えると、郵便の宛名＋印鑑＋受取人の確認がそろって初めて確実に届けられるようなものです。

仕組み（初心者向け解説）

SPF（送信元IP許可）

SPFはTXTレコードで送信を許可するメールサーバーのIPや送信サービスを宣言します。受信側は送信元IPと照合します。

DKIM（署名）

DKIMは送信メールに電子署名をつけ、対応する公開鍵をDNSのTXTまたはCNAMEで公開します。署名キーはセレクタで識別されます。

DMARC（ポリシーと集計）

DMARCは送信ドメインのポリシー（reject/quarantine/none）とレポート送信先（rua/ ruf）を指定します。ruaは集計（Aggregate）レポート用のURIで、メールアドレス形式に見えますが実際は"mailto:"で始める指定が一般的です。

Cloud DNS別の実務ポイント

AWS Route53のポイント

TXTレコードの長さ制限：Route53自体は長いTXTを分割して登録できますが、DKIMキーを登録する際はダブルクォートで囲む必要はなく、AWSコンソールは自動で処理します。API/CLIでは文字列配列で指定することがあります。
CNAMEでのDKIM：SaaS（例：SendGrid等）がCNAMEでDKIMを要求することがあるため、同一ホスト名に既にレコードがあると登録できません。Route53は同名のCNAMEと他レコードの共存を許しません。
プロパゲーションとTTL：変更直後に反映されないことがあるため、検証前に十分（通常はTTL時間）待つか、TTLを一時的に短くしてから変更する手順が有効です。

Google Cloud DNSのポイント

インポート/エクスポート：zoneファイル形式での入出力が可能なので、複数レコードをまとめて管理したい場合に便利です。
TXTレコードの取り扱い：Googleも長いTXTを自動分割できますが、コンソール入力時にエスケープや改行が混在しないよう注意してください。
CNAME制約：こちらもCNAMEは同名の他レコードと併用不可です。MXやTXTと競合する場合は優先順位を考えて設計します。

設定手順（実践ガイド）

共通準備

ドメインの管理画面で現在のレコードをエクスポートしてバックアップする。
送信サービス（自社サーバー／SaaS）の指示に従い、追加すべきレコードの正確な文字列を用意する。

SPFの設定（例）

手順：

TXTレコードを作成。名前は空欄（@）かドメイン名、値は例："v=spf1 include:_spf.example.com ~all"。
複数サービスがある場合はincludeでまとめる（ただしDNSルックアップ回数が10回以内かに注意）。

DKIMの設定（例）

手順：

送信サービスから渡されたセレクタ（例：s1）と公開鍵を確認。
DNSにTXTまたはCNAMEレコードを登録。TXTならホスト名は"s1._domainkey"、値は公開鍵文字列（"v=DKIM1; k=rsa; p=..."）。
登録後、メールヘッダで署名が付与されているかを確認。

DMARCの設定（例）

手順：

TXTレコードのホスト名は"_dmarc"（例：_dmarc.example.com）。
値の例："v=DMARC1; p=quarantine; rua=mailto:dmarc-aggregate@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100;"
まずはp=noneで様子見（レポート収集）→ログ確認→段階的にquarantine/rejectへ移行するのが安全です。

よくあるトラブルと対処法

TXTが正しく反映されない

対処：TTLを確認、登録ミス（余分なダブルクォートや改行）を削除。コンソールとAPIでの表示差に注意。

DKIM署名が失敗する

対処：セレクタ名と公開鍵の一致、キーの途中でスペースや改行が入っていないかを確認。CNAME指定の場合、ターゲットが正しいかを検証。

SPFで"permerror"やルックアップ超過

対処：includeのネストを減らし、必要なら送信サービス側のIPを直接リストに入れるか、外部参照を整理します。

運用のコツと自動化

変更は段階的に：DMARCはまず報告モード(p=none)で影響を把握する。
監視：ruaレポートを自動集約するツールを導入すると運用が楽になります（レポートはXML）。
インフラ移行時の注意：ネームサーバーを移す際は、TTLを下げ、切替後に古いゾーンを残しておく短期戦略が有効です。

他の技術との関係

PTR（逆引き）は送信元IPの信頼に影響しますが、DNSゾーンではなくIPを管理するISP/クラウド側の設定領域です。SPF/DKIM/DMARCと合わせて考えると到達率改善に役立ちます。

まとめ

結論：Route53とGoogle Cloud DNSでは基本的手順は同じですが、レコードの作成方法やCNAMEの共存制約、TXTの扱いに注意が必要です。まずは現状バックアップ→SPF/DKIM/DMARCの順で設定→DMARCは報告モードで観察→問題あればログ解析という流れをおすすめします。

最後に一言：DNSは慎重な作業が求められますが、正しく整備すればメールの信頼性が大きく向上します。小さな設定ミスが大きな配信影響を生むため、必ず手順どおりに実施してください。

Cloud DNSでメール認証レコードを正しく管理