電子郵件驗證概覽

為確保您透過 HubSpot 寄送的行銷電子郵件符合各大電子郵件收件匣服務供應商（例如 Gmail 和 Yahoo Mail）所實施的驗證標準與寄送政策，建議您將電子郵件寄送網域與 HubSpot 進行連結。 網域連結流程需在您的 DNS 服務供應商設定中，建立四種獨立的 DNS 記錄類型：MX、DKIM、SPF 及 DMARC。

本文概述了這些記錄的定義，以及相關驗證協定的運作方式。進一步了解如何連結電子郵件發送網域。

請注意：您的 HubSpot 帳戶經理或 HubSpot 支援團隊成員可協助您了解最佳實務，以及如何使用 HubSpot 工具設定驗證，但他們無法替您做出這些決策，亦無法管理您的 DNS 設定。您需要與您的 IT 團隊或電子郵件管理員合作，才能完整設定電子郵件驗證。 您亦可聯絡第三方 DMARC 諮詢或報告服務以獲取進一步協助。

了解經過驗證的電子郵件所帶來的影響

未經認證的電子郵件與電子郵件變動網域

所有透過 HubSpot 發送、且未使用已連結電子郵件發送網域的行銷電子郵件與交易型電子郵件，均會受制於由 HubSpot 管理的可變網域。此機制可自動偵測並移除您的未驗證網域，同時不會取消寄送。此流程可能會對收件者與您電子郵件的互動產生負面影響。

例如，若您嘗試從未經驗證的網域（例如 user@yourcompany.com，HubSpot 會將電子郵件地址修改為使用 HubSpot 管理的網域（例如hs-domain.com ），因此最終的寄件地址將顯示為：user=yourcompany.com@hs-domain.com 。

進一步了解如何檢查您的自動化電子郵件，以確認是否需要經過驗證的「發件人」地址。

對您的 HubSpot 帳戶的影響

雖然透過 HubSpot 發送電子郵件時，DKIM、SPF 和 DMARC 並非嚴格必要，但在您透過設定 DKIM 將該網域連結至 HubSpot 之前，您將無法在「寄件者」地址中使用您的網域（例如user@company.com）來發送電子郵件。此舉亦將提升該網域的電子郵件送達率。

若您的帳戶中未將某個網域設定為電子郵件發送網域，該網域將被修改為由 HubSpot 託管的系統網域。

對電子郵件表現的影響

大多數收件匣服務供應商傾向接受經 DKIM 驗證的電子郵件。未經 DKIM 驗證的電子郵件更容易被退件、隔離或歸類為垃圾郵件。被隔離的電子郵件在 HubSpot 中會顯示為已送達，但大多數收件人將無法看到，因此強烈建議您設定 DKIM 以提升送達率。

請注意：部分收件匣服務供應商（例如Google 和 Yahoo）將要求任何向其用戶發送大量電子郵件的網域，必須完整設定 DMARC、DKIM 和 SPF。若您未符合這些要求，來自您網域的電子郵件將會被退件。這些退件將被歸類為DMARC或政策退件 。

DKIM 指南

DKIM（DomainKeys Identified Mail）是一種電子郵件驗證方法，旨在防止電子郵件偽造——這是一種惡意行為者用來發送偽造發件人地址電子郵件的技術。

要在 HubSpot 中設定 DKIM，系統將引導您透過 DNS 服務供應商中的兩個 CNAME 記錄來完成設定。 一旦您使用 HubSpot 提供的公鑰在 DNS 服務商處配置好 DKIM 記錄，收件郵件伺服器（例如 Gmail）便能驗證您所發送電子郵件中與您的網域相關聯的簽名。

請參閱本文中的說明，了解如何新增這些記錄。

當您新增這些 DNS 記錄，並經由 HubSpot 和您的 DNS 服務供應商驗證後，DKIM 簽名將會包含在您所發送電子郵件的標頭中，並與您所設定的相關 CNAME 條目相互對應。

SPF 指南

SPF（發件人政策框架）是一種電子郵件驗證標準，用於確認發件郵件伺服器是否獲授權代表特定網域發送電子郵件。

傳統上，SPF 必須設定於信封回傳路徑網域（即退信將被發送至的地址）。對於透過 HubSpot 共用伺服器發送的行銷電子郵件，HubSpot 已預先完成此設定。所有專用 IP 客戶均須在初始 IP 設定過程中，於其信封回傳路徑網域上配置 SPF。

此外，我們強烈建議您將 HubSpot 的 SPF 記錄新增至您的「寄件者地址」網域。您需透過 DNS 服務供應商將此記錄設定為 TXT 記錄，並使用 HubSpot 網域設定中提供的值。此記錄將提供一份定期更新的 IP 位址清單，HubSpot 會使用這些 IP 位址從您的「寄件者地址」網域發送行銷電子郵件。

您可以參照這份指南，將 HubSpot 加入您的 SPF 記錄中。

一旦您新增了 SPF 記錄且驗證流程完成，當電子郵件伺服器處理您發送的電子郵件時，即可驗證 HubSpot 是否已列入您網域的有效寄件者白名單中。

DMARC 指南

DMARC（基於網域的訊息驗證、通報與符合性）是一種電子郵件驗證協定，可進一步保護電子郵件網域擁有者免受電子郵件偽造及其他未經授權使用其網域的行為侵害。

透過設定 DMARC 記錄，收件匣服務提供商便能確認應如何處理任何未通過 SPF 和 DKIM 檢查、且來自您網域的電子郵件。DMARC 同時也提供報告機制，讓網域擁有者能夠了解全球各地的收件伺服器接收來自其網域的電子郵件頻率，以及其中經過正確驗證的比例。

請參閱以下各節，進一步了解可用的政策值及幾個政策範例。當您準備好設定 DMARC 記錄時，請參閱本文中的操作說明。

政策值

您可透過在 DNS 服務供應商的設定中新增 TXT 記錄來定義 DMARC 政策，其值可包含以下以分號分隔的屬性：

• v：DMARC 版本。
• p：政策類型，用以決定如何處理未通過驗證的電子郵件。政策可設定為以下其中一種類型：
  
  • none：用於收集回饋並掌握電子郵件流量狀況，同時不影響現有流量。
  • quarantine：將 未通過驗證的電子郵件過濾 至收件者的隔離區。
  • reject：將未通過驗證的電子郵件退回。
• sp：用於 將政策套用至 DMARC 記錄的子網域。
• pct：將此政策套用至總獨特發送量中未能通過驗證的電子郵件所佔的百分比。例如，若您的 DMARC 記錄包含p=reject; pct=25 ，且有 100 封電子郵件未能通過驗證，其中僅有 25 封會被退回，其餘 75 封則會送達收件人手中。
  
  • 設定此屬性有助於逐步調整您的驗證政策，以確保其運作符合預期。
  • 請注意，某些收件匣服務提供商有時會忽略此參數。
• ruf 與 rua：兩個 可選參數，用於指定接收 DMARC 報告資料的電子郵件地址。這些地址必須以 URI mailto 格式提供（例如：mailto:reporting@example.com ）。所傳送的報告資料會根據參數的不同而有所差異：
  • rua： 您整個網域流量的彙總報告 。
  • ruf：包含未通過驗證之個別郵件經刪除敏感資訊後的副本的失敗報告資料。
• adkim 與 aspf：指定 DKIM 和 SPF 的對齊模式。這兩者都應設定為r（即寬鬆對齊）。對於 DNS 服務而言，寬鬆對齊應為 DMARC 的預設設定。

一旦您在 DNS 服務供應商處新增並驗證了 DMARC 記錄，所有接收電子郵件伺服器便能驗證來自您網域的來信，並根據您指定的政策處理任何驗證失敗的情況。

政策範例

您可以根據業務需求自訂 DMARC 政策。以下提供幾個範例：

中立政策

v=DMARC1; p=none;

此為未包含任何額外參數的中立型 DMARC 政策範例。中立政策適用於剛開始熟悉 DMARC 的寄件者，這是 DMARC 運作所需的最低限度設定。

嚴格政策搭配彙總報告

v=DMARC1; p=reject; rua=mailto:reporting@example.com;

上述範例定義了一項嚴格的 DMARC 政策，會將任何驗證失敗的電子郵件退回，並提供一個電子郵件地址以接收彙總報告資料。

帶有失敗報告的隔離政策

v=DMARC1; p=quarantine; pct=25; ruf=mailto:reporting@example.com;

此範例定義的政策會將 25% 未通過驗證的電子郵件隔離，其餘 75% 未通過驗證的電子郵件則允許送達。該政策同時提供一個報告地址，系統會針對每封未通過驗證的電子郵件，分別發送一封個別通知電子郵件至該地址。

為 `pct ` 屬性設定數值，可讓您對未通過 DMARC 驗證的郵件進行隨機抽樣測試，藉此確認合法電子郵件是否仍能正常送達。

請注意：HubSpot 支援團隊無法協助設定 DMARC 記錄。您所設定的 DMARC 政策須依據您的企業需求及 DNS 服務供應商而定。您應諮詢您的 IT 管理員或負責管理 DNS 設定的人員，以獲取 DMARC 設定的協助。您亦可諮詢第三方 DMARC 諮詢或報告服務以獲得進一步協助。

MX 指南

MX（郵件交換器）記錄是 DNS 條目，用於指定哪些郵件伺服器有權接收特定網域的電子郵件。雖然 MX 記錄主要與收件相關，但也會影響郵件發送。

設定為MX 0 . 的空值 MX 記錄，會告知接收郵件伺服器您的網域不接受傳入郵件。部分收件匣服務供應商會拒絕來自具有空值 MX 記錄網域的電子郵件。當此情況發生時，電子郵件可能會因永久性失敗而退件，進而影響您的發送聲譽。

如果您正在使用自訂發送網域或子網域透過 HubSpot 發送行銷電子郵件，請使用 DNS 查詢工具（例如MXToolbox）檢查您網域的 MX 記錄。

• 建議從您的網域中移除空值 MX 記錄（MX 0 .）。
• 若該網域僅用於發送郵件，且您不希望接收來信，請將 MX 記錄設為未設定，而非發布 null MX 記錄。未設定 MX 記錄所帶來的電子郵件拒收風險，並不如 null MX 記錄那般高。