単一の外部IPを共有する多くのコンピューターを備えたオフィスがあります(アドレスが静的か動的か不明です)。各コンピューターは、Outlookを使用してIMAP経由でメールサーバーに接続します。電子メールはこれらのコンピューターで送受信され、一部のユーザーは携帯電話でも電子メールを送受信します。
http://wizard.easyspf.com/ を使用してSPFレコードを生成していますが、ウィザードの一部のフィールドについて、具体的にはわかりません。
最初のいくつかの質問については、かなり確信があります...十分な情報を提供していただければ幸いです。
SPFレコードは、ドメインでsendメールを送信できるサーバーの詳細を記録します。
質問1〜3は、SPFの要点をまとめたものです。ドメインからのメールの送信が許可されているすべてのサーバーのアドレスをリストしているはずです。
現時点で完全なリストがない場合は、通常、SPFレコードを設定することはお勧めできません。また、ドメインに含めることができるSPFレコードは1つだけなので、すべての情報を1つのレコードに結合する必要があります。
個々の質問は、実際にリストを分解するのに役立ちます。
example.org
のメインメールサーバー(MXレコード)である場合は、mx:example.org
と入力する必要があります。 SPFレコードには、ほとんどすべての状況(mx
)で独自のドメインのMXレコードを含める必要があります。ip4:1.2.3.0/28 ip4:6.7.8.0/22
と入力します。 IPv6スペースは、たとえばip6:2a01:9900:0:4::/64
として追加する必要があります。a:mail.remote.example.com
を入力します。あなたの携帯電話ユーザーは問題があります。たとえばSMTP AUTHを使用してメールサーバーに接続し、そのサーバーを介してメールを送信する場合は、メールサーバーのアドレスを(2)にリストして対処しました。 3G/HSDPAプロバイダーが提供するメールサーバーに接続するだけでメールを送信する場合、メールインフラストラクチャを再構築してdoどのメールからすべてのポイントを制御するまで、SPFを意味のある方法で実行することはできません。あなたからであると主張することはインターネットを打つ。
質問4は少し異なり、ドメインから来たと主張する電子メールの受信者がしないが上記のシステムのいずれかからのものであることを尋ねます。法的な対応はいくつかありますが、興味深いのは~all
(ソフトフェイル)と-all
(ハードフェイル)だけです。 ?all
(回答なし)は~all
(qv)と同じくらい役に立たず、+all
は嫌なものです。
~all
は簡単な選択です。これは、あなたがあなたからのメール送信を許可されているシステムの束をリストしたが、あなたがそのリストを網羅しているわけではないので、他のシステムから来ているあなたのドメインからのメールはまだ合法であるかもしれないと人々に伝えます。 notにお願いします。 SPFを完全に無意味にするだけでなく、SFの一部のメール管理者は、SPF受信者を意図的に~all
をスパマーのバッジとして扱うように設定します。 -all
を実行しない場合は、SPFをまったく使用しないでください。
-all
は便利な選択肢です。これは、あなたがあなたからの電子メールの送信を許可されているシステムをリストしたこと、および他のシステムがそうすることが許可されていないことを人々に伝えます。したがって、彼らはSPFレコードにリストされていないシステムからの電子メールを拒否してもかまいません。これがSPFの要点ですが、アクティベートする前に、自分からのメールの発信またはリレーを許可されているすべてのホストをリストしていることを確認する必要があります。
グーグルは 助言することが知られている それ
〜allではなく-allを使用するSPFレコードを発行すると、配信の問題が発生する可能性があります。
ええ、そうかもしれません。 SPFの要点。なぜgoogleがこのアドバイスをするのかははっきりとはわかりませんが、メールの発信元が正確にわからないシステム管理者が配信の問題を引き起こさないようにするためだと強く思います。 すべてのメールの送信元がわからない場合は、SPFを使用しないでください。 SPFを使用する場合は、SPFの提供元をすべてリストし、-all
を使用して、そのリストで自信があることを世界に知らせます。
これはいずれも、受信者のサーバーを拘束するものではないことに注意してください。 SPFレコードを宣伝するという事実は、他の誰にもそれを尊重する義務を負わせるものではありません。どのメールを受け入れるか拒否するかは、メールサーバーの管理者次第です。 SPFが行うことは、ドメインからのものであると主張されたがそうではなかった電子メールに対する責任を放棄することです。メールの拒否を通知するはずのSPFレコードを確認する必要がないのに、ドメインが迷惑メールを送信しているというメール管理者が来た彼らの耳にノミを連れてかなり送ることができます。
この回答は正規化されているので、include
とredirect
について簡単に説明します。後者の方が簡単です。 SPFレコード、たとえばexample.com
、_redirect=example.org
の場合、example.org
のSPFレコードreplaces自分のレコード。 example.org
もこれらの検索でドメインの代わりに使用されます(たとえば、example.org
のレコードにmx
メカニズムが含まれている場合、MX
検索は、自分のドメインではなくexample.org
で行う必要があります)。
include
は広く誤解されており、 標準の作成者の注記 " 'include'の選択が不十分です"。 SPFレコードinclude
s example.org
のレコードの場合、example.org
のレコードを受信者が調べて、何らかの理由(+all
を含む)が電子メールを受け入れる。もしそうなら、あなたのメールは通過するはずです。そうでない場合、受信者はall
メカニズムに到達するまでSPFレコードの処理を続行する必要があります。したがって、all
dレコード内の-all
以外の+all
、または実際にanyinclude
の他の使用法には、処理結果には影響しません。
SPFレコードの詳細については http://www.openspf.org は優れたリソースです。
これを間違った方法で行わないでください。ただし、SPFレコードが間違っている場合は、修正するまでインターネットの大部分があなたからのメールを受信しないようにすることができます。あなたの質問はあなたがあなたがしていることと完全にau faitではないかもしれないことを示唆しています、そしてそれが事実であるなら、あなたは止める何かをする前に専門家の援助を得ることを検討したいかもしれません非常に多くの人にメールを送信します。
編集:親切な言葉をありがとう、彼らは大いに感謝しています。
SPFは主に joe-jobbing を防止する手法ですが、スパムを検出するためにSPFを使用し始めた人もいるようです。それらの一部は、実際にSPFレコードがない、または過剰なレコード(たとえば、a:3.4.5.6/2 a:77.5.6.7/2 a:133.56.67.78/2 a:203.54.32.1/2
、ひそかに+all
に等しい)に負の値を付加する場合がありますが、それはそれら次第です。あなたがそれについてできることはたくさんあります。
私は個人的にSPFは良いことだと思います。現在のメール構造で許可されている場合は、レコードを宣伝する必要がありますが、インターネット全体で有効な信頼できる回答を提供することは非常に困難です。特定の目的、別の目的で使用することを決定した場合。 doが-all
のポリシーでSPFレコードをアドバタイズし、それが間違っていると、多くの人があなたのメールを見ることはありません。
編集2:コメントに従って削除し、回答を最新の状態に保ちます。
セットアップで重要なのは、最終的にメールをインターネットに送信するサーバーの構成です。あなたはSMTP経由で電子メールを送信すると言います。したがって、IPアドレスに関して重要なのは、SMTPサーバーの構成です(質問2)。
Gmailなどのサードパーティを使用してメールを送信する場合は、次のようなspfレコードを含める必要があります:include:_spf.google.com(ajaxウィザードはこれを認識していないようです)。
「どのように厳格」なのかわからない場合は「ソフトフェイル」(〜all)のままにします。それ以外の場合は、構成がクリーンになったら「拒否(-all)」する方法です。