Protect domains that don’t send email(gov.uk)
gov.uk
Protect domains that don’t send email
https://www.gov.uk/guidance/protect-domains-that-dont-send-email
46 comments
Head slapping moment for me too. Without a DMARC record I would never even know that it's happening.
I wonder if the systems that generate the DMARC reports could be set up to keep historical data for domains with DMARC shut off. When DMARC is turned on, domain owners would be able to see what has been going on without them knowing.
It might be a bit of a shock to some. I learned a lot from my first report.
I wonder if the systems that generate the DMARC reports could be set up to keep historical data for domains with DMARC shut off. When DMARC is turned on, domain owners would be able to see what has been going on without them knowing.
It might be a bit of a shock to some. I learned a lot from my first report.
Nope, you're totally correct. Anytime I give a DMARC talk this is actually the example that I use (all the domains that you buy and don't use). At the end, I close by telling people to go home and turn off email from those domains with the sample SPF and DMARC records that mirror these.
Do you happen to know of a tool that does a comprehensive check of your email configuration? I can find individual tools for SPF, DKIM, etc., but it’d be great if there were one that just have me a big green check mark or something.
DMARC reports actually do this for you. They'll provide a report about how every IP address claiming to send on behalf of your domain is doing.
dmarcian does a great job of helping you make sense of these by grouping all of the traffic by sending source and then letting you drill down for more details. There's also a cool "TMI Mode" on the SPF checker if you have an account that will use the traffic from your DMARC reports to show you which parts of the record it's associated with.
Each sending source (Google, Sendgrid, Mailgun, Mailchimp, etc) needs to be verified for DMARC alignment. Alignment is important because you can pass DKIM using a domain that's totally different than the one that the message claims to be from. DMARC alignment addresses that gap.
* Disclosure, I work for dmarcian
dmarcian does a great job of helping you make sense of these by grouping all of the traffic by sending source and then letting you drill down for more details. There's also a cool "TMI Mode" on the SPF checker if you have an account that will use the traffic from your DMARC reports to show you which parts of the record it's associated with.
Each sending source (Google, Sendgrid, Mailgun, Mailchimp, etc) needs to be verified for DMARC alignment. Alignment is important because you can pass DKIM using a domain that's totally different than the one that the message claims to be from. DMARC alignment addresses that gap.
* Disclosure, I work for dmarcian
Edit: Below brightball pointed out they support inactive domains, so my complaint about not being able to add inactive domains wasn't accurate. I deleted it.
For what it’s worth, dmarcian has allowed inactive domains free for many years. I’m sorry if that wasn’t clear from the pricing description.
We’d love to have you try us out again.
We’d love to have you try us out again.
No. It's fairly clear. I just didn't read past the "2 active domains" part of the pricing. I'll edit my post and I will actually give it another try.
I would say it's also important to receive mail on RFC2142 [1] addresses as well. I usually set up abuse@, hostmaster@, postmaster@, and webmaster@ for idle domains.
1. https://tools.ietf.org/html/rfc2142
1. https://tools.ietf.org/html/rfc2142
That RFC by definition doesn't apply to domains that don't support email. Right in the abstract is this line:
> ...organizations which support email exchanges with the Internet are encouraged to support AT LEAST each mailbox name
These recommendations are all for domains that don't run mail servers. If you do have a mail server, then yeah it is best practice to have those present but these recommendations won't apply to you.
> ...organizations which support email exchanges with the Internet are encouraged to support AT LEAST each mailbox name
These recommendations are all for domains that don't run mail servers. If you do have a mail server, then yeah it is best practice to have those present but these recommendations won't apply to you.
In 30+ years I have only received spam on any of those addresses. I suppose that means that "abuse" is appropriately named :-/
A couple of years ago I pointed them at /dev/null. I considered rejecting them but that would not be compliant.
A couple of years ago I pointed them at /dev/null. I considered rejecting them but that would not be compliant.
I'm not sure I see the benefit in following the letter of the RFC but not the intent
In this case there actually is a benefit.
I've seen issues where people weren't able to communicate with customers because someone's running a mail server that rejects email based on the RFC-Clueless RBL or its predecessor, RFC-Ignorant[0].
I've never in history seen postmaster@domain every receive anything but spam, and I have seen it receive so much spam that I would never identify a legitimate email amongst the screens full of junk if one ever did arrive.
[0] http://rfc-clueless.org/pages/faq
I've seen issues where people weren't able to communicate with customers because someone's running a mail server that rejects email based on the RFC-Clueless RBL or its predecessor, RFC-Ignorant[0].
I've never in history seen postmaster@domain every receive anything but spam, and I have seen it receive so much spam that I would never identify a legitimate email amongst the screens full of junk if one ever did arrive.
[0] http://rfc-clueless.org/pages/faq
In this case you’re right. I really doubt someone is probing the RCPT TO response to decide if a server is legit or not!
Certainly there are protocols where you might be required to accept an option or configuration value you can’t implement and so simply discard it. Perhaps some QoS request for example. Or termcap info for cursor movement when all you do is act like you’re talking to a printing terminal.
Certainly there are protocols where you might be required to accept an option or configuration value you can’t implement and so simply discard it. Perhaps some QoS request for example. Or termcap info for cursor movement when all you do is act like you’re talking to a printing terminal.
[deleted]
I've added a new "no email domain protection" ready-to-import DNS zone file that's in BIND format specially for Cloudflare users. You can download it from here and save time [1].
P.S. There are also files for other services too, feel free to checkout. Some CF employees are also among stargazers, feel free to star if you like it too :)
1: https://github.com/irazasyed/dns-zone-files/blob/master/file...
P.S. There are also files for other services too, feel free to checkout. Some CF employees are also among stargazers, feel free to star if you like it too :)
1: https://github.com/irazasyed/dns-zone-files/blob/master/file...
What about protecting domains that do send emails?
I'm trying to understand how to implement DMARC SPF and DKIM myself but all I can find online is content marketing from SaaS services.
I only did find this on how to add DMARC SPF and DKIM to AWS SES: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-e...
I'm trying to understand how to implement DMARC SPF and DKIM myself but all I can find online is content marketing from SaaS services.
I only did find this on how to add DMARC SPF and DKIM to AWS SES: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-e...
Here's a great writeup by an OpenSMTPD developer: https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-...
Good recommendation, I wish more domain owners followed them, but Unicode quotes in examples for DNS TXT record is bad:
TXT “v=spf1 -all”
should be
TXT "v=spf1 -all"
instead.
I see a lot of broken SPF records where instead if ASCII hyphen (-) some other symbol is used e. g. en-dash (–) or em-dash (—). Probably admins just copy-paste an examples from a web pages like this.
I see a lot of broken SPF records where instead if ASCII hyphen (-) some other symbol is used e. g. en-dash (–) or em-dash (—). Probably admins just copy-paste an examples from a web pages like this.
The UK advice on securing your email is really good.
However, I wish they went further to have none of this vague GCHQ cyber security nonsense but laws with teeth and a clued up police force so that the UK was a very attractive place to do business. If the UK was the best place to host your stuff because hackers got themselves prosecuted instead of let off then this would be a good thing.
This could also cut both ways so that if you didn't have things like DMARC for email then they would close you down.
I know this would not be for everyone but you could always host elsewhere. The internet could go the way of shipping where a 'Liberia' domain meant you didn't care whereas a '.co.uk' flag on the internet 'seas' meant you were afforded the protection of the 'Royal cyber force'.
However, I wish they went further to have none of this vague GCHQ cyber security nonsense but laws with teeth and a clued up police force so that the UK was a very attractive place to do business. If the UK was the best place to host your stuff because hackers got themselves prosecuted instead of let off then this would be a good thing.
This could also cut both ways so that if you didn't have things like DMARC for email then they would close you down.
I know this would not be for everyone but you could always host elsewhere. The internet could go the way of shipping where a 'Liberia' domain meant you didn't care whereas a '.co.uk' flag on the internet 'seas' meant you were afforded the protection of the 'Royal cyber force'.
Why an explicit null MX record? Mainly because email servers may keep trying thinking it's a temporary issue rather than an explicit configuration the domain does not receive email.
Some additional helpful info in this answer: https://serverfault.com/a/714070/53160
Some additional helpful info in this answer: https://serverfault.com/a/714070/53160
Seems reasonable. Am I missing some angle here?
This is excellent advice. I wish more people were aware of this need.
Registrars _should_ be doing this by default IMO.
Registrars _should_ be doing this by default IMO.
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.
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.
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.
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.
> 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.
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.
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.
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.
Shoutout to dmarcian.com.
I don't work for them and am actually a new customer, but getting your domain safe from a DMARC perspective SOUNDS easy until you realize you do want SOME people "spoofing your emails". Mailgun, SendGrid, Greenhouse, Shopify, Google Calendar, etc.
We live in a world where our companies outsource a lot of the logic and many send emails on our behalf so to discern between that and "spoofing" takes some config that DMARCian was super helpful with.
I'm just a happy customer and wanted to share!
I don't work for them and am actually a new customer, but getting your domain safe from a DMARC perspective SOUNDS easy until you realize you do want SOME people "spoofing your emails". Mailgun, SendGrid, Greenhouse, Shopify, Google Calendar, etc.
We live in a world where our companies outsource a lot of the logic and many send emails on our behalf so to discern between that and "spoofing" takes some config that DMARCian was super helpful with.
I'm just a happy customer and wanted to share!
I've been really happy with MXToolbox's service https://mxtoolbox.com/c/products/deliverycenter
I also tried the Mimecast one but it was no better than MXToolbox and significantly more expensive.
I also tried the Mimecast one but it was no better than MXToolbox and significantly more expensive.
Thanks! I work for dmarcian. Great company!
The real trick would be if intermediary MTA servers could make the assumption that any domain without SPF/DKIM/etc. has the same intent ("I'm not supposed to be used for sending email") as a domain that explicitly has these "no-email" records. We could eliminate a huge swathe of spam senders from the web in a single stroke. (Right now we already apply this heuristic, but the output is just a signal for spam classifiers at the receiver, rather than a "drop the mail on the floor" signal at intermediates, the way that e.g. DNSRBLs are.)
If we did make this "you don't intend to send email if you don't have the secure-origin records" assumption, how much would that break email as a system? What old email servers are sitting around sending unsigned mail, that we want to protect/preserve the functioning of (in the same way we keep Internet-realm HTTP transport around in browsers to preserve access to old HTTP-only Web1.0 servers?)
If we did make this "you don't intend to send email if you don't have the secure-origin records" assumption, how much would that break email as a system? What old email servers are sitting around sending unsigned mail, that we want to protect/preserve the functioning of (in the same way we keep Internet-realm HTTP transport around in browsers to preserve access to old HTTP-only Web1.0 servers?)
Your solution would work well if everyone (or nearly all people) agreed to migrate to it.
It may need to be in a few steps. The first step might be, for a 5 year period, mail clients display a warning saying the sending domain doesn't have the correct SPF records. Then after that, those mail clients dropped those emails.
Overall, the cleverness of the OP solution is that it uses to current system to make the next iterative step in solving the problem in a backwards compatible way.
If we could break backwards compatibility, I think we can solve a large number of issues with email wholesale.
It may need to be in a few steps. The first step might be, for a 5 year period, mail clients display a warning saying the sending domain doesn't have the correct SPF records. Then after that, those mail clients dropped those emails.
Overall, the cleverness of the OP solution is that it uses to current system to make the next iterative step in solving the problem in a backwards compatible way.
If we could break backwards compatibility, I think we can solve a large number of issues with email wholesale.
It would be easier to add something like a `forbid` policy to DMARC IMO, since you'd want to set up DMARC to monitor spoof attempts anyway. A simple `p=forbid,sp=forbid` (not real options) in DMARC would be ideal.
forbid - all mail is forbidden regardless of DMARC alignment
forbid - all mail is forbidden regardless of DMARC alignment
There are many servers still not using DKIM, as it requires a server/software update. But SPF is super easy, requiring only DNS changes. Could probably do as you suggest looking at only SPF.
This is good advise. As an aside, I run an ESP and we've seen a marked increase in the number of domains using a DMARC policy. Our users have to set up soms DNS records to add our service as an approved sender.
This is quite clever. All of the things listed are problems we in the hosting industry usually have to fix for people when there are email delivery issues.
Breaking them intentionally will definitely cause mail delivery problems for anyone trying to spoof emails coming from those domains.
Breaking them intentionally will definitely cause mail delivery problems for anyone trying to spoof emails coming from those domains.
Why create a dummy wildcard DKIM record with an invalid/empty public key? Is this in some way different to an absent record?
EDIT: My reading of the RFC is that an absent DKIM record is a PERMFAIL [1], exactly the same result as a record with an empty p=. Exact quote:
"There is no defined semantic difference between a key that has been revoked and a key record that has been removed."
[1] https://www.ietf.org/rfc/rfc6376.txt, section 6.1.2
EDIT: My reading of the RFC is that an absent DKIM record is a PERMFAIL [1], exactly the same result as a record with an empty p=. Exact quote:
"There is no defined semantic difference between a key that has been revoked and a key record that has been removed."
[1] https://www.ietf.org/rfc/rfc6376.txt, section 6.1.2
The reality is that an absent DKIM TXT record does not really tell whether the server-in-question is a legacy mail server or a new domain without mail servers (and you cannot do this with WHOIS filtering because some ccTLDs does not store when the domain was first acquired, only when it was last renewed). At least if you are putting a blank key, it will signal to supported mail servers that it is a positive fail, and not a possible legacy mail system.
A domain with a DMARC record specifying a strict DKIM checking policy and an absent DKIM record can't realistically be considered a legacy domain.
But DKIM has already existed since around 2004, but the first draft of DMARC was seven years after that. In other words, the empty DKIM is for backward compatibilty that signals to other servers which does not yet read DMARC but already does DKIM verification that this domain does not send emails.
If the message isn't signed, the receiver won't do a DKIM lookup. If the message is signed, whether the record is absent or empty doesn't matter, validation will fail.
Anyone know what the story is about Vodafone seemingly controlling the zone files for various gov.uk subdomains (mentioned at the end of the article)? I'm surprised a government agency doesn't have direct responsibility for something like that.
I assume its a holdover from the Government Secure Intranet that was designed in the 1990s by Cable and Wireless, one of the UK's main telecoms infrastructure companies at the time and which was only privatised in the 80s. C&W was taken over by Vodafone.
https://en.m.wikipedia.org/wiki/Government_Secure_Intranet
https://en.m.wikipedia.org/wiki/Government_Secure_Intranet
Thanks! This is the sort of interesting factoid I was hoping for :-)
I generally try to make sure they all redirect back to my site, but I’ve never even thought to do anything with incoming mail and certainly never with outgoing. As soon as I read the title it clicked, it’s obvious, but it’s never occurred to me...