--- a/xml/dnsbl.in	Thu Mar 30 10:31:23 2017 -0700
+++ b/xml/dnsbl.in	Sun Apr 16 09:06:52 2017 -0700
@@ -545,7 +545,8 @@
                 identical to a DMARC reject policy with strict identifier alignment.
                 When doing SPF fallback, DMARC checks SPF based on the rfc5321
                 envelope from domain. DNSBL checks SPF based on the rfc5322 header
-                from domain.  DMARC does not allow mail from good.example.com to be
+                from domain, but we ignore mx: and ptr: elements in the txt record.
+                DMARC does not allow mail from good.example.com to be
                 signed by trusted.example.net - which is a common case. Both Microsoft
                 Office365 and Google run mail for customer domains, but use DKIM
                 signing domains in onmicrosoft.com and gappssmtp.com, which are
@@ -955,11 +956,11 @@
             #
             # blacklisting based on header from value - requiring signatures
             # from an impossible signer.
-            spammer.domain      require_signed  " ";
+            spammer.domain      require_signed  .;
             #
             # whitelisting based on strong spf pass - whitelisted if signed by
             # an impossible signer (which will never happen) or strong spf pass.
-            some.domain         signed_white    " ";
+            some.domain         signed_white    .;
             #
             # whitelisting based on valid signature or strong spf pass.
             # some paychex mail is signed, some is unsigned but passes strong spf.