私の理解では、SPFを使用して、ドメインに代わって送信メールを送信することが許可されているIPアドレスのセットを定義できます。許可されたIPアドレスのセットに含まれていないメールサーバーが電子メールを送信する場合、受信サーバーはfromドメインでTXTレコードルックアップを実行し、レコードを検査して、それが受信メールをソフトフェイルまたはハードフェイルする必要があります。
例えば。
Dig my-site.com TXT
"v=spf1 include:_spf.google.com include:servers.mcsv.net -all"
このレコードは基本的に「TXTレコードで示されるサーバーは許可し、それ以外は失敗します。
SPFは必要ですか?いいえ、インターコムが処理します。インターコムから送信されるメールには、return-pathヘッダーが含まれています。受信者のメールサーバーが私たちの電子メールの1つを受信し、リターンパスでドメインのSPFレコードを確認すると、送信者のIPアドレスが承認された送信者であることがわかります。つまり、インターコム経由で送信されたメールは自動的に認証を通過し、自分でレコードを設定する必要はありません。
これは私を混乱させます。これは、この場合のインターホン(同じ手法を使用しているインターネット上の誰もが)がmy-site.com
私がホワイトリストに登録したIPアドレスのセットにないものを失敗させるはずのSPFレコードを使用したという事実にもかかわらず、電子メールを受け取った人は、これが「から」であることを認識しないでしょう[email protected]
AND SPFパスとして、送信サーバーのIPアドレスが許可されたIPアドレスの1つではなかったとしても?
なお、私はDKIMとDMARCも使用していますが、この議論をSPF側だけに限定したいと思います。
私たちが電子メールに関して「から」について話しているとき、それは2つのことを指すことができます:
クライアントがサーバーに接続してメールを送信する場合、クライアント間の簡単なやり取りは次のとおりです。
client: HELO client.example.com
server: Hello, client.example.com, Nice to meet you
client: MAIL FROM: <[email protected]>
server: Okay
client: RCPT TO: <[email protected]>
server: Okay, go ahead with the message, terminate with a single '.'
client:
From: Junie B. Jones <[email protected]>
Subject: Important discussion
Hello, Claire...
...blah...
...blah...
.
server: Okay, accepted for delivery
上記では、「From」が2回表示されていることがわかります。1回目はMAIL FROM
の一部として、2回目はFrom:
としてメッセージの本文に表示されます。メールサーバーに関する限り、重要なのは最初の1つ( "Envelope From"または "Return Path"と呼ばれます)だけです。2つ目は主に外観用です。実際、完全に欠落している可能性があります。
インターコムが言っていることは、彼らがメッセージを送るとき、彼らはこのようにそれを送るということです:
client: HELO foo.intercom.com
server: Hello, foo.intercom.com, Nice to meet you
client: MAIL FROM: <[email protected]> # <-- envelope-from
server: OK
client: RCPT TO: <[email protected]>
server: OK, proceed, terminate with a single "."
client:
From: Junie B. Jones <[email protected]> # <-- cosmetic "From:"
Subject: Mailing from intercom
...blah...
...blah...
.
server: OK, accepted for delivery
多くのメールクライアントでは、メールを表示するときに、「Junie B. Jones <[email protected]> via foo.intercom.com」と表示されます。 Envelope-FromとコスメティックFromの間の不一致を示しますが、電子メールに関してはコーシャの慣習と見なされます。
SPFは特にEnvelope-Fromのみを処理し、表面的な "From:"フィールドを無視します。
Return-Path
ヘッダーは、SMTP( RFC 5321 )で発行されたmail from
コマンドを表し、「エンベロープ送信者」とも呼ばれます。 Sender Policy Framework は、SMTP情報のみをチェックします。SMTPEHLO
またはHELO
コマンドで識別されるホストとエンベロープ送信者。
SMTP情報に直接アクセスできないシステムによって実行されるSPFは、Return-Path
ヘッダーからエンベロープ送信者を抽出し、適切なReceived
ヘッダーからHELOホストを抽出する必要があります(または、信頼します Received-SPF
ヘッダー)。
エンベロープ送信者は、インターコムでの認証に使用するアカウントを表していると思います。つまり、IntercomのSPFを渡しますが、「調整」されません"for [〜#〜] dmarc [〜#〜] はFrom
ヘッダーのドメインと一致しないため。
これは、インターコムのアウトバウンドサーバーを祝福する独自のSPFレコードが必要であることを意味します(必ずしもレコード全体ではありません。マーケティング担当者もyourマーケティング担当者)。上記のレコードで十分です。 rua
キーを使用してDMARCレコードを設定し、集計レポートを専用のメールボックスに送信すると、ドメインを使用するすべてのものが(長期間にわたって)From
ヘッダーに表示されます。ドメインに合わせたSPFまたはDKIMを渡す。