Looking for a Microsoft person who can help w/ v6 and Office365 email

Frank Bulk frnkblk at iname.com
Wed Apr 22 17:40:52 CEST 2015

Glad to hear that Microsoft did this on their O365 platform.


Is there an RFC or other standard that we can point other email providers to about implementing email admission in this manner?




From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of Bill Owens
Sent: Wednesday, April 22, 2015 8:08 AM
To: ipv6-ops at lists.cluenet.de
Subject: Re: Looking for a Microsoft person who can help w/ v6 and Office365 email


On Wed, Apr 1, 2015 at 8:02 PM, Bill Owens <owens.bill at gmail.com <mailto:owens.bill at gmail.com> > wrote:
> We've been running our Office365 mail account for a few weeks now with IPv6 enabled. We went into this knowing that Microsoft was going to enforce SPF checks on inbound mail, and we've run into a number of issues with people sending mail over v6 transport and having bad SPF records (or none). So far we've been able to resolve all but one of those issues, or are in the process of doing so; that's not a big deal. The one that won't fix their record is going to require us to resubscribe to a few mail lists, not the end of the world.
> However, we've discovered that there are sporadic failures even when there are valid SPF records, and in some cases even when the email enters the Microsoft 'world' using v4 and transitions to v6 between two Microsoft servers - at which point the SPF check is applied even though the message was "accepted" several hops prior, and the check sometimes fails. That's something we can't fix on our own.

I don't know whether this is in response to the problems we've reported, but Microsoft has changed their attitude towards SPF and
IPv6 just a little. Rather than returning a 5xx error code, which causes the mail to bounce immediately, they're going to return 4xx
and allow the sender to attempt redelivery. This ought to prevent the majority of bounces that we've been seeing, although it
doesn't fix the underlying issue(s) that cause the false SPF failures:



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20150422/a7d2796a/attachment.html 

More information about the ipv6-ops mailing list