Could someone please ask support personnel not to enable SPF without asking (and sometimes not even informing) us?
The last two mail problems I've had, support has enabled SPF on 'pass' without asking who my customer's ISP is.
They've also added a custom DNS TXT that shows
"v=spf1 a mx ptr:m****here.biz -all"
This means that customer's regular mail sent through their ISP fails SPF!
On ticket RS #ALP-87152-362, the problem still exists. Adding more SPF records on top of the spurious one will not fix this. I've tried that, and the SPF record returned is not readable because it still contains the spurious record before the real one. I've turned SPF off again, but the rubbish SPF record is still reported (live check at dnsreport.com).
---
You can check dnsreport.com to see the real SPF record returned by the mail servers (if it can connect to them), rather than what Hsphere says.
A good SPF record should say something like
"v=spf1 a mx ptr:m****here.biz ptr:yourisp.com -all"
This will 'pass' all mail sent by servers in the a and mx records, servers that end with 'm****here.biz', or sent through your ISP, and it will 'fail' all others.
A bad SPF record such as the one I'm getting and can't get rid of looks like this:
"v=spf1" "a" "mx" "ptr:comcast.net" "~all" [TTL=86400]
This is gobbledegook and is not understood because it does not have spaces between the parameters. Mail servers checking this will see "v=spf1amxptr:comcast.net~all" and disregard it.
The last two mail problems I've had, support has enabled SPF on 'pass' without asking who my customer's ISP is.
They've also added a custom DNS TXT that shows
"v=spf1 a mx ptr:m****here.biz -all"
This means that customer's regular mail sent through their ISP fails SPF!
On ticket RS #ALP-87152-362, the problem still exists. Adding more SPF records on top of the spurious one will not fix this. I've tried that, and the SPF record returned is not readable because it still contains the spurious record before the real one. I've turned SPF off again, but the rubbish SPF record is still reported (live check at dnsreport.com).
---
You can check dnsreport.com to see the real SPF record returned by the mail servers (if it can connect to them), rather than what Hsphere says.
A good SPF record should say something like
"v=spf1 a mx ptr:m****here.biz ptr:yourisp.com -all"
This will 'pass' all mail sent by servers in the a and mx records, servers that end with 'm****here.biz', or sent through your ISP, and it will 'fail' all others.
A bad SPF record such as the one I'm getting and can't get rid of looks like this:
"v=spf1" "a" "mx" "ptr:comcast.net" "~all" [TTL=86400]
This is gobbledegook and is not understood because it does not have spaces between the parameters. Mail servers checking this will see "v=spf1amxptr:comcast.net~all" and disregard it.
