メール到達率とDNS

SPF、DKIM、DMARCが通っても迷惑メールになる理由

著者:Alexey Bulygin
SPF、DKIM、DMARCによるメール認証と到達率の確認

メール認証: SPF、DKIM、DMARCを設定しても十分ではない理由

必要な作業はすべて済ませました。DNSに何時間もかけ、メール配信サービスから意味の分かりにくい文字列をコピーし、検証ツールも実行しました。結果はすべて緑のチェックです。それでも開封率が落ち、パスワード再設定、請求書、通知といったトランザクションメールが迷惑メールに入ったり、まったく届かなかったりするのはなぜでしょうか。

SPF、DKIM、DMARCによるメール認証には厳しい現実があります。設定が有効でも、送信者評価が良いとは限りません。有効な身分証があっても、酔った人が警備員を通過できるわけではないのと同じです。2024年二月以降、Google、Yahoo、Microsoftなどの事業者は、単に迷惑メールかどうかだけでなく、プロトコルが正確に守られているかも厳しく見るようになりました。管理画面が緑でも売上に赤信号が出ているなら、基本的な認証の先にある隠れた関門に引っかかっている可能性があります。

一斉送信者の落とし穴: 基準は想像より低い

最も危険な思い込みは、「一日の送信数は5,000通未満だから、一斉送信者向けのルールは関係ない」というものです。

この考えには二つの誤りがあり、SPF、DKIM、DMARCを正しく設定しても回避できません。第一に、Googleはプライマリドメイン単位で送信量を合算する場合があります。news.example.comからマーケティングメールを2,000通、app.example.comからトランザクションメールを2,000通、corp.example.comから社内通知を1,500通送れば、一斉送信者に該当します。サブドメインの送信量はルートドメインに集約されます。

第二に、過去の最大送信量も問題になります。ブラックフライデーのキャンペーンや一度限りのデータベース更新通知などで5,000通の基準を一度でも超えると、Googleはそのドメインを継続的に一斉送信者として扱う可能性があります。その後一日50通まで減っても、厳格な要件が適用され続けることがあります。実際の運用では、必ず各事業者の最新ポリシーを確認してください。

Microsoftは別の要素も重視します。SPF、DKIM、DMARCの記録が完璧でも、IPの利用期間や送信パターンが評価されます。新しいドメインとIPを用意してすぐに2,000通を送ると、SPFの結果に関係なく4xxエラーで流量を制限されることがあります。相手から見れば実績のない送信者なので、信頼を段階的に築く必要があります。

SPF、DKIM、DMARCが機能しない主なパターン

SPF、DKIM、DMARCを設定し、構文を確認しただけで作業を終える管理者は少なくありません。しかし、構文が正しいことと、実際に機能することは別です。ここからが見落とされやすいポイントです。

SPF: 転送で生じる認証の穴

SPFはIPアドレスの許可リストです。たとえば「IP 1.2.3.4はexample.comのメールを送信できる」と宣言します。受信者が自動転送を設定するまでは問題なく機能します。

client@smallbiz.com宛てに請求書を送り、その顧客がすべてのメールをclient@gmail.comへ転送しているとします。Gmailに接続するのはあなたのIPではなくsmallbiz.comのIPです。GmailがあなたのSPF記録を調べてもsmallbiz.comは含まれていないため、SPFは失敗します。SPFだけに頼ると、転送されたメールが迷惑メールに入ったり拒否されたりします。転送後も認証を維持するにはDKIM署名が必ず有効なままである必要がありますが、それだけで受信トレイへの到達が保証されるわけではありません。設定方法はSPFレコードのガイドをご覧ください。

DKIM: ドメインアライメントの問題

DMARCは二つの点を確認します。RFC 6376に基づくDKIMまたはSPFが成功したか、そして使用されたドメインがアライメントしているかです。アライメントとは、Fromヘッダーのドメインが技術上のヘッダードメイン、つまりSPFのReturn-PathまたはDKIMのd=と一致することです。

サポート業務で起こりがちな例を見てみましょう。ZendeskやHubSpotなどのCRMからsupport@yourcompany.comとして送信します。バウンスはCRMが処理するため、Return-Pathはbounces.zendesk.comとなり、SPFアライメントに失敗します。カスタムCNAMEも設定していなければ、DKIMはd=zendesk.comで署名され、DKIMアライメントも失敗します。Zendeskが送信し、Zendeskが署名しているので技術的には認証済みですが、DMARCから見ると自社ドメインに合致する方式がありません。ポリシーがp=rejectなら、そのメールは拒否される可能性が高くなります。

DNS参照は10回まで

RFC 7208で定義されるSPFには、一回の評価につきDNS参照を10回までとする厳格な上限があります。SaaSツールを多用する顧客を抱える代理店なら、よく目にする問題です。例によってはGoogle Workspaceだけで4回を消費します。そこにMailchimp、HubSpot、チケット管理、人事ツールを追加すると次のようになります。

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com ~all

include:は一つごとにDNS参照を発生させ、参照先がさらに別のincludeを含むこともあります。合計が10を超えると、受信サーバーはPermErrorを返します。実質的にはSPFが成功していない状態です。送信サービスを漏れなく登録しようとした結果、かえって認証を壊すことがあります。

SPF、DKIM、DMARCの先にある隠れた関門

主要な三方式のほかにも、派手な呼び名こそないものの、メールをすぐに止めてしまう技術要件があります。

FCrDNS、正引き確認済み逆引きDNS

すべての送信IPには、ホスト名へ解決するPTRレコード、つまり逆引きDNSが必要です。さらに、そのホスト名のAレコードが元のIPを指していなければなりません。この往復確認によって、送信者がインフラを管理していることを示せます。クラウドVMを作成してPostfixを導入し、PTRレコードなしで送信を始めると、Gmailは不審な送信元と判断して550 5.7.1を即座に返すことがあります。実際の応答は事業者や送信者評価によって異なります。

RFC 8058: ワンクリック登録解除

2024年六月以降、マーケティングメールでは本文末尾のリンクだけでは大手事業者の要件を満たせない場合があります。次の二つのヘッダーを含める必要があります。

List-Unsubscribe: <https://example.com/unsub>, <mailto:unsub@example.com> List-Unsubscribe-Post: List-Unsubscribe=One-Click

HTTPSエンドポイントはGETではなくPOSTリクエストを受け付ける必要があります。迷惑メール対策ボットはリンクを「クリック」してメールを検査します。GETで登録解除が成立すると、実在する利用者をボットが誤って解除する恐れがあります。一方、簡単に解除できなければ、利用者は「迷惑メールとして報告」を選びやすくなり、送信者は苦情率0.3%の警戒線に近づきます。

0.3%の崖: 送信者評価を左右する数字

SPF、DKIM、DMARCもFCrDNSもヘッダーも完璧でも、受信者が内容を嫌えば効果はありません。

最も重要な指標の一つが迷惑メール苦情率です。目安となる上限は0.3%、つまり3件の苦情につき1,000通です。これを超えると、Googleが配信を大幅に制限したり、ドメインをブロックしたりする可能性があります。具体的な計算方法と措置は、必ず事業者の最新ポリシーで確認してください。

Yahooで注意したい受信トレイ基準の分母

Yahooは総送信数ではなく、受信トレイに届いたメールを分母として苦情率を計算する場合があります。1,000通を送ったとします。ドメイン評価がすでに不安定で、900通が迷惑メールに入り、100通だけが受信トレイに届きました。そのうち一人が苦情を申し立てると、計算は1/100 = 1.0%となり、示された基準の3xです。たった一件の苦情から、抜け出しにくい悪循環が強まる可能性があります。

共有IPで起こる「迷惑な隣人」問題

SPF、DKIM、DMARCが正しくても、一般的な共有ホスティングや格安の「無制限」メールサービスでは、何千もの顧客と同じIPからメールが送られることがあります。そのうち一社が暗号資産詐欺を配信すれば、SpamhausがIPをブロックリストに載せ、あなたのメールまで止まります。自社に落ち度がなくても、問題のある利用者とインフラの評価を共有しているからです。

送信方式評価を管理する主体適している利用者
共有IP(多くのESP)事業者。他の利用者と事業者の管理体制に影響される事業者の不正対策を信頼できる少量送信者
マネージドSMTP(TrekMail Starter/Pro)TrekMail。厳格な迷惑メール対策を適用し、悪質な送信者を排除配信管理を任せたい企業
持ち込みSMTP(TrekMail Free + 有料プラン)利用者。Amazon SES、SendGrid、Mailgunの専用IPを接続十分な分離を求める代理店や大量送信者

金曜日の確認事項: SPF、DKIM、DMARCを見直す

1. ヘッダーを確認: 個人用Gmailへメールを送ります。メールを開き、三点メニューから「メッセージのソースを表示」を選び、Authentication-Resultsを探します。SPFとDKIMは成功していますか。dkim=のドメインはheader.fromのドメインと一致していますか。一致しなければアライメントに問題があります。

2. FCrDNSを確認: dig -x <your-sending-ip>を実行します。ホスト名が返りますか。続けてdig <that-hostname>を実行し、元のIPが返るか確認します。往復が成立しない場合は送信を止め、DNSを修正してください。

3. メールの流れを分離: マーケティングメールを主要な企業ドメインから送らないでください。個人間のやり取りにはteam@company.com、一斉配信にはnewsletter@marketing.company.comを使用します。マーケティング用サブドメインが0.3%の警戒線に達しても主要ドメインへの直接的な影響を抑えやすくなりますが、サブドメインで評価を完全に分離できるとは限りません。

4. 関連情報: 評価を回復する具体的な方法は、メール送信者評価のガイドメールドメイン評価の詳しい解説をご覧ください。

TrekMailのプラン

プラン料金認証機能
Free$0持ち込みSMTP、IPを完全管理(カード不要)
Starter$3.50/moマネージドSMTP、DKIMを自動生成
Pro$10/mo複数ドメイン、DNS検証ダッシュボード
Agency.25/mo共有ストレージ、DNSの一括設定、マネージド評価

すべての有料プラン: 14日間のトライアル、カードが必要。Free: カード不要。料金と機能は変更される場合があるため、契約前に最新情報をご確認ください。

まとめ

SPF、DKIM、DMARCは一度設定して終わりの作業ではなく、継続的な運用要件です。認証チェックに通ることは、あくまで入口にすぎません。受信トレイへ安定して届けるには、厳密なドメインアライメント、FCrDNSやワンクリック登録解除ヘッダーを含む適切なネットワーク管理、共有IPの他利用者から受ける影響を抑える評価戦略が必要です。初期設定のままにせず、自社の送信インフラを管理し続けてください。

SPF、DKIM、DMARCがすべて緑でも、それは出発点に立っただけです。TrekMailを無料で試して、メール認証を自分で管理しましょう。

この記事を共有

投稿 共有 共有

TrekMail の運用と保護に必要な技術を使用します。確認すると、Cookie ポリシーに記載された限定的な分析と広告測定も許可されます。

TrekMail にサインイン

ダッシュボード、メールボックス、DNS にアクセスできます。

または

12 文字 パスワードが一致

または

再設定メールを送信しました

このメールアドレスのアカウントが存在する場合、パスワード再設定の手順をお送りしました。

続行すると、TrekMail の 利用規約 および プライバシーポリシーに同意したものとみなされます.