要点。 確認する場所:Authentication-Resultsヘッダー · SPF permerror:レコードが2つ、またはルックアップが10回超 · DMARC fail:多くはアライメントの問題 · ツール:無料のヘッダー解析ツール
要約
- 認証結果を見つける。 送信したメッセージを開き、元のソースまたは完全なヘッダーを表示します。
- SPFの結果の意味。 passは、送信元IPが記載されていることを意味します。
- DKIMの結果の意味。 passは、署名が公開鍵と一致したことを意味します。
- DMARCの結果の意味。 DMARCは、SPFまたはDKIMがパスし、そのドメインがFromドメインとアライメントしている場合にパスします。
- 対処:SPFレコードが見つからない。 ドメインにSPFのTXTレコードがないか、公開した名前とは別の名前が参照されていることを意味します。
- 対処:DKIM鍵が見つからない、または無効。 メッセージのDKIM-Signatureヘッダーにあるセレクター(s=の値)を確認し、selector._domainkey.yourdomain.comにTXTレコードが存在することを確かめます。
認証結果を見つける
送信したメッセージを開き、元のソースまたは完全なヘッダーを表示します。受信側サーバーが追加したAuthentication-Resultsというヘッダーを探してください。spf=pass、dkim=pass、dmarc=passのように各チェックの結果と、各チェックで使われたドメインが表示されます。
生のテキストが読みにくい場合は、無料のメールヘッダー解析ツールがこれらのヘッダーを読み取ります。
SPFの結果の意味
passは、送信元IPが記載されていることを意味します。failは記載がなく、レコードが拒否を指示していることを意味します。softfailは記載がなく、レコードがそのメッセージを疑わしいものとして扱うよう指示していることを意味します。neutralとnoneは、レコードが何も主張していないか、存在しないことを意味します。temperrorは一時的なDNSの問題で、permerrorはレコードが壊れていること、たとえばレコードが2つある、あるいはルックアップが多すぎることを意味します。
permerrorが表示された場合は、レコード自体を修正してください。利用中のサービスからのfailまたはsoftfailが表示された場合は、そのサービスがレコードに含まれていません。
DKIMの結果の意味
passは、署名が公開鍵と一致したことを意味します。failは一致しなかったことを意味します。よくある原因は、署名後にメッセージが変更された場合(別のシステムがフッターを追加した場合など)、DNSレコードが誤ってコピーされた場合、送信側が使用したものとセレクターが一致していない場合です。
noneは、メッセージがまったく署名されていないことを意味します。送信サービスでDKIMが有効になっていること、そしてDNSレコードが表示されたとおりの正確な名前で公開されていることを確認してください。
DMARCの結果の意味
DMARCは、SPFまたはDKIMがパスし、そのドメインがFromドメインとアライメントしている場合にパスします。そのため、spf=passとdkim=passが表示されていても、パスしたドメインが自社ではなくサービス側のものであれば、dmarc=failになることがあります。
これが最も混乱しやすいケースです。対処法は、送信サービス側で自社ドメインを認証し、そのDKIM署名、できればリターンパスにも自社ドメインを使用することです。
対処:SPFレコードが見つからない
ドメインにSPFのTXTレコードがないか、公開した名前とは別の名前が参照されていることを意味します。レコードがReturn-Pathにある正確なドメインのルートに設定されているか、誤ってサブドメインに設定していないかを確認してください。
メールがサブドメインから送信される場合があり、その場合はサブドメイン専用のレコードが必要になることを覚えておいてください。作成方法は、SPFガイドをご覧ください。
対処:DKIM鍵が見つからない、または無効
メッセージのDKIM-Signatureヘッダーにあるセレクター(s=の値)を確認し、selector._domainkey.yourdomain.comにTXTレコードが存在することを確かめてください。長い鍵は1つの値として貼り付ける必要があります。DNSの管理画面によっては鍵が分割されたり切り詰められたりするため、公開後にレコードを引いて確認してください。
最近プロバイダーを変更した場合や鍵をローテーションした場合は、古いセレクターがまだ使われていることがあります。新しいレコードを公開し、DNSが伝播するのを待ってから署名を有効にしてください。
対処:SPFとDKIMがパスしているのにDMARCが失敗する
Fromヘッダーのドメインと、パスしたドメインを比較してください。異なっていれば、アライメントは失敗します。送信サービスでカスタムドメインを設定し、DKIMが自社ドメインで署名されるようにします。
どのドメインが関係しているか分からない場合は、DMARC集計レポートに送信元ごとのドメインが一覧表示され、どの送信元がアライメントしていないかが正確に分かります。
対処:すべてパスしているのに迷惑メールになる
認証は必要条件であり、保証ではありません。すべてパスしているのに迷惑メールに入る場合、原因の多くは評判、コンテンツ、またはリストにあります。たとえば、高い苦情率、購入したアドレス、送信量の急増、迷惑メールのような件名などです。
苦情率とバウンス率を確認し、送信先を見直し、最近送信量を増やしたのであればペースを落としてください。これらの手順は、配信品質に関するガイドで取り上げています。
落ち着いて進める順序
最初にSPFから始めます。最も早く修正できるためです。次に各送信元のDKIMを確認し、その後DMARCのアライメントを確認します。一度に1つだけ変更して再テストすれば、どの変更が効果的だったか分かります。
行き詰まった場合は、メッセージのヘッダーとドメイン名をお送りください。どのチェックがなぜ失敗しているのかを、私たちが一緒に確認します。
ヘッダーの例
典型的な結果行は次のようになります。Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounce.yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com。各部分は、チェックされたドメインを示しています。
右から読んでください。header.fromのドメインは、受信者に表示されるものです。dkimのheader.dとspfのsmtp.mailfromのドメインは、チェックに使われたものです。これらがheader.fromと異なり、そのサブドメインでもない場合は、アライメントの失敗が予想されます。
参考資料と出典
- RFC 7208: Sender Policy Framework (SPF)
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- RFC 7489: DMARC
MigoSMTPでの設定:ヘルプセンター記事
関連ガイドとツール
- メールヘッダー解析ツール:認証結果を分かりやすい言葉で読み解きます。
- SPFレコードの作成方法:構文、例、よくあるエラー。
- DMARCの設定方法:p=noneから始めて、安全にrejectへ移行します。
レコードが正しいか不安ですか?無料のチェッカーをお試しいただくか、ヘッダーをお送りください。読み解きをお手伝いします。
よくある質問
SPF・DKIM・DMARCが失敗したかどうかは、どこで確認できますか?
受信したメッセージの完全なヘッダーを開き、受信側サーバーが追加したAuthentication-Resultsヘッダーを探してください。spf、dkim、dmarcの結果が記載されています。
SPFとDKIMがpassなのに、DMARCが失敗するのはなぜですか?
DMARCにはアライメントが必要だからです。SPFまたはDKIMをパスしたドメインが、Fromドメインと一致していなければなりません。別のドメインでパスしても、DMARCの判定には役立ちません。
SPFのpermerrorとは何を意味しますか?
レコードを評価できなかったことを意味します。多くの場合、ドメインにSPFレコードが2つ存在するか、レコードが10回を超えるDNSルックアップを必要としていることが原因です。
認証は通っているのに、迷惑メールに入ってしまうのはなぜですか?
認証は必要条件であり、保証ではありません。評判、リストの品質、コンテンツ、エンゲージメントも影響します。