AWS Route 53は、メールを認証する3つのDNSレコード（SPF、DKIM、DMARC）を公開する場所として、高速で信頼性の高いサービスです。ただしコンソールには、つまずきやすい慣習が2つあります。完全修飾のレコード名と、すべてのTXT値を二重引用符で囲むことが必須である点です。レコード自体は、どのDNSホストで公開する場合とも同じで、違うのはエディターだけです。このガイドでは、Route 53コンソールのどこで各レコードを追加するのか、レコード名のフィールドにルートドメイン、_dmarc、DKIMセレクターのそれぞれで何を入力するのか、そして見落とすと長いDKIM鍵が気づかないうちに壊れる引用符の癖を、順に解説します。
結論#
3つのレコードはすべて、Route 53のホストゾーン内にある通常のTXTレコードです。ホストごとに違うのは、命名規則と入力形式だけです。
- SPF：ドメインのルートにあるTXTレコードです。Route 53ではレコード名のフィールドを空欄のままにすると、ルートドメインに適用されます。
- DKIM：
<selector>._domainkey.yourdomain.comにあるTXTレコードです。レコード名のフィールドには<selector>._domainkeyの部分だけを入力します。セレクターと長い鍵の値は、どちらもメールサービスから提供されます。 - DMARC：
_dmarc.yourdomain.comにあるTXTレコードです。レコード名のフィールドに_dmarcと入力すると、Route 53がゾーンを補います。
値はサービスごとに異なるため、手書きしないでください。SPFの行はSPFレコード作成ツールで、ポリシーの行はDMARCレコード作成ツールで生成し、DKIM鍵はメールプラットフォームのダッシュボードからそのままコピーします。各レコードの仕組みについては、SPF・DKIM・DMARCの解説で、役割と重要性を説明しています。
SPF、DKIM、DMARCとRoute 53のレコードの対応#
Route 53は、DNSをホストゾーン（ドメインごとに1ゾーン）で管理します。ゾーン内のすべてのレコードには、ルートドメインを基準にした完全修飾名があります。コンソールでは、「Record name」ボックスの横にドメインのサフィックスが表示され、入力した文字列はその前に付加されます。この1点で、3つのレコードの場所がすべて説明できます。
| レコード | 「Record name」に入力する値 | 結果のレコード名 |
|---|---|---|
| SPF | （空欄のまま） | example.com |
| DKIM | s1._domainkey | s1._domainkey.example.com |
| DMARC | _dmarc | _dmarc.example.com |
Route 53コンソールでレコードを追加する場所#
3つのレコードとも、手順は同じです。Route 53コンソールを開き、左のナビゲーションでHosted zonesを選び、メールを送信しているドメインのゾーンをクリックします。Create recordをクリックします。「Quick create」と「Wizard」の切り替えが表示される場合は、TXTレコード1件の追加なら「Quick create」のほうが簡単です。
レコード作成フォームでは、3つの項目を設定します。Record name（前述の表にあるプレフィックス）、Record type（3つともTXT）、Valueです。ルーティングポリシーは、デフォルトの「Simple routing」のままにします。これらは単なる情報用のレコードで、トラフィックのルーティングではないためです。TTLもデフォルト（300秒または3600秒）で問題ありません。TTLを短くすると、テスト中に変更が反映されるのが早くなります。
ルートドメインにSPFレコードを公開する#
SPFは、自社ドメインを使ってメールを送信してよいサーバーを承認します。TXTレコードを作成し、ルートドメインに配置されるようレコード名を空欄のままにして、SPFの値を貼り付けます。一般的な値は次のようになります。
"v=spf1 include:amazonses.com include:_spf.google.com ~all"
全体が二重引用符で囲まれている点に注意してください。Route 53ではTXT値を引用符で囲む必要があります。忘れてもコンソールが通常は付けてくれますが、自分で含めておくほうが確実です。末尾の~allはsoftfailです。-allはhard failで、承認されていない送信者を受信側が完全に拒否するよう指示します。
特に重要なルールが2つあります。1つ目は、SPFレコードを必ず1つだけ公開することです。ルートにある2つ目のTXTレコードもv=spf1で始まっていると、SPFが無効になり、すべてのチェックが失敗します。すでに別のサービス経由で送信している場合は、新しいレコードを追加せず、すべてのinclude:メカニズムを1行にまとめてください。2つ目は、DNSルックアップを10回以内に収めることです。include:はそれぞれ1回として数えられ、超えると恒久的なSPFエラーになります。SPFレコード作成ツールは、実際に使っているサービスから有効な1行を作成し、ルックアップの上限についても警告します。
セレクターにDKIMレコードを追加する#
DKIMは、署名鍵の公開鍵側を公開し、受信側がメッセージの偽造や改ざんがないことを検証できるようにします。メールサービスからは、2つの情報が提供されます。セレクター（s1、google、ランダムな文字列などの短いラベル）と、長い公開鍵の値です。この鍵を、<selector>._domainkeyのTXTレコードとして公開します。
TXTレコードを作成し、レコード名のフィールドにセレクターと._domainkeyを続けて入力します（例：s1._domainkey）。値には、サービスから提供されたものを貼り付けます。値は次のようになります。
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
この値を自分で作ったり編集したりしないでください。メールプラットフォームの認証設定から、そのままコピーします。公開鍵は、署名に使われる秘密鍵と完全に一致していなければならないためです。サービスによっては（Amazon SESなど）、1つのTXTレコードではなく、CNAMEベースのDKIMレコードを3つ発行します。その場合は、提供された名前とターゲットで3つのCNAMEレコードを作成します。ここでも、プレフィックスを入力するとRoute 53がゾーンを補う、というルールは同じです。どちらの形式でも、値はサービスから提供されるものであり、自分で決めるものではありません。
_dmarcにDMARCレコードを公開する#
DMARCは、SPFとDKIMを表示される「From」アドレスに結び付け、認証に失敗したメールをどう扱うかを受信側に伝え、レポートを送ってもらう仕組みです。TXTレコードを作成し、レコード名のフィールドに_dmarcと入力して、初期ポリシーを貼り付けます。
"v=DMARC1; p=none; rua=mailto:dmarc@example.com"
まずはp=noneから始めます。これは監視モードで、メールの扱いは何も変わりませんが、毎日の集計レポートが有効になり、安全に展開を進められます。レポートで、正規の送信がすべてアライメントが一致した状態で認証に成功していると確認できてから、p=quarantine、さらにp=rejectへと引き上げます。初日からp=rejectを公開するのは、自社のメールを迷惑メールに送り込む最短の方法です。DMARCレコード作成ツールは、構文の正しいポリシーを作成します。DMARCの設定手順のガイドでは、監視からポリシー適用までの流れを詳しく解説しています。レポートが届き始めたら、DMARC集計レポートの読み方で、その活用方法を確認できます。ドメイン診断の監視は、MX、SPF、DKIM、DMARC、MTA-STS、BIMIを毎日チェックするため、貼り付けた値のせいでSPFやDMARCが壊れた場合は、メールで知らせてくれます。
長いDKIM鍵を壊す引用符の癖#
ここはRoute 53特有の注意点で、気づかないうちに失敗するため、じっくり確認してください。DNSのTXT文字列1つは、255文字までに制限されています。SPFの行やDMARCのポリシーのような短い値は、1つの引用符付き文字列に余裕で収まります。しかし2048ビットのDKIM公開鍵は255文字より長いため、1つの文字列には収められません。
Route 53では、値を複数の引用符付き文字列に分割します。各文字列は255文字以下で、同じレコード値の中に並べて置きます。DNSリゾルバーが、それらの文字列を連結して1つの鍵に戻します。コンソールのValueボックスでは、隣り合った2つの引用符付き文字列として表示されます。
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...up-to-255-chars"
"...the-remaining-characters-of-the-public-key"
注意点は、2つの文字列が間に空白を入れずに連結されて1つの連続した鍵になることです。分割する箇所に文字を追加しないでください。また、2つの文字列は別々の2つのレコードにせず、1つのTXTレコード値の中に収めてください。鍵自体は完全に見えるのに、セットアップ直後にDKIMのチェックが失敗する場合は、分割の誤りが原因であることがほとんどです。鍵全体を貼り付け、可能であればコンソールやツールに分割を任せ、結果は信用せずに確認してください。
レコードをコードで管理する#
Route 53は、Infrastructure as Codeを運用するチームに人気があり、コンソールを一切使わなくても構いません。AWS CLIでは、aws route53 change-resource-record-setsでレコードを公開します。名前、TXTタイプ、TTL、値を指定するJSONのチェンジバッチを渡します。Terraformでは、各レコードがaws_route53_recordリソースになります。
resource "aws_route53_record" "dmarc" {
zone_id = aws_route53_zone.primary.zone_id
name = "_dmarc.example.com"
type = "TXT"
ttl = 3600
records = ["v=DMARC1; p=none; rua=mailto:dmarc@example.com"]
}
ルールは同じです。ルートドメインにSPFレコードを1つ、DKIMの値はサービスから提供されたものをそのまま、DMARCはp=noneから始めます。255文字の文字列の制限もここで適用されます。長いDKIM鍵は、レコード値の中で複数の文字列に分割する必要があるため、レコードを適用したあと、公開された結果を確認してください。
ポリシーを適用する前に確認する#
Route 53のDNS変更は、通常1～2分以内に反映されますが、TTLや下流のキャッシュによって長引くことがあります。レコードが公開されたら、送信ドメイン認証チェックで、3つすべてが正しく解決され、解析できることを確認します。このツールは、SPFレコードの欠落や重複、分割や貼り付けを誤ったDKIM鍵、構文エラーのあるDMARCポリシーを指摘します。この3点が、Route 53で最も起こりやすい問題です。チェックツールの結果が問題なくなってから、DMARCポリシーをnoneからrejectへと段階的に引き上げます。
3つを公開して成功させることが、大量送信者向けのGoogleとYahooの送信者ガイドラインを満たす条件です。ただし、認証の限界は忘れないでください。認証が証明するのは送信者が誰かであり、良い送信者かどうかではありません。完全に認証されたメールでも、無効なアドレスだらけのリストに送れば、迷惑メールに振り分けられます。信頼できる送信元を受信トレイへの配信につなげるレピュテーションとリスト管理については、メール到達率ガイドで解説しています。
よくある質問
01ルートのSPFレコードでは、Route 53のレコード名に何を入力しますか？
空欄のままにします。Route 53では、名前が空のレコードはルートドメイン自体に適用されます。SPFのTXTレコードを置くべき場所がそこです。タイプをTXTにして、1つだけのv=spf1 ...の値を貼り付けてください。フィールドに@やドメイン名を入力しないでください。Route 53では、レコード名を空にすることでルートを表します。
02鍵は正しく見えるのに、Route 53でDKIMレコードが失敗するのはなぜですか？
ほとんどの場合、255文字の文字列制限が原因です。2048ビットのDKIM鍵は1つのTXT文字列には長すぎるため、Route 53では複数の引用符付き文字列に分割し、リゾルバーが連結する形にする必要があります。分割時に余分な空白が入る、文字が欠ける、あるいは2つの文字列が1つの値ではなく別々の2つのレコードになってしまうと、鍵は検証に通りません。鍵全体を貼り直し、1つのレコード値にまとめたうえで、DKIMチェックツールで確認してください。
03レコード名には_dmarcと入力しますか、それとも_dmarc.example.comと入力しますか？
_dmarcだけを入力します。Route 53はフィールドの横にドメインのサフィックスを表示し、自動的に付加するため、_dmarcは_dmarc.example.comになります。完全な名前を入力すると、_dmarc.example.com.example.comのように重複し、どの受信側も問い合わせません。DKIMセレクターにも、同じ付加のルールが適用されます。
04TerraformやCLIで、Route 53のSPF、DKIM、DMARCを管理できますか？
はい。Terraformでは各レコードがaws_route53_recordリソースに、CLIではaws route53 change-resource-record-setsのチェンジバッチになります。レコード名、タイプ、値はコンソールで入力するものと同じで、長いDKIM鍵の255文字の分割も同様に適用されます。まず値を生成し、次にコードにコミットして、公開された結果を確認してください。
Route 53は、命名と引用符のルールさえ分かれば、3つのレコードを簡単に設定できます。ただし、認証は受信トレイへの入場券にすぎません。レコードは無料ツールで作成し、その背後にあるリストは無料メールチェッカーでクリーニングしてください。無効なドメイン、入力ミス、スパムトラップをバウンスする前に見つけられます。信頼できる送信元も、署名するリストがクリーンでなければ、受信トレイへの配信は得られないからです。
