So, my Exchange 2013 server is sending mail happily to the whole world, except when a user is behind a Barracuda cloud email security service. I have some details of a log entry sent to me by an administrator of one of the receiving systems protected by Barracuda hosted systems:
Received-SPF: fail (mx9.ess.sfj.cudaops.com: domain of <agency>.org does not designate ::1 as permitted sender) Received: from <redacted>.local (10.5.10.11) by <redacted>.local (10.5.10.11) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 2 Jun 2015 15:59:30 -0400 Received: from <redacted>.local ([::1]) by <redacted>.local ([::1]) with mapi id 15.00.0847.030; Tue, 2 Jun 2015 15:59:30 -0400
So, if we look at the bottom, <redacted>.local originates email from [::1] - which is the localhost with IPv6. Then it starts using IPv4 for the rest of the mail - moving through the private IPv4 for <redacted>.local and then out the public IP address. The MTA in Exchange identifies the EHLO with mail.<agency>.org. which is identified as the primary MX record for <agency>.org My SPF record reads:
v=spf1 mx a include:constantcontact.com -all
So, why for the love of all that is holy and good in this world, is the Barracuda system at all concerned with the IPv6 originating address in the header? It just stops there. In other email systems, they all start listing the FQDN and MX record, then match it up to the SPF, and pass it through. Please, oh God please tell me why, the system is marking this as an SPF fail based on Private IP and not Public IP which it doesn't even get to? Why fail immediately on the initial server in the header chain? So many systems out there have multiple servers mail passes through before it even gets to the public gateway...
I got one administrator to create an SPF skip rule, but seriously I cannot be the only one with this issue.