Recent searches
Search options
@link2xt While it's true that understanding the nuances of email authentication like SPF, DKIM, and DMARC can be complex, these protocols serve crucial roles in securing email communications. They are highly effective when implemented properly. Securing and ensuring the deliverability of your emails requires a certain level of effort and understanding. If you find it challenging, opting for a third-party email service that manages DNS records might be a viable alternative.
Implementing DMARC isn't just about receiving reports; it's also about checking alignment to prevent email spoofing and spear-phishing attacks, thereby enhancing your email security. Choosing not to enable DMARC reports is an option, but it's important to understand that DMARC, along with SPF and DKIM, is fundamentally about protecting your email infrastructure. The notion that "they" have misled us is a misunderstanding of the purpose and function of these email security measures. It's essential to approach these topics with a willingness to learn and understand their significance in the broader context of internet security.
@freddieleeman
At @delta we are currently building https://github.com/deltachat/chatmail email setup running on https://nine.testrun.org/
For email authentication we have SPF, DKIM and DMARC records and pass all https://www.learndmarc.com/ checks, but instead of any DMARC implementation run only OpenDKIM and reject any incoming mail that does not have strictly aligned to HELO, MAIL FROM and From: field DKIM record without even requesting SPF or DMARC from the sender. That is more secure than any DMARC setup.
@freddieleeman This would result in similar policy for outgoing mail if every receiver implements DMARC correctly. But we want to enforce strict DKIM policy on every other server sending incoming mail to us even if they publish p=none record or no SPF/DKIM/DMARC at all.
I consider changing current "v=spf1 a:nine.testrun.org -all" to "'v=spf1 ~all" or "'v=spf1 -all", but this might break delivery to servers that only implement SPF.
@link2xt Sorry, your reply is very confusing, so I hope this response makes sense. Setting a DMARC policy is for receiving servers, not incoming email. If you run your own mail server, you can bounce every email without a valid aligned DKIM signature, but that would undoubtedly cause deliverability issues. Most large email providers have properly adopted DMARC, so if you want servers to reject emails from your domain, without DKIM, set up SPF and DKIM like I mentioned previously.
@freddieleeman
> If you run your own mail server, you can bounce every email without a valid aligned DKIM signature
This is what we do. This already resulted in two servers reportedly fixing their DKIM setup after getting a DKIM error and revealed a bug in incoming filter breaking DKIM signature in some cases. We are fine with not receiving mails without proper DKIM signatures.
@freddieleeman
> Most large email providers have properly adopted DMARC, so if you want servers to reject emails from your domain, without DKIM, set up SPF and DKIM like I mentioned previously.
This is almost what we do. We publish proper SPF, DKIM and DMARC records with the strictest policies possible except that we have not removed "a:nine.testrun.org" from SPF yet because of the concern that it might break delivery to servers that only support SPF.
@freddieleeman Opened an issue to track this with more explanation: https://github.com/deltachat/chatmail/issues/211
@freddieleeman To clarify, STOP DOING DMARC is mostly a joke, but I am also serious about not running DMARC software on the server which implements all sorts of policies and generates DMARC reports as it adds a lot of complexity. We can do this because we don't care about federating with non-secure servers not supporting DKIM and hopefully it results in faster adoption of DKIM among servers which want to federate with us.
@freddieleeman This is not a conventional setup as we have essentially defederated all email servers not implementing DKIM, but is much easier to reason about than learning about all the possible non-strict alignments, interactions between SPF and DKIM fails/softfails etc.