Print

[xy16644]

I'm hoping someone can help me or explain to me when IPv6 with SMTP is used over IPv4. Let me explain. I have setup IPv6 with my email server. It has an IPv4 address as well. When I send an email FROM Gmail to my email server it all gets sent using IPv6 so no issues here (I check this in the email headers and Exchange logs).

What I am battling with is when I send email from my email server to Gmail it seems to use IPv4 90% of the time. I can't seem to understand why IPv6 is so rarely used when sending TO Gmail? Why does IPv4 get used most of the time while IPv6 gets used very rarely when Gmail supports IPv6 email? I just can't seem to pinpoint a pattern here!

Yes, I have a PTR record setup for IPv6.

Any ideas? Also, is there another way to test IPv6 email besides using Gmail?

Thanks.

[passport123]

What MTA do you use on your email server?  Does that MTA have any configuration parameters that specify a preference for IPv4 over IPv6?

For example:
http://www.postfix.org/postconf.5.html#smtp_address_preference


Also, are the MX addresses of the destination of equal priority for the IPv4 and IPv6 addresses.

[xy16644]

What MTA do you use on your email server?  Does that MTA have any configuration parameters that specify a preference for IPv4 over IPv6?
For example:
http://www.postfix.org/postconf.5.html#smtp_address_preference

I'm using the Exchange 2016 Edge server as my MTA. I thought IPv6 was always prefered over IPv4? Correct me if I am wrong  I have had a look at the send connector but couldn't find anything wrong.

Also, are the MX addresses of the destination of equal priority for the IPv4 and IPv6 addresses.

I had a look at gmail.com's MX records and they are as follows:

gmail.com   IN   MX   
preference:   5
exchange:   gmail-smtp-in.l.google.com

gmail-smtp-in.l.google.com   IN   A   108.177.9.26
gmail-smtp-in.l.google.com   IN   A   108.177.9.27
gmail-smtp-in.l.google.com   IN   AAAA    2607:f8b0:4003:c13::1b

gmail.com   IN   MX   
preference:   10
exchange:   alt1.gmail-smtp-in.l.google.com

alt1.gmail-smtp-in.l.google.com   IN   A   173.194.219.26
alt1.gmail-smtp-in.l.google.com   IN   A   173.194.219.27
alt1.gmail-smtp-in.l.google.com   IN   AAAA    2607:f8b0:4002:c03::1a

gmail.com   IN   MX   
preference:   20
exchange:   alt2.gmail-smtp-in.l.google.com

alt2.gmail-smtp-in.l.google.com   IN   A   209.85.232.26
alt2.gmail-smtp-in.l.google.com   IN   A   209.85.232.27
alt2.gmail-smtp-in.l.google.com   IN   AAAA    2607:f8b0:400d:c0d::1a

gmail.com   IN   MX   
preference:   30
exchange:   alt3.gmail-smtp-in.l.google.com

alt3.gmail-smtp-in.l.google.com   IN   A   173.194.214.26
alt3.gmail-smtp-in.l.google.com   IN   A   173.194.214.27
alt3.gmail-smtp-in.l.google.com   IN   AAAA    2607:f8b0:400c:c0b::1b
   
gmail.com   IN   MX   
preference:   40
exchange:   alt4.gmail-smtp-in.l.google.com

alt4.gmail-smtp-in.l.google.com   IN   A   64.233.186.26
alt4.gmail-smtp-in.l.google.com   IN   A   64.233.186.27
alt4.gmail-smtp-in.l.google.com   IN   AAAA    2800:3f0:4003:c00::1b

The strange thing is that in Gmail in the email header is says:

Received: from MAIL.domain.com (mail.domain.com. [213.xxx.xxx.xxx])
        by mx.google.com with ESMTPS id k84si25404388wmb.52.2016.05.03.00.41.51

I did a lookup of mx.google.com and it doesn't resolve to anything so I am stumped at this stage. Each MX record has A and AAAA records so I thought the AAAA (IPv6) MX record would have been used as a prioroty over the IPv4 one?

[passport123]

...
I'm using the Exchange 2016 Edge server as my MTA. I thought IPv6 was always prefered over IPv4?
...

The preference depends upon the decisions made by the MTA which, in part, may be determined by how it is configured.

It appears that you have working IPv6 at the server (you get inbound IPv6 mail), you can get IPv6 DNS results, and I don't see any preference for IPv4 over IPv6 in google's MX records. 

If it were my server, my next step in troubleshooting would be to assure the MTA is not configured to give IPv4 a preference over IPv6 for outbound email.  Maybe pose a question on the Exchange support forum?

[xy16644]

Ok, thanks for the help. I'll see what the Exchange forums say!

[passport123]

Also, keep in mind that the main goal of an MTA for outgoing mail is to deliver the mail. 

Whether IPv4 or IPv6 is used to deliver the mail is quite secondary to the goal of assuring the mail gets delivered.

[AndrewButterworth]

I think this might be a quirk of Exchange 2016 or maybe a combination of Exchange 2016 running on Windows Server 2016.

I have had a Windows 2012R2 server running Exchange 2013 for a couple of years.  Its a standalone Exchange server that's a member server in an AD domain.  I have native IPv6 via HE with my own /48 prefix and my egress IPv4 traffic is NAT'd to a single dynamic IPv4 address.
It has been working flawlessly for a couple of years.  It took me a bit of time to get the various DNS records correct initially, however its been flawless since.
I recently decided to retire the Exchange 2013 VM and replace it with Exchange 2016.  I built a Windows 2016 server (Version 1607 OS Build 14393), got it patched to the latest versions of everything, added the prerequisites, prepared AD and then installed Exchange 2016 CU18.  I then migrated everything over and then finally updated various DNS records and the external firewall NAT/Rules.  Everything was working or so I thought.  Then I sent an email to a Gmail recipient and got an undeliverable message from google:

mx.google.com gave this error:
[x.x.x.x] The IP you're using to send mail is not authorized to send email directly to our servers. Please use the SMTP relay at your service provider instead. Learn more at https://support.google.com/mail/?p=NotAuthorizedError n13si8706925wrj.468 - gsmtp

After digging through various logs I can see that the Exchange 2016 server is using the IPv4 address of the server with the highest ranking MX record, even though it has both A & AAAA records.

2020-11-13T11:48:31.794Z,08D887BD691B7D56,SMTP,gmail.com,+,DnsConnectorDelivery 8fb227fc-ba17-49d2-947e-d54dbfcdc25e;QueueLength=TQ=1;RN=1;.
2020-11-13T11:48:32.041Z,08D887BD691B7D56,SMTP,gmail.com,>,"gmail-smtp-in.l.google.com[74.125.133.26, 2a00:1450:400c:c07::1a], alt1.gmail-smtp-in.l.google.com[209.85.233.27, 2a00:1450:4010:c03::1b], alt2.gmail-smtp-in.l.google.com[172.253.118.27, 2404:6800:4003:c05::1b], alt3.gmail-smtp-in.l.google.com[108.177.9..."
2020-11-13T11:48:32.059Z,08D887BD691B7D56,SMTP,gmail.com,>,Established connection to 74.125.133.26

If I block connections to the IPv4 address of the Google SMTP server (74.125.133.26) then it fails the initial connection but retries the IPv6 address which works:

2020-11-13T11:52:13.905Z,08D887BD691B7D59,SMTP,gmail.com,+,DnsConnectorDelivery 8fb227fc-ba17-49d2-947e-d54dbfcdc25e;QueueLength=TQ=1;RN=1;.
2020-11-13T11:52:13.905Z,08D887BD691B7D59,SMTP,gmail.com,>,"gmail-smtp-in.l.google.com[74.125.133.26, 2a00:1450:400c:c07::1a], alt1.gmail-smtp-in.l.google.com[209.85.233.27, 2a00:1450:4010:c03::1b], alt2.gmail-smtp-in.l.google.com[172.253.118.27, 2404:6800:4003:c05::1b], alt3.gmail-smtp-in.l.google.com[108.177.9..."
2020-11-13T11:52:16.752Z,08D887BD691B7D59,SMTP,gmail.com,>,Failed connection to 74.125.133.26:25 (TimedOut:0000274C)[TargetIPAddress:74.125.133.26:25|MarkedUnhealthy|FailureCount:1|NextRetryTime:2020-11-13T11:53:16.751Z]
2020-11-13T11:52:16.753Z,08D887BD691B7D59,SMTP,gmail.com,-,Messages: 0 Bytes: 0 (Attempting next target)
2020-11-13T11:52:16.753Z,08D887BD691B7D5A,SMTP,gmail.com,*,Session Failover; previous session id = 08D887BD691B7D59; reason = SocketError
2020-11-13T11:52:16.753Z,08D887BD691B7D5A,SMTP,gmail.com,+,DnsConnectorDelivery 8fb227fc-ba17-49d2-947e-d54dbfcdc25e;QueueLength=TQ=0;RN=1;.
2020-11-13T11:52:16.775Z,08D887BD691B7D5A,SMTP,gmail.com,>,Established connection to 2a00:1450:400c:c07::1a
2020-11-13T11:52:17.344Z,08D887BD691B7D5A,SMTP,gmail.com,-,Messages: 1 Bytes: 3736 ()

If I open a command prompt on the Exchange 2016 and attempt to telnet to gmail-smtp-in.l.google.com on port 25 it connects using IPv6 which is what I would expect with Windows 2016 as it prefers IPv6 over IPv4 by default.
What appears to be happening is the Exchange MTA is preferring IPv4 for outbound SMTP connections.  I don't think this was the case with Exchange 2013 (or a combination of Server 2012R2 and Exchange 2013).

I am going to bring the original Windows 2012R2 server back online and install Exchange 2016 on it and then add a specific send connector for *.gmail.com via this and see what happens.

Andy

[snarked]

1). You expect Microsoft to do the RFC correct thing?
2). Look at your resolver results.  IPv4 entries are all appearing first, so the mailer is trying IPv4 first as a result.  Probably very little to no randomization of the order of the answers.  Maybe you need to tell your DNS to prefer AAAA over A in its answers (if the mail server lacks such a feature), assuming you have such a setting (BIND does) and appropriate administrative access.

[AndrewButterworth]

OK, you might be on to something there....
The DNS servers are Windows 2019 DC's.  If I capture the DNS traffic when looking up the MX record 'gmail.com' the reply contains the list of server names and priorities plus the reply also contains additional records for entries that are already cached on the DNS server.  For each of the cached hosts the A record IPv4 address is listed 1st.
I can replicate the behaviour by clearing the cache on the client and the server then doing a nslookup for the MX record.  The 1st reply shows no additional records, however if I lookup the A & AAAA records for one of the hosts in the MX record reply and then run the nslookup on the MX records I see the host in the additional records.
If I repeat the behaviour with googles DNS (2001:4860:4860::8844, or 8.8.8. I never see these additional records in the reply.

This must be a side effect of the DNS server behaviour with Windows Server 2019?  I have had a quick search but not found anything so far.

For the time being I have created an ACL on the edge router to drop IPv4 SMTP traffic from the Exchange server to the two google SMTP servers.

Andy