Hi, >>> I think you mean, *FROM* a server that is not in your SPF record. >>> >>> SPF says nothing about the *recipient* MTA. >> >> >> Unless that recipient MTA is my own, correct? > > No. The recipient *does not matter*. SPF is vetting the *sending* MTA. > >> The SPF record contains a list of servers that are allowed to send >> mail using my domain, including to my own MX. > > Correct. > >> This can't be used for spoof protection for my own domain as easily as for >> remote systems to ascertain whether an email received by a remote system was >> sent legitimately from one of our systems? > > Yes, it can be used for that purpose. That does not mean the recipient > matters. Your MTA is just another MTA using SPF to validate the sending MTA.
That's perhaps the part I didn't make clear. If there is a host sending mail to me using my domain, my MTA would validate the email using my own SPF record. This is what I'm trying to do. > However, that MTA also has the added burden of correctly classifying email > received from internal sources that do not appear in your public SPF record. Yes, and I would think that's what $mynetworks in postfix is for. > SPF_FAIL should not be triggered when somebody else's MTA (which will not be > in your SPF record) receives a message using your domain *from* your MTA > (which will be in your SPF record). > > If SPF_FAIL triggers in that situation, then SPF is pointless. Yes, understood. This was always about my own MTA receiving a message appearing to be "FROM" my own domain, and my own SPF record would be used to check the IP of the remote system to determine if it was permitted. I may have made that especially clear at one point. Does this make sense now? I'm trying to use my SPF record to verify mail FROM our domain being received by our MX is not spoofed. I have some sender access restrictions in place with postfix, but I'm concerned about adding networks to $mynetworks that we don't control but are authorized to send mail as my domain according to our SPF record. Hope that makes sense. Thanks, Alex
