/
メール認証DNSレコード生成

メール認証DNSレコード生成

SPF、DKIM、DMARC、MX、BIMIなど主要なメール認証DNSレコードを一括自動生成。なりすましや迷惑メール判定を防止し、BINDゾーンファイルの書き出しや到達率100%の最適化を支援します。

✨ クイックプリセット:

リアルタイム メール認証配信パイプライン

現在のDMARCポリシー:p=none
送信元MTAacme-corp.comSPFゲート判定~all (1/10 回検索)RFC 7208DKIM検証google (RSA-2048)RFC 6376DMARCアライメント判定p=none (100%)RFC 7489受信トレイ到達監視のみ (none)迷惑メール / 隔離バイパス受信拒否 / Drop 550非アクティブ
ドメインおよびメール配信環境設定acme-corp.com
SPFレコード設定 (RFC 7208)1/10 回検索
DKIMレコード設定 (RFC 6376)
DMARCポリシー制御エンジン (RFC 7489)_dmarc.acme-corp.com
ポリシー適用率パーセンテージ (pct=)100%
MXメールルーティング (RFC 5321)1 台のサーバー
1smtp.google.com.
BIMIブランドロゴ表示制御 (BIMI v1)
ドメイン名: acme-corp.comSPF Lookup回数: 1/10
生成されたすべてのDNSリソースレコード一覧です。個別値のコピーまたはゾーンファイル全体のエクスポートが可能です。4 件のレコード
種別ホスト名 / レコード名優先度 / TTLレコード値操作
MX@1 (TTL 3600)smtp.google.com.
TXT@3600v=spf1 include:_spf.google.com ~all
TXTgoogle._domainkey3600v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0w9Z8fGk3wIDAQAB
TXT_dmarc3600v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
合計レコード数: 4セキュリティ状態: B (65/100)
RFC 7208 Lookup許容量
1 / 10PermError 回避（正常）
暗号鍵セキュリティ強度
RSA-2048単一文字列
なりすまし防止ポリシー
p=none100% 段階的ロールアウト

クライアントサイド高速処理

すべての構文検証および計算処理がブラウザのメモリ上のみで高速に完結します。

サーバー送信ゼロの完全プライバシー

秘密鍵やドメイン設定情報を含むすべてのペイロードはローカルに保持され、外部送信されません。

即座に本番導入可能な出力

BINDや主要DNSプロバイダの規格に準拠したクリーンで最適化されたレコードを出力します。

技術リファレンス・アーキテクチャガイド

Email DNS Record Generator (SPF DKIM DMARC) ガイド — 技術リファレンス

SPF、DKIM、DMARC、MX、BIMIを含むメール送信用DNSレコードを一括生成・検証。BINDゾーンファイルの出力、なりすましメール対策、主要受信プロバイダでの到達率100%達成を支援する技術仕様ガイド。

Email DNS Record Generator (SPF DKIM DMARC) ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図
Email DNS Record Generator (SPF DKIM DMARC) ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図

主要パラメータと設定項目

v=spf1 (SPFプロトコルバージョン宣言)文字列 ("v=spf1")

対象のTXTレコードがRFC 7208に準拠したSPFバージョン1ポリシー定義であることを宣言します。レコード文字列の先頭プレフィックスとして必須であり、先行文字や小文字表記（v=spf1以外）が存在する場合、受信側MTAは構文エラー（PermError）として判定します。

初期値: v=spf1
include (委任送信ドメイン指定メカニズム)ドメイン文字列リスト ("include:domain.com")

サードパーティの外部メール送信サービス（Google Workspace、SendGrid等）のSPFレコードへ認証権限を委任します。各includeメカニズムは再帰的なDNSクエリをトリガーし、RFC 7208で義務付けられた『10回以内』のDNSルックアップ制限を消費します。

初期値: _spf.google.com
all (SPFフォールバック修飾子)列挙型 ("-all" | "~all" | "?all" | "+all")

先行メカニズムに一致しない未承認IPアドレスからの送信メールに対する処理ポリシーを指定します。'-all'は厳格な拒絶（HardFail）、'~all'は不審メールとしてマークしつつ受信するSoftFail、'?all'は判定を行わないNeutralを示します。

初期値: ~all
k & p (DKIM暗号化アルゴリズムおよび公開鍵データ)列挙型 ("rsa" | "ed25519") & Base64公開鍵文字列

<selector>._domainkey.<domain> のTXTレコードに公開されます。RFC 6376およびRFC 8463に基づき、受信側MTAがメールのDKIM-Signatureヘッダーを電子署名検証するための鍵アルゴリズム（k）とBase64エンコードされた公開鍵（p）を定義します。

初期値: k=rsa; p=...
p & sp (DMARC基本ポリシーおよびサブドメインポリシー)列挙型 ("none" | "quarantine" | "reject")

RFC 7489に基づき、DMARCアライメント検証に失敗したメールを受信メールサーバーがどのように処理するかを指定します。'none'は監視のみで配送継続、'quarantine'は迷惑メールフォルダへの隔離、'reject'はSMTP接続段階で受信を即時拒否します。

初期値: none
rua & ruf (DMARCフィードバックレポート先URI)URIリスト (mailto:[email protected])

ruaは送信総数や認証合否結果をまとめた日次集約XMLレポートを受信し、rufはRFC 6591 AFRF形式による認証失敗インシデントの個別フォレンジック通知を準リアルタイムで受信します。

初期値: mailto:[email protected]
aspf & adkim (DMARC識別子アライメントモード)列挙型 ("r" | "s")

SPFおよびDKIMのアライメント判定厳格度。'r'（緩和モード）はサブドメインと親組織ドメインの一致を許容し、's'（厳格モード）はRFC 5322 FromヘッダーのドメインとSPF Return-PathドメインまたはDKIMのd=ドメインの完全一致（byte-for-byte）を要求します。

初期値: r
BIMIロゴ指定および認証局証明書 (l= および a= タグ)HTTPS URI文字列

default._bimi.<domain> 配下にTXTレコードとして公開されます。l=タグは正方形のSVG Tiny Portable/Secure（Tiny-PS）規格のブランドロゴURLを指定し、a=タグは認証局が発行したPEM形式のVMC（Verified Mark Certificate）証明書URLを指定します。

初期値: なし (None)

現場のベストプラクティス・実践Tips

致命的なSPFのDNSルックアップ10回制限超過を回避する

RFC 7208により、SPFレコード評価時のDNSクエリ回数はinclude、a、mx、ptr、redirect等のメカニズム合計で厳格に最大10回までに制限されています。11回以上の問い合わせが発生すると即座にPermError（恒久的エラー）となり、Google WorkspaceやMicrosoft 365などの主要受信側で認証失敗・迷惑メール判定を受けます。aやmxメカニズムの使用を避け、直接IPv4/IPv6 CIDRブロック（ip4:/ip6:）を指定するか、連携SaaSのincludeチェーンをフラット化（集約）してください。

BINDおよびCloudflareでのDKIM 2048ビット鍵の255文字分割

RFC 1035の仕様上、DNS TXTレコードの単一文字列は最大255バイトに制限されています。標準的な2048ビットRSA公開鍵はBase64形式で約400文字に達するため、鍵を切り詰めるのではなく、複数文字列に分割して二重引用符で囲み括弧で連結表記する必要があります（例: ("v=DKIM1; k=rsa; p=前半文字列..." "後半文字列...")）。Cloudflare等の最新DNSは自動分割しますが、BINDゾーンファイルでは明示的な丸括弧による文字列連結記述が必須です。

DMARCポリシーを安全に完全強制化する3段階移行プロトコル

本番環境ドメインで最初から'p=reject'を適用してはいけません。まずは'p=none; rua=mailto:...'を2〜4週間運用し、CRMや経理システム、外部ヘルプデスクなど社内の正規送信経路（シャドーIT）をruaレポートで漏れなく可視化します。その後、'p=quarantine; pct=25'から段階的に100%まで引き上げ、全正規送信元でDKIMおよびSPFのアライメント合格を確認した上で最終的に'p=reject; sp=reject'へと移行してください。

sp=rejectによる休眠サブドメインのなりすまし悪用遮断

攻撃者はメール送信設定が行われていない休眠サブドメイン（例: invoice.example.com など）を悪用してフィッシング詐欺メールを送信することが多々あります。組織の親ドメインが導入検証期（p=none）であっても、'sp=reject'を明示的に付与することで、未設定のサブドメインからの不正送信を即座にブロックしつつ、親ドメインの通常メールトラフィックへの影響を防ぐことができます。

よくある落とし穴とトラブルシューティング

⚠️SPFとDKIMの単体認証がPASSしているにもかかわらずDMARCアライメントに失敗する

DMARC合格には、技術的な暗号・IP認証の通過だけでなく『識別子アライメント（一致性）』が不可欠です。受信者に表示されるRFC 5322 Fromヘッダーのドメインが、SPFのRFC 5321 Return-Path（Mail From）ドメインまたはDKIM署名のd=タグドメインと組織レベルで一致しているか確認してください。外部配信SaaS（SendGridやZendesk等）を利用している場合は、ベンダー共通ドメインではなく自社ドメインの独自DKIM鍵とカスタムReturn-Path（CNAME）を設定する必要があります。

⚠️GmailやYahoo宛ての送信メールが『550-5.7.26 認証エラー』で一斉に拒否される

2024年2月よりGoogleおよび米Yahoo（日本の主要プロバイダも追従）は、1日5,000通以上を配信する一括送信者に対してSPF、DKIM、DMARCの導入を義務化しました。ドメインに有効なDMARCレコード（最低でもp=none）が公開されていること、送信サーバーのホスト名と正引き・逆引き（rDNS/PTRレコード）が完全に一致していること、メルマガ等の大量配信にRFC 8058準拠のワンクリック配信停止ヘッダーが付与されていること、およびSPFのDNSルックアップ数が10回未満であることを確認してください。

⚠️DNS管理画面で『文字列が255文字を超えています』または『TXTレコードの構文が無効です』というエラーが出る

2048ビットや4096ビットのDKIM公開鍵を、文字列自動分割に非対応のレジストラや古いDNS管理画面にそのまま貼り付けた場合に発生します。本ツールの『255バイト安全分割』オプションを有効化し、ダブルクォーテーションで区切られた複数文字列形式で出力して登録するか、送信側MTAが対応している場合は最新の楕円曲線暗号Ed25519（鍵長が非常にコンパクト）への移行を検討してください。

よくある質問 (FAQ)

SPFのDNSルックアップ10回制限はメール到達率にどのような影響を与えますか？▼

RFC 7208の規定により、SPFレコードの評価中に発生するDNSクエリ（include:、a、mx、ptr、exists:、redirect等のメカニズム解決）は、直接・再帰的問い合わせを合算して厳格に最大10回までに制限されています。11回目のルックアップが発生した瞬間、受信側MTAは即座に評価を中断し『PermError（恒久エラー）』を出力します。Google Workspace、Microsoft 365、Yahooなどの主要メールプロバイダはPermErrorを認証失格とみなし、メールを迷惑メールフォルダへ振り分けるか、SMTP通信段階で受信拒否します。上限超過を防ぐには、不要なaやmx指定を廃止し、自社固定IPを直接ip4:/ip6:のCIDR形式で記述するとともに、複数の外部SaaSが入れ子になったincludeチェーンの整理・フラット化が必要です。

SPFとDKIMが合格（pass）しているのにDMARCアライメントに失敗する原因は何ですか？▼

DMARC認証では、SPFやDKIMの技術的な検証が成功することに加え、認証されたドメインがユーザーに表示される『RFC 5322 Fromヘッダー（送信元アドレス）』と組織レベルで一致（アライメント）することが求められます。SendGrid、Salesforce、Shopifyなどのクラウド配信サービスを利用する際、独自ドメイン設定を行わないと、SPFはベンダー所有のドメイン（Return-Path: sendgrid.netなど）で合格し、DKIMもベンダー共通鍵で合格しますが、どちらも送信元ドメイン（例: yourcompany.co.jp）とは一致しません。この認証ドメインの不一致によりDMARCアライメントが失格となります。これを解決するには、SPF用のカスタムReturn-Pathサブドメインを設定し、自社ドメイン名で電子署名を行う専用のDKIM CNAMEレコードを公開する必要があります。

DNS TXTレコードの255文字上限を超えるDKIM 2048ビット公開鍵はどのように分割記述しますか？▼

RFC 1035により、DNS TXTレコード内の1つのテキスト文字列は255オクテット（バイト）以下に定められています。Base64化された2048ビットRSA公開鍵は約400文字になるため、2つ以上の文字列に分割して登録する必要があります。BINDゾーンファイルやPowerDNSでは、レコード全体を丸括弧で囲み、各文字列ブロックをダブルクォーテーションで囲んで記述します（例: ( "v=DKIM1; k=rsa; p=第1ブロック" "第2ブロック" )）。DNSリゾルバがクエリした際、これらの隣接する文字列はスペースを挟まず自動的に1本の鍵文字列として連結復元されます。Cloudflare、AWS Route 53、Google Cloud DNS等の最新クラウドDNSは1つの長い文字列として貼り付けてもバックエンドで自動分割しますが、従来型のcPanelや国内ドメイン管理画面では手動分割や複数行引用符による入力が求められます。

DMARCポリシーのp=none、p=quarantine、p=rejectの違いは何ですか？▼

p=タグは、自社ドメインを騙る送信メールがSPFおよびDKIMのアライメント検証の両方に失敗した場合に、受信側MTAが適用すべき処置を指示します。'p=none'は監視・情報収集モードであり、不合格メールも正常に受信トレイへ届きますが、集約されたXMLレポートがruaアドレスへ送信され送信実態を把握できます。'p=quarantine'は隔離ポリシーであり、不合格メールを受信者の迷惑メールフォルダや隔離領域へ振り分け、受信者をフィッシング被害から保護しつつメールの確認を可能にします。'p=reject'は完全拒否ポリシーであり、SMTPトランザクション層でエラー（550 SMTP拒絶）を返し、なりすましメールの配送を完全に遮断します。

GmailやApple MailでBIMIレコードとVMC（マーク証明書）を設定するにはどうすればよいですか？▼

BIMI（Brand Indicators for Message Identification）を導入すると、GmailやApple Mail、米Yahoo等の受信トレイで送信者名の横に公式ブランドロゴを表示できます。実装手順は以下の通りです: 1) ドメインに'p=quarantine (pct=100)'または'p=reject'のDMARCポリシーを適用していること。2) 正方形・スクリプト排除・XML形式のSVG Tiny Portable/Secure（Tiny-PS）規格に完全準拠したロゴ画像を用意すること。3) 特許庁等に登録された商標に基づき、認定認証局（DigiCertやEntrust等）からPEM形式のVMC（Verified Mark Certificate）を取得すること。4) DNSの『default._bimi.自社ドメイン』にTXTレコードとして『v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/cert.pem』を公開すること。米Yahoo等はVMCなしでもロゴ表示をサポートしますが、GmailおよびApple Mailではロゴ表示に正規VMC証明書が必須です。

関連開発者ツール

全ツール一覧 →
JWTデコード・署名検証セキュリティ

JWTトークンをブラウザ上で安全にデコード・検証。ヘッダーやクレームの解析、HS256・RS256・ES256の暗号署名検証、有効期限チェックを完全ローカルで実行します。

ツールを開く→
CSPヘッダー生成ツールセキュリティ

堅牢なContent Security Policy（CSP）ヘッダーを即座に自動生成。script-src、style-src、nonce、ハッシュ値を設定し、XSS攻撃の防止とCSPエラーの解消を支援します。

ツールを開く→
Bcrypt ハッシュ生成＆パスワード検証ツールセキュリティ

ソルトラウンド数 (4〜16) を自由に設定できるEksblowfish暗号ベースのBcryptハッシュ生成＆ローカル検証ツール。完全ブラウザ完結。

ツールを開く→
HMAC 署名生成・整合性検証ツールセキュリティ

RFC 2104 準拠の鍵付きハッシュ（HMAC-SHA256、HMAC-SHA512、HMAC-SHA1、HMAC-MD5）をブラウザ内で瞬時に算出・定数時間（Timing-Safe）検証。

ツールを開く→
クライアントサイド AES-GCM / CBC 暗号化・復号ツールセキュリティ

Web Crypto APIによるブラウザ内ハードウェア高速化AES-256認証暗号。サーバー送信一切なし、完全ローカル実行。

ツールを開く→
RSA 公開鍵・秘密鍵ペア生成ツールセキュリティ

Web Crypto APIを利用して、ブラウザ内で安全に2048/4096ビットのRSA暗号化キーペア（PEM形式）を生成・ダウンロードできます。

ツールを開く→