DNS PTR Record with 2 FQDN Entries with SPAM Check
-
@JaredBusch true, and your point is ?
-
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
@pattonb argh the ip IS NOT listed in their spf record, can't type today
This should affect things.
Valid SPF is critical to helping reducing spam.
-
@JaredBusch SPF has it flaws, however, in this case , ptr check yields 2 fqdn, and no listing in the SPF to confirm validity of sender.
-
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
@JaredBusch true, and your point is ?
That you could likely not receive email from my client because the PTR does not resolve to their domain name. Hence PTR is not a verification of for email.
Or my other client that proxies their outbound email through Google Mail Security (wtf ever they changed the name to).
-
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
@JaredBusch SPF has it flaws, however, in this case , ptr check yields 2 fqdn, and no listing in the SPF to confirm validity of sender.
PTR and SPF have nothing to do with each other.
-
@JaredBusch correct, they are tools to determine validity of incoming email. If you have a mail server , ( I would think with a static ip), why you wouldn't have a ptr record that matches your mailserver, is asking for issues.
-
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
why you wouldn't have a ptr record that matches your mailserver, is asking for issues.
Two very simple reasons that I hae already stated.
Because PTR is not for email verification.
Because PTR records are not something I have access to update. -
Look at it more obviously, taking the entire stupid local email server out of the equation.
How the fuck am I supposed to know what IP Microsoft is using to send my email since I use O365? Let alone how am I supposed to get access to the IP scope to change the PTR.
Of and then also that would screw over every other O365 user that has their email sent out on the same IP address.
-
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
@JaredBusch correct, they are tools to determine validity of incoming email. If you have a mail server , ( I would think with a static ip), why you wouldn't have a ptr record that matches your mailserver, is asking for issues.
No reason for a sending mail server to have a static IP, that's for receipt only. It's actually a sending client. The whole concept of email sending as a static IP'd server doesn't actually make sense. People do it because of bad spam filtering attempts, but it isn't actually logical. The sending action is more akin to a web browser and we don't expect a static IP or PTR record for each web browser out there. It's a transient action.
PTR records are controlled by the ISP and loads of ISPs won't modify them.
-
@JaredBusch said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
Of and then also that would screw over every other O365 user that has their email sent out on the same IP address.
PTR lookups are just for the canonical name of the server (that it is filled in), not that it matches the email address. It's not supposed to match the email domain, if it does, it almost certainly is a bad record.
-
@scottalanmiller said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
@JaredBusch said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
Of and then also that would screw over every other O365 user that has their email sent out on the same IP address.
PTR lookups are just for the canonical name of the server (that it is filled in), not that it matches the email address. It's not supposed to match the email domain, if it does, it almost certainly is a bad record.
But that is specifically what he is asking about. That the PTR matches the sending mail server
-
@JaredBusch incorrect, Scott has summarized succinctly
-
@pattonb said in DNS PTR Record with 2 FQDN Entries with SPAM Check:
@JaredBusch incorrect, Scott has summarized succinctly
That is what you asked. But going with that is not what you actually wanted, then the answer to your original post is that you don't fix anything.
You whitelist the domain in question and move on.
The sender's ISP is in charge of setting the PTR record and there is not a damned thing you can do about it.
