配信可能性を向上させるための電子メール送信のベストプラクティスを実装しようとしています(または正しくフォローしていることを確認してください)が、SMTPサーバーのホスト名とFrom:
電子メールアドレスのドメイン名の役割は何十もの人々の記事/入力を読んだ後でも、不明確です。
具体的には、逆引きDNSチェックを満たすには、送信側マシン/ SMTPサーバーのホスト名と一致するドメイン名を生成する送信側マシンのIPアドレスのPTRレコードが必要であることを理解しています。 「hostname」コマンドで指定されたものと一致する必要があると言う人もいれば、HELO/EHLOステートメントで指定されたものと一致する必要があると言う人もいます。 この男 は同じでなければならないとさえ言っています(/によると)何によって強制されるのか、私にはわかりません。とにかく、それはほんのわずかな混乱のポイントです)。
まず、どこにも見つからないのはFrom:
メールアドレスのドメイン名がSMTPサーバーのドメイン名と一致する必要があるかどうかです。
だから私の場合、私はlinodeを備えたVPSを持っています。それは主に私の特定のドメインexample.com
をホストしますが、他のプロジェクトfoo.com
とbar.com
で作業することもあります。
だから私が疑問に思っているのは、デフォルトのlinode PTRレコード(abc.def.linode.com
に解決される)をそのままにしておくことができるかどうかです。abc.def.linode.com
が私のメールサーバー(qmail)がHELOで言うように構成されていることを確認してください、次にそれを使用してexample.com
、foo.com
などの電子メールを送信します。
もしそうなら、私は与えられたアドバイスに混乱しています ここ 、具体的には(悪いケースのシナリオのリストで):
HELOコマンドで使用されているドメインのSPFレコードがありません
そのドメインにSPFレコードが必要なのはなぜですか?その場合、どのドメインにホワイトリストを提供する必要がありますか:HELOドメイン、または差出人のドメイン:電子メールアドレス(エンベロープ送信者)?また、[email protected]
に送信されたメールを受け入れる必要があるドメインはどれですか?
ドメインが同じでなければならない場合、それは私にはかなり制限されているように思われます。なぜなら、メールを送信したいすべてのドメインについて、別のIPアドレスを取得する必要があるからです。また、電子メール以外の送信物(wgetなど)を比較的匿名で実行する能力を損なうか、台無しにします。ただし、利点は、これが当てはまる場合、セットアップの混乱がはるかに少なくなることです。
私は現在、linode.comSMTP + PTRドメインとexample.comFrom:
アドレスの組み合わせをあまり使用していません配信可能性の問題がありますが、私のボリュームは非常に少ないので、誰かがより大きなボリュームの経験があり、違いを具体的にテストしたか、内部知識を持っているか、および/または信頼できる答え(およびソース)を持っているかどうかを知りたいですこの特定の質問のために。何でも明確にさせていただきますので、お知らせください。前もって感謝します。
注:これにはいくつかの意見のある暴言があります。あなたはそれを無視するのは自由です:)
さて、これは私たちが話している電子メールなので、メッセージの配信可能性を保証する方法はないということから始める必要があります。 SMTPは、より静かで信頼できる時間に考案されました。それ以来、多くの人々がスパムの最終的な解決策と見なしているものを実装してきましたが、それが機能しなかったことに驚いています。または、スパマーがそれを打ち負かす方法を考え出したこと。または、全員が効果を発揮することに依存していること。 (または他の数十の理由)。私たちが今持っているのは、バルカニゼーションされたシステムと半分実装されたアイデアの混乱です。つまり、メッセージが確実に通過することは不可能です。
私の意見では、ベストプラクティスのほとんどは、電子メールを送信するのではなく、受信することに集中する必要があります。送信者として、受信者が実施しているランダム測度を確実に満たすのはあなたの仕事ではありません。メールメッセージがどのように見えるかについての仮定に基づいて、フィルタリングが正当なメールをブロックしないようにするのが彼らの仕事です。それらの多くは、メールをルーティングおよび配信できる興味深い方法を十分に考慮していません。
まず、どこにも見つからないのは、From:メールアドレスのドメイン名がSMTPサーバーのドメイン名と一致する必要があるかどうかです。
原則として、いいえ。 MTAが自身のドメインとは関係のないアドレスからメールを送信する正当な理由はたくさんあります。この理由でメールを拒否するシステムに出くわすかもしれませんが、これはあなたの問題ではありません。少なくともTLDでは、PTRレコードがドメインと一致し、HELOアナウンスがそれらと一致することは問題ありません。しかし、From:
ドメインがPTRTLDと一致しないという理由だけで拒否するものはすべて壊れています。
もしそうなら、私はここで与えられたアドバイス、特に(悪いケースのシナリオのリストで)混乱しています:
HELOコマンドで使用されているドメインのSPFレコードがありません。
SPFレコードは、これらの「原則的に正しいように聞こえる」アイデアの1つであり(その主題に関する別の暴言については ここ を参照)、多くの重みが増しています。私にとっての主な問題は、多くのMTAが、SPFをまったく公開していないドメインを不当に罰することです。繰り返しますが、これはあなたの問題ではありません。
とは言うものの、私はドメイン用に1つ配置しました。これは、顧客のシステム管理者と頻繁に結婚するために行われていないためです。それは結局、技術的な決定ではなく、政治的な決定になります。
SPFを使用し、PTRとHELOをabc.def.linode.com
のままにする場合。次に、From:
ドメインのallのSPFレコードに、そのサーバーを送信者としてリストする必要があります。 foo.com
およびbar.com
DNSを制御できない場合は、制御できる人と話す必要があります。
私は現在、linode.com SMTP + PTRドメインとexample.comFrom:アドレスの組み合わせを使用していますが、配信可能性の問題はほとんどありません。
どちらも持ってはいけません。 SPFをまったく公開しておらず、linode.com
seerverがリストされていない場合は、多くのバウンスが発生します。ただし、それをリストした場合、またはexample.com
がSPFレコードをまったく公開しない場合は、問題ないはずです。 (SPFがまったく公開されていないためにMTAがメールを拒否すると、壊れており、おそらく多くの正当なメールが返送されるという以前のポイントを繰り返します)。
多くの大規模なメールプロバイダー(Googleは明らかな例です)は、ヘッダーのFrom
アドレスのドメインがPTRレコードと一致しない電子メールを送信し、それらの間で(ある種の)一致を強制するプロバイダー2つのトークンは、多くの有効な電子メールを拒否する可能性があります。したがって、いいえ、From:
電子メールアドレスのドメイン名はSMTPサーバーのドメイン名と一致する必要はありません。
PTRレコードが、サーバーがHELO
と言ったときにアナウンスする名前と一致することを確認することを強くお勧めします。スパムフィルターがこれをフィルタリングする理由は、それらが一致する理由がほぼ確実にないためですnot。 <qmail-control-dir>/helohost
をオーバーライドする必要がある場合は、これを<qmail-control-dir>/me
で明示的に設定できます。