Protect domains that do not send email | Hacker News Reader

Protect domains that do not send email

gov.uk

237 pointszinekeller34 comments

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.

It sure would be nice if companies like Cloudflare would help offer something to this effect.

cloudflare has a point & click wizard that does exactly this, and a suggestion to use it at the top of your dns control panel.

Thanks for this!

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.

Null MX is for positive signalling: 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.

That makes sense.

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?

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 >_>

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.

Thank you for this answer!

A few more questions:

1. Would there be any issues receiving emails with these policies set?

2. Quoting OP's edit:

> 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?

None. SPF, DKIM and DMARC only affect outgoing mail.

Incoming mail is handled entirely by your mail server which is pointed to by your MX record.

This is actually where a lot of the confusion comes from. When you buy a domain, it doesn't go anywhere until you point it to specific web servers by adding A or CNAME records in your DNS. Same thing with your incoming email, nobody knows where to send a message until you setup your MX records. You can setup a web server that will serve any domain you want, but until the DNS points to it there's not an easy way for people to find it.

Outgoing mail had no such check though. Any server could send a message claiming it was from your domain unless you took the time to specify where your mail is coming from.

And no, this won't hurt you at all. All it does is tell the receiving mail servers that for an email from the domain to be valid, it must pass a DMARC check. If you subsequently setup something like Google for your domain's email, you'd just update the record by following the instructions Google will give you. For example:

"v=spf1 include:_spf.google.com ~all"

This let's Google manage the set of IP addresses. Google will likely also give you instructions to setup DKIM by adding a couple of additional records. This will ensure anything sent by Google for you domain will pass both SPF and DKIM, allowing it to be properly validated and delivered.

You'll notice that "~all" instead of "-all" as well. When you're actually sending email from the domain, it's best to use "~all" instead of "-all". The "-all" can sometimes be over zealously strict and by using "~all" instead it will be enforced but let you defer to the DMARC policy for the enforcement of failures (such as forwarding or list serves that DKIM would still survive but SPF wouldn't).

> nobody knows where to send a message until you setup your MX records

Not quite. RFC 974 says It is possible that the list of MXs in the response to the query will be empty. This is a special case. If the list is empty, mailers should treat it as if it contained one RR, an MX RR with a preference value of 0, and a host name of REMOTE. (I.e., REMOTE is its only MX). In addition, the mailer should do no further processing on the list, but should attempt to deliver the message to REMOTE.

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

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.

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.

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.

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).

Thanks, I do have several subdomain A records, but not a ton. I should get around to explicitly adding at least the SPF rejects for them.

I do hope that an SPF2 will allow defining subdomains. Until then, this is the best defence.

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.

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

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

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.

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.

... in theory. In practice, I don't think any major provider actually sends RUF reports.

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.

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..

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.

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.

You mean there would be no tracking, because you don’t need banners for cookies used only for non-tracking purposes.

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

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.

(2021)

Reply on news.ycombinator.com