@j_massey check your spam folder because 100% of all emails to our servers from the domain are being delivered.
Latest error is
451 4.4.1 [internal] No valid hosts (unable to make any connections)
The only time I have seen this is when the recpient server is blocking connections from the IP. Can you check this?
bradleycollection.com has not contacted the comcast.net server in the last 14 days indicating that they have an email for you.
The domain bradleycollection.com has sent over 100 emails to the comcast.net server in the last 24 hours though and all have been delivered.
I only show 3 messages sent in the last week, with over 100 attempts to deliver. I truncated the recipient email, but just to make sure we are on the same page, here are the details. We are doing root lookups to determine mx records, and we have no other emails queued for delivery to other domains. Notice the error goes back and forth between the two errors below. Thanks
right, im doing root lookup on not just individual delivery, but also overall delivery. Overall, there is no blocks, filtrations, or failures in delivery. Specific to you - there are no existent logs. Meaning that the domain in question never reached the Comcast.net server for deliveries specificly to your email.
edit: I was able to review your images, its confirming that there is a [internal] issue on the domain side when trying to send. This issue is not caused by the comcast.net server. It is internal to the domain.
I telneted directly from the server to 126.96.36.199 on port 25, and was immedialy disconnected. As I mentioned, I usually see this when the desitnation server is blocking my email servers IP. Is the IP address of your server correct? Is there anything else you can check on your side? Thanks
no, even if we were to block the communication, it would report so in the root logs. Its why we have an entire website dedicated to instances where we are blocking a server/ip/domain with reason codes: http://postmaster.comcast.net/smtp-error-codes.php
I've even checked the blocklist and the IP is not being blocked. Seeing how there are successful deliveries from the domain overall, it further solidifes that the error isnt coming from the Comcast server. That and the [internal] notice you are getting from your server with failed delivery messages. Feel free to PM me the recipient on comcast.net that you are trying to send it to and i can see if i can dig anything else up. I can at least confirm if the domain outbound server even reached our inbound on the back end. So far everything says that the outbound connection when delivering to that specific address never leaves the bradleycollection.com server because it cant find the comcast.net server.
I have had a similar problem in the past. After much gnawing and research, it appears this is what was happening. The sender is not creating correct email headers and in my case, it did not have a return email address (actually it was another field but I have forgotten it). COMCAST would throw it in the spam folder. This usually happens when the sender is a "canned system" and they do not have one of the required email headers fields filled in (My memory is iffy here so I would rather not guess). I had to jump through hoops and go up and down a few phone calls to get this corrected on the vendors' end as everybody was pointing the finger at each other. I hate these canned systems. They have their place but nobody takes the responsibility to get the issue fixed. One thing that helped me was that I had an email sent to a YAHOO email account and YAHOO had an error highlighted that indicated the issue. I am not an email guru but COMCAST was of no help and I had some people that I had to get involved to help me out. Good luck.
I checked futher back, and the last sucessful sent email was May 1st. The errors began when the Comcast SMTP server switched from 188.8.131.52 to 184.108.40.206. Hope this helps.
Servers/routers rebooted, SPF and PTR's are all coming back ok.
the Comcast SMTP server switched from 220.127.116.11 to 18.104.22.168.
The servers have never actually switched, we have two equally weighted MXs that have been established for multiple years. I've also engaged an engineering team to review the issue just in case as well and will keep you updated as soon as i get a response from them.