I have a question about our Exchange Server: Do you think it is a good idea to refuse incoming external e-mails that have our own domain in the ending?
Like external eMail from [email protected]?
Because if it would be from a real sender in our company, the email would never come from outside?
If yes, what's the best way of doing this?
Yes, if you know that email for your domain should only be coming from your own server, then you should block any email for that domain originating from a different server. Even if the sender's email client is on another host, they should be logging into your server (or whatever email server you use) to send email.
Taking that a step further, you could configure your server to check SPF records. This is how many hosts prevent that sort of email activity. SPF records are a DNS record, a TXT record, which gives rules about which servers are allowed to send email for your domain. How to enable SPF record checking would depend on your email service, and would be beyond the scope of what to cover here. Fortunately, most hosting environments and software will have documentation for working with SPF records. You might want to learn more about SPF in general. Here's the Wikipedia article: https://en.wikipedia.org/wiki/Sender_Policy_Framework
There is a standard for doing this already. It's called DMARC. You implement it with DKIM signing (which is a good idea to implement anyway).
The high level overview is you sign every single email that leaves your domain with a DKIM header (which is good practice anyway). Then you configure DMARC to reject every email that hits your mail server, from a domain you own, that is not signed with a valid DKIM header.
This means you can still have external services deliver email to your domain (like hosted helpdesk software, etc), but can block spear phishing attempts.
The other great thing about DMARC is that you get failure reports delivered, so you can manage exception handling as required.
The down side is that you need to be sure you've got everything sorted out thoroughly beforehand or you might start dropping legitimate emails.
Such a block is likely to reduce spam and possiblly make social engineering harder but it may also block legitimate mail. Examples include mail forwarding services, mailing lists, users with misconfigured mail clients, webapps that send mail direct from the webhost without involving your main mailserver and so-on.
Dkim can mitigate this to some extent by providing a way to identify a message that was sent from your network, looped through a mailing list or forwarder and was then received at your mail but it's not a perfect cure, some mailing lists will break dkim signatures and you still have the problem of tracking down all legitimate mail origination points and making sure they go through a dkim signer.
Tread carefully, especially if implementing this on an existing domain.
Maybe, but there are some cases you need to consider before you make such a change.
1) Does anybody in your company use any kind of external service (for example Survey Monkey, Constant Contact, etc.) to send out emails that appear to be "from" your domain? Even if they aren't doing it today, might they do it in the future?
2) Are there any an outside addresses that forward to your users? For example, assume the gmail account "[email protected]" forwards to "[email protected]", and your user "[email protected]" sends to "[email protected]". In that case, the message will arrive from "outside", but with a "@mycompany.com" From: address.
3) Are any of your users subscribed to external distribution lists that preserve the original "From:" address on messages to the list? For example, if Bob subscribes to "[email protected]" and sends a message, he will receive an inbound message looking something like: From: [email protected] To: [email protected] Sender:
If your server naively looks at the "From:" header (instead of "Sender:"), it might reject this message because you are receiving it from outside.
Because of all of the above, having a blanket policy of "...from a real sender in our company, the email would never come from outside" is not always feasible.
You can do this in PowerShell by updating your Receive Connector permissions to exclude Anonymous users from sending as an authoritative domain sender:
Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender
However the problem arises when you have remote application servers that need to send status emails to you, as these generally use your domain name in their From address. It's possible to create an additional Receive Connector for their specific IP addresses so that you don't inadvertently exclude them.
GMail has a setting where it allows you to send emails with a non-GMail domain provided the email address get's first verified. Your decision would block those emails.
Whether or not you have users who might use this GMail feature and whether it makes sense to cater to them depends very much on the behavior within your company.
I highly suggest you implement DMARC for your domain. DMARC will help you to protect your brand and prevent spoofing or phishing attacks from occurring on your domain. In order to use DMARC you must also setup SPF and DKIM for your domain.
Another benefit of implementing DMARC is that you can use a new layer of email authentication called BIMI. BIMI is an additional layer of email authentication that displays your logo in your client’s mailboxes. BIMI allows your email to stand out from the rest.
If you wanted to learn more about DMARC Reporting and how to set it up we just finished The Ultimate Guide to DMARC Reporting in 2022.
Also, you can use our DMARC Analyzer to monitor and review 10,000 messages monthly at no cost.
SPF wont cure this as the envelope could well have a proper SPF pass (i.e. spammers using compromised server) whilst they will forge the email inside the envelope. What you need is a block on your own domain email message that has an originating email server on the envelope not acceptable to you.
