You'll find that several validators are somewhat liberal with
interpretation of RFC logic and the ABNFs. So, it's not really too
surprising.
For example, MXToolbox's SPF validator (until very recently, it seems
they have since fixed it) used to count the number of IP addresses
resolved from the A records returned from an MX query against the number
of allowed A record queries in an MX RR (10), which obviously doesn't
make sense if you read the second paragraph in RFC7208 4.6.4
<https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4>.
Prior to their update, if an A RR in an MX record had 10 IPs returned,
it was counted against the MX address record limitation as 15 A lookups
instead of 1, and immediately said your SPF record had errors. There's
plenty other examples like this with other validators.
Personally, I've liked URIports <https://www.uriports.com/tools>
MTA-STS/SPF/DKIM/DMARC validator, as theirs is one of several that are
strict and accurate to RFC logic.
- Mark Alley
On 6/2/2023 3:17 PM, Gellner, Oliver via mailop wrote:
On 02.06.2023 at 10:22 Johan Lavsund via mailop wrote:
Hi Oliver,
Can you try adding a ; to the end of the dns record?
On 02.06.2023 at 10:23 Taavi Eomäe via mailop wrote:
Your DKIM TXT record seems valid, but does not specify the key type, looking at the
length it should probably contain "k=rsa". Or they might not like you
specifying acceptable hash algorithms.
Your mta-sts.txt does not have a trailing newline, I'm not sure if the standard
mandates it, but that seems to be at least one of the differences.
Thank you all for the recommendations. I‘m going to add a semicolon to the
_mta-sts entry, just to see if this alone makes a difference to that validator,
although RFC8461 describes a trailing semicolon as optional.
I could do the same with k=rsa in the DKIM record, but as mentioned by Benny
Pedersen this tag is optional as well and rsa is the default value anyway.
While I agree that you should be strict in what you send and liberal in what
you receive, I‘d say that adding superfluous tags makes a policy less robust
and not more, as it introduces additional fields which the other party might
trip over.
The DKIM record of John Levines domain is reported as invalid too, while you
should think that he knows his way around DKIM. So in the end this Google tool
might in fact be buggy.
—
BR Oliver
________________________________
dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de<mailto:dmt...@dm.de> *www.dmTECH.de<http://www.dmtech.de>
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
________________________________
Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser ServiceCenter
Fragen haben, bei uns einkaufen oder unser dialogicum in Karlsruhe besuchen, mit uns
in einer geschäftlichen Verbindung stehen oder sich bei uns bewerben, verarbeiten wir
personenbezogene Daten. Informationen unter anderem zu den konkreten
Datenverarbeitungen, Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
Datenschutzbeauftragten finden Sie
hier<https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832>.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
