公司電郵收不到信怎樣查：由退信內容到收件規則逐步排除

公司電郵收不到信：客戶說已寄，先問「寄到哪裏」

公司電郵收不到信時，先請寄件者提供完整收件地址、寄送時間、是否收到退信，以及退信原文，不要急著改 DNS。假設觀塘公司有兩位同事，一人能收到同一封報價電郵，另一人收不到；全公司網域的收信路徑未必壞了，可能是個別郵箱規則、容量或裝置顯示。先縮小故障範圍，才能避免為一個郵箱問題改壞整個公司的郵件設定。

以下按寄出、傳遞、伺服器接收與使用者看到郵件四段排除。接收方是否收過、寄件方是否收到退信，會決定下一步要查哪裏；只憑客人說「我按了傳送」無法證明郵件已送達。不要請寄件者把整張含私人內容的信轉發給不相關的人，先收集時間、寄件與收件地址、退信代碼等必要資料。

分叉一：寄件者有沒有收到退信

有退信，先讀錯誤代碼和產生者

退信通常包含被拒的收件地址、伺服器回覆及錯誤描述。地址不存在、信箱已滿、暫時連接失敗、收件政策拒絕等，處理方向各不相同。先保留原始內容與完整標頭，判斷是寄件方系統、途中轉寄還是收件方返回錯誤。不要只截一句「發送失敗」便猜是寄存空間不夠，也不要在未核實前要求客戶反覆重寄多次，免得原信稍後遞送成功後出現重複。

沒收到退信，也未必代表已到目的郵箱

郵件可能仍在排隊、被寄到錯誤地址、被規則搬到其他資料夾，或由收件系統接收後隔離。請寄件者核對寄件備份和完整地址，收件人用網頁版郵箱搜尋寄件地址與主旨，包含垃圾郵件、封存、已刪除及其他資料夾。若使用供應商管理的郵件系統，管理員可以按權限查傳遞紀錄，判斷系統是否真的接過該封信。

1. 記下完整寄件地址與收件地址。
2. 核對寄送日期時間和時區。
3. 保留原始退信，不只保留截圖。
4. 核對收件者是否有共同問題。

分叉二：全部郵箱都出問題，還是只有一個人

全域收件異常先核對域名和 MX

如果不同來源寄往同一公司網域都失敗，檢查域名是否正常、目前權威 DNS 設定是否正確、MX 是否指向實際使用的收件服務，再問服務商是否有故障。網站首頁能開不代表電郵收件路徑正確；MX 控制寄往域名的郵件應交給哪些伺服器。若有人剛更換域名服務或網站寄存，先找回改動前後的 DNS 紀錄，尤其不能只看 A 記錄便下結論。

單一郵箱異常檢查容量、別名和狀態

如果其他同事能收信，查涉事帳戶是否仍啟用、地址拼寫是否正確、所謂別名是否真的存在，以及郵箱容量或使用限制是否已達上限。這些細節需依實際郵件平台及帳戶設定確認，不宜把某一平台的介面當作全公司的通用步驟。若有共享郵箱、轉寄和群組信箱，檢查訊息是交到原郵箱還是被轉到其他地方。

分叉三：伺服器顯示已接收，同事仍看不到

先從網頁版找全郵箱，再看桌面和手機程式

同一帳戶在瀏覽器可找到郵件、手機卻找不到，多數應先查裝置同步、檢視範圍、搜尋條件和帳戶是否登入正確。不要因手機看不到便立即修改全域 MX；先確定網頁版能否看到信及其所在資料夾，再比較裝置使用的帳戶和同步狀態。若手機使用本地下載方式，也要知道郵件可能已被另一裝置搬走，需依實際協定和用戶設定判斷。

規則和垃圾郵件處理可能改變可見位置

自動分類、轉寄、封存、黑名單、隔離和垃圾郵件判斷都會令收件匣沒有信。管理員若能看到傳遞已完成，要查收件後的處理紀錄；個別同事可暫時檢查最近新增的過濾條件。看到來自陌生地址的電郵被判垃圾信，不應為了找回一封郵件關掉全部防護，先核實寄件人身份並用平台提供的個別處理方法。

• 用網頁版全域搜尋地址與關鍵字。
• 查看垃圾、隔離、封存和轉寄目的地。
• 核對最近修改過的收件規則。
• 最後才比較裝置設定與同步日誌。

分叉四：寄件者說「只有寄到你公司才出問題」

跨來源測試避免誤判

從不同可靠寄件來源向同一地址送受控測試信，再從同一來源向另一個正常收件地址送信；記下時間和結果。若只有某一家供應商的郵件失敗，須與寄件系統的管理員一起查看退信及傳送紀錄；若所有來源都失敗，焦點則放在公司的接收路徑。測試信內容應簡短且不含敏感資料，避免因大量重寄或包含連結而被防護措施影響判斷。

寄件驗證與收件問題如何分辨

SPF、DKIM 和 DMARC 是寄件身份驗證相關機制，收件系統可能依驗證結果採取處理；但公司自己收不到信，不能一概歸咎自家 SPF 設定。先查該封信的發信網域、驗證結果及收件方紀錄。想了解各機制及對齊，可讀公司寄件驗證的逐步設定；本篇重點是找出信件在哪一段失蹤。

域名或系統剛改過，從變更紀錄開始追

核對真正生效的 DNS，不只看管理介面

一家公司可能在某處登入域名帳戶，卻在另一家供應商管理 DNS。改了非權威區域的 MX，介面看似已儲存，外界仍看不到；相反，一次更換名稱伺服器可能讓舊的 MX、DKIM 等紀錄無意中消失。先查域名委派到哪個 DNS 服務，再查外界實際讀到的 MX 值，與收件供應商現行要求比對。公司域名帳戶與 DNS 管理的權責清單有助找到正確負責人。

更換郵件供應商要保留舊信處理安排

若最近更換電郵系統，收信切換與舊郵箱歷史搬遷是兩件不同工作；切換期間舊系統可能仍收到部分郵件，須有負責人核對並轉交，不可只看新系統收得到測試信便停止舊帳戶。具體情況取決於 DNS 快取與供應商設定，不能向客人承諾每封郵件都會在同一時間進入新系統。若有延遲，向客服交代回覆安排並保存收件追查紀錄。

建立故障工單，讓服務商可直接開始排查

當初步檢查無法定位，向電郵服務商提供受影響地址、寄件地址、寄送時間及時區、退信原文或郵件標頭、已測試的資料夾、是否全公司受影響，以及最近的域名或郵件設定改動。毋須向不相關人員提供密碼。若同時有網站表單通知無法送達，要辨別是網站未寄出還是收件途中被拒；可對照企業電郵設定檢查實際寄件路徑。

排查前先建一張「哪裏收不到」的範圍圖

同一封信寄給兩個同事，結果不同

如果寄給甲與乙的郵件只有甲收到，先請對方確認兩個收件地址是否完全正確，再核對乙帳戶的別名、容量及個別規則。若甲收到的是以副本寄來，而乙是透過群組轉寄，兩人走的路徑其實可能不同。診斷要把 To、Cc、群組與轉寄區分，不要一句「同公司有人收到」便推斷全域收件毫無問題。管理員可在授權範圍內看信件傳遞記錄，確認兩個地址各自的最終結果。

另一種情況是同事以為收件地址有點號、連字號或拼寫的不同版本都會送到同一帳戶。這要由實際郵件服務設定決定，不能假設自動兼容。請寄件人複製他用的完整地址，與管理系統已建立的地址逐字比對；確認別名後，再測一次收件。

只有網站通知收不到，普通電郵正常

網站表單可能從另一個寄件系統發出，與職員用電郵程式寄出的信走不同路徑。先查表單是否真的成功提交、網站有沒有發信錯誤、目標收件地址是否正確，然後才查收件端是否拒絕或分類。若寄件網域與顯示 From 不符，亦可能與寄件驗證有關；須保留原始標頭才能判斷。不要只改表單畫面的「成功」字眼，應核對消息有無到達後台和指定收件人。

若公司同時用商務電郵、外部行銷平台與網店通知，記下每種系統的收件測試結果。普通郵件正常但系統通知失敗，焦點較可能在網站寄件設定或該來源的信譽與驗證；反之全部來源都無法到達同一郵箱，先回到收件帳戶和 DNS。測試分組能避免向不相關的供應商反覆報錯。

退信代碼可以問出甚麼，不可以問出甚麼

暫時性與永久性錯誤的處理不同

退信若指出暫時無法連接或稍後重試，先記下代碼、時間、產生退信的系統，再查服務狀態和後續是否送達；不應每隔一分鐘叫客戶手動重寄。若明確指出收件帳戶不存在或網域設定無法找到，則先核對地址和 MX。相似的自然語言描述未必代表相同來源，原始 SMTP 回覆與整份退信會比只記「郵件被拒」有用。

也要認清退信可能由轉寄途中產生。假設公司地址自動轉到員工私人郵箱，前段收件成功，後段被另一方拒絕；表面看見的是公司的信收不到，但真正失敗在轉寄目的地。核對郵件傳遞鏈與轉寄規則，才能決定應找公司郵件管理員、寄件者還是目的服務商處理。

被判垃圾信與根本沒到收件系統

收件系統已接收再分流至垃圾或隔離，需要沿過濾與使用者規則查；收件系統根本無這封信的紀錄，則要回頭查寄件者和中途傳輸。兩種情況不要混為一談。查看隔離區時依公司權限及私隱安排操作，只取足以排查的標頭與結果；不要為了復原一封信把所有隔離郵件任意轉發給測試者。

若信件被判可疑，先核實寄件者身份及原始地址，避免讓同事因為「客戶急」便白名單整個不明網域。可以用供應商提供的安全方式處理個別誤判，再查看是否存在大量相似信件被拒；若多宗個案同時出現，才與寄件方一起檢查配置。

網頁版有信，手機沒有信，順序要倒轉查

先確定兩邊登入的是同一帳戶

員工換手機或更改密碼後，手機可能仍連到舊帳戶、舊租戶或只同步最近的一段郵件。先在網頁版確認信件所在資料夾和時間，再在手機查看帳戶地址、同步範圍、上次成功更新時間。若手機能收到新信卻看不到舊信，可能是同步範圍或資料夾設定；若完全無法更新，則檢查帳戶登入與連線。毋須立即調整公司全域設定。

如果使用 POP 與 IMAP 等不同取信方式，要查郵件是否被下載到另一部裝置、伺服器上還有沒有副本，以及商戶現行服務支援甚麼協定。這些設定與個別裝置的儲存狀態相關，應由有授權的管理員協助檢查。不要在未備份或未了解作用前，直接刪除手機帳戶並重新加入，免得本地尚未同步的資料也一起失去。

搜尋方式也會令人誤以為失蹤

有些電郵程式只搜尋目前資料夾，或只顯示某段日期內的內容；分類檢視可能把同一對話折疊成一串。請同事先用準確寄件地址、部分主旨與日期範圍搜尋，再檢查隱藏的封存和群組。若網頁版有信但桌面版搜尋不到，可在同一封信上比較訊息日期、資料夾與帳戶。只有確認雲端郵箱中確實不存在，才需要往外追收件伺服器。

若多人共用同一郵箱，其他同事的規則可能把郵件移走或標記已讀，造成「我無收到」的印象。查操作權限與共用方式，同時建立處理記號或分派流程，讓客服知道信被誰接手，而不是把共用郵箱當成每位員工各有獨立副本。

改 DNS 前，先知道誰是權威資料來源

網域購買帳戶與 DNS 設定位置可以不同

商戶在域名註冊商看見一個控制台，不代表外界一定使用裏面的 MX。要查名稱伺服器委派到哪裏，再到真正負責的 DNS 區域核對紀錄。若外界查出的 MX 與管理畫面不同，先處理權威位置，不要兩個後台來回修改。更換服務商時尤其要把原有收件、寄件驗證及其他 DNS 設定抄錄完整，再核對新區域有沒有漏掉項目。

MX 目標還要依郵件供應商的要求配置。填錯主機名稱或指向未建立的服務，可能使外部信件排隊或失敗。變更前留存原紀錄、理由和操作人，變更後從外部網絡查實際結果，並用數個來源做可追查的測試。DNS 更新需要時間，但若查到的是不應存在的舊紀錄，也要找是否改錯帳戶，不可一概以「等快取」推搪。

已有電郵的網域別在搬網站時順手「清理」

假設公司只打算搬網站而不更換郵件供應商，網站的新 IP 與原本收信服務沒有必然關係。技術人員應保留 MX 及相關寄件設定，只更改實際需要的網站指向。若網站主機以前也負責寄表單通知，要另核對新的寄件方式；兩項工作需要分別測試。讓負責網站與負責電郵的同事在變更清單上各自確認，會比搬完才找不到信更穩妥。

若已發生誤改，先記下變更的確切時間與原紀錄，再按現行供應商指示回復，並查看切換期間舊、新收件位置是否有遺留郵件。通知客服先用電話或其他既定渠道處理緊急查詢，避免一邊搶修一邊仍告訴客戶「請再寄一次電郵」而沒有人能接收。

修好之後，怎樣證明沒有只修到測試帳戶

從至少兩個不同來源寄往原本出問題的地址及一個正常地址，檢查寄件者有無退信、收件系統紀錄與使用者的實際收件位置。若問題涉及群組或轉寄，沿每一層查最後目的地；若問題只在裝置，先測網頁版，再測原本出問題的手機或桌面程式。驗證後由當事員工確認能以正常工作方式找到信，不能只由管理員宣稱伺服器已接收便結案。

最後寫下錯誤成因、修改的設定、原始退信代碼、重測結果與仍待觀察的事情。若牽涉資料遺失或無法取回的郵件，清楚向負責人說明範圍，安排按時間與寄件者逐一核對；沒有證據時不要保證「所有漏信已全部送回」。往後再遇到類似情況，同事可先照這份紀錄縮小範圍，再決定是否需要服務商進一步調查。

用三封測試信切開複雜的收件路徑

第一封：外部寄件者直寄公司地址

選一個可配合測試的外部帳戶，寄一封不含客戶資料的簡短郵件到出問題的公司地址，記錄準確寄送時間與主旨。寄件方看有無退信，收件方看網頁版全部資料夾，管理員再按需要查看傳遞紀錄。這封信可初步判斷一般外部郵件能否到達；若失敗，先查地址、MX、帳戶和收件服務。不要在第一步同時測自動轉寄、群組和網站表單，否則故障點會混在一起。

第二封：公司內另一位同事寄往同一地址

內部互寄可能不經相同外部路徑，因此結果與第一封不同時很有價值。若內部信成功、外部信失敗，要向外部收件連線與政策追查；若兩封都失敗，則核對收件帳戶、規則與服務狀態。這並不是一條絕對判斷，因為不同郵件系統的內部路由不同；管理員應依實際平台傳遞紀錄核實。用同一位收件者測兩種來源，才較容易比較。

第三封：從網站或業務系統產生通知

如果失蹤的原本是網站查詢或訂單通知，要提交一筆虛構測試資料，先確認網站後台真的建立紀錄，再看它有否嘗試寄信、寄給哪個地址、收件服務如何處理。若普通外部信正常而網站通知失敗，應沿應用程式、寄件驗證及郵件傳輸排查；若兩者都失敗，收件側可能需要先處理。三封信要各有不同可辨認的主旨，避免混入同一封對話線索。

當客人等著報價，如何在排查期間不中斷跟進

先確認已知失蹤的範圍

客服可根據受影響的時間窗、寄件地址及業務主旨，對照網頁查詢後台、電話紀錄和其他已批准的聯絡途徑。只要尚未能證明信件完整抵達，就應把需要回覆的客戶個別列出，避免系統恢復後重複回覆或漏掉。若客人沒有退信，但公司未找到內容，應請對方使用已確認可用的渠道再提供必要資料，並提醒不要在公開平台貼上含私隱的文件。

臨時安排要能回到日常流程

使用替代收件地址或電話處理急事，可以暫時維持服務，但須由負責人核對誰有權存取、回覆紀錄在哪裏保存，以及正式郵箱恢復後如何合併查詢。臨時改聯絡方式時，先確認新地址真的能收、寄件人知道正確拼寫；不要在慌亂中將公司郵件全部無條件轉到個人帳戶。問題解決後，移除不再需要的臨時轉寄和額外權限。

常見退信字眼的查法，別只憑中文翻譯判斷

「找不到收件者」先核對對象

訊息可能指個別帳戶不存在、別名未設，亦可能是寄件時誤寫網域。取得完整收件地址，在管理員畫面查是否有相應帳戶或群組，並確認域名拼寫正確。若只有一個員工收不到，先別修改全公司的 MX；但若整個網域的地址都被判不存在，需檢查郵件服務的網域驗證與路由設定。調查要依供應商原始錯誤代碼，不是單憑翻譯。

「容量不足」不一定是網站硬碟滿了

退信指出收件箱容量、帳戶配額或服務限制時，先查具體郵箱及供應商的實際限額。網站寄存硬碟、商務電郵容量及客人裝置本地空間可能是不同資源。若只有個別帳戶達限制，可依公司保留政策整理資料或調整方案；但不要為了收一封信便直接刪除重要舊郵件而未備份。容量恢復後重新測收件，已退回的原信亦可能需要寄件者再寄。

「被拒收」要找收件方的處理理由

拒收可能與驗證結果、內容政策、連線來源或管理規則有關。請寄件者提供原始退信與可追查資訊，由兩邊管理員核對真正作出拒收的一方。若某個寄件人經常被拒，不應簡單把整個外部網域加入信任清單，先確定來源是否真實及問題可否在寄件配置修正。否則雖然短期收得到一封測試信，卻可能留下其他濫用風險。

常見問題

網站可以開，是否表示 MX 一定正確？

不是。網頁讀取與電郵收件可以使用不同 DNS 紀錄和伺服器。先查外界看見的 MX 是否指向目前公司使用的郵件服務，再用可追查的測試郵件驗證；不要因首頁正常就排除收件路徑。

收件匣找不到信，是否一定沒有收到？

未必。先用網頁版搜尋所有資料夾，再看垃圾郵件、隔離、轉寄、收件規則及裝置同步。若管理員能查到郵件已送達帳戶，便沿收件後的處理方向尋找；若查不到，再回到寄件與傳遞紀錄。

客戶沒有退信，能否當作本公司已收到？

不能。對方未收到退信只表示沒有看到明確的退回通知；郵件可能仍在傳送、交到別處或被隔離。取得時間、完整地址與訊息識別資訊，再由相關郵件管理員按權限查詢實際路徑。

若故障已修好，亦應邀請最初報告問題的同事或寄件者以日常方式再試一次，確認資訊真的抵達需要工作的人，而不只是測試帳戶。

交接前最後檢查

公司電郵收不到信的排查次序是先保留證據，再縮小範圍，最後才修改設定。請先用一封可追查的測試信確認問題出在寄件、傳遞、接收或裝置，並保存退信和改動時間。若需要排查公司商務電郵與主機配置相關問題，可把工單資料帶給 Black Media；與網站表單有關的通知亦可一併說明，透過聯絡頁交代受影響地址和重現方法。