Google blocks receipt of IPv6 email sent by OS X Server

Question

If you are using both IPv4 and IPv6 internet connections and your email users are complaining about not receiving email, especially Google email, read on.
I use a Mac Mini running OS X Server to provide email addresses for officers in our civic association.  Most of the mail was going through but more and more complaints were coming in claiming non-receipt of email.  The mail was not in the recipients spam folder, either.
Postfix on the MacMini would send using either IPv4 or IPv6 connections when forwarding to the recipient email account.  Sending SMTP mail on using either IPv4 or IPv6 to test sites works perfectly.  Google, for some reason, has decided to refuse IPv6 connections that do not resolve with a rPTR record for sending IPv6 address.  Getting a PTR record set for IPv6 isn't always possible and there isn't a good reason why Google needs to be this restrictive.  If the email went to Google using the IPv4 route, messages would arrive in the destination mailboxes just fine since the Google rules on mail sent by IPv4 servers are less restrictive.
Two others have written how to overcome this situation on LINUX servers here http://tanguy.ortolo.eu/blog/article109/google-ipv6-smtp-restrictions and here http://christian.skala.me/blog/gmail-why-are-you-doing-this-to-me/#.VHDsUbnkHYs
These solutions work well on OS X Server's implementation of POSTFIX as long as you change the path names to the files.  So if you run into this problem on your OS X Server here are steps to force all email sent to gmail.com to use IPv4 and mail to all other domains can use wither IPv4 or IPv6.  This is the same process documented in the above links changed to work with the file paths used by POSTFIX in OS X Server
Edit /Library/Server/Mail/Config/postfix/transport using your favorite text editor (I use BBEdit) and add these lines:
Limit gmail.com to IPv4                                                             
gmail.com smtp-ipv4:
Edit /Library/Server/Mail/Config/postfix/master.cf and add these lines:
Limit gmail.com to IPv4 
smtp-ipv4 unix -       -       -       -       -       smtp -o inet_protocols=ipv4
Using terminal turn the transport file into a database POSTFIX can use:
sudo postmap /Library/Server/Mail/Config/postfix/transport
Edit /Library/Server/Mail/Config/postfix/main.cf and add these lines:
Limit gmail.com to IPv4
transport_maps = hash:/Library/Server/Mail/Config/postfix/transport
Use terminal to reload POSTFIX so the changes take place:
sudo postfix reload
You should now be able to send email messages consistently to people with [email protected] addresses and they will always use the IPv4 route while email to other domains will take either IPv4 or IPv6 routes, depending on what is optimally available at the time.

Answer 1

It is increasingly common for (receiving) mail servers to want to check the IP address of a sending mail server matches the authorised listed mail server for a domain, there are various different ways this is done and I don't know whether a simple DNS forward/reverse comparison is one of them. One I do know Google use is SPF (Sender Policy Framework). This uses the addition of a txt record in your domain to list which mail servers are authorised for sending emails for your domain. The SPF rule can be set to be a 'hard' fail which means an unauthorised server is always blocked, or a 'soft' fail in which case it merely increases the spam score making it more likely to be marked as spam. There are other schemes as I mentioned like domain-records/domain-eys and so on.
To check to see if your domain has one of these records try the following in Terminal.app
nslookup -query=txt domain.com
where domain.com is your domain name as used in your email address
Here is the relevant line resulting from checking google.com
google.com text = "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
The ~all entry means 'soft' fail a -all would mean 'hard' fail. The rest of that line defines a group of hostnames to allow, and two IP address ranges to allow.
For domain keys try
nslookup -query=txt mail._domainkey.domain.com
There are other schemes but those are the ones I have used. These are all aimed at trying to filter out fake aka. spam emails, a lot of spam uses fake from email addresses.
One could also argue that at this stage one should have a valid IPv4 address (and reverse PTR) for a mail server so as to allow other IPv4 only connected mail servers to reach you. IPv6 is still not widely adopted unfortunately. It is possible to have DNS records for both IPv4 (an A record) and IPv6 (and AAAA record) and similarly both types of reverse PTR. If your ISP is giving you true IPv6 connectivity and you are running a mail server then I would expect such an ISP to be able to define PTR records. You may need to speak to your ISP about this. The need for a valid reverse PTR is equally valid for both IPv4 and IPv6 and an ISP should be able to do both.