Good idea? Refuse incoming emails with our own domain ending? (because they must be fake)

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.