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?

  • 3
    Do you have any sort of spam filtering solution in place right now?
    – ewwhite
    Commented Jul 5, 2016 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 "[email protected]". 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). Commented Jul 6, 2016 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
    Commented Jul 6, 2016 at 19:59
  • @Matt gotya, brainfart Commented Jul 6, 2016 at 20:18
  • 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
    Commented Jul 8, 2016 at 2:15

8 Answers 8


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

  • 3
    @Kurtovic a well configured email server should bounce the email it rejects, so the sender would be notified.
    – Calimo
    Commented Jul 6, 2016 at 8: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. Commented Jul 6, 2016 at 8: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
    Commented Jul 6, 2016 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. Commented Jul 7, 2016 at 3: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
    Commented Jul 7, 2016 at 3:20

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.

  • 4
    It's highly recommended to implement SPF as well as DKIM before testing DMARC. Commented Jul 6, 2016 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
    Commented Jul 8, 2016 at 0: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. Commented Jul 8, 2016 at 0: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
    Commented Jul 13, 2016 at 5:33

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.

  • "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
    Commented Jul 12, 2016 at 0:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .