8 ms·

Protect domains that do not send email

237 points by zinekeller 5y ago

judge2020 5y ago
Previously (2020): https://news.ycombinator.com/item?id=25210245 https://news.ycombinator.com/item?id=25210245
brightball 5y ago
Yes! I've been begging for this for years. It's IMO the biggest enabler of phishing out there. Every time I give a talk on DMARC, SPF and DKIM people seem generally unaware that any IP address can send email claiming it's from your domain until you have explicitly turned it off. By default all domains should come with a strict reject policy on email until you intentionally turn it on. I usually go through this example with my fictional pirate themed gym, Slimmer Ye Timbers. Go turn off email for all of your currently unused domains. If you don't, odds are high that phish are using them. Just go set an SPF and a DMARC entry. You can look at slimmeryetimbers.com for an example. _dmarc.slimmeryetimbers.com. 5 IN TXT "v=DMARC1; p=reject; aspf=s; adkim=s;" slimmeryetimbers.com. 5 IN TXT "v=spf1 -all" Looks like the article goes even further, but I'm not sure the extra steps they are taking are necessary.
- kmfrk 5y ago
  It sure would be nice if companies like Cloudflare would help offer something to this effect.
  - jabroni_salad 5y ago
    cloudflare has a point & click wizard that does exactly this, and a suggestion to use it at the top of your dns control panel.
    - creeble 5y ago
      Thanks for this!
- AviationAtom 5y ago
  Many folks like to outsource DNS hosting for smaller sites, which doesn't afford logging capabilities. Out of curiosity I chose to self-host DNS on one of my domains. I noticed many queries for MX records, and naturally assumed it was spammers looking for domains to send mail to. Looking at it again, I could see where maybe they were ultimately looking for which domains lack SPF and DKIM, perhaps checking MX first.
- zinekeller 5y ago
  Null MX is for positive signalling: https://www.rfc-editor.org/rfc/rfc7505.txt https://www.rfc-editor.org/rfc/rfc7505.txt For domains previously sending mail but no longer (transitioning to a new domain name), DKIM selector revocation is basically a cleaning-up (hinted at "Revoke all existing DKIM selectors in both TXT and CNAME records."). This prevents abuse at servers who don't understand DMARC but might be fooled by an errant DKIM-signed message (especially old 512-bit keys, I know key rotation but considering this is intended for government consumption there will be old systems still using a 512-bit RSA DKIM keys). This is just brownie points however if the domain never sent a valid mail at all.
  - brightball 5y ago
    That makes sense.
- eslaught 5y ago
  It's great to have the two-liner, but can someone explain what these settings actually mean? Edit: Also, if I have a domain that currently does not send email but may in the future, am I hurting my future self by setting any of these?
  - jabroni_salad 5y ago
    Whether or not DMARC approves a message is based on both/either DKIM and SPF also approving. That string says that both SPF and DKIM must align and to Reject any message that fails either. The SPF record has "-all" which means to fail any message that is not from the designated approved mailserver. Since there isn't one defined, all messages will be failed. Having these will not impact your domain's reputation, but not having them can if you become party to spoofing. The only catch is that it will take as long as your record's TTL to make the domain sendable again, and even longer for some webmail providers who like to hang on to cached records past their expiry. If you are at a larger company you will want to look up the rua/ruf tags and set up an aggregator because one of your other business units will totally try to send a newsletter from the domain and instruct their business partners to manually whitelist it >_>
  - brightball 5y ago
    Sure! First off, no you are not hurting yourself. If anything, you're helping because you're making it harder for your domain to be flagged by spam filters for things you haven't done. Here's a quick explanation of SPF, DKIM and DMARC. SPF - It's a simple record in your DNS that let's you list IP addresses authorized to send email from your domain. 3rd party senders will often ask you to include them in your spf record. With nothing in the record and the "-all" meaning strictly enforced, you've not authorized any senders at all with SPF. DKIM - DKIM has to be setup for every sending mail server with a configuration mapped to a key located in your DNS config. If a receiving mail server gets a message without a DKIM signature, it has no way of knowing it should be there. DMARC - When you enforce a dmarc policy, you tell a server that receives email saying it is from your domain to only accept it if the message passes either an SPF or DKIM check that "aligns" with the domain. It's possible to send a message saying it's from slimmeryetimbers.com with a DKIM check that passes for "myphishdomain.com" and DMARC will not accept it. So has to be from one of your allowed IP addresses in the SPF record or must include a DKIM signature from your specific domain. With SPF essentially empty of options, this will mean that an aligned DKIM signature must present the for it to pass. The dmarc policy is the "p=". A "p=none" is just for show. Doesn't enforce anything. "p=quarantine" asks the receiving mail server to put messages that fail into spam while "p=reject" tells it to not deliver them at all. ------- So summarizing all of that...the SPF record above says that no IP addresses are allowed to send mail on your behalf and the DMARC record tells the receiving mail server not to allow any messages saying they are from your domain unless they pass the SPF check (which they can't, because nothing is allowed) or they pass the DKIM check (which they can't, because you haven't set any up). Hope that helps and I'm happy to clarify anything that needs it.
- ancientsofmumu 5y ago
  Here are 4 tarpit MX services which can complement the solution to absorb spam being directed at/into the no-email domain, depending on needs: # https://wiki.junkemailfilter.com/index.php/Project_Tar tar.junkemailfilter.com ## https://abusix.com/blackhole-mx/ void.blackhole.mx ## https://www.dnswl.org/?page_id=17 mail-in.verboten.net ## https://fakemx.org/ mx.fakemx.net
- justin_oaks 5y ago
  I understand doing this for all of your domains, but what about subdomains? I can understand the value of doing this for subdomains that were used for email in the past, but otherwise I would think setting DMARC and SPF records for every subdomain would be a real pain.
  - brightball 5y ago
    If you set them at the top level, they should carry across the subdomains unless you configure them differently or override them with a subdomain specific record. You may want to verify that directly though. I haven't looked at the subdomain settings in a couple of years.
    - dundarious 5y ago
      What if you do receive email for your domain but never for your subdomains, and therefore have necessary and non-"null" MX, etc., set up on the domain? Is there any point in having "null" records for the subdomains, and if so, is there any non-verbose way to do this? e.g., receiving emails at me@example.com, but never anything @sub1.example.com, @sub2.example.com, etc.
      - zinekeller 5y ago
        Use wildcard reject SPF for nameserver entries, for example: example.net TXT "v=spf1 include:spf.yourmailprovider.example -all" *.example.net TXT "v=spf1 -all" and use strict DMARC policies. Unfortunately due to how DNS was defined, wildcard entries are not used whenever a subdomain is defined - even if its an A entry, so if you use an active subdomain (www is used most of the time) you unfortunately need to add them manually*. Also depending on your specific provider you may not be able to add them (unfortunately that's on them). * Except on, rather surprisingly, Microsoft's DNS servers (you can tick a box to force an wildcard entry to show up even if there are records already defined).
        dundarious 5y ago
AviationAtom 5y ago
Reading DMARC reports it's pretty interesting to see just how often spammers attempt to use others' domains. The forensic reports should show the full contents of what they attempted to send, IIRC.
- benmanns 5y ago
  Doing some reading, it looks like configuring RUA will send an aggregate like you mention, while configuring RUF (F for forensic) will give more granular details.
  - sdflhasjd 5y ago
    ... in theory. In practice, I don't think any major provider actually sends RUF reports.
    - AviationAtom 5y ago
      It would be nice, to see what exactly the people are sending who are trying to impersonate you. Though my hunch is that it's deemed a potential security risk. Instead I rely on bounce messages from invalid addresses spammers are trying to send to, to show me what they were trying to send. It's rarely ever anything too exciting.
  - scblzn 5y ago
    Forensics reports would be nice indeed, but even Google doesn't send them to the RUF address. Never got one report in 4 years of DMARC. Only RUA. Maybe one day..
deleted 5y ago
[deleted]
ChrisArchitect 5y ago
(2021)
Zababa 5y ago
I really like how they do their cookie banner. It's visible, very clear, but not too distracting, and if you just scroll down it disappears.
- hoosieree 5y ago
  I wouldn't say I like it, but I dislike it much less than the typical cookie banner. In a perfect world, there would be no cookies, and no banner.
  - layer8 5y ago
    You mean there would be no tracking, because you don’t need banners for cookies used only for non-tracking purposes.
boomer918 5y ago
Can the registrars do this for me? I have no idea what half of those records do.
- AviationAtom 5y ago
  Generally email providers will provide these for you (i.e. O365, Google Workspace, etc.) If you self-host email then it's really up to you to set them. SPF is super easy, just read some docs on the syntax, then include all valid IPs that might send email on your behalf. DKIM is where it gets a bit tricky, as you need to generate keys and sign all you mail. This is assuming you WANT to send mail from those domains. If you do not wish to, then just follow what they show in this guide, or in one of the comments above.
rafaelturk 5y ago
I'm puzzled that it's not the other way. Domains without MX, SPF, DMARC should not be trusted..
mprovost 5y ago
When I worked as a sysadmin at Warner Bros back around 2001 our corporate mail was name@warnerbros.com which went to an AOL inbox (they made everyone eat the AOL dogfood). We realised that we owned a ton of domains including wb.com that didn't use email, so we set up some MX records and pointed them at a Solaris box running qmail and had our own wb.com addresses. I think I checked my official account maybe a handful of times the entire time I worked there.

237 points by zinekeller 5y ago

judge2020 5y ago

Previously (2020): https://news.ycombinator.com/item?id=25210245 https://news.ycombinator.com/item?id=25210245

Yes! I've been begging for this for years. It's IMO the biggest enabler of phishing out there. Every time I give a talk on DMARC, SPF and DKIM people seem generally unaware that any IP address can send email claiming it's from your domain until you have explicitly turned it off. By default all domains should come with a strict reject policy on email until you intentionally turn it on. I usually go through this example with my fictional pirate themed gym, Slimmer Ye Timbers. Go turn off email for all of your currently unused domains. If you don't, odds are high that phish are using them. Just go set an SPF and a DMARC entry. You can look at slimmeryetimbers.com for an example. _dmarc.slimmeryetimbers.com. 5 IN TXT "v=DMARC1; p=reject; aspf=s; adkim=s;" slimmeryetimbers.com. 5 IN TXT "v=spf1 -all" Looks like the article goes even further, but I'm not sure the extra steps they are taking are necessary.

kmfrk 5y ago
It sure would be nice if companies like Cloudflare would help offer something to this effect.
- jabroni_salad 5y ago
  cloudflare has a point & click wizard that does exactly this, and a suggestion to use it at the top of your dns control panel.
  - creeble 5y ago
    Thanks for this!
AviationAtom 5y ago
Many folks like to outsource DNS hosting for smaller sites, which doesn't afford logging capabilities. Out of curiosity I chose to self-host DNS on one of my domains. I noticed many queries for MX records, and naturally assumed it was spammers looking for domains to send mail to. Looking at it again, I could see where maybe they were ultimately looking for which domains lack SPF and DKIM, perhaps checking MX first.
zinekeller 5y ago
Null MX is for positive signalling: https://www.rfc-editor.org/rfc/rfc7505.txt https://www.rfc-editor.org/rfc/rfc7505.txt For domains previously sending mail but no longer (transitioning to a new domain name), DKIM selector revocation is basically a cleaning-up (hinted at "Revoke all existing DKIM selectors in both TXT and CNAME records."). This prevents abuse at servers who don't understand DMARC but might be fooled by an errant DKIM-signed message (especially old 512-bit keys, I know key rotation but considering this is intended for government consumption there will be old systems still using a 512-bit RSA DKIM keys). This is just brownie points however if the domain never sent a valid mail at all.
- brightball 5y ago
  That makes sense.
eslaught 5y ago
It's great to have the two-liner, but can someone explain what these settings actually mean? Edit: Also, if I have a domain that currently does not send email but may in the future, am I hurting my future self by setting any of these?
- jabroni_salad 5y ago
  Whether or not DMARC approves a message is based on both/either DKIM and SPF also approving. That string says that both SPF and DKIM must align and to Reject any message that fails either. The SPF record has "-all" which means to fail any message that is not from the designated approved mailserver. Since there isn't one defined, all messages will be failed. Having these will not impact your domain's reputation, but not having them can if you become party to spoofing. The only catch is that it will take as long as your record's TTL to make the domain sendable again, and even longer for some webmail providers who like to hang on to cached records past their expiry. If you are at a larger company you will want to look up the rua/ruf tags and set up an aggregator because one of your other business units will totally try to send a newsletter from the domain and instruct their business partners to manually whitelist it >_>
- brightball 5y ago
  Sure! First off, no you are not hurting yourself. If anything, you're helping because you're making it harder for your domain to be flagged by spam filters for things you haven't done. Here's a quick explanation of SPF, DKIM and DMARC. SPF - It's a simple record in your DNS that let's you list IP addresses authorized to send email from your domain. 3rd party senders will often ask you to include them in your spf record. With nothing in the record and the "-all" meaning strictly enforced, you've not authorized any senders at all with SPF. DKIM - DKIM has to be setup for every sending mail server with a configuration mapped to a key located in your DNS config. If a receiving mail server gets a message without a DKIM signature, it has no way of knowing it should be there. DMARC - When you enforce a dmarc policy, you tell a server that receives email saying it is from your domain to only accept it if the message passes either an SPF or DKIM check that "aligns" with the domain. It's possible to send a message saying it's from slimmeryetimbers.com with a DKIM check that passes for "myphishdomain.com" and DMARC will not accept it. So has to be from one of your allowed IP addresses in the SPF record or must include a DKIM signature from your specific domain. With SPF essentially empty of options, this will mean that an aligned DKIM signature must present the for it to pass. The dmarc policy is the "p=". A "p=none" is just for show. Doesn't enforce anything. "p=quarantine" asks the receiving mail server to put messages that fail into spam while "p=reject" tells it to not deliver them at all. ------- So summarizing all of that...the SPF record above says that no IP addresses are allowed to send mail on your behalf and the DMARC record tells the receiving mail server not to allow any messages saying they are from your domain unless they pass the SPF check (which they can't, because nothing is allowed) or they pass the DKIM check (which they can't, because you haven't set any up). Hope that helps and I'm happy to clarify anything that needs it.
ancientsofmumu 5y ago
Here are 4 tarpit MX services which can complement the solution to absorb spam being directed at/into the no-email domain, depending on needs: # https://wiki.junkemailfilter.com/index.php/Project_Tar tar.junkemailfilter.com ## https://abusix.com/blackhole-mx/ void.blackhole.mx ## https://www.dnswl.org/?page_id=17 mail-in.verboten.net ## https://fakemx.org/ mx.fakemx.net
justin_oaks 5y ago
I understand doing this for all of your domains, but what about subdomains? I can understand the value of doing this for subdomains that were used for email in the past, but otherwise I would think setting DMARC and SPF records for every subdomain would be a real pain.
- brightball 5y ago
  If you set them at the top level, they should carry across the subdomains unless you configure them differently or override them with a subdomain specific record. You may want to verify that directly though. I haven't looked at the subdomain settings in a couple of years.
  - dundarious 5y ago
    What if you do receive email for your domain but never for your subdomains, and therefore have necessary and non-"null" MX, etc., set up on the domain? Is there any point in having "null" records for the subdomains, and if so, is there any non-verbose way to do this? e.g., receiving emails at me@example.com, but never anything @sub1.example.com, @sub2.example.com, etc.
    - zinekeller 5y ago
      Use wildcard reject SPF for nameserver entries, for example: example.net TXT "v=spf1 include:spf.yourmailprovider.example -all" *.example.net TXT "v=spf1 -all" and use strict DMARC policies. Unfortunately due to how DNS was defined, wildcard entries are not used whenever a subdomain is defined - even if its an A entry, so if you use an active subdomain (www is used most of the time) you unfortunately need to add them manually*. Also depending on your specific provider you may not be able to add them (unfortunately that's on them). * Except on, rather surprisingly, Microsoft's DNS servers (you can tick a box to force an wildcard entry to show up even if there are records already defined).
      - dundarious 5y ago

AviationAtom 5y ago

Reading DMARC reports it's pretty interesting to see just how often spammers attempt to use others' domains. The forensic reports should show the full contents of what they attempted to send, IIRC.

benmanns 5y ago
Doing some reading, it looks like configuring RUA will send an aggregate like you mention, while configuring RUF (F for forensic) will give more granular details.
- sdflhasjd 5y ago
  ... in theory. In practice, I don't think any major provider actually sends RUF reports.
  - AviationAtom 5y ago
    It would be nice, to see what exactly the people are sending who are trying to impersonate you. Though my hunch is that it's deemed a potential security risk. Instead I rely on bounce messages from invalid addresses spammers are trying to send to, to show me what they were trying to send. It's rarely ever anything too exciting.
- scblzn 5y ago
  Forensics reports would be nice indeed, but even Google doesn't send them to the RUF address. Never got one report in 4 years of DMARC. Only RUA. Maybe one day..

deleted 5y ago

[deleted]

ChrisArchitect 5y ago

(2021)

Zababa 5y ago

I really like how they do their cookie banner. It's visible, very clear, but not too distracting, and if you just scroll down it disappears.

hoosieree 5y ago
I wouldn't say I like it, but I dislike it much less than the typical cookie banner. In a perfect world, there would be no cookies, and no banner.
- layer8 5y ago
  You mean there would be no tracking, because you don’t need banners for cookies used only for non-tracking purposes.

boomer918 5y ago

Can the registrars do this for me? I have no idea what half of those records do.

AviationAtom 5y ago
Generally email providers will provide these for you (i.e. O365, Google Workspace, etc.) If you self-host email then it's really up to you to set them. SPF is super easy, just read some docs on the syntax, then include all valid IPs that might send email on your behalf. DKIM is where it gets a bit tricky, as you need to generate keys and sign all you mail. This is assuming you WANT to send mail from those domains. If you do not wish to, then just follow what they show in this guide, or in one of the comments above.

rafaelturk 5y ago

I'm puzzled that it's not the other way. Domains without MX, SPF, DMARC should not be trusted..

mprovost 5y ago

When I worked as a sysadmin at Warner Bros back around 2001 our corporate mail was name@warnerbros.com which went to an AOL inbox (they made everyone eat the AOL dogfood). We realised that we owned a ton of domains including wb.com that didn't use email, so we set up some MX records and pointed them at a Solaris box running qmail and had our own wb.com addresses. I think I checked my official account maybe a handful of times the entire time I worked there.