Quote:
Originally Posted by deepsand
From personal experience with Authorize.net, as well as another ASP, I observed multiple instances where e-mail generated on behalf of a client merchant, bearing that client's name/e-mail address as the Sender, but sent from Authorize.net's server, was refused by recipients' e-mail systems which had adopted SPF, owing to Authorize.net not having implemented such.
|
Hi Deepsand, thanks for the clarification.
Just to clear up any confusion this may cause to readers of this thread, I'll put into my own words what I think (IMO) Deepsand seems to have experienced. Of course, I may have it wrong if I've misunderstood him, but what he's describing sounds like an easily preventable situation.
An SPF record allows you to specify "permitted" senders for your domain name. This means you will indicate if your own server sends mail for the domain and also if there are any other servers that might send mail on behalf of your domain.
So, in the instance above, it was not up to Authorize.net to implement SPF in order to send the mail reliably. Rather, it was up to Deepsand's client to ensure their SPF record was complete and Accurate. Mail sent from Authorize.net's server on behalf of Deepsand's client's domain would NOT be rejected if the SPF record were properly configured to identify authorize.net as a "permitted" sender. (Actually, that's kind of the whole point of the SPF record - only the domain owner can change what it says)
Furthermore, the SPF method allows the domain owner to specify how you would like receiving servers to handle mail that does not come from an explicitly permitted server. You can tell it to "pass," "soft-fail" or "hard-fail" such mail. Of course, receiving servers don't have to abide by your instructions but most will take it into account.
Feel free to correct me if I've misunderstood the scenario, Deepsand.
Quote:
Originally Posted by deepsand
My comment was, as stated, addressing SPF only, and under the assumption that SPF was fully implemented, as opposed to being used only for outgoing messages.
|
This makes sense Deepsand. But it's worth noting that SPF does NOT need to be implemented on the server for a domain to have its own SPF record. And perhaps most importantly, if SPF is implemented on the incoming mail server, in most cases (unless you control the server configuration) there's no choice about it for the domain owner. Mail from non SPF recorded domains MAY be blocked, whether they create their own SPF record or not.