香港中小企電郵網域防偽：SPF、DKIM、DMARC 實務

分類：網絡安全 | 日期：2026-10-23

適用範圍：香港市場。本文講述通用技術做法，唔係任何供應商的服務承諾。

一、開場：冒名電郵點樣呃到人

電郵最初設計時，並無內置寄件人身份證明。只要收件一方無驗證機制，任何人都可以在 From 欄填上你公司的網域，寄出睇落似由你公司發出的電郵。對香港中小企而言，最實際的風險往往唔係伺服器被入侵，而係名義被盜用。

常見手法包括：冒充公司名義寄假報價、假發票或者假付款指示畀客戶或供應商，要求更改銀行資料或者付款；冒充老闆或者財務同事，發出假內部指示，要求同事轉帳或者交出資料；客戶收到假電郵之後，即使公司本身無被入侵，都可能對之後的真電郵起疑。

要先分清楚兩件事：SPF、DKIM、DMARC 保護的，是「你個網域有無被冒充寄信」；而「你個電郵帳戶有無被盜用」是另一回事，兩者要分開處理。

香港背景方面，只作騙案普遍性背景，唔好誤讀為電郵冒充專屬數字：警方數字顯示，2025 年首 8 個月全港騙案共 28,379 宗，涉及損失 50.2 億港元。呢個數字涵蓋所有騙案類別，唔係單指電郵網域冒充；本文章亦無香港電郵網域冒充專屬官方統計，唔好將上述數字改寫成電郵冒充損失。金管局亦提醒，銀行唔會以電郵或短訊附連結要求客戶交易，亦唔會以電郵索取登入密碼或一次性密碼。HKCERT 亦將「含可疑連結／附件嘅電郵」同「誘使轉帳嘅詐騙電郵」列為資訊保安事故例子。

二、SPF：邊啲伺服器有權用你個網域寄信

SPF 係 DNS TXT 紀錄，以 v=spf1 開頭，列出獲授權以該網域寄信嘅伺服器或服務。收件方會比對寄信伺服器 IP 是否在授權名單內，唔在名單就會出現 SPF 失敗，或者按結尾符號而有不同處理。

SPF 結尾符號的意思要分清楚：-all 為硬拒，即未列明即唔授權；~all 為軟拒，即只作參考；?all 為中立。實務起步常用 ~all，確認正當來源齊全之後先轉 -all。如果起步就用 -all 而漏列某個正當寄信服務，該服務寄出的真郵件就可能被拒。

只經 Microsoft 365 寄信嘅網域，常見 SPF 例子為 v=spf1 include:spf.protection.outlook.com -all。呢個例子只適用於只經 Microsoft 365 寄信嘅情況；如同時有用其他服務寄信，必須將各服務嘅 include: 合併入同一條 SPF 紀錄，唔好另開第二條。

三、SPF 兩大硬限制：單一紀錄同 10 次 DNS 查詢上限

第一個硬限制：同一個網域標籤只可以有一條 SPF 紀錄。出現兩條 v=spf1 紀錄會導致 PermError，收件方可能當成無 SPF。換句話說，「兩條都寫齊全仲好」係誤解，兩條並存反而等於無保護。

第二個硬限制：每次 SPF 評估最多 10 次 DNS 查詢。include:、a、mx、exists、redirect 等連同巢狀 include 一併計算；ip4／ip6／all 本身唔使查詢。超標同樣會導致 PermError。另有 2 次 void lookup（空回應）上限。

實務上最容易超標的情況，係疊加多個服務商的 include:。每加一個寄信服務之前，都要先計好合併之後的查詢次數，唔好只顧加服務而唔計上限。DNS 改動傳播時間一般數分鐘至數小時，個別情況可達 48 小時；改動之後必須重寄測試郵件驗證，唔好憑「已儲存」當完成。

四、DKIM：證明內容寄出後無被改過

DKIM 用私鑰為郵件簽名，簽名放喺郵件標頭；網域擁有人喺 DNS 發布對應公鑰，通常為 selector._domainkey 形式嘅 TXT 或 CNAME 紀錄。收件方用公鑰驗證內容無被竄改。本文唔會列出任何私鑰、真實 CNAME 目標值或者登入資料，讀者須按自己服務商或者租戶提供的數值填寫。

每個寄信服務須獨立設定 DKIM。只開啟主郵箱 DKIM，唔等於電子報平台、CRM 等其他寄信服務已有簽名。主郵箱有簽名，不代表其他服務寄出的信都有簽名，逐個服務檢查先算齊全。

DKIM 簽名跟住郵件內容走，單純轉發一般唔會破壞簽名，中途改動內容除外。SPF 則會因轉發改變寄信路徑而失效，故轉發場景下 DKIM 更可靠。不過要留意：DKIM 證明的是內容無被竄改，唔證明內容本身真實；冒充者用自己網域寄出內容完整的假消息，DKIM 照樣可以通過。

五、Microsoft 365 自訂網域 DKIM 對齊陷阱

用 Microsoft 365 的公司要特別留意一個對齊陷阱：Microsoft 365 預設只會以初始 *.onmicrosoft.com 網域簽署 DKIM，呢個簽名同自訂網域嘅 From 地址唔對齊。

要令自訂網域的 DKIM 對齊，必須為自訂網域發布兩條 CNAME（selector1._domainkey、selector2._domainkey）再開啟簽名。CNAME 目標值由自己租戶提供，絕對唔好由教學文章抄錄他人數值。抄錯目標值，簽名就對唔上自訂網域，之後 DMARC 亦可能因此失敗。

呢個陷阱說明一個重點：「買咗 Microsoft 365」唔等於自動有齊三項機制。SPF 要自己發布，DKIM 要為自訂網域手動開啟，DMARC 完全要自己發布，三樣缺一都唔算齊全。

六、DMARC：家規同監察，建基於 SPF 同 DKIM 之上

DMARC 建基於 SPF 同 DKIM 之上。網域擁有人喺 _dmarc.<網域> 發布以 v=DMARC1 開頭嘅 TXT 紀錄，講明驗證失敗時嘅政策及監察報告收件地址（rua=）。

DMARC 通過條件係最常被誤解的一點：SPF「或」DKIM 其中一條「通過＋對齊」即通過，唔使兩條齊過；但兩條都通過而無一條對齊，DMARC 仍然失敗。換句話說，單有通過唔夠，仲要對齊先計數。

對齊的意思係：SPF 嘅 envelope-from（Return-Path）網域，或 DKIM 簽名嘅 d= 網域，必須同收件人見到嘅 From 網域有關聯。預設寬鬆對齊（aspf=r／adkim=r）：同一組織網域下嘅子網域都算對齊；嚴格對齊（s）要求完全相同；標籤唔寫即預設寬鬆。舉例而言，DKIM 簽名網域同 From 網域唔對齊，例如用服務商預設網域簽名，即使 DKIM 通過都唔計 DMARC 通過。

DMARC 三級政策分別係：p=none 只監察、唔採取行動，收件方只寄報告；p=quarantine 將失敗郵件送入垃圾郵件／隔離區；p=reject 直接拒收失敗郵件。sp 標籤可為子網域另設政策；無設則沿用主政策。

七、p=none 只係起步，唔係保護

收緊次序必須係監察先、收緊後：先 p=none 睇報告、執漏正當來源，再至 p=quarantine，最後至 p=reject。一開始就用 p=reject 而漏列正當來源，會令真郵件被拒收。

起步紀錄例子（佔位符，唔好照抄地址）：v=DMARC1; p=none; rua=mailto:dmarc@example.com。例子中的網域同地址只作格式示範，實際報告地址須用自己公司有人負責睇的郵箱。

p=none 只監察，唔執法，冒充郵件仍然可以進入收件箱。長期停留 p=none，有監察、無執法，唔等於已經受保護；p=none 係起步，唔係終點。無人睇報告亦等於無監察：如果 rua= 指向一個無人睇的郵箱，或者報告係 XML 無人解析，收緊時就無依據。

DMARC 匯總報告（rua=）為每日 XML 匯總，按寄信 IP 列出數量同 SPF／DKIM／DMARC 結果，只含驗證元數據，唔含郵件內容。個別失敗報告（ruf=）在實務上不可依賴：大型郵箱供應商基於私隱原因普遍唔寄送，支援有限；監察應以 rua 匯總報告為主，唔好承諾讀者一定收到 ruf 報告。

公開指引建議的 DMARC 監察期由數星期至 90 日不等，視乎寄信來源數量；來源少的中小企通常數星期已可睇到全貌，來源多或有季節性寄信的公司要睇更耐。呢個只係範圍，唔係單一保證，唔好寫成做幾多日就一定足夠。

建議的通用節奏係：先盤點所有用公司網域寄信的服務，包括主郵箱、電子報、CRM、發票／會計系統、網站表格同舊供應商；再合併 SPF 成一條紀錄並計好查詢次數，起步用 ~all；然後每個服務逐一開 DKIM 簽名、逐一驗證對齊；再發布 DMARC p=none 加 rua= 收報告；睇報告、執漏正當來源之後，先逐步收緊至 p=quarantine，再至 p=reject；收緊之後仍要持續監察，因為每加一個新寄信服務、轉供應商或者改 DNS，都可能破壞原有對齊。

完全唔寄信的網域，建議發布 v=spf1 -all 加 v=DMARC1; p=reject，明確表示無人應該用該網域寄信。主網域收緊咗，但漏咗子網域同唔寄信網域，騙徒可以轉用子網域或者閒置網域冒充，呢個係常見缺口。

大型郵箱供應商的門檻亦值得留意。Google／Yahoo 自 2024 年 2 月起要求：每日向個人 Gmail／Yahoo 帳戶寄 5,000 封或以上嘅寄件人，必須同時有 SPF＋DKIM、至少 p=none 嘅 DMARC、From 對齊、推廣郵件一鍵退訂、同投訴率低於 0.3%；所有寄件人（不論數量）都起碼要 SPF 或 DKIM、有效正反向 DNS、TLS。Microsoft 對 Outlook.com／Hotmail 等自 2025 年 5 月 5 日起對同級大量寄件人（5,000 封／日）實施類似要求，不合規郵件可被拒收（錯誤碼 550 5.7.515）。香港中小企一般未必達到 5,000 封／日的門檻，但呢啲門檻說明「三項齊全」已由最佳做法變成大型收件方的基本要求。

八、三項機制擋唔到嘅嘢

做齊 SPF、DKIM、DMARC 唔等於唔會再有詐騙電郵。以下三類，三項機制都擋唔到，必須另外處理：

第一，相似網域。騙徒可為串法極近似的假網域正確設定三項紀錄，驗證會通過，因為驗證只認網域本身，唔認「呢個網域係咪你公司」。對策係員工同客戶教育，加留意發件網域串法，唔係靠三項機制。

第二，顯示名稱冒充。顯示名係真人名，實際地址係陌生網域；驗證針對網域，唔針對顯示名。收件人要睇實際地址，唔好只睇顯示名。

第三，已入侵的真帳戶。信確實由授權伺服器寄出，SPF、DKIM、DMARC 全部會通過。對策係帳戶保安，包括多重驗證同異常登入監察，三項機制無能為力。

除此之外，付款指示詐騙亦唔可以只靠電郵驗證把關。任何付款資料變更或轉帳指示，必須以非電郵渠道核實，例如打去對方公司公開電話，並宜設雙重批核。即使郵件驗證通過，都唔好只憑電郵執行「改銀行戶口」或者「緊急轉帳」指示。

九、初步自查：讀者自己做得到的方法

以下方法唔使假設讀者已有任何工具帳戶：

• 1. 查 DNS 紀錄：用 dig TXT <網域> 睇 SPF，應只有一條 v=spf1 開頭；用 dig TXT _dmarc.<網域> 睇 DMARC，應以 v=DMARC1 開頭。
• 2. 查 DKIM：DKIM 須向各寄信服務查詢其 selector 再查 DNS，無法單憑網域名稱查到。向每個寄信服務問清楚 selector，再逐一查對應的 DNS 紀錄。
• 3. 查真郵件標頭：寄測試郵件去自己 Gmail，開「顯示原始郵件」睇 Authentication-Results 入面嘅 spf=、dkim=、dmarc= 是否 pass。
• 4. 對照寄信來源清單：將報告或者標頭見到的寄信來源，同公司內部盤點清單逐一對照；多出嚟的來源先處理，唔好一見到就即刻收緊政策。
• 5. 改動後必重測：每改一項 DNS 紀錄，等 DNS 傳播後再寄測試郵件驗證，唔好憑「已儲存」就當完成。

常見誤區再整理一次：兩個 SPF 紀錄並存會 PermError；SPF 查詢超標會 PermError；只設 SPF 無 DKIM，或者反之，DMARC 只剩一條路；DKIM 簽名網域同 From 網域唔對齊，DMARC 仍然失敗；長期停留 p=none 唔係保護；無人睇報告等於無監察；漏咗子網域同唔寄信網域會留低缺口；轉郵件供應商、加新工具或者改 DNS 託管時無同步更新三項紀錄，正當郵件即可能中斷。

十、定價頁講咗乜、冇講乜（未證實部分，必須分清楚）

以下為 live 定價頁原文引用（2026-10-23 親驗，https://www.itsupportking.com/pricing/），只作引用，唔係服務承諾：

• 基礎遙距版 HK$600／月
• 專業進階版 HK$1,200／月
• 企業設備版 HK$2,200／月
• 全方位無憂版 HK$2,950／月
• 設計專用版 HK$4,950／月
• 旗艦網頁版 HK$5,950／月

基礎版 scope 原文包括正版 Office 365 商業授權，本文只用呢個原文表述，唔寫版本、數量或者持有人名義。

關鍵否定結果：定價頁全文檢索 SPF、DKIM、DMARC 均為 0 命中，即定價頁無寫明任何一級包括 SPF／DKIM／DMARC 設定、電郵安全檢查或 DMARC 報告監察。首頁 FAQ Q4 提及「公司電郵域名設定」，只證明域名設定曾被提及，唔等於 SPF／DKIM／DMARC 設定已包，唔好由「域名設定」反推成防偽設定已包。

以下內容全部未證實／需用戶確認，本文一律唔寫成已包：定價頁未列明 SPF／DKIM／DMARC 設定服務，邊一級包、定係另行報價、收費幾多，全部未證實。要確認乜：邊一級包括設定、定係另行報價、收費幾多、範圍包唔包所有寄信來源。點確認：要求對方以電郵／服務協議書面確認，唔好只信口頭承諾。

同樣未證實的，還包括 DMARC 報告由邊個睇、幾耐睇一次、收緊政策決定權、子網域／閒置網域處理、轉供應商交接、持續監察同新寄信服務更新，全部未證實。要確認乜：上述每一項的負責人、頻率、準則同交接安排。點確認：要求對方以電郵／服務協議書面確認，唔好只信口頭承諾。

十一、簽約前要問的問題（全部問題式，唔係本站服務承諾）

以下問題適用於向任何 IT 支援供應商提問，本文唔將任何一條寫成已包的服務：

• 1. SPF／DKIM／DMARC 設定是否包括在內？如包括，係邊一級包括，定係另行報價？
• 2. 設定範圍包唔包所有寄信來源（主郵箱、電子報、CRM、發票系統、網站表格），定係只包主郵箱？
• 3. DMARC 報告（rua=）由邊個負責睇、幾耐睇一次、報告點樣交畀客戶？
• 4. 由 p=none 收緊至 p=quarantine 再至 p=reject 的決定由邊個做、按咩準則做？
• 5. 子網域同唔寄信網域（閒置網域）係咪一併處理？
• 6. 轉供應商或轉郵件平台時，SPF／DKIM／DMARC 紀錄點樣交接？DNS 託管權、網域註冊人、Microsoft 365 管理員權限分別歸邊個？
• 7. 設定之後的持續監察包唔包？新加寄信服務時，邊個負責更新紀錄？
• 8. 設定出錯導致正當郵件被拒或入垃圾郵件，責任同補救安排係點？有無書面紀錄？
• 9. 以上各項能否寫入服務協議？口頭承諾一律要求書面確認？

以上各項如屬未公佈，要確認乜就係上面每一條問題的答案同適用範圍；點確認就係要求對方以電郵／服務協議書面確認，唔好只信口頭承諾。簽約前亦要問清楚排除項目：邊啲已包、邊啲另收費、邊啲唔提供，全部要寫入協議，唔好只憑口頭理解。

十二、結尾

SPF 講明邊啲伺服器有權寄信，DKIM 證明內容寄出後無被改過，DMARC 講明驗證失敗時點處理同點監察。三者齊全、對齊正確，再由監察逐步收緊，先算係完整的網域防偽起步；但相似網域、顯示名冒充同已入侵真帳戶，仍然要靠教育、睇實際地址、帳戶保安同非電郵渠道核實付款指示去補位。

免責聲明：本文為一般資訊，唔係法律意見，亦唔係保安保證。實際設定須按自己網域、寄信服務同租戶提供的數值進行，改動 DNS 之前宜先備份原有紀錄，並以測試郵件驗證結果為準。