Welcome to Comcast Help & Support Forums
Find solutions, share knowledge, and get answers from customers and experts

New to the Community? Start here.

5,763,002

members

21

online now

1,918,610

discussions

Back to Top

Re: Domains unable to send to Comcast.net from Exchange servers

ANSWERED
Highlighted
Regular Visitor

Re: Domains unable to send to Comcast.net from Exchange servers

We are having this same "delay" problem.

 

I am not sure how to trace this; not sure how to identify the problem.

 

We have tried to send to a half dozen comcast accounts.  After a few hours, we get some "delayed" message, but no further details.  We confirm that the email is not received.  This only happens when sending to Comcast servers.

 

We have implemented the changes described in this thread, but still have the same results.

 

We have tried submitting our IP to comcast for blacklist / blockedlist removal, but they say it is not on the list.

 

Any other suggestions?  We have customers that use Comcast... this is a bit of a problem for us...

 

==> Mike.

 

Accepted Solution

Re: Domains unable to send to Comcast.net from Exchange servers

Big thanks to "ComcastAlex".

 

This was a bit of a challenge, so I  thought I'd post my results.

 

We host our own Exchange Server.  Our DNS is managed at Bluehost.

 

We switched to a new ISP.

 

Outbound email worked immediately.  We changed our MX record at Bluehost, and after an hour or so we started receiving inbound email.  Inbound/outbound was good for worldwide.  All seemed great... until we started getting "Delivery is delayed to these recipients or groups: " errors.  Only on mails sent to Comcast.  They would ultimately turn into “Undeliverable”, with the error message “#550 4.4.7 QUEUE.Expired; message expired ##”.  The Comcast postmaster does not really provide much information about this particular error.

 

I went into Comcast online chat.  Support guy was friendly, but could not offer much advice beyond “Report IP as blacklisted, they will remove.”  I explained that I had already tried that.  He offered phone number for Networking Department, Level 2 support.  I made two calls.  They were no help.  The first one said it was not comcast’s problem to solve.  Hang up, dial again.  Second one said “Comcast is having some inbound problems, so just wait a few days, and it will clear itself up.”  OK, this is going nowhere…

 

So, I connected with ComcastAlex on this board.  After a little work, ComcastAlex found out that our new IP number did not have a PTR record.  I didn’t know much about a PTR record, other than it is apparently a reverse DNS.

 

I called Bluehost.  They were not particularly helpful.  The first online chat person said to enter it as a TXT record, but could not tell me the format.  Suggested I keep trying until it starts to work.  The second contact – a phone call – was more productive.  He put me on hold for some time, then came back and said that Bluehost does not support PTR.  Bluehost did say that they supported SPF, which they claimed was equivalent.  They pointed to this TXT record:  “v=spf1 a mx ptr include:bluehost.com ?all”  Researching it suggested that an SPF record is sufficient for most email systems.

 

ComcastAlex pointed out that none of that mattered for Comcast.  PTR is required for Comcast.  No exceptions.

 

I was puzzled; our email worked before, and there was nothing in our previous DNS records.  Why would an ISP switch matter?  Our DNS management remained unchanged, except for the mx record.

 

Well, to bring this long story to an end… turns out that DNS for a single IP can be managed at multiple places.  ComcastAlex showed me the PTR record from our previous IP, and while it didn’t point to our domain (and probably never did), there was nonetheless a PTR record, and that was apparently enough for Comcast.  I contacted the new ISP, explained the problem.  “No problem…” and they created a PTR record (this time pointing to our domain).  It had never occurred to me that multiple places can set DNS records for the same IP.  We manage our DNS at Bluehost, but the ISP can also set the PTR record.

 

So now, Comcast customers receive email, and we’re able to close the book on this problem.

 

(One final note… in researching this I stumbled across a tip when changing MX records.  A few days in advanced, change the TTL setting to a lower number.  This way, when you make the change, it will propagate faster!  After making the change, you can increase it again back to the “normal” setting.)

View answer in context
Official Employee

Re: Domains unable to send to Comcast.net from Exchange servers

Do you have a copy of the "delay" message?  Your sending IPs would help as well.  If you'd feel more comfortable sending me a private message for this, please click on my name and see the link for sending me a private message.




Community Icon
I am an Offical Comcast Employee.
Official Employees are from multiple teams within Comcast: Product; Support; Leadership.
We ask that you post publicly so people with similar questions may benefit from the conversation.

Was your question answered? Mark it as an accepted solution!solution Icon
Community Icon
I am an Offical Comcast Employee.
Official Employees are from multiple teams within Comcast.
We ask that you post publicly so people with similar questions may benefit.
Was your question answered? Mark it as an accepted solution!solution Icon
Community Icon
I am a Comcast Employee.
Please post so people with similar questions may benefit.
Was your question answered?
Mark it as a solution!solution Icon
Regular Visitor

Re: Domains unable to send to Comcast.net from Exchange servers

Big thanks to "ComcastAlex".

 

This was a bit of a challenge, so I  thought I'd post my results.

 

We host our own Exchange Server.  Our DNS is managed at Bluehost.

 

We switched to a new ISP.

 

Outbound email worked immediately.  We changed our MX record at Bluehost, and after an hour or so we started receiving inbound email.  Inbound/outbound was good for worldwide.  All seemed great... until we started getting "Delivery is delayed to these recipients or groups: " errors.  Only on mails sent to Comcast.  They would ultimately turn into “Undeliverable”, with the error message “#550 4.4.7 QUEUE.Expired; message expired ##”.  The Comcast postmaster does not really provide much information about this particular error.

 

I went into Comcast online chat.  Support guy was friendly, but could not offer much advice beyond “Report IP as blacklisted, they will remove.”  I explained that I had already tried that.  He offered phone number for Networking Department, Level 2 support.  I made two calls.  They were no help.  The first one said it was not comcast’s problem to solve.  Hang up, dial again.  Second one said “Comcast is having some inbound problems, so just wait a few days, and it will clear itself up.”  OK, this is going nowhere…

 

So, I connected with ComcastAlex on this board.  After a little work, ComcastAlex found out that our new IP number did not have a PTR record.  I didn’t know much about a PTR record, other than it is apparently a reverse DNS.

 

I called Bluehost.  They were not particularly helpful.  The first online chat person said to enter it as a TXT record, but could not tell me the format.  Suggested I keep trying until it starts to work.  The second contact – a phone call – was more productive.  He put me on hold for some time, then came back and said that Bluehost does not support PTR.  Bluehost did say that they supported SPF, which they claimed was equivalent.  They pointed to this TXT record:  “v=spf1 a mx ptr include:bluehost.com ?all”  Researching it suggested that an SPF record is sufficient for most email systems.

 

ComcastAlex pointed out that none of that mattered for Comcast.  PTR is required for Comcast.  No exceptions.

 

I was puzzled; our email worked before, and there was nothing in our previous DNS records.  Why would an ISP switch matter?  Our DNS management remained unchanged, except for the mx record.

 

Well, to bring this long story to an end… turns out that DNS for a single IP can be managed at multiple places.  ComcastAlex showed me the PTR record from our previous IP, and while it didn’t point to our domain (and probably never did), there was nonetheless a PTR record, and that was apparently enough for Comcast.  I contacted the new ISP, explained the problem.  “No problem…” and they created a PTR record (this time pointing to our domain).  It had never occurred to me that multiple places can set DNS records for the same IP.  We manage our DNS at Bluehost, but the ISP can also set the PTR record.

 

So now, Comcast customers receive email, and we’re able to close the book on this problem.

 

(One final note… in researching this I stumbled across a tip when changing MX records.  A few days in advanced, change the TTL setting to a lower number.  This way, when you make the change, it will propagate faster!  After making the change, you can increase it again back to the “normal” setting.)