1. 24
  1.  

  2. 3

    Very nice article. One interesting addition would be MTA-STS.

    1. 1

      And TLS-RTP. Hardenize has good primers on both:

    2. 3

      Interesting. Really if you’re a big provider, you don’t have to implement jack shit. If you’re sending out a lot of legit e-mail from your company and have enough people mark it as not spam, those IPs get trusted. It’s much more difficult for small independent e-mail providers and people who self-host. I simply don’t have the volume of outgoing e-mail to not get pulled into the big player’s spam filters:

      https://battlepenguin.com/tech/how-google-and-microsoft-made-email-unreliable/

      1. 1

        Larger providers should employ the same features. It’s not just about avoiding being marked as spam, but also about trustworthiness as a business. SPF and DKIM are both mechanisms designed to ensure the receiver can trust that the message is from you and that you are actually representing that business. In other words, it’s not just about combating spamming, but also about maintaining a reputation.

      2. 1

        pct is the percent of “bad” emails on which to apply the policy

        Why would you ever want to change that to below 100%?

        1. 4

          pct is the percent of “bad” emails on which to apply the policy

          This is bad wording on my part - it’s actually what percentage of failures should be reported. This is to prevent an inundation of email reports. I’ll update it, thanks!

          1. 1

            Oh that makes sense. Thanks for clarifying!

            1. 2

              Actually, I’m incorrect. The RFC actually does specify it as the percentage of emails on which to enforce the policy. Weird, right?

              The idea is to allow a slow rollout of DMARC policies, to make sure nothing breaks. It’s not meant to be kept at that percentage forever - it’s for the first time you set up DMARC, in case you mess it up, you can start at 1% of emails and make sure they still get delivered.