共用方式為

Azure 通訊服務電子郵件中的寄件者驗證支援最佳做法

  • 發行項

本文會提供 DNS 記錄的電子郵件傳送最佳做法，以及如何使用寄件者驗證方法，協助防止攻擊者傳送看起來像來自您網域的郵件。

電子郵件驗證和 DNS 設定

傳送電子郵件需要數個步驟，包括驗證電子郵件的寄件者實際擁有網域、檢查網域信譽、病毒掃描、垃圾郵件篩選、網路釣魚嘗試、惡意代碼等。設定適當的電子郵件驗證是建立電子郵件信任並保護您的網域信譽的基本原則。 如果電子郵件通過驗證檢查，接收網域可以將原則套用至該電子郵件，以符合與這些驗證檢查相關聯的身分識別信譽，而且收件者可以確保這些身分識別有效。

MX (郵件交換) 記錄

MX (郵件交換) 記錄可用來將電子郵件路由傳送至正確的伺服器。 它會指定負責代表您網域接受電子郵件訊息的郵件伺服器。 DNS 必須以您電子郵件網域 MX 記錄的最新資訊進行更新，否則會導致某些傳遞失敗。

SPF (寄件者原則架構)

SPF RFC 7208 是一種機制，可讓網域擁有者透過標準 DNS TXT 記錄發佈和維護，這是授權代表他們傳送電子郵件的系統清單。 此記錄可用來指定哪些郵件伺服器有權代表您的網域傳送電子郵件。 這有助於防止電子郵件詐騙，並增加電子郵件傳遞能力。

DKIM (網域金鑰已識別的郵件)

DKIM RFC 6376 可讓組織宣告以收件者可驗證的方式傳輸郵件的責任 此記錄也可用來驗證電子郵件傳送的來源網域，並協助防止電子郵件詐騙並增加電子郵件傳遞能力。

DMARC (網域型訊息驗證、報告和一致性)

DMARC RFC 7489 是可調整的機制，郵件來源組織可以表達郵件驗證、處置和報告郵件接收組織可用來改善郵件處理的網域層級原則和喜好設定。 它也可用來指定電子郵件接收者如何處理 SPF 和 DKIM 檢查失敗的郵件。 這可改善電子郵件傳遞能力，並有助於防止電子郵件詐騙。

ARC (已驗證的接收鏈結)

ARC 通訊協定 RFC 8617 會為訊息提供經過驗證的監管鏈，讓每個處理訊息的實體識別先前處理的實體，以及每個躍點的訊息驗證評估。 ARC 還不是網際網路標準，但已經增加採用此方法。

電子郵件驗證的運作方式

電子郵件驗證會驗證寄件者的電子郵件訊息 (例如，notification@contoso.com) 是合法的，而且來自該電子郵件網域的預期來源 (例如 contoso.com)。電子郵件訊息可能包含多個發源者或寄件者位址。 這些地址可用於不同用途。 例如以下地址：

  • 郵件寄件者位址會識別寄件者，並指定如果郵件傳遞發生任何問題，例如非傳遞通知，則傳送傳回通知的位置。 這會出現在電子郵件訊息的信封部分，而且您的電子郵件應用程式不會顯示。 這有時稱為 5321.MailFrom 位址或反向路徑位址。

  • 寄件者位址是您的郵件應用程式顯示為寄件者位址的位址。 此地址可識別電子郵件的作者。 也就是說，是負責撰寫郵件的人員或負責的系統信箱。 這有時稱為 5322.From 位址。

  • 寄件者原則架構 (SPF) 可協助驗證從網域傳送的郵件所傳送的輸出電子郵件，(來自發言者)。

  • DomainKeys 已識別的郵件 (DKIM) 有助於確保目的地電子郵件系統信任從網域寄出的郵件。

  • 網域型郵件驗證、報告和一致性 (DMARC) 可與寄件者原則架構搭配運作，(SPF) 和 DomainKeys 識別的郵件 (DKIM)，以驗證郵件寄件者，並確保目的地電子郵件系統信任從網域傳送的郵件。

實作 DMARC

使用 SPF 和 DKIM 實作 DMARC 可針對詐騙和網路釣魚電子郵件提供豐富的保護。 SPF 會針對指定的網域使用 DNS TXT 記錄來提供授權的傳送 IP 位址清單。 一般而言，SPF 檢查只會針對 5321.MailFrom 地址執行。 這表示當您單獨使用 SPF 時，不會驗證 5322.From 位址。 這可讓使用者可以接收訊息的案例，該訊息通過 SPF 檢查，但有詐騙的 5322.From 寄件者位址。

如同 SPF 的 DNS 記錄，DMARC 的記錄是 DNS 文字 (TXT) 記錄，其有助於防止詐騙和網路釣魚。 您在 DNS 中發佈 DMARC TXT 記錄。 DMARC TXT 記錄會根據傳送網域的擁有者驗證電子郵件作者的 IP 位址，以驗證電子郵件的來源。 DMARC TXT 記錄可識別已獲授權的輸出電子郵件伺服器。 目的地電子郵件系統接著會驗證收到的郵件是否來自於已獲授權的輸出電子郵件伺服器。 這會強制 5321.MailFrom 與來自您網域的所有電子郵件中 5322.From 位址不符，而 DMARC 會針對該電子郵件失敗。 若要避免這種情況，您必須為網域設定 DKIM。

DMARC 原則記錄可讓網域宣告其電子郵件使用驗證；提供電子郵件地址來收集其網域使用意見反應；和會針對未通過驗證檢查的訊息處理指定要求的原則。 我們的建議如下

  • 如果可能的話，發佈 DMARC 記錄的 Policy 陳述式會是「p=reject」，否則為「p=quarantine」。
  • 「p=none」、「sp=none」 和 pct100 < 的 Policy 陳述式聲明應該只視為過渡狀態，而目標是能儘快移除。
  • 任何已發佈的 DMARC 原則記錄都應該至少包含「rua」標籤，指向接收 DMARC 彙總報告的信箱，而且在因隱私權考慮而接收報告時，不應傳回任何回復。

下一步

您可能會對下列文件感興趣：