icon

「最適なサービスで一歩先行く組織へ」ビジネスに伴走する課題解決メディアCHECK!

迷惑メール判定されないために注意したいDNSの設定とは? Part1

迷惑メール判定されないために注意したいDNSの設定とは? Part1

はじめに

昨今、私たちのメールボックスに届く「なりすまし」やスパムなどの迷惑メールは、以前に比べれば減りつつあります。その背景にはISPをはじめとした通信業界の努力によって開発されたさまざまな迷惑メール対策技術があります。

しかし、迷惑メールを完全になくすことができていないのも事実です。迷惑メール送信者は手を替え品を替え、迷惑メール対策をかいくぐるようにして迷惑メールを送信しています。通信業界は、新たな手法が見つかる度に新たな対策を講じ、ユーザに迷惑メールが届かないよう日々努力しています。

一方、こうした各種迷惑メール対策の裏で問題となっているのが、本来問題なく届くはずのメールが誤って迷惑メールと判定され届かないといった事態です。

迷惑メールと判定される原因は、DNSなどの設定不備や、メール内容の問題、送信リストの問題などさまざまです。

本記事では迷惑メールと判定されないために、とくに重要なDNSとその設定項目について取り上げていきます。

そもそもDNSとは何か?

DNSとはDomain Name Systemの頭文字を取ったもので、ドメイン名とサーバのIPアドレスを対応づけるシステムです。サーバの住所とも言えるIPアドレスは「210.130.xxx.xx」と言った数字の羅列であり、人には覚えにくく分かりにくいため、Webサイトへのアクセスなどに利用しやすくするために「baremail.jp」など文字列で表したものがドメイン名です。

ドメイン名からIPアドレスを調べることを「正引き」と言い、反対にIPアドレスからドメイン名を調べることを「逆引き」と言います。このドメイン名とIPアドレスを結びつけ、相互に変換する仕組みが「名前解決」です。

DNSによる名前解決

例えば「www.baremail.jp」というWebサイトにアクセスする際、コンピュータはDNSにこのドメイン名を問い合わせ、DNSサーバはそのドメイン名に紐づくIPアドレスを調べて回答します。そしてコンピュータは教えてもらったIPアドレスのサーバにアクセスすることでWebサイトを閲覧します。

メールを送る際も同様に、まずはその送信先のドメイン名のメールサーバをDNSに問い合わせ、その回答を受けてメールサーバにメールを送信するという流れになっています。

このように、ドメイン名をWebサイトやメールの送受信に利用するには、ドメイン名とIPアドレスの紐付けをインターネット上で公開する必要があり、ドメイン名の名前解決に必要な情報を管理するという重要な役割を果たしているのがDNSサーバ(ネームサーバ)なのです。

DNSサーバの正しい設定はメール到達率を下げないためにも重要

DNSサーバの動きからわかる通り、設定を正しく行っておかないと、Webサイトを公開してもアクセスができなかったり、メールが届かなかったりという事態を引き起こしてしまいます。また、メール送信という面で見た場合、DNSサーバは加えて重要な役割を持っています。それが「送信ドメイン認証」と呼ばれるものです。

送信ドメイン認証は、悪意を持った第三者による「なりすまし」の迷惑メール送信を防ぐために開発された認証技術です。送信元のIPアドレスに基づいて認証する「SPF」と、電子署名に基づいて認証する「DKIM」が主に使用されます。昨今ではそれに加え、SPFとDKIMの認証結果を用いて「なりすまし」対策をさらに補強する「DMARC」が取り入れられつつあります。

これらの設定はDNSサーバで行われますが、正しく設定されていないと認証が失敗し、メールの到達率を下げる一因となるため、設定には注意が必要です。

迷惑メールに判定されないためのDNSレコードを解説

このように、メールの到達率を下げないためにも、DNSサーバの設定を正しく行うことはとても重要だと言えます。ここではDNSサーバの主な設定項目について説明していきます。

⚫︎ Aレコード

⚫︎ MXレコード

⚫︎ PTRレコード(逆引き)

⚫︎ TXTレコード(送信ドメイン認証)

Aレコード(Address

ホスト名に紐づくIPアドレス(IPv4)を関連付けるために定義するレコードで、DNSの中で最も基本的な設定項目になります。

<基本書式>


[ホスト名]. IN A [IPアドレス]

※「ドメイン名」「ホスト名」「FQDN」などは混同されやすいため、念のため例を挙げておきます。

ドメイン名:インターネット上で重複しない独自のネットワークの名前

例:baremail.jp

ホスト名:あるネットワーク内に存在する特定のコンピュータ(ホスト)の名前

例:www

FQDN(完全修飾ドメイン名):ホスト名とドメイン名を省略せずにつなげて記述したもの

例:www.baremail.jp

MXレコード(Mail Exchange

対象ドメイン宛のメール配送先(メールサーバ)のホスト名を定義するレコードで、ドメインを使用したメールアドレスを使用する場合には重要な項目になります。

<基本書式>


[ドメイン名]. IN MX 10 [メールサーバのホスト名].

※「10」という数字について

preferenceと呼ばれるパラメータで、メールサーバの優先順位を表します。

一般的に「10」を最優先とし、100までの範囲内で10刻みで設定が可能です。


例:優先順位1番=10、優先順位2番=20、均等にしたい=すべて10を設定。

PTRレコード(Pointer Record/逆引き)

Aレコードの逆で、IPアドレスに紐づくホスト名を定義するレコードです。通常はあまり意識することのない設定ですが、メール送信の際には実は重要な役割を果たしています。

受信側メールサーバはメールを受け取ると、送信元IPアドレスを逆引きできるかチェックし、

① ホスト名がきちんと返ってくるか

② 逆引きで返ってきたホスト名の正引きとIPアドレスが一致しているか

を確認します。

迷惑メール送信業者は身元を特定されないようにするため、逆引きの設定をしないことが多いと言われています。そのため、逆引きが正しく設定されていないと、受信側メールサーバのポリシーによっては迷惑メールと判断されて届かない原因になり得ます。「逆引きが設定されていないと絶対に届かない」というわけではありませんが、設定しておくと安心でしょう。

<基本書式>


● IPv4の場合

[IPアドレスの逆. in-addr.arpa.] IN PTR [ドメイン名].

例:IPアドレス=210.140.191.14、ドメイン名=baremail.jp

   14.191.140.210. in-addr.arpa. IN PTR baremail.jp

● IPv6の場合

[IPアドレスの逆.ip6.arpa.] IN PTR [ドメイン名].

例:IPアドレス=0000:0000:0000:0000:0000:ffff:d28c:bf0e、ドメイン名=baremail.jp

   0000:0000:0000:0000:0000:ffff:d28c:bf0e. ip6.arpa. IN PTR baremail.jp

TXTレコード(TEXT)

ドメイン名に関するコメントを設定することができます。

コメントには自由に文字列を設定することができますが、目的に応じた特定の記述をすることで、別の意味を持たせることができます。

具体的にはSPFレコード・DKIMの署名・DMARC認証といった送信ドメイン認証に使われ、なりすましメールの防止対策として使用することが可能です。

<基本書式>

単純にコメントを付ける場合は次の通りになります。


[ドメイン名]. IN TXT [“コメント”]

項目記述例
備考
SPF
[ドメイン]. IN TXT ”[SPF version] [qualifier] [mechanism]:[値] ” 詳細はこちら
 DKIM [セレクタ]. _domainkey.[ドメイン名]. IN TXT “v=DKIM; k=rsa; p=(公開鍵データ)
※利用できるタグ(オプション)に関する参考サイトはこちら
DMARC _dmarc.[ドメイン名]. IN TXT “v=DMARC;p=none;rua=(集計レポート受信アドレス);ruf=mailto:(認証失敗レポート受信アドレス);rf=(レポート受取頻度);pct=100” 要電子署名対応メールサーバ

まとめ

今回は、迷惑メールに誤判定されないために重要なDNSの仕組みと、各種レコードの概要について解説しました。次回は、実際に各種レコードの設定で注意すべきポイントについて解説します。

DNSを含め、メールサーバを適切に設定し、運用を行うことはメール到達率の向上に大きな影響を与えます。

もし、DNSやメールサーバの運用に不安をお持ちであればぜひ、当社の「ベアメール」をご検討ください。ベアメールは、長年培ってきたホスティング事業者としての知識やノウハウを活かし、メールの到達率向上のために日々チューニングを行っているメールリレーサービスです。お客さまが抱えるシステム面での負担を軽減し、マーケティング活動に注力していただくことが可能です。

メールリレー完全ガイド

The post 迷惑メール判定されないために注意したいDNSの設定とは? Part1 first appeared on ベアメールブログ.