Link to home
Start Free TrialLog in
Avatar of Scott Townsend
Scott TownsendFlag for United States of America

asked on

Blocking SPAM that comes from yourself? SFP is setup, but getting through.

System/Setup:
Exchange 2010 Hybrid with Office 365 Tenant.
Multiple Domains. Some Go Directly to Office 365 Tenant, some go to the On-Premise First, then either Stay on the On-Prem, or get Transferred to the Office 365 Tenant.
I'm trying to Block some SPAM that the user is forging our Email Addresses.   I Have SPF Records setup and have tested them and they seem to be functioning fine.   Though we are still getting emails from us to us though they are not coming from us.

The From: Header has my email address in it, so it looks like it came from me, though the sender used the Following Headers, which I think caused the SoftFail on the SPF and managed to get the email through.
X-Sender: jarch@chol.com
X-Complaints-To: <abuse@mailer.chol.com>
Errors-To: noreply@chol.com
Return-Path: jarch@chol.com


I've just started to look into DKIM/DMARC though still learning what it is all about. I'm not sure if this would prevent the email from reaching us.   Would it? Is there something else I can do?

Here is a copy of one of the emails with Most all of the Headers. My IPs/Names/Emails have been edited. I've removed all of the X-Microsoft-Exchange-Diagnostics: Headers.

Received: from BYAPR15MB2310.namprd15.prod.outlook.com (2603:10b6:a02:bc::33)
 by BYAPR15MB2312.namprd15.prod.outlook.com with HTTPS via
 BYAPR07CA0020.NAMPRD07.PROD.OUTLOOK.COM; Tue, 5 Feb 2019 20:33:15 +0000
Received: from CY4PR15CA0015.namprd15.prod.outlook.com (2603:10b6:910:14::25)
 by BYAPR15MB2310.namprd15.prod.outlook.com (2603:10b6:a02:8b::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Tue, 5 Feb
 2019 20:33:14 +0000
Received: from BN3NAM04FT057.eop-NAM04.prod.protection.outlook.com
 (2a01:111:f400:7e4e::205) by CY4PR15CA0015.outlook.office365.com
 (2603:10b6:910:14::25) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22 via Frontend
 Transport; Tue, 5 Feb 2019 20:33:13 +0000
Authentication-Results: spf=softfail (sender IP is <MailServerIP>)
 smtp.mailfrom=chol.com; <tenantDomain>.mail.onmicrosoft.com; dkim=none (message
 not signed) header.d=none;<tenantDomain>.mail.onmicrosoft.com; dmarc=none
 action=none header.from=<MyDomain>;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
 chol.com discourages use of <MailServerIPExternal> as permitted sender)
Received: from <MailServer> (<MailServerIPExternal>) by
 BN3NAM04FT057.mail.protection.outlook.com (10.152.93.80) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
 15.20.1580.10 via Frontend Transport; Tue, 5 Feb 2019 20:33:13 +0000
Received: from mailsnd3.chol.com (203.252.1.124) by
 <MailServer> (<MailServerIPInternal>) with Microsoft SMTP Server id
 14.3.382.0; Tue, 5 Feb 2019 12:33:11 -0800
Received: (qmail 22976 invoked from network); Wed, 6 Feb 2019 05:33:03 +0900
 (KST)
Received: from [203.252.1.171] (203.252.1.171)  by mailsnd3.chol.com with
 ESMTP; Wed, 6 Feb 2019 05:33:03 +0900 (KST)
Received: from [92.241.66.138] ([92.241.66.138])           by
 watcher1.chol.com ([203.252.1.171])           with ESMTP id
 1549398779.780360.2907691920.watcher1          for
 <MyEamil@myDomain.com>;           Wed, 06 Feb 2019 05:32:50 +0900 (KST)
X-Sender: jarch@chol.com
X-Complaints-To: <abuse@mailer.chol.com>
Errors-To: noreply@chol.com
To: <MyEamil@myDomain.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907
 Thunderbird/15.0.1
Message-ID: <xfdqmzdt-ygq4-2a0h-8ho7-m8fwl45l5uef>
From: <MyEamil@myDomain.com>
X-Priority: 5 (Lowest)
Date: Tue, 5 Feb 2019 21:33:02 +0100
List-Unsubscribe: <mailto:unsubscribe@chol.com?subject=unsubscribe:gaz4jasyo908c7q9e1n9ad3mwy0ooqhs87t3mtptcj5nathabgv>
List-Subscribe: <https://chol.com/lists/?p=subscribe>
Abuse-Reports-To: <abuse@mailer.chol.com>
Subject: <My Name>
X-TERRACE-DUMMYSUBJECT: Terrace Spam system                                  *
X-TERRACE-SPAMMARK: NO       (SR:8.63)                    
  (by Terrace)                                                  
MIME-Version: 1.0
Return-Path: jarch@chol.com
X-TM-AS-Product-Ver: SMEX-12.0.0.1220-8.200.1013-23806.001
X-TM-AS-Result: No--7.095400-0.000000-31
X-TM-AS-MatchedID: 144052-186105-701236-702020-708325-702445-710687-700476-7
      00618-704156-705754-704301-701035-106240-700354-705802-701618-701446-701390
      -186107-705140-701461-703385-139504-705753-704597-188019-700023-703835-1059
      20-700752-300989-703712-700445-309658-708496-711432-700107-701588-702112-70
      4930-700706-700345-712024-148004-148042-148046-148133-148152-10010-23109-42
      000-42003-63
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-OrganizationHeadersPreserved: <MyMailServer>
X-MS-Exchange-Organization-ExpirationStartTime: 05 Feb 2019 20:33:13.3923
 (UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 2:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
 684faf54-c8c4-4f00-284a-08d68ba926aa
X-EOPAttributedMessage: 0
X-MS-Exchange-Organization-MessageDirectionality: Originating
X-MS-Exchange-Organization-SCL: 5
X-CrossPremisesHeadersPromoted:
 BN3NAM04FT057.eop-NAM04.prod.protection.outlook.com
X-CrossPremisesHeadersFiltered:
 BN3NAM04FT057.eop-NAM04.prod.protection.outlook.com
X-Forefront-Antispam-Report:
 CIP:204.145.245.173;IPV:CAL;CTRY:US;EFV:NLI;SFV:SPM;SFS:(2980300002)(199004)(189003)(5820100001)(3480700005)(8676002)(65826007)(55666002)(8936002)(1096003)(47776003)(81686011)(33896004)(76786011)(305945005)(65956001)(7596002)(7636002)(246002)(90146011)(65806001)(55176004)(23676004)(58126008)(2876002)(6916009)(6200100001)(6706004)(9036002)(63326003)(45954011)(66574012)(9686003)(336012)(50466002)(486006)(306002)(26826003)(106466001)(956004)(86152003)(476003)(146002)(156004)(42882007)(95636005)(26005)(61793004)(2351001)(575854001)(19627235002)(356004)(105596002)(126002)(6666004)(64126003)(436003)(14444005)(76806002)(173224004)(114323001)(98824002)(87826002)(17046004);DIR:INB;SFP:;SCL:5;SRVR:BYAPR15MB2310;H:<MyMailServer>;FPR:;SPF:SoftFail;LANG:en;PTR:<MyMailServer>;A:1;MX:1;CAT:SPM;
X-Microsoft-Exchange-Diagnostics:
 1;BN3NAM04FT057;1:9B1/C0nMcye5dT/GGZAlrLGeXz0fSgXfmBmmjAKqlcH31BZHDEUg9sYsbbEODe0YZN9Amo0IId6RkA1qzHmEkoWJZqKal4el/ky4YVc4CuJeJ/ZhHqek6wNaQofO3GAyyPXu8bTsreSmooLOYzCwxg==
X-MS-Exchange-Organization-AuthSource: <MyMailServer>
X-MS-Exchange-Organization-AuthAs: Anonymous
X-OriginatorOrg: <MailServerDomain>
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 684faf54-c8c4-4f00-284a-08d68ba926aa
X-Microsoft-Antispam:
 BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(8559020)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060);SRVR:BYAPR15MB2310;
X-MS-TrafficTypeDiagnostic: BYAPR15MB2310:
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Feb 2019 20:33:13.0580 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 684faf54-c8c4-4f00-284a-08d68ba926aa
X-MS-Exchange-CrossTenant-Id: 29b9a438-bcbd-487a-8b52-8e53a14d70a5
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=29b9a438-bcbd-487a-8b52-8e53a14d70a5;Ip=[<MyMailServerIP>];Helo=[<MyMailServer>]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2310
X-MS-Exchange-Transport-EndToEndLatency: 00:00:02.5237506
X-MS-Exchange-Processed-By-BccFoldering: 15.20.1580.012
X-Microsoft-Antispam-Mailbox-Delivery:
      ucf:0;jmr:0;ex:1;auth:0;dest:J;OFR:ExclusiveSettings;ENG:(20160513016)(750119)(520011016)(520003179)(708172)(944506303)(944626516);RF:JunkEmail;
X-Microsoft-Antispam-Message-Info:
      =?us-ascii?Q?1u6LAlNlYYhNt46L3ArOc+xZq0uxVoZaCm6eoIOkHl2jWhSl+EK6+f2VenSb?=
 =?us-ascii?Q?f7VHdm+R6c6tiTsyPFeu/j5VtnpuO21OvoQ6ze5Y7rDQeoGS2v97A6WHmCZA?=
 =?us-ascii?Q?tY4viTNDn4JenOIaUUlfEd3FAxdkcbwyiRnO0qnMLLJa0oerf0Zs4NRV6ady?=
 =?us-ascii?Q?08eySZqZYaFaSt5oVCEi7nb/xrwNXJKIzFbGhba46K+zDACHXEPs66cbkKIv?=
 =?us-ascii?Q?JyRZGJnBNrXMJOdMmH0eElJqUjbiQMcnLqZ/oLdfpnll7muJmvIcT7kGc3aC?=
 =?us-ascii?Q?8AZLRuG5SSgJucAfWIr+3DRttsvrYeJ2c4JDC51/h6aLQxMqGM9drM7yzdtj?=
 =?us-ascii?Q?tHZYX3tNobIdCsB4IDM2V1cw6KbftqJDFxrra2JMH8JrjLj3ZvZZ5cJeVDbo?=
 =?us-ascii?Q?pc3FoTBXW71XqeeEaoYPEU0Bmk8s3eyjD7t0l0rC9vYLXDQ371+bs9n8CoLo?=
 =?us-ascii?Q?WH47CX6qwX0e8QghU7ZQK/GWd8lPUPk/JoZW+iG1rlchP0EVr5mHCfAQACkj?=
 =?us-ascii?Q?f0P0jdt/Wlpzm0Q+wcarY8htLnD5BwXVFSE5tADRouu/mWKESqe1x4feoukQ?=
 =?us-ascii?Q?xIoVpvpADDTXi8FhcAiUoPR3ZztBNSr8P1hMahMbIP+GJO7oYkmW0MpFF13y?=
 =?us-ascii?Q?uIUyKzjXvFKUPcmlEpOyaG0HDrZth+XyzfBhHGIaOJ5j3JeevvY8G4MaOvFR?=
 =?us-ascii?Q?cE4BECECTYjFD5Nctu2pIq2u0QfNBk/JcmrQgh1Q9Mjv5hZSlEdd4SqxNk/C?=
 =?us-ascii?Q?qsZoVyIKnMf4Tf4/KZQg8wRiN2+B4ahQYtASLTmslvCRlYUi+1elndUF8RkO?=
 =?us-ascii?Q?7gsr/cYQCPwqthCaFvkBH2RFCYFgtcU9eKJQMw4pA8E9S9N8JD2SPp2xQhSr?=
 =?us-ascii?Q?AsG5yB70MUNU3XkT7XVHWT7Tx5SzSjKcRAmkkW94gCMDYRDTmuKHdBeWExhs?=
 =?us-ascii?Q?vFN298UwnfEDJN3GVXwb1sApr+dkBWWGjloNzmUQPoIesfJNMi4MZs1iJfAb?=
 =?us-ascii?Q?0Nyb6JQ71yM+z5umeA2pGiUjO8pPabPW4op5oSV9NUmRRi8QJrpj5l4Nv89F?=
 =?us-ascii?Q?S6c2ZqKVrKia+WbfwZ7jB3lehIDdIl2kNs8ChfpSBU4lDd7B/fIzpDlv37d2?=
 =?us-ascii?Q?P2bIfL+4c/FCYaxplrBSji6BCGHaKNgDkNfpBpEQQKcQCBzaJLgmcnHZXe+R?=
 =?us-ascii?Q?t733d20MLrcAo8wusFfaCFTtiwjrV+378lquhkyP/VMELTggrj/8m5EIPjOa?=
 =?us-ascii?Q?eKGOI83ADETFgElXl55F?=
Content-type: text/plain;
      charset="UTF-8"
Content-transfer-encoding: quoted-printable

Hi, your account was recently hacked! It will be good idea to change your p=
swd immediately!
You might not heard about me and you obviously are definitely wanting to kn=
ow why you're reading this electronic message, proper?
I'mhacker who burstyour email boxand devices and gadgetsseveral months ago.
You should not try to msg me or find me, in fact it's not possible, since I=
 directed you an email from YOUR hacked account.
I started malware soft to the adult videos (porn) site and guess you watche=
d this website to have a good time (you realize what I mean).
During you have been keeping an eye on vids, your browser started out to ac=
t like a RDP (Remote Control) having a keylogger that granted me permission =
to access your display and camera.
Consequently, my softobtainedall information.
You have entered passwords on the web services you visited, I intercepted a=
ll of them.
Surely, you can modify them, or have already changed them.
But it really doesn't matter, my spyware renews it regularly.
What did I do?
I compiled a backup of your system. Of all the files and personal contacts.
I have managed to create dual-screen videofile. The first section demonstra=
tes the clip that you were observing (you've the perfect taste, huh...), and=
 the second part reveals the video from your camera.
What must you do?
Clearly, in my view, 500 USD will be a fair amount of money for our little =
riddle. You'll make your deposit by bitcoins (if you don't recognize this, g=
o searching =E2=80=9Chow to purchase bitcoin=E2=80=9D in Google).
My bitcoin wallet address:
13v2bbgDUDqojx2CxcsaCwMgM3WLRWgK3s
(It is cAsE sensitive, so copy and paste it).
Attention:
You have only 2 days to perform the payment. (I have an exclusive pixel to =
this letter, and at the moment I understand that you've read this email).
To monitorthe reading of a letterand the activityin it, I utilizea Facebook=
 pixel. Thanks to them. (The stuff thatis usedfor the authorities may helpus=
.)

In case I fail to get bitcoins, I shall immediately offer your videofile to=
 each of your contacts, along with family members, co-workers, ?etcetera?.

Avatar of Alan
Alan
Flag of New Zealand image

Hi Scott,

I normally add a Transport Rule that blocks any incoming external email purporting to be from an internal domain.

If required, I add exceptions (such as an external newsletter provider for example).

Should be pretty much rock-solid.

Alan.
Avatar of Kimputer
Kimputer

Since this is essentially email TO you (on premise)

From: <MyEamil@myDomain.com>
To: jarch@chol.com

It's already "legit" email that shouldn't trigger SPF at all. Please note it was never (From: jarch@chol.com, To: jarch@chol.com, which WOULD trip SPF)
After that, it's being forwarded to Office365, which shouldn't trip SPF once again (otherwise the Office365 subs would be there for nothing, always empty mailbox).

Therefore, it's not an SPF issue, it's a spam issue (on premise should've filtered it, so it wouldn't be forwarded to Office365)
Ideally you should have antispam gateway on exchange or at least should enable antispam transport agent on exchange server

Further you should enable sender ID on exchange server and have combination of Spf + DMARC OR SPF + DKIM + DMARC which will enforce sender domain to authenticate either SPF or DKIM originating from his own domain
Though he can spoof your org email addresses (he can do that from internet) but either SPF OR DKIM validation will fail and you could easily reject / declare that message as spam
when spammer try to send email from your smtp domain, exchange will check received message for either SPF or DKIM resolution with your own smtp domain because of DMARC policy, since spammer email origin IP (SPF) or DKIM signature will not match, it will identify it as spoofed email and according to DMARC policy exchange will act on it.
@my previous post, I think I misunderstood who is who. So, SPF indeed didn't trigger because it was indeed from jarch@chol.com, sending from the correct IP stated in the SPF record.
The FROM header came later, during the email data conversation (passed the SPF checking point already, can't reject it based on SPF anymore).

How would you've caught this one though? Easy, also enable other DNS blacklists, since this IP has been blacklisted already:

LISTED      DNS Realtime Blackhole List      203.252.1.171 was listed        300      31      Ignore
 LISTED      ivmSIP      203.252.1.171 was listed        2100      0      Ignore
 LISTED      PSBL      203.252.1.171 was listed        2100      0      Ignore
 LISTED      SERVICESNET      203.252.1.171 was listed        2100      47      Ignore
 LISTED      UCEPROTECTL1      203.252.1.171 was listed        2100      0      Ignore

ALso, it was one of those standard phishing mails that's been going around for months already, any simple spam filter would've caught it.
M$ probably let it through intentionally, wanted you to cough up some extra dough for the extra protection subscription they're offering.
92.241.66.138 is the originating IP.. Which is in Georgia, RU.. you could block that range of IP's
"Softfail", means that the  SPF record probably ends with ~all

A "softfail" is not the same as a "fail". It means that SPF is still being configured and tested, so results should not be taken too seriously.

Change the end bit to -all , and this spam will likely be blocked.
Checking your SPF record confirms that it does indeed end with a softfail qualifier. Needs to be changed.

"v=spf1 ip4:203.252.1.0/24 ip4:203.252.3.0/24 ip4:164.124.191.0/24 ip4:210.120.128.25 ~all"

Be aware however, that if you don't have all IPs that your domain may send mail from listed in the SPF record, making this change will probably result in some of your outgoing email being spam binned.
Avatar of Scott Townsend

ASKER

@Alan - We cant do that as we do have other legitimate mail providers sending mail as us to us. I’m sure I could then come up with rules to allow only them to bypass.

@kimputer I do have some RTBL setup, I’ll have to look to see why its not picking it up.

@David Johnson The origin IP address changes, so keeping on top of the different subjects they are using is tough.

@Mal Osborne - My SPF Récord is:
v=spf1 mx a:webex.com include:spf.protection.outlook.com ip4:10.0.0.0/8 include:e2ma.net ip6:fe80::c530:2fc8:c944:bbe include:_spf.mailspamprotection.com -all
  So I do have the -all at the end.

@Mahesh - I’m still looking into DKIM and DMARC, it looks like its the way to go.

Thank you all for your replies
OK, so your domain is NOT chol.com?

SPF specifies that interpreting a record to a set of IP addresses cannot involve more than 10 DNS queries, including the includes.  Your record is too complex, and will almost certainly hit that limit, breaking SPF.

MX Will be at least  2 DNS lookups, but probably 3 or more: an MX, and an A for each mail server.
a:webex.com Will be another DNS lookup.
Includes x3 Will generate another 3 lookups.

So, that means at least  6 DNS queries, even before resolving whatever is in the includes.

That should result in a PERMERROR.

This site can help check for excess DNS lookups:
https://www.kitterman.com/spf/validate.html
Hi Scott,

I don't understand what you mean by:

We cant do that as we do have other legitimate mail providers sending mail as us to us. I’m sure I could then come up with rules to allow only them to bypass.

Are you saying that you have a large number of external parties sending you email using your domain name?

Bear in mind, this is NOT your users who are outside the LAN (using their SmartPhone etc) - this is external parties sending email 'pretending' to be you?

If so, then you have a very unusual situation.

If not, then there should be no issue - you are only blocking incoming emails that are purporting to be FROM your domain.

This solution is simple, free, pretty much bullet-proof, and you can do it in ten minutes.


Alan.
@mal Osborne - No, chol.com Is not My Domain, that is from the Spammer.   I know my SPF récord resolves to 11 and not 10. I dont know how to consolidate as I need the ones from Microsoft, WebEx and our Email Marketing Provider,

@Alan - We have email marketing campaign providers that send out our marketing emails. The from address they use is one from our domain. Our employees as well as customers receive the marketing emails.   So I could I guess create a rule that blocks our domains unless it is coming from the marketing company. Though the SPF usually does this with the from address only, since there is the X-Sender the SPF didn’t kick it out.
@scott, as I said before, it's not about the FROM and X-Sender, SPF has always been acting "correctly" to check X-Sender (the first part of the SMTP conversation), the FROM is from the second part of the SMTP conversation, PASSED the SPF stage.
You incorrectly assume it's because of this, that the email got through.
This one got through (despite what I told you DNS blacklist and normal decent spam filter would've caught it), is because it's one of those rare spam messages from a higher level hack.

The lowest spam types that are easily caught are from mindless bots, running on compromised PC's connected to home PC's, running on ISP's customer dynamic IP range.
This is a "higher" type of spam, because it originated from a more "established" host, where all the things were in place (static public IP nrs, DNS records etc). And these higher types of spam, obviously pass SPF (because it was a chol.com user, sending from a chol.com server). So you should help other people on the internet by stopping this users from abusing chol.com valid services (that probably serves thousands of legitimate law abiding users), by finishing the abuse trajectory (sending headers to abuse dept. it's clearly stated in the headers, abuse@mailer.chol.com).
Probably a really tiny fish out of the water, but a fish nonetheless (the jarch@chol.com user will probably be banned or warned that his PC is compromised)
Hi Scott,

We have email marketing campaign providers that send out our marketing emails. The from address they use is one from our domain. Our employees as well as customers receive the marketing emails.   So I could I guess create a rule that blocks our domains unless it is coming from the marketing company

Yes - Most companies only have a few such providers, so trivial to create exceptions for them.

Your call, but I add such a rule at all my clients by default, and never had any issues in all the years (probably since Transport Rules came out - hard to recall, but maybe Exchange 2010, so about ten years or so).

Even if the client also has other anti-spam setup, this just sits there as an additional backstop for one of the most dangerous types of spam emails - those that look like they are from someone within your organisation.


Given the negligible time it takes to setup, there's really no reason not to try it, and if you want to be conservative, you could initially have all such emails go into a separate mailbox to be reviewed hourly, daily, weekly, monthly - whatever suits your business requirements.


Alan.
ASKER CERTIFIED SOLUTION
Avatar of Mahesh
Mahesh
Flag of India image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
@Kimputer I have the Following RBL setup
Spamhaus ZEN
HostKarma (JMF)
Weighted Private Block List
Passive Spam Block Lost
Mailspike Combined List
SpamCop Blocking List
Barracuda Reputation Blocking List

Interestingly enough it made it past PSBL. So It must of been whitelisted before that.   I'll Keep looking there.

@Alan, I'll Look into creating the Rule.

@Mahesh I have DKIM on one domain and will work on DMARC next. See how it goes and then add it to the Primary Domain.
I still need to learn more about this. Is there any issues with losing mail if something is not setup right or would it just not run the test or?

I also have the Issue where some domains are Pointed to protection.outlook.com and some are pointed to the on-Premise server, so I have a Mix. We have about 30 Different domains. I'll be testing with the ones that are not as critical.

Thanks All.
@Alan - When I went to create the Rule I didn't see a way to do it to allow good mail vs not good.   Since we are a Hybrid and most of the users are in the Cloud, I cant see a way to create a Rule to Allow from a Specific Sending Host(s) vs people's email.   So if I block all @MyDomain.com except if from marketing@mydomain.com I would then block the clouduser@mydomain.com too.

THanks!
Hi Scott,

When your clouduser@mydomain.com sends an email to another user (an internal email), does it come in via smtp somehow?

If not, then it should not get blocked, as you are only applying this rule to incoming, external emails.  The rule would be constructed something like this:

  • from users that are outside the organisation
  • when the from address matches yourdomain.com
  • redirect the message to testmailbox
  • except when (whatever criteria you want to use)

To test, you could block yourself only (or one user that you can talk to who is setup that way), and see if you / they get blocked when you send an email to each other.  To do that, this line would be something like:

when the from address matches scott@yourdomain.com


If they are coming in via smtp, then this approach might be too hard to implement :-(


Thanks,

Alan.
the way that a Hybrid On-Premis/O365 system is setup, they use SMTP to transfer from on to off and off to on premise via SMTP.   So when I went to look at my SMTP Log to fund senders from my domain, it is listing the Cloud users sending to On-Premise.
Darn - Probably not a good option then.

Sorry!

Alan.
I have SPF and DKIM implemented.  Still Looking into doing DMARC Correctly.

Thank You!