Can't send email using my own server to comcast.net email addresses

Can you post the sendmail output? I will say that I have my own postfix-based email server and can send & receive emails to/from comcast.net addresses with no problem.

Yeah nothing looks off there. I'm guessing you've checked the recepients spam folders? And for your own domain, made sure PTRs and SPFs are setup OK?

SPF is right because if I send something to a gmail account, it goes through fine.  The comcast user I sent it to has nothing , not even SPAM.

What would I be looking for as far as PTR records are concerned?

It seems I only have an issue getting emails through to comcast customers.  It use to work until comcast changed our static IP address when we went from 1 static IP to 5.

When we did that, I did have comcast make sure they setup reverse DNS for our new static IP addresses.  They assured me it did but it still doesn't get through.  I asked them a million times if our IP address is blocked but they do not provide any answer or feedback.  I'm at a loss for what to look at next.

[root@msaapache ~]# sendmail -v XXXX@comcast.net

test

.

XXXX@comcast.net... Connecting to [127.0.0.1] via relay...

220 mail.marplesportsarena.com ESMTP Sendmail 8.14.7/8.14.7; Wed, 3 Jun 2015 10:15:29 -0400

>>> EHLO marplesportsarena.com

250-mail.marplesportsarena.com Hello msaapache [127.0.0.1], pleased to meet you

250-ENHANCEDSTATUSCODES

250-PIPELINING

250-8BITMIME

250-SIZE

250-DSN

250-ETRN

250-AUTH LOGIN PLAIN

250-DELIVERBY

250 HELP

>>> MAIL From: SIZE=5 AUTH=root@marplesportsarena.com

250 2.1.0 ... Sender ok

>>> RCPT To:

>>> DATA

250 2.1.5 ... Recipient ok

354 Enter mail, end with "." on a line by itself

>>> .

250 2.0.0 t53EFTv9030007 Message accepted for delivery

XXXX@comcast.net... Sent (t53EFTv9030007 Message accepted for delivery)

Closing connection to [127.0.0.1]

>>> QUIT

221 2.0.0 mail.marplesportsarena.com closing connection

You have new mail in /var/spool/mail/root

[root@msaapache ~]# sendmail -bv XXXX@comcast.net

XXXX@comcast.net... deliverable: mailer esmtp, host comcast.net., user XXXX@comcast.net

For PTRs, I have understood best practice to be the following. Your domain will have an A record pointing to the IP Address of the mail server, and that IP address should have a PTR that points back to the A record. For example, my A record for my mail server is "mx.pLAN9.co" and points to 50.252.78.1. I contacted Comcast to add a PTR for 50.252.78.1 that has the value "mx.pLAN9.co." The result is shown in the DNS lookups below:

PS C:\> nslookup mx.pLAN9.co
Server:  pLAN9-Server1.pLAN9.site
Address:  fe80::20d:b9ff:fe33:198

Non-authoritative answer:
Name:    mx.pLAN9.co
Addresses:  2601:5:580:1400:6a05:caff:fe0b:a9c3
          50.252.78.1

PS C:\> nslookup -type=PTR 50.252.78.1
Server:  pLAN9-Server1.pLAN9.site
Address:  fe80::20d:b9ff:fe33:198

Non-authoritative answer:
1.78.252.50.in-addr.arpa        name = mx.pLAN9.co

My experience is that some mail servers will attempt to validate PTRs, and some will not.... Perhaps Comcast's mail servers enforce this?

EDIT a site I use often when testing mail server's configuration is http://emailsecuritygrader.com

Well, my configuration is a little more complicated.  Our actual email is hosted by office365.  So all incoming email is directed to that MX server.  The sendmail client is only used to send automated email out from our CRM system.    The IP address of the sendmail client is authorized to send mail through the SPF.  But, if you did an MX lookup of our domain, you would be directed to office365

Was this solved? I'm having the same issue but couldn't reply to the thread that was moved.

Thanks!

Kevin