企業電子郵件會應用到混合雲 (Hyper Cloud) 佈署，有幾種應用情境，例如公司準備全部郵件轉入雲端信箱服務或從雲端信箱 (Email hosting) 轉回本地 (On-premise) 郵件主機 (Email Server)，轉換的過程為了確保穩定與安全，郵件服務架構上就會有雲端服務與地端系統同時並存的架構。除此之外，如果公司是多據點服務，例例如總公司在台北，廠區在台南，一般除了專線外，可能因為廠區會用到電子郵件的員工偏少數，也會考慮部分帳號使用雲端服務來減少基礎建設的投資成本。以下從郵件收發路由、帳號管理方式，說明混合雲的架構規劃。

混合雲郵件路由規劃

基本上規畫郵件路由 (Email routing)會需考慮到幾個問題，首先是 DNS-MX 的指向設定，一般設定政策會視帳號數量與行為決定，例如主要對外溝通的帳號，多數在都在本地郵件主機，那麼 MX 優先設定於本地主機，其次是雲端主機 ; 反之，如果對外溝通的帳號多數在雲端主機，那麼就會建議 MX 優先設定於雲端主機上。分散設定的優點就是本地郵件主機跟雲端服務主機可互相視為收信備援的角色。

接下就是規劃郵件互相轉送的設定，先從收信 (Inbound) 的流程來看，不論是本地郵件主機或者雲端服務主機，接收到信件後都必須先做帳號是否存在於本機的判斷，例如本地郵件主機收到信件後，根據信件的收件人判斷該帳號存在於本地郵件主機，則將信件收下進行保存，如果該帳號非存在於本地郵件主機，則路由指向雲端主機 ; 反之雲端郵件主機也採用相同的政策，如此不論帳號在雲端或本地，都可以接收到信件。

關於發信 (Outbound) 的部份則由本地郵件主機跟雲端主機直接處理，避免增加路由轉送作業成本，內部信 (Internal) 的部分區分同主機跟不同主機的路由，以雲端主機來說，如果員工 A 寄給員工 C 發生在這 2 個帳號都同時存在於雲端主機，則郵件遞送則雲端主機內完成，不必透過其他路由設定，如果員工 A 寄給員工 B，而員工 B 位於本地主機，則透過路由規則設定，凡收件人不存在雲端主機則轉送至本地郵件主機。因為兩台主機互有轉送 (Email relay) 規則，為了避免收件者不存在，必須從 訊息識別碼 (Message id) 主機名稱 (Hostname) 或位置 (IP) 限制，避免造成雲端主機與本地主機產生轉送迴圈。

混合雲帳號認證同步規劃

帳號管理的部分，因為帳號數量差異，最直覺的方式就是本地郵件主機跟雲端主機帳號分別管理，如果公司規模大，易動員工帳號的頻率高，就會增加 IT 管理者的工作負擔。因此也可透過目錄存取服務 (LDAP/AD) 整合方式進行帳號自動新增/停權/刪除作業，為了讓帳號同時跟雲端主機、本地郵件主機進行同步，因此在可以在 LDAP/AD 的結構資訊上，新增不同屬性 (Attribute) 欄位資訊，提供給本地郵件主機跟雲端主機識別要同步的帳號屬性。

全域通訊錄的設定可以參照 LDAP/AD 混合雲佈署架構，分別提供雲端主機與本地主機查詢 (Query) 權限建立對應的全域通訊錄，完成混合雲佈署後，仍需要持續觀察郵件路由的穩定性。不論企業需要進行混合雲架構佈署的應用情境為何? 落實事前的規劃並建立測試預備環境 (Staging ) 進行各項的測試檢驗，是佈署混合雲架構的關鍵成功因素。