SPF・DKIM・DMARCとは:迷惑メール判定を避ける設定
自分のメールが本物であることを証明する3つのDNSレコード。それぞれの役割、設定方法、DMARCレポートの読み方を解説します。
送ったメールが迷惑メールに振り分けられる、あるいは自社ドメインを名乗る偽メールが出回っている——原因はたいてい同じ3つのDNSレコード、SPF・DKIM・DMARCにあります。これらは受信側サーバーが「そのメールが本当にあなたから来たのか」を検証するための仕組みです。
SPF:送信を許可されたサーバー
SPFは、自ドメインのメールを送信してよいサーバーを列挙したTXTレコードです。受信側は送信元をこの一覧と照合し、載っていない送信元を疑わしいものとして扱います。最小構成は v=spf1 include:_spf.yourprovider.jp -all のような形です。
実務で重要なのは二点です。1ドメインにつきSPFレコードは1件だけ公開すること(2件あると相互に無効化されます)。そして正当な送信元をすべて含めること——メールプロバイダーだけでなく、メール配信サービス、CRM、請求書システムも自社名義で送信します。
DKIM:改ざんされていないことの証明
DKIMは送信メールごとに電子署名を付けます。秘密鍵は送信サーバーに置かれ、対応する公開鍵をDNSに公開します。受信側は署名を検証することで、そのメールが自ドメインから送られ、途中で内容が変更されていないことを確認できます。
鍵はプロバイダーが生成します。利用者の作業は、指定されたセレクタ名でレコードを公開することだけです。
DMARC:失敗したときの扱い
SPFとDKIMは結果を返し、その意味を決めるのがDMARCです。v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.co.jp のような初期設定は、扱いを変えずにレポートだけを要求します。重要なのはポリシーの値です。
p=none— 監視のみ、レポートを受け取るp=quarantine— 失敗したメールを迷惑メールへp=reject— 受け取らずに拒否
まず p=none で開始し、数週間レポートを読み、正当な送信元がすべて認証を通るようになってから厳しくします。いきなり reject にするのは、忘れていた外部サービスからの請求書を失う典型的な失敗です。
それでも迷惑メールに入る理由
認証は必要条件であって十分条件ではありません。ほかによくある原因は次のとおりです。
- 送信実績のない新しいドメイン。 評価は数週間かけて作られます。少量から始めましょう。
- 逆引き(PTR)レコードの欠落や不一致。
- 迷惑メールらしい内容:全角大文字の件名、短縮URL、テキストのない大きな画像1枚。
- リスト管理の不備。 存在しないアドレスへ送り続けると評価は急速に落ちます。
- 共有IPの同居者。 安価な共有環境では他者の行動が影響します。
設定の確認方法
無料のメール検査サービス宛に送信し、レポートを読みます。SPF・DKIM・DMARC・PTRの結果と迷惑メールスコアが確認できます。コマンドラインなら dig TXT yourcompany.co.jp でSPFとDMARCを確認できます。DNS変更のたびに再確認してください。
よくある質問
3つすべて必要ですか。 SPFとDKIMが最低限です。DMARCはそれらを実効的なポリシーに変え、可視化をもたらすため、必須と考えてください。
DMARCでメールマガジンが届かなくなりませんか。 配信基盤が許可されていない場合だけです。SPFに追加しDKIMを設定してから、ポリシーを厳しくしてください。
DNSの変更にどれくらいかかりますか。 通常は数分、TTLやキャッシュ次第で最大48時間です。
SPFは ~all と -all のどちらがよいですか。 ~all(softfail)は穏やかな出発点です。一覧が揃ったら -all のほうが厳格で望ましい設定です。
imail.com.tr の認証設定
imail.com.tr のビジネスプランでは、SPF・DKIM・DMARCはドメイン追加の一部です。管理画面が自社DNS用の正確なレコードを表示し、不足があれば警告します。ビジネスプラン、または先に独自ドメインの設定手順をご覧ください。