3 ms·

This is excellent advice. I wish more people were aware of this need. Registrars _should_ be doing this by default IMO.

Nextgrid 6y ago
Maybe the standard should be changed to distrust lack of SPF/DKIM by default? Within a few years we've severely reworked how HTTPS certificates work (max validity period, signature algorithms, etc) and the world hasn't ended, so maybe mainstream e-mail providers should do the same with e-mail? This would force everyone else into compliance, and unconfigured domains will no longer be a problem because the lack of SPF/DKIM would automatically fail any authentication across the board.
- remram 6y ago
  I would like more sending systems validating the policy before changing the default. E.g., I don't think sendgrid/mailgun/gmail check that they are allowed by the SPF policy to send emails from a domain, when you add a sender address. Worse, some APIs don't require you to set up sender addresses ahead of time, you can just set it in the "send email" API call, which makes it easy to unknowingly send emails that are blocked by your own policy. DMARC would allow you to find out, but I'm not sure how many people have configured reports, apart from those whose whole business is email.
- jeffbee 6y ago
  > Maybe the standard should be changed to distrust lack of SPF/DKIM by default? I don't know what standard might be relevant, but the lack of SPF will kill your inbound reputation for gmail. You'll be lucky to even get beyond MAIL.
- brightball 6y ago
  The challenge there is that SPF/DKIM are a lot harder for bigger companies with thousands of legacy servers that might be sending email. That's specifically why I wish registrars would do this because it's not a big deal for new domains with no existing real mail traffic. DMARC enforcement is getting a lot more recent momentum toward becoming an expectation, it's just a long play. The moment that Google or Microsoft decide to send any mail that doesn't pass DMARC to spam will be the moment where it's a defacto requirement.

Maybe the standard should be changed to distrust lack of SPF/DKIM by default? Within a few years we've severely reworked how HTTPS certificates work (max validity period, signature algorithms, etc) and the world hasn't ended, so maybe mainstream e-mail providers should do the same with e-mail? This would force everyone else into compliance, and unconfigured domains will no longer be a problem because the lack of SPF/DKIM would automatically fail any authentication across the board.

remram 6y ago
I would like more sending systems validating the policy before changing the default. E.g., I don't think sendgrid/mailgun/gmail check that they are allowed by the SPF policy to send emails from a domain, when you add a sender address. Worse, some APIs don't require you to set up sender addresses ahead of time, you can just set it in the "send email" API call, which makes it easy to unknowingly send emails that are blocked by your own policy. DMARC would allow you to find out, but I'm not sure how many people have configured reports, apart from those whose whole business is email.
jeffbee 6y ago
> Maybe the standard should be changed to distrust lack of SPF/DKIM by default? I don't know what standard might be relevant, but the lack of SPF will kill your inbound reputation for gmail. You'll be lucky to even get beyond MAIL.
brightball 6y ago
The challenge there is that SPF/DKIM are a lot harder for bigger companies with thousands of legacy servers that might be sending email. That's specifically why I wish registrars would do this because it's not a big deal for new domains with no existing real mail traffic. DMARC enforcement is getting a lot more recent momentum toward becoming an expectation, it's just a long play. The moment that Google or Microsoft decide to send any mail that doesn't pass DMARC to spam will be the moment where it's a defacto requirement.