送信ドメインを認証するには、3つのDNSレコードを公開し、Gmail、Yahoo、Outlookをはじめとするすべての受信サーバーに、メッセージが確かにご自身のものであることを証明します。SPFは送信を許可するサーバーを列挙し、DKIMは各メッセージに暗号署名を付与し、DMARCはこれらのチェックに失敗した場合の動作を受信側に伝えます。一度にまとめて作業すれば通常は約30分で完了し、受信トレイへの到達率を高めるうえで最も効果の大きい施策です。
始める前に。ドメインのDNS設定(レジストラまたはCloudflareなどのDNSホスト)にアクセスできること、そしてMigoSMTPダッシュボードのドメインセクションに表示される、お客様のドメイン専用のレコード値が必要です。本ガイドのプレースホルダーではなく、ダッシュボードの値を使用してください。
ポイントのまとめ
- 現状を確認する。重複を避け、既存のものを編集できるよう、現在のSPF、DKIM、DMARCレコードを調べます。
- SPFレコードを1つ公開する。ドメインのルートに、御社として送信するすべてのサービスを含めた単一のTXTレコードを設定します。
- DKIMを公開する。各メッセージに署名が付くよう、ダッシュボードのセレクターレコードを公開します。
- DMARCをp=noneで公開する。レポート送信先アドレスを指定し、監視モードで開始します。
- 検証する。digを実行し、テストメールを送信してヘッダーを確認します。
- 強制適用する。レポートを確認したうえで、p=quarantine、続いてp=rejectへ移行します。
送信ドメインを認証するとはどういうことですか
メールは、送信者を検証する仕組みを持たない設計で作られました。誰でもFromフィールドに他人のアドレスを入力できるため、フィッシングやなりすましが多発しています。認証は、受信サーバーに対してそれぞれ異なる問いに答える3つの補完的なチェックで、この隙を埋めます。
- このサーバーは、このドメインとして送信することを許可されているか。これがSPF(Sender Policy Framework、RFC 7208で定義)です。
- このメッセージは確かにこのドメインから送られ、改ざんされていないか。これがDKIM(DomainKeys Identified Mail、RFC 6376)です。
- いずれかのチェックに失敗した場合どう扱い、誰にレポートを送るか。これがDMARC(RFC 7489)です。
受信側はこの3つを組み合わせて信頼性を判断します。認証に成功し、Fromドメインとアライメントが取れているメッセージは、時間をかけて安定したドメインレピュテーションを築きます。そうでないメッセージはフィルタリング、遅延、拒否の対象となり、大量送信の場合は主要なメールボックスプロバイダーに完全に拒否されるようになっています。
SPF、DKIM、DMARCの比較
| SPF | DKIM | DMARC | |
|---|---|---|---|
| 何を証明するか | 送信サーバーがドメインに対して許可されていること | メッセージがドメインによって署名され、転送中に変更されていないこと | チェック結果が表示されるFromドメインとアライメントしていること、およびポリシーを定めること |
| DNS上の場所 | ドメインルートのTXTレコード | selector._domainkeyのTXTまたはCNAME | _dmarcのTXTレコード |
| 何を検査するか | Return-Path(エンベロープ送信者)ドメインと送信元IP | DKIM-Signatureヘッダー内の署名 | SPFおよびDKIMの結果に対するFromヘッダーのドメイン |
| 転送後も有効か | 通常は無効 | はい(内容が変更されない場合) | DKIMがパスしアライメントしていればパス |
| 主な失敗原因 | 送信元の記載漏れ、またはルックアップが10回超 | セレクターの誤り、または鍵のコピーミス | アライメントの不一致 |
始める前に:必要なもの
- ドメインのDNSを編集できる権限(レジストラ、Cloudflare、cPanel、またはお使いのDNSホスト)。
- 御社のドメインとしてメールを送信するすべてのサービスの一覧:MigoSMTPアカウント、社内メール(Google WorkspaceまたはMicrosoft 365)、CRM、請求システム、サポートツールなど。
- DMARCレポートを受信するメールボックス。dmarc-reportsなど、御社ドメインの専用アドレスが望ましいです。
- MigoSMTPダッシュボードのドメインページに表示されるSPFのincludeおよびDKIMレコードの値。
ヒント。マーケティングメールとトランザクションメールの両方を送信する場合は、今のうちにサブドメインを分けておくことをおすすめします(例:トランザクション用にmail.example.com、キャンペーン用にnews.example.com)。後から整理するより、最初に設定するほうがはるかに簡単です。詳しくは後述のサブドメインのセクションをご覧ください。
ステップ1:現在のレコードを確認する
認証が失敗する最も多い原因は、レコードの重複です。何かを追加する前に、すでに公開されているものを確認してください。macOSまたはLinuxではdig、Windowsではnslookupを使用します。
dig +short TXT example.com
dig +short TXT _dmarc.example.com
# Windows
nslookup -type=TXT example.comv=spf1で始まるTXTレコード(SPF)と、_dmarcにあるv=DMARC1で始まるレコードを探してください。どちらかがすでに存在する場合は、新たに追加せず、そのレコードを編集します。
ステップ2:SPFレコードを追加する
SPFは、ドメインのルートに設定する単一のTXTレコードです。エンベロープ送信者(Return-Path)にご自身のドメインを使ってメールを送信できるサービスを列挙します。
SPFレコードの構文
v=spf1 include:YOUR-MIGOSMTP-INCLUDE include:_spf.google.com ~all| 要素 | 意味 |
|---|---|
v=spf1 |
必須。レコードがSPFバージョン1であることを示します。 |
include:domain |
指定したドメイン自身のSPFレコードが許可するものをすべて許可します。MigoSMTPダッシュボードの値を使用してください。 |
ip4:203.0.113.10 |
特定のIPv4アドレスまたは範囲を許可します。IPv6にはip6:を使用します。 |
a, mx |
ドメインのAレコードまたはMXレコードのIPを許可します。 |
~all |
ソフトフェイル:記載のないものは疑わしいと扱いますが、即座には拒否されません。送信元を追加している段階でよく使われます。 |
-all |
ハードフェイル:記載のないものは許可されません。すべての送信元を記載したと確信できてから使用してください。 |
重要。1つのドメインに公開できるSPFレコードは1つだけです。(たとえばGoogle Workspace用に)すでにSPFレコードがある場合は、2つ目のTXTレコードを作成せず、そのレコードにMigoSMTPのincludeを追加してください。
10回のルックアップ上限
SPFの評価で発生してよいDNSルックアップは最大10回です。include、a、mx、exists、redirectはすべてカウントされ、インクルードしたレコード内で行われるルックアップも含まれます。上限を超えると受信側は永続的なエラーを返し、すべてのメッセージでSPFが失敗します。ルックアップ数を抑えるには、使用していないサービスを削除する、安定している場合はaやmxを明示的なip4の範囲に置き換える、あまり使わないツールを専用のサブドメインに移す、といった方法があります。
SPFのよくある間違い
- 同じ名前にSPFレコードが2つある(1つにまとめてください)。
- インターネット全体を許可してしまう
+allを使っている。 - include値に余分なスペースがある、またはコロンが抜けている。
- 請求システムやヘルプデスクなどの送信元を記載し忘れ、そのメールがSPFに失敗する。
- ドメインルートではなく、wwwホストなど誤った名前にSPFを公開している。
ステップ3:DKIMレコードを公開する
DKIMは、すべてのメッセージにデジタル署名を付与します。送信プラットフォームが、秘密にしている秘密鍵で送信メールに署名し、対応する公開鍵をDNSに公開することで、受信側が署名を検証できるようになります。
セレクターとレコードの設定場所
各鍵は、セレクターと呼ばれる名前の下に置かれ、selector._domainkey.yourdomain.comという形式になります。セレクターを使うことで、複数の鍵を同時に公開し、ダウンタイムなしでローテーションできます。お客様のドメインに対応する正確な名前と値は、MigoSMTPダッシュボードに表示されます。
Name: selector1._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(long public key)TXTかCNAMEか
プラットフォームによっては、公開鍵をTXTレコードとして直接公開するよう求められます。また、プラットフォーム側が管理するレコードを指すCNAMEが提供され、鍵のローテーションを代行してもらえる場合もあります。ダッシュボードに表示されたタイプのとおりに公開してください。一方を他方に変換しないでください。
鍵の長さとフォーマット
- 可能な場合は2048ビットのRSA鍵を使用してください。1024ビットの鍵は多くの受信側でまだ受け入れられていますが、脆弱とされています。
- 2048ビットの鍵は255文字を超え、DNSの1つの文字列は255文字を超えられません。DNSホストで、値を1つのTXTレコード内の複数の引用符付き文字列に分割する必要があります。多くの管理画面は自動で分割しますが、そうでない場合は手動で分割してください。
- 改行やスマートクォートを加えずに値をコピーし、DNSホストが要求しない限り、余分な引用符で囲まないでください。
ローテーション
DKIM鍵は6〜12か月ごとに、秘密鍵が漏洩した可能性がある場合は直ちにローテーションしてください。まず新しいセレクターを公開し、署名をそちらに切り替え、古いセレクターで署名されたメールの到着が完了してから古いセレクターを削除します。
ステップ4:DMARCレコードを公開する
DMARCは、SPFとDKIMを受信者が実際に目にするFrom行のドメインに結び付け、認証に失敗したメールの扱いを受信側に伝えます。これは_dmarc.yourdomain.comに設定するTXTレコードです。何かを強制適用する前に、誰が御社として送信しているかを把握できるよう、監視モードで開始してください。
Name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1| タグ | 役割 | 一般的な値 |
|---|---|---|
v |
バージョン。必ず先頭に記述します。 | DMARC1 |
p |
認証に失敗したメールのポリシー:none(監視)、quarantine(迷惑メールフォルダー)、reject(拒否)。 | 最初はnone |
rua |
日次の集計レポートの送信先。 | mailto:dmarc-reports@example.com |
ruf |
失敗サンプルの送信先。送信する受信側はわずかです。 | 任意 |
pct |
ポリシーを適用する、認証に失敗したメールの割合。段階的な移行時に使用します。 | 25、50、100 |
sp |
親ドメインと異なる場合の、サブドメインのポリシー。 | 必要な場合を除きpと同じ |
adkim, aspf |
アライメントモード:r(relaxed、緩やか)またはs(strict、厳格)。 | デフォルトはr(relaxed) |
fo |
失敗レポートを生成するタイミング。 | 1 |
「アライメント」の本当の意味
DMARCは、SPFまたはDKIMがパスし、かつパスしたドメインがFromドメインとアライメントしている場合にパスします。relaxedアライメントでは、Fromドメインのサブドメインもアライメントしているとみなされるため、bounce.example.comのReturn-Pathはnews@example.comのFromとアライメントします。strictアライメントでは、ドメインが完全に一致する必要があります。「SPFはパスするのにDMARCが失敗する」最も一般的な原因は、Return-PathまたはDKIMのドメインが、御社ではなく送信プラットフォームのものになっていることです。カスタムReturn-Pathと独自のDKIM署名ドメインを有効にすれば解決します。
ステップ5:すべてが機能していることを確認する
DNSでレコードを確認する
dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com各コマンドは、公開したレコードを返すはずです。何も返ってこない場合は、レコードが誤った名前に設定されているか、まだ伝播していません。TTLが切れるのを待ってから、再度テストしてください。
テストメールを送信してヘッダーを確認する
- 認証済みのドメインから、ご自身が管理するGmailアドレスにメールを送信します。
- メッセージを開き、3点メニューからメッセージのソースを表示を選択します。
- 上部に、SPF、DKIM、DMARCそれぞれのPASSまたはFAILが表示されます。
- 各PASSの横に表示されるドメインが、Fromドメインと一致していることを確認します。
正常な状態とは。SPF:御社のドメインでPASS。DKIM:d=yourdomain.comでPASS。DMARC:PASS。neutral、softfail、failのいずれかが表示される場合は、下記のエラー表を参照してください。
DMARCを安全に移行する:p=noneからp=rejectへ
最終目標はp=rejectです。これが、第三者によるドメインのなりすましを防げる唯一のポリシーだからです。ただし、一気に移行すると、見落としていたツールからの正当なメールをブロックしてしまうおそれがあります。段階的に進め、レポートを参考にしてください。
| 段階 | ポリシー | 期間 | やること |
|---|---|---|---|
| 1. 監視 | p=none |
2〜4週間 | 集計レポートを読みます。御社のドメインとして送信しているすべての送信元を洗い出し、正当なものは修正または許可します。 |
| 2. 部分的な隔離 | p=quarantine; pct=25 |
1〜2週間 | 認証に失敗した、トラフィックの25パーセントのメールが迷惑メールになります。メールが届かないという苦情がないか注意します。 |
| 3. 完全な隔離 | p=quarantine |
2週間 | レポートで失敗しているのが未許可の送信元だけになったら、pctを100に引き上げます。 |
| 4. 拒否 | p=reject |
継続 | rejectに移行します。必要に応じてpctを段階的に引き上げます。毎月レポートの確認を続けてください。 |
DMARCの集計レポートは圧縮されたXMLファイルとして届き、手作業で読むことは想定されていません。無料または有料のDMARCレポート分析ツールを使って、送信元、送信量、パス・失敗の結果を一覧表にまとめてください。
大量送信者向けのGmail、Yahoo、Microsoftの要件
2024年2月から、GmailとYahooは大量にメールを送信する送信者に対して、認証と配信停止に関するルールの適用を開始しました。Microsoftも、2025年5月からOutlook.comの個人向けメールボックスに同等の要件を適用し始めました。概要は次のとおりです。
| 要件 | すべての送信者 | 大量送信者(プロバイダー宛に1日約5,000通以上) |
|---|---|---|
| SPFまたはDKIM | 必須 | 両方必須 |
| DMARCレコード | 推奨 | 必須(少なくともp=none、Fromとアライメント) |
| ワンクリック配信停止 | トランザクションメールでは不要 | マーケティングメールおよび購読メールでは必須(RFC 8058ヘッダー)。リクエストは2日以内に対応 |
| スパム苦情率 | 低く保つ | 0.10パーセント未満を維持し、0.30パーセントには決して到達させない(Google Postmaster Tools) |
| 有効な正引き・逆引きDNS、TLS | 必須 | 必須 |
しきい値はプロバイダーによって変更される可能性があるため、各社の最新の送信者ガイドラインをご確認ください。リンクは本ガイド末尾の参考資料一覧に掲載しています。
サブドメインでマーケティングメールとトランザクションメールを分離する
レピュテーションは、送信ドメインとIPごとに追跡されます。プロモーションキャンペーンで苦情が発生しても、パスワードリセットのメールが迷惑メールに振り分けられては困ります。一般的には、ストリームごとに1つのサブドメインを使います。
| ストリーム | Fromアドレスの例 | 分離する理由 |
|---|---|---|
| トランザクション | noreply@mail.example.com | 常に迅速に届く必要があります。低ボリュームで高いエンゲージメントがレピュテーションを高く保ちます。 |
| マーケティング | hello@news.example.com | ボリュームが大きく、苦情も増えやすいため、問題を局所化できます。 |
| 社内メール | name@example.com | 従業員のメールボックスを、大量送信のリスクから守れます。 |
各サブドメインには、それぞれSPFとDKIMのレコードが必要です。親ドメインのDMARCレコードは、デフォルトでサブドメインも保護します。異なるポリシーが必要な場合は、sp=タグを追加するか、サブドメインに別のレコードを設定してください。
よくある認証エラーと対処法
| 症状 | 考えられる原因 | 対処法 |
|---|---|---|
| SPF permerror、または「too many DNS lookups」 | ルックアップが10回超、または構文エラー | 不要なincludeを削除し、安定した範囲はip4に置き換え、まれにしか使わない送信元はサブドメインに移します。 |
| Multiple SPF records found | v=spf1で始まるTXTレコードが2つある | 1つのレコードにまとめます。 |
| DKIM: no key for signature | セレクター名が誤っている、またはレコードが未公開 | DKIM-Signatureヘッダーのセレクターを確認し、DNSの名前と照合します。 |
| DKIM: body hash did not verify | 署名後にメッセージが変更された(フッターの追加や、他のシステムによるリンクの書き換えなど) | 変更を加える処理を無効にするか、署名より前に移します。 |
| SPFはパスだがDMARCは失敗 | Return-PathドメインがFromとアライメントしていない | 御社のドメインでカスタムReturn-Pathを使用します。 |
| DKIMはパスだがDMARCは失敗 | DKIMのd=ドメインがFromとアライメントしていない | プラットフォームのデフォルトではなく、御社のドメインで署名します。 |
| レコードが見つからない | ホスト名の誤り、末尾のドット、またはDNS管理画面によってドメインが二重に付加されている | 多くの管理画面はドメインを自動で付加します。その前の部分のみを入力してください(例:selector1._domainkey)。 |
| レコードが更新されない | 古いレコードがキャッシュされている | TTLが切れるまで待ちます。変更を予定している場合は、事前にTTLを短くしておきます。 |
認証チェックリスト
- ドメインルートにSPFレコードが1つで、ルックアップが10回以内、末尾が~allまたは-all。
- DKIMセレクターのレコードを公開済み。DNSホストが対応していれば2048ビット。
- _dmarcにDMARCレコードがあり、p=noneで、ruaアドレスが機能している。
- カスタムReturn-PathとDKIMドメインにより、両方がFromドメインとアライメントしている。
- テストメールでSPF、DKIM、DMARCがすべてPASSと表示される。
- 移行期間中、DMARCレポートを毎週確認している。
- マーケティングメールとトランザクションメールをサブドメインで分離している。
- DKIM鍵のローテーション用にカレンダーのリマインダーを設定している。
ドメインの検証を始めませんか。MigoSMTPに送信ドメインを追加し、お客様のアカウント専用の正確なレコードをコピーしてください。
参考資料・出典
- RFC 7208: Sender Policy Framework (SPF)
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC)
- RFC 8058: Signaling One-Click Functionality for List Email Headers
- Google: Email sender guidelines
- Yahoo: Sender best practices
- 関連ガイド:メールウォームアップガイドおよびSMTPバウンスコードの解説。
よくある質問
SPF、DKIM、DMARCはすべて必要ですか。どれか1つで十分ですか。
3つすべてを設定してください。2024年以降、GmailとYahooは、ユーザーに1日5,000通を超えるメールを送信する送信者に対し、SPFとDKIMに加えてDMARCレコードを必須としており、すべての送信者に少なくともSPFまたはDKIMが求められます。3つすべてを設定すると、レポートによる可視化となりすましへの対策も得られます。
送信ドメインの認証にはどのくらい時間がかかりますか。
レコードの公開自体は通常30分ほどです。DNSの変更は、古いレコードの有効期限(TTL)が切れた時点で反映されます。多くは数分、場合によっては数時間かかります。DMARCを強制的なポリシーへ移行するには、事前にレポートを確認する必要があるため、通常数週間かかります。
1つのドメインにSPFレコードを2つ設定できますか。
できません。ドメインが公開できるSPFレコードは1つだけです。v=spf1で始まるTXTレコードが2つあると、受信側は永続的なエラーを返し、SPFは失敗します。すべての送信元を1つのレコードにまとめてください。
SPFレコードのDNSルックアップが10回を超えるとどうなりますか。
SPFの評価は永続的なエラー(permerror)で停止し、チェックは失敗します。include、a、mx、exists、redirectの各項目は、インクルード先のレコード内で行われるルックアップも含めて、10回の上限にカウントされます。不要なincludeを削除するか、サービスをサブドメインに移してください。
DMARCのp=noneだけで十分ですか。
GmailやYahoo、Outlook.comの大量送信者向けルールの最低要件は満たしますが、認証失敗時の対応を受信側に指示するものではないため、なりすましは防げません。p=noneは監視フェーズと位置づけ、レポートに問題がなくなったらquarantine、さらにrejectへ移行してください。
DKIMの鍵長はどれくらいにすべきですか。
DNSホストが対応していれば、2048ビットのRSA鍵を使用してください。1024ビットの鍵も見かけますが、脆弱とされています。2048ビットの公開鍵は255文字を超えるため、1つのTXTレコード内で複数の引用符付き文字列に分割する必要があります。多くのDNS管理画面では自動的に分割されます。
SPFはパスするのに、なぜDMARCは失敗するのですか。
DMARCでは、単なるパスではなくアライメントが求められます。SPFをパスしたドメイン(Return-Pathドメイン)またはDKIMをパスしたドメイン(d=ドメイン)が、表示されるFromドメインと一致している必要があります。Fromアドレスに合致するカスタムReturn-PathまたはDKIM署名ドメインを使用してください。
トランザクションメールのみの送信者にもDMARCは必要ですか。
はい、必要です。パスワードリセットや領収書のメールは、フィッシングで最もなりすまされやすいメッセージであり、DMARCポリシーはご自身のドメインと受信者を守ります。また、大量送信者の送信量のしきい値を超えると必須になります。
DKIM鍵はどのくらいの頻度でローテーションすべきですか。
一般的には6〜12か月ごと、秘密鍵が漏洩した可能性がある場合は直ちに行います。まず新しいセレクターを公開し、署名をそちらに切り替え、古い鍵で署名されたメールの配送が完了してから古いセレクターを削除してください。
サブドメインは別々に認証すべきですか。
マーケティングメールとトランザクションメールを別のサブドメインから送信すると、一方のレピュテーションの問題がもう一方に影響しないため、推奨されます。送信に使う各サブドメインには、それぞれSPFとDKIMのレコードが必要です。親ドメインのDMARCレコードは、sp=タグまたはサブドメインのレコードで上書きしない限り、サブドメインにも適用されます。