[HN Gopher] Use SPF softfail, not (hard) fail
       ___________________________________________________________________
        
       Use SPF softfail, not (hard) fail
        
       Author : LeonM
       Score  : 4 points
       Date   : 2023-01-11 20:53 UTC (2 hours ago)
        
 (HTM) web link (www.mailhardener.com)
 (TXT) w3m dump (www.mailhardener.com)
        
       | LinuxBender wrote:
       | I will personally always use hard fail. If I need to relay mail
       | then I configure the receiving site to make an exception for the
       | relay. If that isn't possible then I do not relay. In a
       | corporation this requires some level of discipline and knowing
       | what is sending emails and why. Security teams should have a
       | weekly test to see if they can spoof senders in their corporate
       | email both from inside their company and from untrusted external
       | IP's. I have found it too easy to spoof people in legal, security
       | and leadership in most companies.
       | 
       | Adding to this, hard fail should be used with parked domains
       | without exception. If a domain is not used for sending emails
       | then it should have a null MX and hard fail SPF stating not to
       | trust any IP's or domains.                   @  1d in mx 0 .
       | @  1din txt "v=spf1 -all"         @  1d in caa 0 issue ";"
       | @  1d in caa 0 issuewild ";"         dmarc  1d in txt
       | "v=DMARC1;p=reject;sp=reject;pct=100;aspf=s;"         _domainkey
       | 1d in txt "v=DKIM1; p="         _bimi 1d in txt "v=BIMI1; l=;
       | a=;"         *  1d in mx 0 .         *  1d in txt "v=spf1 -all"
       | *._domainkey 1d in txt "v=DKIM1; p="         *  1d in caa 0 issue
       | ";"         *  1d in caa 0 issuewild ";"
        
         | LeonM wrote:
         | > Adding to this, hard fail should be used with parked domains
         | without exception. If a domain is not used for sending emails
         | then it should have a null MX and hard fail SPF stating not to
         | trust any IP's or domains.
         | 
         | This is correct, but this is also mentioned in the article
         | multiple times.
         | 
         | To add to that, a DMARC record with a "reject" policy is also
         | recommended for domains that are not supposed to send any
         | email, see also: https://www.mailhardener.com/kb/hardening-
         | unused-domains
        
           | LinuxBender wrote:
           | Also null BIMI records as well, especially if one is going to
           | use soft-fail. Or maybe a malware symbol.
        
             | LeonM wrote:
             | > Also null BIMI records as well
             | 
             | Could be useful, but a successful attack on BIMI would
             | require: - Getting access to the DNS of the domain (in
             | which case the null record will simply be replaced) -
             | Obtaining a VMC for the domain, which should not be
             | possible due to the extended validation requirement for a
             | VMC (such as: phone validation) - Spending ~$800 on a VMC
             | 
             | > especially if one is going to use soft-fail.
             | 
             | As explained in the article, if DMARC is deployed then
             | softfail is equal to (hard) fail. With DMARC anything that
             | is not an SPF pass, is not aligned, thus a fail.
             | 
             | The only exception here would be a very old legacy email
             | system that doesn't support DMARC. But those will also not
             | support BIMI anyway.
             | 
             | > Or maybe a malware symbol.
             | 
             | BIMI should always require a VMC. It should be impossible
             | to obtain a VMC with a 'malware symbol'. Unless of course
             | you are willing to pay a lot to get it registered as your
             | company logo at your trademark office.
        
       ___________________________________________________________________
       (page generated 2023-01-11 23:02 UTC)