Thanks for this tool, which I just ran. 

We don't support IPv6, which were pretty much all of our bad scores, so not 
bothered. 

We got a ding on our DNSSEC score, because the PTR record isn't signed. Is this 
really as big an issue as the explanatory test makes out? 

"Some names needed for email delivery are not DNSSEC signed. This is important 
to verify the authenticity and integrity of the SPF, DKIM and DMARC entries." 

Our cluster is hosted on AWS; we really have no control over whether they sign 
PTR records for their IPs. 

Thoughts? 

We also got a ding on our MTA-STS record, but [ 
https://esmtp.email/tools/mta-sts/ | https://esmtp.email/tools/mta-sts/ ] said 
the only problem is a missing CRLF at the end of our txt file; easy enough to 
fix. This tool however just said that our system doesn't support MTA-STS. After 
I add the CRLF I'll rerun the test; if it still fails, I'll report back. 

Thanks again for this testing tool! 
Mark 

P.S. We also got a ding on our MTA-STS record, but [ 
https://esmtp.email/tools/mta-sts/ | https://esmtp.email/tools/mta-sts/ ] said 
that's due to a missing CRLF at the end of our txt file; easy enough to fix. 
_________________________________________________________________ 
L. Mark Stone, Founder 
North America's Leading Zimbra VAR/BSP/Training Partner 
For Companies With Mission-Critical Email Needs 


From: "Laura Atkins via mailop" <[email protected]> 
To: "Gellner, Oliver via mailop" <[email protected]> 
Sent: Thursday, March 2, 2023 12:38:52 PM 
Subject: Re: [mailop] Mail Sending Self-Test Platform 





On 1 Mar 2023, at 16:21, John R Levine via mailop <[email protected]> wrote: 


BQ_BEGIN
Still, i am a bit wondering; Looking at the data flushed in so far (and 
already multiple bugs filed against implementations)... there are a lot 
of funny milters and often unmaintained software integrated in funny 
docker stacks (probably preaching to the choir there, but i have a lot 
of grievances with those setups), and generally a lot of awry things 
(example.com. IN TXT "v=spf1 include:example.com -all" is, for example, 
far more common than i'd have ever believed...). 



In the DMARC working group we've had endless arguments about what changes will 
or won't break existing DMARC setups, informed by a lot of opinions and very 
little data. Actual data would be greatly appreciated. 

It's not surprising that there are a lot of broken DMARC and SPF records. The 
question is whether anyone cares. My impression is that in many cases there was 
a checklist item "DMARC" so someone did the absolute mimimum. A p=none policy, 
a sloppy SPF record, and no DKIM is a strong hint. 

BQ_END

Likewise, there are countless folks out there recommending implement DMARC for 
every deliverability problem (with absolutely zero recommendations as to what 
that means). There are also soom EXTREMELY broken SaaS providers who have 
instructions for that say: publish this DKIM key in your DNS, publish this 
DMARC record and publish this SPF record - while the SaaS provider uses none of 
the customer domains anywhere in the mail. 

Additionally, there are scammers out there hunting for bug bounties using “your 
domain is at risk due to a lack of DMARC record, how much will you pay me for 
letting you know?” 

laura 

-- 
The Delivery Experts 

Laura Atkins 
Word to the Wise 
[email protected] 

Email Delivery Blog: http://wordtothewise.com/blog 







_______________________________________________ 
mailop mailing list 
[email protected] 
https://list.mailop.org/listinfo/mailop 
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop

Reply via email to