I encountered an unusual case where a client's domain had a SPF record with "include=" instead of "include:" for one of its includes. While I didn't notice it immediately, the DMARC report revealed numerous PERMERRORs for SPF results from the client. What made it even more peculiar was that some reporters accepted it as valid, while others returned PERMERROR.
As far as I understand and according to RFC 7208, the only '=' sign in the SPF record should be in the version part (v=spf1). Please correct me if I'm mistaken.
Upon examining the code, I noticed that in lines 38 to 41 of spf.py, the following regular expression was used:
Hi,
I encountered an unusual case where a client's domain had a SPF record with "include=" instead of "include:" for one of its includes. While I didn't notice it immediately, the DMARC report revealed numerous PERMERRORs for SPF results from the client. What made it even more peculiar was that some reporters accepted it as valid, while others returned PERMERROR.
As far as I understand and according to RFC 7208, the only '=' sign in the SPF record should be in the version part (v=spf1). Please correct me if I'm mistaken.
Upon examining the code, I noticed that in lines 38 to 41 of spf.py, the following regular expression was used:
SPF_MECHANISM_REGEXSTRING = ( r"([+-~?])?(mx|ip4|ip6|exists|include|all|a|redirect|exp|ptr)" r"[:=]?([\w+/.:-{%}]*)" )
I replaced it with the following (noting the removal of the equal sign on the third line):
SPF_MECHANISM_REGEXSTRING = ( r"([+-~?])?(mx|ip4|ip6|exists|include|all|a|redirect|exp|ptr)" r"[:]?([\w+/.:-{%}]*)" )
And it appears to be functioning correctly. This leads me to wonder about the purpose of the equal sign and what I might be overlooking.
I've created a test subdomain with this issue. To observe the problem, please run the CLI for the following domain: "invalid-spf.nestous.nl".
Best regards, Ebrahim Aharpour