When signing up for anonymous inbound IPv6 support in Office 365, Office 365 requires that senders over IPv6:
- Send email from an IP with a PTR record
- The sending message must pass either SPF or DKIM
Office 365 customers are given a special tag to publish in their MX records which the service resolves. Suppose that Contoso, whose domain is contoso.com, is an IPv4-only customer. Their MX records that they publish in their DNS look like the following:
contoso.com. 3599 IN MX 5 contoso-com.mail.protection.outlook.com.
Which resolves to:
contoso-com.mail.protection.outlook.com. 9 IN A 207.46.163.138
contoso-com.mail.protection.outlook.com. 9 IN A 207.46.163.215
contoso-com.mail.protection.outlook.com. 9 IN A 207.46.163.170
Contoso publishes their mx record contoso-com.mail.protection.outlook.com, but Office 365 then resolves that domain with the above A-record (since Office 365 owns the zone fileprotection.outlook.com).
When a customer enables IPv6, their MX records look like the following:
contoso.com. 3599 IN MX 5 contoso-com.mail.protection.outlook.com.
Which resolves to:
contoso-com.mail.protection.outlook.com. 9 IN A 207.46.163.138
contoso-com.mail.protection.outlook.com. 9 IN A 207.46.163.215
contoso-com.mail.protection.outlook.com. 9 IN A 207.46.163.170
contoso-com.mail.protection.outlook.com. 9 IN AAAA 2a01:111:f400:7c10::1:10
contoso-com.mail.protection.outlook.com. 9 IN AAAA 2a01:111:f400:7c09::11
contoso-com.mail.protection.outlook.com. 9 IN AAAA 2a01:111:f400:7c10::10
Both IPv4 and IPv6 resolve to the same MX priority and it’s up to the sending mail server to pick which one to use. However, because mail servers are supposed to prefer IPv6 over IPv4, most will start with IPv6.
The problem of dual stack IPv4 and IPv6 at the same MX priority
There are a lot of mail servers that send over IPv4 no matter what. And, there are mail servers that will send over IPv6 first (examples include LinkedIn, Gmail, and Office 365 itself). This is fine for senders who authenticate, but what about small senders?
We still live in a day and age where many senders don’t publish SPF records. This includes a lot of small businesses who go to a registrar, get a domain, and send email the same day. They don’t know anything about SPF. Indeed, in Office 365, only 80% of the inbound email we receive has an SPF record and this is heavily skewed by a few large senders.
What frequently happens is that a small business uses their ISP that has properly set up PTR records for their infrastructure to send email. But their ISP then sends email over IPv6 instead of IPv4 and the sender receives a bounce, saying “Huh? What’s SPF? What’s DKIM? I don’t get it.”
For a small receiver like myself, I get email from a few sources like newsletters, and friends and family on large mail providers. Large mail providers all authenticate their email, and so do good newsletters. That’s because their business is getting email delivered so they are on top of things.
But small businesses and senders are not. For someone like me, it doesn’t matter because I don’t have anyone like that who regularly communicates with me. But for a large business that deals with lots of senders, they will lose some legitimate email from senders who don’t authenticate because they don’t know anything about email authentication and their mail provider picks IPv6, unbeknownst to them.
A workaround for IPv6
There is a workaround for this problem. It is not officially endorsed by Office 365 but it should work, I tested it the other day. What you need are two domains whose MX is hosted by Office 365.
This shouldn’t be a problem. If you are a customer with a custom domain, you will have your custom domain plus <yourname>.onmicrosoft.com, for example, contoso.com and contoso.onmicrosoft.com. You get the *.onmicrosoft.com automatically even if you never use it. Alternatively you could create a domain that is used specifically for this purpose.
Your two domains’ MX records would then be the following:
contoso.onmicrosoft.com. 21599 IN MX 10 contoso.mail.protection.outlook.com.
contoso.com. 3599 IN MX 10 contoso-com.mail.protection.outlook.com.
What you can do is the following – if you want to enable contoso.com for IPv6 (because that is the domain you send email from, not contoso.onmicrosoft.com):
- Request to have your primary domain enabled for IPv6, in this case contoso-com.mail.protection.outlook.com.
- Update your DNS records for this domain’s MX records.
For your primary domain (the one you want enabled for IPv6), publish your non-primary domain MX – the one that is IPv4 only - as the higher MX priority (lower number in DNS), and the primary domain’s MX – the one that is IPv6 and IPv4 – as the lower MX priority (higher number in DNS).
For example:
contoso.com. 3599 IN MX 0 contoso.mail.protection.outlook.com.
contoso.com. 3599 IN MX 10 contoso-com.mail.protection.outlook.com.
Which resolves to:
contoso.mail.protection.outlook.com. 9 IN A 207.46.163.138
contoso.mail.protection.outlook.com. 9 IN A 207.46.163.215
contoso.mail.protection.outlook.com. 9 IN A 207.46.163.170
contoso-com.mail.protection.outlook.com. 9 IN A 207.46.163.138
contoso-com.mail.protection.outlook.com. 9 IN A 207.46.163.215
contoso-com.mail.protection.outlook.com. 9 IN A 207.46.163.170
contoso-com.mail.protection.outlook.com. 9 IN AAAA 2a01:111:f400:7c10::1:10
contoso-com.mail.protection.outlook.com. 9 IN AAAA 2a01:111:f400:7c09::11
contoso-com.mail.protection.outlook.com. 9 IN AAAA 2a01:111:f400:7c10::10
What happens is that an IPv4-only email sender to @contoso.com will pick highest priority MX, in this case, the one that is MX 0 which only advertises IPv4 addresses.
However, an IPv6-only email sender to @contoso.com will iterate through the MX records, looking for IPv6 AAAA records until it finds one. It finds it at the lower MX (10) priority.
A dual-stack sender, one that sends over both IPv4 or IPv6, will only send over IPv4 unless the mail server is unavailable and retries over multiple MX records, or sends to the secondary MX (which some senders do – I’m looking at you backcountry.com).
Benefits and drawbacks of this method
This is not an officially endorsed way of receiving email over IPv6.
For one thing, customers have to play around with MX records in DNS rather than simply publishing what we tell them to with a straightforward one-to-one mapping. Setting up DNS records is not most people’s core competency.
Second, the entire point of requiring SPF and DKIM is to move the industry forward – 20% of email does not have SPF and it’s more than that in terms of unique senders because big senders (Facebook, LinkedIn, Twitter, etc.) have so much more email that account for the majority of mail sent, but not the majority of unique senders. This workaround lets unauthenticated email stay unauthenticated.
Still, this requirement does not remove the minimum sending requirements for IPv6 (PTR + SPF or DKIM); it only allows “poor” senders to stay on IPv4. But if you’re going to send on IPv6 intentionally you probably already have PTRs + SPF and DKIM set up.
This workaround lets you receive email over IPv6 if you have a lot of unauthenticated senders by encouraging them to stay on IPv4. And, the IPv6 senders will still be able to reach you because they probably know what they are doing. We still prefer you have dual stack IPv4/IPv6 MX records at the same priority.
But if you can’t, you can try this.
Related Articles
- Support for anonymous inbound email over IPv6 in Office 365
http://blogs.msdn.com/b/tzink/archive/2014/10/28/support-for-anonymous-inbound-email-over-ipv6-in-office-365.aspx - How to create Allow rules for senders in Office 365 over IPv6
http://blogs.msdn.com/b/tzink/archive/2014/10/28/how-to-create-allow-rules-in-office-365-for-senders-over-ipv6-and-also-for-ipv4.aspx