テックブログ

技術ネタ

迷惑メール判定の回避で試行錯誤したお話

技術部 takaraです。こんにちは。

メールサーバを構築し、いざ稼働テストを始めた際に、問題としてよく挙がるのは、各種メールサービス側での迷惑メール判定。

その回避方法について相談頂き、SPFレコードの設定、IPの逆引き設定、DKIM設定を段階的に実装し、配送テストを行いました。

  1. SPFレコードの設定
    test@example.comのメールは、どのサーバから出るのが正しい、といった体で、メール送信元の情報をDNSゾーンに設定します。
    今回は255個のIPアドレスを含むネットワークアドレスをソフトフェイルで指定しました。

    TXT "v=spf1 +ip4:xxx.xxx.xxx.0/24 ~all"

    このネットワークアドレスに含まれるIPアドレスからのメール送信については、Gmail側に配送される場合は、下記のSPFチェックをパスしたヘッダ情報が含まれます。

    Received-SPF: pass
    (google.com: domain of test@example.com designates xxx.xxx.xxx.227 as permitted sender)
    client-ip=xxx.xxx.xxx.227;
    
    Authentication-Results: mx.google.com;spf=pass
    (google.com: domain of test@example.com designates xxx.xxx.xxx.227 as permitted sender)
    smtp.mailfrom=xxx@example.com
    Received: from localhost (example.com [127.0.0.1]) by example.com (Postfix) with SMTP id 2B9349F6B1 for <xxx@gmail.com>;
    Fri, 7 Oct 2016 11:47:01 +0900 (JST)

    SPFレコードに関するチェックをパスできたと取れる情報です。
    この設定完了時点では、某メールサービスの迷惑メールフォルダに配送されてしまう状態でした。

  2. DNS逆引き設定
    “example.com” は、”xxx.xxx.xxx.227″ のIPアドレスで運用されている、といった既に設定されていた正引きのDNSレコードとは別に、”xxx.xxx.xxx.227″ のIPアドレスでは、”example.com” ドメインが運用されている、と確認できる、逆引きのDNSレコードを設定します。ドメイン情報からIPアドレスを確認する正引きの設定とは異なり、IPアドレスに対する設定となるため、クラウドサービスやハウジング、ホスティング業者にご確認頂く必要のある設定となります。当設定完了後、Windows端末のコマンドラインで確認を取りました。

    [Windows コマンドラインインターフェース]
    
    C:\Users\ttakara> nslookup xxx.xxx.xxx.227
    サーバー: google-public-dns-a.google.com
    Address: 8.8.8.8
    
    名前: example.com
    Address: xxx.xxx.xxx.227
    Aliases: 227.xxx.xxx.xxx.in-addr.arpa

    逆引きのDNSレコード設定では、Gmailに配送されたメールのヘッダ情報に変化はありませんでした。
    この設定完了時点でも、某メールサービスの迷惑メールフォルダに配送されてしまう状態が継続していました。

  3. DKIM(電子署名での送信ドメイン認証)の設定
    メールデータを署名用プログラムを介して送信するよう、メールサーバを調整します。プログラムが付与する署名を元に、メールを受信する側のサーバがDNSに登録されたDKIM情報との照らし合わせを行い、メールの配送元として認証されたサーバからの送信メールであるか、確認する仕組みとなります。この設定にあたり、鍵の情報をDNSレコードに設定するため、長ったらしいレコード設定が必要となります。

    TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB...3HZDwIDAQAB"
    
    ※ p= に続く216字は一部省略しています

    署名用プログラムを介して配送されたメールには、下記のようなヘッダ情報が付与されます。

    DKIM-Filter: OpenDKIM Filter v2.10.3 example.com DC5199F673
    DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
     s=selector1; t=1475830433; bh=gZpzGaY7k3qK1Riz+pvoqjjPlwkdexL4h2XZje48avc=;
     h=Date:From:To:Subject:From;
     b=QrfKU5aemmy7XxsqqxOxBM5r6Vl+8vWjNShj9uXZrqMuI+5hdYmb08XQacV9bKQK8
     U78sGocCoxkVjAl+0qXulAULD2A4FNpLO9IvNyJ+F3QIpK/cianxMZIxuttvKHeSoM
     B1PtIDO5Th1TR39uNGUhoMYc/e8YT/Moo2pgi9dI=

    Gmailに配送されたメールには、下記ヘッダ情報が付与されていることから、DKIMの設定状況をチェックされ、それにパスしたことが伺えます。

    Authentication-Results: mx.google.com;
     dkim=pass header.i=@example.com;
     spf=pass (google.com: domain of test1@example.com designates xxx.xxx.xxx.227 as permitted sender)

    ここまでやっても、某メールサービスでは迷惑メールフォルダへの配送は継続する結果となりました。

結果として、送信サーバ側の信頼性を高める設定をしても、某メールサービスでは迷惑メールフォルダに配送されてしまう結果は変わらず、そのサービスのサポートへ問合せ、フィルタ設定を修正頂いての改善となりました。

各メールサービスの運営母体毎に迷惑メール判定の基準が異なるため、受信拒否のバウンスメール、配送メールのヘッダ情報や各サービスの利用ガイドラインはあれど、完璧なメール配送システム構築は永遠の課題のように思えてきます。

改めてテストを振り返るだけでも、Googleのサービスに依存していると しみじみ。

ではまた。

実績数30,000件!
サーバーやネットワークなど
ITインフラのことならネットアシストへ、
お気軽にご相談ください