PHP郵件函數無法完成電子郵件的傳送
P粉684720851
2023-08-23 19:27:00
<p><br /></p>
<pre class="brush:php;toolbar:false;"><?php
$name = $_POST['name'];
$email = $_POST['email'];
$message = $_POST['message'];
$from = 'From: yoursite.com';
$to = 'contact@yoursite.com';
$subject = 'Customer Inquiry';
$body = "From: $namen E-Mail: $emailn Message:n $message";
if ($_POST['submit']) {
if (mail ($to, $subject, $body, $from)) {
echo '<p>Your message 有 been sent!</p>';
} else {
echo '<p>Something went wrong, go back and try again!</p>';
}
}
?></pre>
<p>我嘗試建立一個簡單的郵件表單。表單本身位於我的<code>index.html</code> 頁面上,但它提交到一個單獨的“謝謝您的提交”頁面<code>thankyou.php</code>,其中上面的PHP 代碼是嵌入的。
程式碼完美提交,但從未發送電子郵件。我該如何解決這個問題? </p>
儘管此答案的某些部分僅適用於
mail()
函數本身的使用,但其中許多故障排除步驟可以應用於任何 PHP 郵件系統。 嗯>您的腳本未發送電子郵件的原因有很多。除非有明顯的語法錯誤,否則很難診斷這些事情。如果沒有,您需要仔細檢查下面的清單,以查找您可能遇到的任何潛在陷阱。
確保錯誤報告已啟用並設定為報告所有錯誤
錯誤報告對於根除程式碼中的錯誤以及 PHP 遇到的一般錯誤至關重要。需要啟用錯誤報告才能接收這些錯誤。將以下程式碼放在 PHP 檔案的頂部(或主設定檔中)將啟用錯誤報告。
請參閱如何獲得有用的錯誤PHP 中的消息? — 此答案以了解更多詳細資訊。
確保呼叫
mail()
函數這可能看起來很愚蠢,但一個常見的錯誤是忘記在程式碼中實際放置
mail()
函數。確保它在那裡並且沒有被註釋掉。確保正確呼叫
mail()
函數郵件函數採用三個必要參數,以及可選的第四個和第五個參數。如果您對
mail()
的呼叫沒有至少三個參數,它將失敗。如果您對
mail()
的呼叫沒有以正確順序提供正確的參數,它也會失敗。檢查伺服器的郵件日誌
您的網站伺服器應該記錄透過它發送電子郵件的所有嘗試。這些日誌的位置會有所不同(您可能需要詢問伺服器管理員它們的位置),但通常可以在使用者根目錄的
logs
下找到它們。裡面將是伺服器報告的與您嘗試發送電子郵件相關的錯誤訊息(如果有)。檢查連接埠連線是否失敗
連接埠阻止是大多數開發人員在整合程式碼以使用 SMTP 發送電子郵件時面臨的一個非常常見的問題。並且,這可以在伺服器郵件日誌中輕鬆追蹤(郵件日誌伺服器的位置可能因伺服器而異,如上所述)。如果您位於共用主機伺服器上,則預設情況下連接埠 25 和 587 仍處於封鎖狀態。此封鎖是由您的託管提供者故意完成的。即使對於某些專用伺服器也是如此。當這些連接埠被封鎖時,請嘗試使用連接埠 2525 進行連線。如果您發現該連接埠也被阻止,那麼唯一的解決方案就是聯絡您的託管提供者以解除這些連接埠的阻止。
大多數託管提供者都會阻止這些電子郵件端口,以保護其網路免於發送任何垃圾郵件。
使用連接埠 25 或 587 進行普通/TLS 連接,使用連接埠 465 進行 SSL 連接。對於大多數用戶,建議使用連接埠 587 以避免某些託管提供者設定的速率限制。
不要使用錯誤抑制運算子
當錯誤抑制運算子
@
被加入到 PHP 中的表達式之前,該表達式可能產生的任何錯誤訊息都會被忽略。在某些情況下,需要使用此運算符,但發送郵件不是其中之一。如果您的程式碼包含
@mail(...)
,那麼您可能隱藏了有助於您偵錯的重要錯誤訊息。刪除@
並查看是否報告任何錯誤。僅當您使用
error_get_last()
緊接著具體失敗。檢查
mail()
傳回值mail()
函數:這一點值得注意,因為:
FALSE
回傳值,您就知道錯誤在於您的伺服器接受您的郵件。這可能不是編碼問題,而是伺服器配置問題。您需要與系統管理員聯繫以找出發生這種情況的原因。TRUE
傳回值,並不表示您的電子郵件一定會發送。這僅表示電子郵件已透過 PHP 成功傳送到伺服器上對應的處理程序。還有更多 PHP 無法控制的故障點可能導致電子郵件無法傳送。因此,
FALSE
將協助您指明正確的方向,而TRUE
並不一定表示您的電子郵件已成功傳送。值得注意的是!確保您的託管提供者允許您發送電子郵件並且不限制郵件發送
許多共享網站主機,尤其是免費網站主機供應商,要么不允許從其伺服器發送電子郵件,要么限制在任何給定時間段內可以發送的數量。這是因為他們努力限制垃圾郵件發送者利用其更便宜的服務。
如果您認為您的主機有電子郵件限製或阻止發送電子郵件,請查看他們的常見問題解答,看看他們是否列出了任何此類限制。否則,您可能需要聯絡他們的支援人員,以驗證發送電子郵件是否有任何限制。
檢查垃圾郵件資料夾;防止電子郵件被標記為垃圾郵件
通常,由於各種原因,透過 PHP(和其他伺服器端程式語言)發送的電子郵件最終會進入收件者的垃圾郵件資料夾。在對代碼進行故障排除之前,請務必檢查那裡。
為了避免透過PHP 發送的郵件被傳送到收件者的垃圾郵件資料夾,您可以在PHP 程式碼或其他方面執行多種操作,以最大程度地減少電子郵件被標記為垃圾郵件的機會。 Michiel de Mare 提供的好建議包括:
有關此主題的詳細信息,請參閱如何確保以程式設計方式發送的電子郵件不會自動標記為垃圾郵件? 。
確保提供所有郵件標頭
如果郵件缺少「寄件者」和「回覆」等通用標頭,某些垃圾郵件軟體將拒絕郵件:
確保郵件標頭沒有語法錯誤
無效的標頭與沒有標頭一樣糟糕。一個不正確的字元就可能導致您的電子郵件脫軌。請仔細檢查以確保您的語法正確,因為 PHP 不會為您捕獲這些錯誤。
不要使用虛假的
寄件者:
寄件者雖然郵件必須有寄件者:寄件者,但您不能只使用任何值。特別是用戶提供的寄件者地址是阻止郵件的可靠方法:
原因:您的網路或發送郵件伺服器未列入 SPF/DKIM 白名單,無法假裝對 @hotmail 或 @gmail 位址負責。它甚至可能會默默地丟棄帶有未配置的
From:
寄件人域的郵件。確保收件者值正確
有時,問題就像電子郵件收件者的值不正確一樣簡單。這可能是由於使用了不正確的變數。
測試此問題的另一種方法是將收件者值硬編碼到
mail()
函數呼叫中:這可以套用於所有
mail()
參數。傳送到多個帳戶
為了協助排除電子郵件帳戶問題,請將您的電子郵件傳送到不同電子郵件提供者的多個電子郵件帳戶。 。如果您的電子郵件未到達使用者的 Gmail 帳戶,請將相同的電子郵件傳送至 Yahoo 帳戶、Hotmail 帳戶和常規 POP3 帳戶(例如您的 ISP 提供的電子郵件帳戶)。
如果電子郵件到達所有或部分其他電子郵件帳戶,則您知道您的程式碼正在發送電子郵件,但電子郵件帳戶提供者可能出於某種原因阻止了它們。如果電子郵件未到達任何電子郵件帳戶,則問題很可能與您的程式碼有關。
確保程式碼與表單方法符合
如果您已將表單方法設定為
POST
,請確保使用$_POST
來尋找表單值。如果您已將其設定為GET
或根本沒有設置,請確保使用$_GET
來尋找表單值。確保您的表單
action
值指向正確的位置確保您的表單
action
屬性包含指向您的 PHP 郵件程式碼的值。確保網站主機支援發送電子郵件
某些網站寄存供應商不允許或啟用透過其伺服器傳送電子郵件。造成這種情況的原因可能有所不同,但如果他們禁止發送郵件,您將需要使用替代方法,即使用第三方為您發送這些電子郵件。
發送給他們的技術支援的電子郵件(在訪問他們的線上支援或常見問題解答之後)應該澄清您的伺服器上是否可以使用電子郵件功能。
確保已設定
localhost
郵件伺服器如果您使用 WAMP、MAMP 或 XAMPP 在本機工作站上開發,則您的工作站上可能未安裝電子郵件伺服器。如果沒有,PHP 預設無法傳送郵件。
您可以透過安裝基本的郵件伺服器來克服這個問題。對於 Windows,您可以使用免費的 Mercury Mail。
您也可以使用 SMTP 傳送電子郵件。請參閱來自 這個很棒的答案 >Vikas Dwivedi 以了解如何執行此操作。
啟用 PHP 的自訂
mail.log
除了 MTA 和 PHP 的日誌檔案之外,您還可以啟用 專門記錄
mail()
函數。它不記錄完整的SMTP交互,但至少記錄了函數呼叫參數和呼叫腳本。請參閱http://php.net/manual/en/mail.configuration.php 以了解詳細資訊。 (最好在
php.ini
或.user.ini
或.htaccess
中啟用這些選項。)檢查郵件測試服務
您可以使用各種傳送和垃圾郵件檢查服務來測試您的 MTA/網路伺服器設定。通常,您將郵件探測發送到:他們的地址,然後獲取遞送報告和更具體的故障或稍後分析:
使用不同的郵件程式
PHP 的內建
mail()
函數很方便,通常可以完成工作,但它 有其缺點。幸運的是,有一些替代方案可以提供更強大的功能和靈活性,包括處理上述許多問題:所有這些都可以與專業的 SMTP 伺服器/服務提供者結合使用。 (因為典型的 08/15 共享虛擬主機計劃在電子郵件設定/可配置性方面時好時壞。)