33

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 fake@example.com?

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?

techraf
  • 4,163
  • 8
  • 27
  • 44
Steffen Maier
  • 527
  • 4
  • 7
  • 3
    Do you have any sort of spam filtering solution in place right now? – ewwhite Jul 05 '16 at 22:23
  • 14
    You should double-check that you don't have any vendors of any web applications trying to send from your own domain. Like if you have a payroll system that might send e-mails to your staff from "payroll@example.com". Also check whether marketing or HR might use an external bulk mail service and they want staff to get those messages. Usually those messages have a sender or at least reply-to address of someone in marketing or HR. In those situations, you will usually be able to put the service's e-mail servers on an allow list and still block your own domain incoming (that's what we do). – Todd Wilcox Jul 06 '16 at 15:33
  • 6
    @NeilMcGuigan What would that matter? The mail should still originate from an internal mail server? It would not come from outside the network just because he is not physically present. – Matt Jul 06 '16 at 19:59
  • @Matt gotya, brainfart – Neil McGuigan Jul 06 '16 at 20:18
  • Our company does that (since years), and it works so far. However, there _are_ issues, but mostly non-business-related: for example, our bowling league has over 40 members from the office, and most of them use their company email. Now if I mail to members@ourleague.com, the external list server we use forwards this email to all 40 people, and 38 of them _bounce_. Makes things very awkward to use. – Aganju Jul 08 '16 at 00:58
  • 1
    If you have automated email notifications coming from one of your servers, for example, failed cron jobs notifications, or attempted breach from IDS, or resource usage monitor, and they're configured so their From address is with your domain name. You'll need to take care to either route those emails through your internal mailserver, or to whitelist those servers as permitted senders. – Lie Ryan Jul 08 '16 at 02:15

8 Answers8

53

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

DKing
  • 796
  • 4
  • 13
  • Would it be wise to autoreply to blocked E-Mails? If for example some client sent something to an internal mail by accident (lets say copied the internal only e-mail address from a CC field of some conversation with multiple people). – WalyKu Jul 06 '16 at 07:49
  • 3
    @Kurtovic a well configured email server should bounce the email it rejects, so the sender would be notified. – Calimo Jul 06 '16 at 08:14
  • 9
    @Calimo Not when it rejects email for being spam. Doing so would just enable the spammer to keep trying until he has learnt what your algorithm allows and doesn't allow. – Jon Bentley Jul 06 '16 at 08:30
  • 29
    @Calimo - no. accept-and-bounce is the worst possible thing to do, you're contributing to back-scatter spam and WILL get blacklisted very quickly. just reject the unwanted mail - dealing with that is the **sending** host's problem. If you can't do that then accept, check, and discard if spam or malware. never accept and bounce. – cas Jul 06 '16 at 10:40
  • 2
    @cas: There's a third alternative: reject at SMTP acceptance time. This leaves the burden of producing an error response on the sending SMTP server, if it wants to do so, and thereby allows many legitimate senders to see if their mail was rejected while guaranteeing that you will never produce spam yourself. – R.. GitHub STOP HELPING ICE Jul 07 '16 at 03:18
  • 2
    @R.. i think you'll find that's not a third alternative, it's a paraphrase of what i said "just reject the unwanted mail - dealing with that is the sending host's problem." – cas Jul 07 '16 at 03:20
  • 1
    Ah okay. Sorry I missed that. By the way a nasty alternative I like is producing a 450 instead of a 550 for spam so that you waste their resources retrying it. – R.. GitHub STOP HELPING ICE Jul 07 '16 at 03:21
  • 1
    I have a secondary MX (an alternate cfg on my primary postfix host) just to give out 450 to everything. spammers often target secondary MXes (they're often misconfigured with weaker anti-spam rules and without a complete list of valid recipients for the domains they handle), legit senders only use secondaries when they can't reach the primary MX...and with my config that should never happen (and wouldn't cause any harm if it did, eventually they'll try delivering to the primary). see http://serverfault.com/questions/47312/mx-backup-service/47325#47325 – cas Jul 07 '16 at 03:24
  • @Kurtovic a client won't be sending emails FROM a company's email address without being logged in to their email server. – Davidmh Jul 07 '16 at 11:23
  • @Davidmh spoofing a company's domain is trivially simple. – FuriousFolder Jul 07 '16 at 21:05
32

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.

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
  • 4
    It's highly recommended to implement SPF as well as DKIM before testing DMARC. – Todd Wilcox Jul 06 '16 at 15:30
  • How can DMARC work with emails come from a different server than your own, such as with external services, since those would not be signed by your server? – jpaugh Jul 08 '16 at 00:17
  • 1
    @jpaugh you add the other servers public key to your DMARC records in your DNS. They will be able to give you the record to add. – Mark Henderson Jul 08 '16 at 00:32
  • I've +1'd this answer because it's technically correct - that is exactly what DMARC is for, and what it does - but DMARC is a very bad idea if you want to interoperate with things like mailing lists, since it violates RFCs and generally misbehaves. – MadHatter Jul 13 '16 at 05:33
11

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.

Peter Green
  • 4,056
  • 10
  • 29
3

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 "mycompany.sales@gmail.com" forwards to "sales@mycompany.com", and your user "bob@mycompany.com" sends to "mycompany.sales@gmail.com". 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 "foo-list@lists.apple.com" and sends a message, he will receive an inbound message looking something like: From: bob@mycompany.com To: foo-list@lists.apple.com 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.

David Gelhar
  • 251
  • 1
  • 2
2

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.

Neil
  • 248
  • 3
  • 11
1

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.

Jesse Hernandez
  • 21
  • 1
1

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.

Christian
  • 123
  • 4
-1

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.

Jim
  • 1
  • _"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"_ - that's exactly what you do with SPF, create a list of legitimate originating email servers for your domain. – GAThrawn Jul 12 '16 at 00:42