<div dir="ltr">On Wed, Apr 22, 2015 at 11:40 AM, Frank Bulk &lt;<a href="mailto:frnkblk@iname.com">frnkblk@iname.com</a>&gt; wrote:<br>&gt;<br>&gt; Glad to hear that Microsoft did this on their O365 platform.<br>&gt;<br>&gt;  <br>&gt;<br>&gt; Is there an RFC or other standard that we can point other email providers to about implementing email admission in this manner?<br><br>MAAWG<br>has<br>guidelines, for whatever level of &#39;standard&#39; that is:<br><br><a href="https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf">https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf</a><br><br>They do a little handwaving around how to handle SPF records: &quot;MAAWG therefore recommends moving toward rejecting email that does not contain a valid DKIM<br>signature or that does not pass SPF checks...&quot;<br><br>I am not an expert on SPF, though I&#39;ve learned quite a bit while troubleshooting this<br>and I think something between the Google standard of only allowing SPF to influence spam scores and the Microsoft no-soup-for-you mode is probably appropriate. If I were to sketch out a policy for my own server, it might look like this:<br><br>   missing or invalid SPF record -&gt; increased spam score, moving to soft fail or greylisting over time as fewer domains lack SPF<br>   failed SPF check -&gt; follow the SPF record (+?~-)<br><br>I&#39;d also only check on the true ingress, when the email enters my domain (not too hard since I only have one mail server). With a lot of logging to detect issues without relying on the users to report bounces (admittedly very hard on a big server, but Google at least may be doing some of that) and a whitelist mechanism for domains like <a href="http://debian.org">debian.org</a> that use v6 mail but refuse to add an SPF record.<br><br><br>Bill.</div>