關於本影片

文件驗證需要付費帳號。BillionVerify 與 Apple 沒有關聯，也未獲其認可。

影片文字稿

1. 00:00你看到了什麼

   你的 iCloud 地址回傳了未知。不是有效，也不是無效。下面說明這個結果的含義，以及如何處理這些聯絡人。有三個 Apple 域名是這樣的行為：icloud.com、me.com 和 mac.com。每一個都回傳狀態「未知」，原因是 smtp_unverifiable。「未知」並不對這個地址作任何斷言。它很可能是個正常工作的收件箱，只是我們兩邊都沒有證據。

2. 00:29為什麼會這樣

   大多數郵件伺服器在你指明收件人時會給出可用的回覆。在這三個域名上，Apple 的伺服器沒有給出我們能依賴的訊號。所以基於那個回覆得出的任何結論都只是猜測。因此我們不去問。檢查會依次經過語法、一次性、標籤和 DNS，然後停在策略層。這些地址不會建立 SMTP 連接。更早的層級仍然可以作出判定。地址格式有誤的，即使在 iCloud 上也是無效。個人姓名是未知。像 info 這樣的角色名也是未知，因為檢查在角色判定生效之前就停了。

3. 01:03在哪裡找到原因

   在控制台裡，單次檢查顯示「未知狀態」。原因代碼不在那張卡片上。要看到它，可以開啟文件任務的即時結果，下載結果文件，或者讀取 API 回應。在結果文件裡，篩選 ev_status 和 ev_reason，再看 ev_domain。三者缺一不可，因為這個原因代碼也可能出現在其他域名上，由其他原因造成。再次驗證這些地址不會有任何變化。API 把這個原因標記為不可重試。沒有相關設定，傳入 check_smtp: true 也沒用，因為策略層在前。這些結果不收費。「未知」從不消耗積分，不管你的文件裡有多少 iCloud 地址。有一個例外很重要。這條規則只適用於 Apple 自己的域名。轉寄到 iCloud 的自定義域名會得到正常的 SMTP 檢查，所以可能回傳明確的結果。

4. 01:55如何處理

   那這些聯絡人怎麼處理？我們幫助中心的建議是：把它們當作未確認，但很可能可以傳送。不要僅僅因為顯示「未知」就刪掉。把它們留在你的傳送裡，讓真實的郵件來回答這個問題。如果沒有退信，就繼續給這個聯絡人發。如果出現硬退信，就移除這個地址。格式有誤的，在開始前先剔除。這是確認 iCloud 地址最穩妥的方式：正常傳送，同時開啟退信報告。然後根據實際發生的情況更新你的名單。查看域名，查看原因。保留地址，讓退信來定論。

5. 02:32免費開始

   每天使用帳號可獲得 20 個免費積分，每月最多 600 個，無需信用卡。造訪 billionverify.com 開始使用。

本影片中展示的工具