The changes in #212 and #249 should have addressed this. Updating to the latest version should solve your issue.

Thanks for the quick reply Matt. I think those are slightly different issues though (regarding just SPF). This happens when I call Mail::DMARC::PurePerl->new with the header_from parameter. I've tried the latest version of the module and the same problem happens.

The problem is slightly more subtle than I thought. It only happens with public domains that consist of 2 suffixes (with no single suffix equivalent). E.g. .CO.ZA. This is because the single suffix check includes lc whereas the double-suffix does not:

Ahhhhhh, I can see that. I think this is the better way to solve that:

diff --git a/lib/Mail/DMARC.pm b/lib/Mail/DMARC.pm
index 8cd57c7..9a3a3bb 100644
--- a/lib/Mail/DMARC.pm
+++ b/lib/Mail/DMARC.pm
@@ -45,19 +45,19 @@ sub source_ip {
 
 sub envelope_to {
     return $_[0]->{envelope_to} if 1 == scalar @_;
-    croak "invalid envelope_to" if !$_[0]->is_valid_domain( $_[1] );
+    croak "invalid envelope_to" if !$_[0]->is_valid_domain( lc $_[1] );
     return $_[0]->{envelope_to} = $_[1];
 }
 
 sub envelope_from {
     return $_[0]->{envelope_from} if 1 == scalar @_;
-    croak "invalid envelope_from" if !$_[0]->is_valid_domain( $_[1] );
+    croak "invalid envelope_from" if !$_[0]->is_valid_domain( lc $_[1] );
     return $_[0]->{envelope_from} = $_[1];
 }
 
 sub header_from {
     return $_[0]->{header_from} if 1 == scalar @_;
-    croak "invalid header_from" if !$_[0]->is_valid_domain( $_[1] );
+    croak "invalid header_from" if !$_[0]->is_valid_domain( lc $_[1] );
     return $_[0]->{header_from} = lc $_[1];
 }
 

Thoughts?

Thanks Matt, that will definitely work and I'd be happy with that. Given that a domain is always (?) case-insensitive though, I would have thought it might be better to add it to the is_valid_domain function in case it gets used elsewhere in the future?

In a world with unicode characters and IDN, where a naive case change could be lossy, I feel reluctant to be altering domain names at all. I almost feel that passing in valid domain names should be the purview of the calling application (normalizing them with toASCII or punycode). OTOH there's Postel's Law. If we're going to be liberal in what we accept, then I think any case changes should be at the boundaries of the public API, so they're predictable.

Fair enough, makes sense :)