İletişim formu mailleri yeni hostingte neden gitmez?

Yeni bir sunucuya taşındıktan sonra iletişim formundan gönderilen mesajların gelmemesi, çoğu zaman form eklentisinin bozulduğu anlamına gelmez. Sorun genellikle e-posta gönderim yöntemi, DNS kayıtları, SPF/DKIM doğrulaması, SMTP ayarı veya sunucu tarafındaki güvenlik kısıtlamalarıyla ilgilidir. Özellikle WordPress sitelerde form gönderimi başarılı görünse bile mesajlar alıcı kutusuna hiç ulaşmayabilir ya da spam klasörüne düşebilir.

Bu durum kurumsal web siteleri için kritik bir kayıp yaratır. Teklif talepleri, destek başvuruları veya müşteri mesajları fark edilmeden kaybolabilir. Bu nedenle problemi yalnızca “form çalışıyor mu?” seviyesinde değil, hosting değişimi sonrası e-posta teslim sürecinin tamamı üzerinden değerlendirmek gerekir.

Yeni sunucuda iletişim formu mailleri neden gitmez?

WordPress iletişim formları çoğunlukla PHP mail fonksiyonunu kullanarak gönderim yapar. Ancak birçok yeni sunucu, kötüye kullanımı önlemek için bu yöntemi sınırlar veya tamamen devre dışı bırakır. Eski ortamda çalışan yapı, yeni ortamda aynı şekilde çalışmayabilir.

Ayrıca web sitesi taşınırken dosyalar doğru aktarılmış olsa bile DNS ve e-posta doğrulama kayıtları eksik kalabilir. Bu durumda form gönderimi teknik olarak yapılır; fakat alıcı e-posta sunucusu mesajı güvenilir bulmadığı için kabul etmeyebilir.

En sık görülen teknik nedenler

PHP mail fonksiyonunun kapalı veya kısıtlı olması

Bazı sunucularda PHP mail fonksiyonu güvenlik politikaları nedeniyle kapalıdır. Açık olsa bile saatlik gönderim limiti, kimlik doğrulama zorunluluğu veya şüpheli içerik filtresi nedeniyle mesajlar engellenebilir. Form eklentisinde “mesaj gönderildi” uyarısı görünmesi, e-postanın gerçekten teslim edildiğini garanti etmez.

SMTP ayarının yapılmamış olması

Kurumsal sitelerde en sağlıklı yöntem, iletişim formu maillerini doğrulanmış SMTP hesabı üzerinden göndermektir. SMTP; kullanıcı adı, parola, port ve şifreleme yöntemiyle kimlik doğrulaması yapar. Bu sayede mesajlar alıcı sunucular tarafından daha güvenilir algılanır.

Yeni hosting ortamında SMTP bilgileri değişmiş olabilir. Eski sunucudaki mail adresi, yeni sunucuda tanımlı değilse veya parola güncellenmediyse gönderim başarısız olur. Özellikle 465 SSL ve 587 TLS portları karıştırıldığında bağlantı hatası alınabilir.

SPF, DKIM ve DMARC kayıtlarının eksik olması

Alan adınız adına e-posta gönderen sunucunun yetkili olduğunu göstermek için SPF kaydı gerekir. DKIM ise gönderilen mesajın değiştirilmediğini doğrular. DMARC, bu iki kontrol başarısız olduğunda alıcı sunucunun nasıl davranacağını belirler.

Taşıma sonrası DNS kayıtları yeni IP adresine göre güncellenmediyse, form mailleri özellikle Gmail, Outlook ve kurumsal mail sistemleri tarafından reddedilebilir. Bu nedenle yalnızca A kaydını değiştirmek yeterli değildir; e-posta teslim edilebilirliği için doğrulama kayıtları da kontrol edilmelidir.

Form eklentisi tarafında kontrol edilmesi gerekenler

Contact Form 7, WPForms, Elementor Forms veya benzeri eklentilerde gönderici adresi kritik öneme sahiptir. “From” alanında Gmail, Hotmail veya farklı bir domain kullanmak çoğu zaman sorun çıkarır. En doğru yaklaşım, alan adınızla aynı uzantıya sahip bir adres kullanmaktır.

Örneğin site adresiniz example.com ise gönderici adresi [email protected] gibi tanımlanmalıdır. Ziyaretçinin e-posta adresi ise “Reply-To” alanında kullanılmalıdır. Böylece mesaj alan adı adına doğru şekilde gönderilir, siz de yanıt verirken ziyaretçiye ulaşabilirsiniz.

Yanlış yapılandırma örneği

Birçok sitede formun gönderici alanına ziyaretçinin yazdığı e-posta adresi atanır. Bu yapı geçmişte çalışıyor gibi görünse de modern e-posta güvenliği açısından risklidir. Çünkü sunucu, kendisine ait olmayan bir alan adı adına mail göndermeye çalışır ve bu durum sahtecilik şüphesi doğurur.

Sunucu ve güvenlik filtreleri nasıl kontrol edilir?

İlk adım, form eklentisinin hata günlüğünü veya WordPress SMTP eklentisinin test gönderim sonucunu incelemektir. Test maili başarısız oluyorsa hata kodu genellikle problemi işaret eder. Kimlik doğrulama hatası, port engeli, SSL problemi veya alıcı reddi gibi bilgiler burada görülebilir.

Sunucu tarafında mail loglarına erişiminiz varsa gönderimin gerçekten yapılıp yapılmadığını görebilirsiniz. Paylaşımlı paketlerde bu erişim kısıtlı olabilir; bu durumda servis sağlayıcıdan belirli saat aralığı ve alıcı adres bilgisiyle log kontrolü istenmelidir.

Taşıma sonrası hızlı kontrol listesi

• Alan adına ait e-posta hesabının yeni sunucuda tanımlı olduğundan emin olun.
• Formdaki gönderici adresini alan adınızla uyumlu hale getirin.
• SMTP bağlantısını doğru port ve şifreleme yöntemiyle test edin.
• SPF, DKIM ve DMARC kayıtlarını DNS üzerinde doğrulayın.
• Spam klasörünü, mail kuyruğunu ve hata loglarını kontrol edin.
• Form eklentisi bildirim alıcısının doğru yazıldığını kontrol edin.

Ne zaman profesyonel destek alınmalı?

DNS kayıtları doğru görünmesine rağmen mailler hâlâ ulaşmıyorsa, problem sunucu itibarı, IP kara liste durumu, güvenlik duvarı veya mail servis sağlayıcısı politikalarıyla ilgili olabilir. Bu aşamada rastgele ayar değiştirmek yerine mevcut yapı kayıt altına alınmalı ve adım adım test edilmelidir.

Kurumsal web sitelerinde iletişim formlarının düzenli test edilmesi de önemlidir. Taşıma, tema güncellemesi, eklenti değişimi veya DNS düzenlemesi sonrasında test mesajı gönderilmeli; hem teslimat hem de yanıtlanabilirlik kontrol edilmelidir. Böylece ziyaretçi mesajlarının görünmeden kaybolması önlenir ve yeni sunucu geçişi daha güvenli yönetilir.