PTR Records

[HCHTech]

PTR records need to resolve to the IP address of the A record of the domain, right? NOT the IP address of the SMTP server sending mail for the domain? I'm sure this is simple, but the more I read the less I'm sure.

1-person business, using GoDaddy for hosting, so their mail is coming from smtp.secureserver.net. Their A record, however points to a Cloudflare address, and that's where their DNS is. Name servers are elisa.ns.cloudflare.com and leonidas.ns.cloudflare.com.

They are getting bouncebacks when sending any email with an attachment to any Comcast address - fails as spam siting PTR failed. They don't have any PTR record currently.

Hence the question - should the PTR record use the IP of the GoDaddy SMTP server or the Cloudflare IP of their A record? It seems obvious that to prove email is coming from that domain it should point to the IP of the A record, but on the other hand, that does nothing to prove that the sending server belongs to the domain. Point me out of this circular reasoning, will ya?


Edit, found some further explanation of the code in a Comcast technote:

554 - [PTR lookup failure]​

Comcast requires all sending mail server IP addresses have a valid PTR record set up. This error results when the lookup failed. NXDOMAIN response. One of the authoritative servers for the relevant section of the in-addr.arpa DNS tree is saying that there is no PTR record for the given IP address.​

 

[Markverhyden]

If I remember correctly PTR is used for reverse lookup. So you want to the SMTP server.

What is a pointer (PTR) record?

A pointer (PTR) record is a type of Domain Name System (DNS) record that resolves an IP address to a domain or host name, unlike an A record which points a domain name to an IP address. PTR records...

help.returnpath.com

SMTP - SMTP Reverse DNS Resolution

mxtoolbox.com

 

[HCHTech]

So you want to the SMTP server.

I'm thinking this means this is a GoDaddy problem, then. Wouldn't THEY be the ones to need a PTR record for their mail server? This is different than when you have an onprem Exchange server, for example.

 

[Sky-Knight]

PTR records are simply reverse lookup records. They aim at forward lookup records.

And yes, if you want to run a mail server you need a PTR record that resolves the IP address sending SMTP to the world, to the forward lookup of the mail server in question.

So if mail.whatever.com resolves to the SMTP service that's transmitting, then that's what you want the PTR record aimed at.

PTR records are handled by the ISP that owns the IP's by the way, so Godaddy has nothing to do with this. Call your ISP, and if they don't offer PTR support... well have fun migrating them to m365. Which... to be fair is where they probably should be to begin with. Managing a mail server all on your own is NOT TRIVIAL. It's an entire technical specialty all on its own.

And no, this is no different if the on premise mail server is exchange, or anything else.

 

[HCHTech]

Thanks - This person has their own domain (probably originally done through GoDaddy, but that's just a guess), but this isn't Exchange - they are POPing email, so there is no mail.theirdomain.com. Their mailservers are smtp.secureserver.net and pop.secureserver.net - the same as all GoDaddy clients that aren't using Exchange. So GoDaddy owns the IPs of those mailservers. Does that change your answer?

 

[Sky-Knight]

Yes, because Godaddy's pop/imap/smtp mail cluster is properly configured. (Nope, couldn't type it with a straight face)

Email from that mess isn't going into the junk folder becauese of reverse DNS, it's going into the junk folder because that very same cluster is responsible for all of Godaddy's shared mail hosting systems emailing... sitting on top of terrible security that's been breached multiple times in the last year alone... and generally rightfully considered the largest botnet on the planet.

All you can do is call Godaddy, lodge a complaint, and hope support gets in touch with Comcast to get things sorted. Though any attempt is likely to have them try to sell you their horrifyingly gimped M365 rebranded service.

It's not up to your customer to complain, it's up to your customer's customers at Comcast to complain... that's where the real fix needs made. I wouldn't hold my breath though.

But there is no record you can make that will fix this... it's utterly out of your hands. Well, unless you want to migrate them to a proper mail solution. That is the only way to fix Godaddy pop/imap mail. (My last two clients are FINALLY coming off that crap)

I can however offer a unique service if you'd like... type something up... I'll print it, drive over to their HQ in Scottsdale and staple it to someone's forehead. Oh wait... crap... they're all working from home so I can't do that... erm... well... Sorry for the pain the local internet juggernaut has inflicted on you.

Outgoing Email from Godaddy Email Relay not delivered to @comcast.net addresses

On Feb. 5th 2020 my clients were noticing they weren't getting email from their websites, if they were being sent to a COMCAST.NET account. After investigating with test php scripts logs were reporting the emails did leave sites and did make the Godaddy email relay servers. The emails were...

www.godaddy.com

Apparently you're not alone... nor is this new behavior.

 

[HCHTech]

I can however offer a unique service if you'd like... type something up... I'll print it, drive over to their HQ in Scottsdale and staple it to someone's forehead.

Hahahahaha - Now THIS is a service I can get behind! Hard to convince tiny businesses like this to go O365 because their crappy email now is "free". This nonsense gives a real reason they can understand.

 

[Markverhyden]

Irrespective of the issues between providers it's the domain email manager who is responsible for making sure all proper DNS records are there. So they need to have DKIM, DMARC, SPF, and PTR published. If you can't prove those have been published they'll just point that finger back at you.

 

[Sky-Knight]

Irrespective of the issues between providers it's the domain email manager who is responsible for making sure all proper DNS records are there. So they need to have DKIM, DMARC, SPF, and PTR published. If you can't prove those have been published they'll just point that finger back at you.

I'm sorry but this is partially incorrect.

PTR records belong to the owner of the IP address, not the domain. All the other records belong to the domain's namespace, PTR records are in a different name space, that again belongs to the IP holder. In this case, Godaddy.

@HCHTech Godaddy has said that service will die at some point, they've never announced exactly when... but their sales team is working double time trying to get people out of that and into M365. Eventually, they'll just get frustrated with the lack of movement and sunset the entire thing, but that won't happen until it costs more than it makes... When will that happen? I have no idea... nor does anyone else.

Which is my primary driver... it's not supported anymore. And it's not a great idea to wait until it dies to move.

 

[YeOldeStonecat]

Can you post an example of the NDR?
I've never....had to fiddle with RevDNS and PTR for POP/IMAP email hosted by an ISP or web host. I've only had it done for Exchange servers we had at our clients that sat on the ISP bandwidth....you call the ISP to have that done.

If your clients email resides with GoDaddy, the management of those are Godaddys responsibility. You shouldn't have to life a finger for our clients DNS relating to mail except for the MX and SPF....and I guess DKIM....although I don't really do POP/IMAP so haven't seen what DKIM for those is like.

 

[Markverhyden]

I stand corrected on PTR. Could have sworn I had made changes related to that a few years ago because of rDNS issues and my email server. But when I checked some notes turns out, while it was an rDNS issue, it's because I was using a residential account for my email server. So even if I published the correct MX records certain ISP's still returned the ISP assigned FQDN, eg 1.2.3.4-somerouter-sometown-someisp.com. Which ****** me off because up to that point I'd been using the residential, lower cost, account for almost 10 years with no problems. Getting a business account fixed that problem.

I've enabled DKIM, DMARC, and SPF on all my O365 customers. On my own server I've just fiddled around with them to see what happens. Currently I just have DMARC enabled.

 

[HCHTech]

Can you post an example of the NDR?

Reporting-MTA: dns; p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.228]
Received-From-MTA: dns; Brian2019 [XX.XXX.204.122]
Arrival-Date: Fri, 04 Dec 2020 11:23:30 -0700


Final-recipient: rfc822; xxxxxxx@comcast.net
Diagnostic-Code: smtp; 554 5.1.0 173.201.193.231 Comcast block for spam. Please see http://postmaster.comcast.net/smtp-error-codes.php#BL000000

Last-attempt-Date: Fri, 04 Dec 2020 11:23:31 -0700

-----

the "554" is the key - I posted Comcast's explanation for that at the bottom of the original post. This is definitely a GoDaddy problem. We're working through the process now - it's a bit complicated because they have a web guy who is reselling GoDaddy, so there is a middleman.

 

[YeOldeStonecat]

As much as I want to rag on GoDaddy ....I was surprised that they wouldn't have a PTR setup for one of their servers.

I ran the above IP against MX Toolboxes PTR check..and it has a record and it's published.
In my experience, Comcasts spam filtering is frequently on the wonky side.

 

[HCHTech]

Ahh - good call, it didn't occur to me to try and disprove their own message. So this is a Comcast problem after all. At least that gives me somewhere to point them. Thanks!

 

[Markverhyden]

smtp: 554 5.1.0 has nothing to do with PTR. Almost all search references point to spam filtering/blocking. If you check the sending client IP, .231, for blacklist it's listed.

 

[YeOldeStonecat]

Hah...a GoDaddy mail server used for spamming? Nooooo........can't be.....

LOL.