İletişim Formu E-postaları Spam'a Düşüyor — Web Sunucusu Gönderici Sorunu ve Çözümü (2026)

Yayımlanma 2026-07-08

Veriler 2026-06-29 itibarıyla · metodoloji v7. 261 milyon derecelendirilmiş alan adı genelinde toplu sayım verileri. Bkz. nasıl derecelendiriyoruz.

İletişim formu ve web sitesi e-postaları spam’a düşüyor çünkü web sunucunuz bunları kimlik doğrulamasız gönderiyor — ne SPF yetkisi ne de DKIM imzası var. Güvenilir çözüm, sunucuyu beyaz listeye almak değil, postaları kimliği doğrulanmış SMTP üzerinden yönlendirmektir. Defaults.Exposed sayımında derecelendirilen 261,086,232 alan adının (veri: 2026-06-29) 46.4%‘i hiç SPF kaydı yayımlamıyor.

Çözüm sırası önemlidir ve çoğu kılavuz bunu tersine anlatır. Alan adınızın gerçekte ne yayımladığını görmek için ücretsiz bir tarama yapın; kimlik doğrulamasız SMTP yerine kimliği doğrulanmış SMTP (posta kutusu sağlayıcınız veya işlemsel e-posta hizmeti) üzerinden site postasını yönlendirin, böylece gerçek bir DKIM imzası elde edin; formun Kimden adresini düzeltin ve yalnızca son çare olarak sunucunun IP adresini SPF’ye ekleyin.

Web sitemi e-postalar neden spam’a düşüyor?

Gerçekte kimin gönderdiği sorunundandır. Bir ziyaretçi iletişim formunuzu gönderdiğinde, e-posta posta sağlayıcınız tarafından değil, web sunucusunun kendisi tarafından — genellikle PHP’nin mail() işlevi aracılığıyla — oluşturulur. Alıcı taraftan bakıldığında bu mesaj:

SPF kaydınızın yetkilendirmediği bir IP’den geliyor (SPF kaydınız posta sağlayıcınızı kapsıyor, web barındırıcınızı değil);
DKIM imzası taşımıyor, dolayısıyla hiçbir şey alan adınızla kriptografik olarak bağlı değil;
çoğunlukla yüzlerce yabancı sitenin paylaştığı ortak barındırma IP’sinden çıkıyor.

Karışık itibarı olan bir IP’den gelen kimlik doğrulamasız posta, spam filtrelerinin tam olarak yakalamak için var olduğu şeydir — Gmail ve Outlook, siz olduğunu iddia eden rastgele bir sunucu görür. Genel tablo karamsar: alan adlarının 46.4%‘i hiç SPF yayımlamıyor ve yalnızca 10.59% (2026-06-29 itibarıyla 261,086,232 derecelendirilmiş alan adının 27,640,987‘i) bir DMARC politikası uyguluyor.

Bu neden özellikle WordPress sitelerini etkiliyor?

WordPress, tüm e-postalarını — form bildirimleri, şifre sıfırlamaları, sipariş onayları — web sunucusundaki PHP mail() işlevini varsayılan olarak sarmalayan tek bir işlev olan wp_mail() aracılığıyla gönderir. Kasıtlı olarak yeniden yapılandırılmamış her WordPress sitesi, kutudan çıktığı haliyle kimlik doğrulamasız bir göndericidir. Form eklentileri (Contact Form 7, WPForms, Gravity Forms) postayı aynı işleve iletir: bir eklenti sorunu gibi görünür ama aslında bir aktarım sorunudur.

Çözüm, farklı bir form eklentisi değil, SMTP eklentisidir (WP Mail SMTP ve benzerleri); bu eklenti, wp_mail() üzerinden gönderilen her şeyi gerçek, kimliği doğrulanmış bir posta hesabına yönlendirir — SPF’nizin zaten yetkilendirdiği, DKIM imzalı altyapı.

Site hangi gönderme yöntemini kullanmalı?

Gönderme yöntemi	SPF	DKIM	Barındırıcı göçünden sağ çıkır mı?	Karar
Web kutusundan PHP `mail()` / varsayılan `wp_mail()`	başarısız	yok	yok — her yerde bozuk	sorun, seçenek değil
Posta kutusu sağlayıcısı (Google Workspace, Microsoft 365 vb.) üzerinden kimliği doğrulanmış SMTP	geçer	imzalı	evet — barındırmadan bağımsız	çoğu site için çözüm
Alan adınız doğrulanmış işlemsel e-posta hizmeti (SES, Postmark, Brevo vb.)	geçer	imzalı	evet	yüksek hacimde çözüm (e-ticaret, yoğun formlar)
Sunucunun IP’si SPF kaydınıza eklenir	geçer (yalnızca SPF)	yok	hayır — IP değiştiğinde sessizce bozulur	yalnızca geri çekilme yolu — aşağıya bakın

Günde birkaç bildirim için zaten ödediğiniz posta kutusundan SMTP en kısa yoldur; gerçek hacimde işlemsel hizmet bunun için tasarlanmıştır. Her ikisi de DKIM sağlar — IP beyaz listeye alma kısayolu hiçbir zaman vermez.

İletişim formu e-posta teslimini nasıl düzeltirim?

Herhangi bir şeye dokunmadan önce defaults.exposed üzerinden ücretsiz taramayı çalıştırın. Alan adınızın gerçekte ne yayımladığını gösterir — formun aktarımını, eksik bir kaydı veya her ikisini birden düzeltip düzeltmediğinizi anlarsınız. Hiç SPF yok mu? SPF nasıl düzeltilir kılavuzundan başlayın.
Site için özel bir SMTP kimliği oluşturun — örneğin posta kutusu sağlayıcınızda [email protected] veya işlemsel bir hizmette doğrulanmış gönderici alan adı. Bir kişinin posta kutusu şifresi değil, geri alınabilir bir uygulama şifresi veya API anahtarı kullanın.
Sitenin postasını bu kimlik üzerinden yönlendirin. WordPress: bir SMTP eklentisi kurup o hesaba yönlendirin. Diğer altyapılar: yerel mail() yerine çerçevenin posta gönderici ayarını yapılandırın.
Kimden adresini düzeltin (aşağıdaki anti-kalıp): Kimden kendi alan adınız olmalıdır; ziyaretçi Yanıtla alanına gider.
Gönderen işlemsel bir hizmetse DKIM kayıtlarını ekleyin (genellikle bir çift CNAME) — postanın alan adınızla imzalanması için — DNS adımları SPF kurulum kılavuzlarını taklit eder.
Test gönderimi yapın ve yeniden tarayın. Başlıklar kendi alan adınız için spf=pass ve dkim=pass göstermelidir; ardından SPF düzelt ve DKIM düzelt üzerinden taramanın işaretlediği diğer sorunları çözün.

Form neden ziyaretçinin e-posta adresinden “gönderilmiş” görünüyor?

Form yapılandırmasındaki en yaygın öz kaynaklı yara; pek çok eklenti bunu eskiden varsayılan olarak yapıyordu: bildirim Kimden: ziyaretçinin adresi olarak geliyor, böylece yanıtlayabiliyorsunuz. Kullanışlı hissettiriyor — ama bu sahtekârlık. Sunucunuzun [email protected] adına posta gönderme hakkı yok — gmail.com için SPF ve DKIM’ı başarısız kılıyor ve Gmail’in DMARC politikası alıcılara bunu çöpe atmalarını ya da reddetmelerini söylüyor. Çözüm hiçbir şeye mal olmaz:

Kimden: kendi alan adınızdan bir adres (2. adımdaki SMTP kimliği)
Yanıtla: ziyaretçinin adresi — yanıt yine doğrudan onlara gider

Her ana akım form eklentisi bunu destekler; bildirim ayarlarında iki alandır.

Sunucunun IP’sini neden SPF kaydıma eklememeliyim?

Çoğu forum başlığının ilk önce başvurduğu düzeltmedir ve bunun bir nedeni var: geri çekilme yolu. SPF’ye ip4:<sunucu> (veya web barındırıcınız için a mekanizması) eklemek ham denetimi geçirir — ama:

Paylaşımlı barındırmada yabancıları yetkilendirir. IP kutuya ait, size değil; o sunucudaki diğer her site artık alan adınız adına SPF geçiren posta gönderebilir.
Sessizce bozulur. Barındırıcılar sizi haberdar etmeden sunucuları ve IP’leri değiştirir; SPF’niz aylarca önce terk ettiğiniz bir adresi yetkilendirmeye devam eder.
DKIM vermez. Yalnızca SPF, yönlendirme altında bozulur ve imzanın yapabileceği şekilde DMARC zorlamasına taşımanıza yardımcı olamaz.

Bu yolu gerçekten kısıtlı durum için saklayın: kontrol ettiğiniz statik IP’ye sahip özel bir sunucu ve SMTP konuşamayan bir uygulama — mümkünse kutu üzerinde DKIM imzalamayla birleştirin.

SPF, formumun “Kimden” alanına koyduğum adresi kontrol eder mi?

Hayır — ve bu, tüm DIY teşhislerin yarısını tökezletiyor. Alıcılar SPF’yi Kimden başlığına değil, Return-Path (RFC5321.MailFrom) alan adına karşı değerlendirir. Web sunucuları genellikle Return-Path üzerine kendi ana bilgisayar adlarını damgalar; dolayısıyla SPF kaydınıza hiç bakılmadı — alıcı srv0421.examplehost.com için SPF kontrol etti. Kimliği doğrulanmış SMTP bunu da çözer: Return-Path alan adınız olur, böylece SPF geçişi nihayet sizin için sayılır. DKIM’ın neden önemli olduğu da budur — DMARC hizalaması, Kimden alanındaki alan adına bağlı bir geçiş gerektirir ve DKIM imzası mesajla birlikte taşınır.

Sık sorulan sorular

Bir SMTP eklentisi şifre sıfırlama ve WooCommerce e-postalarını da düzeltir mi? Evet. WordPress’te her şey wp_mail() üzerinden geçer; dolayısıyla yeniden yönlendirmek form bildirimlerini, şifre sıfırlamalarını ve sipariş e-postalarını tek hamlede düzeltir.

SMTP eklentisi kullanırsam hâlâ SPF ve DKIM kayıtlarına ihtiyacım var mı? Evet — eklenti hangi altyapının postanızı gönderdiğini değiştirir; kayıtlar onu yetkilendiren şeydir. Alan adınız 261,086,232 derecelendirilmiş alan adının 46.4%‘i arasında (sayım, 2026-06-29) hiç SPF kaydı olmadan yer alıyorsa, kimliği doğrulanmış SMTP tek başına sizi kurtaramaz. Yeni alan adı e-posta kontrol listesi tam kayıt setini kapsar.

Form e-postalarım SPF’yi geçiyor ama hâlâ DMARC’ı başarısız kılıyor — neden? Neredeyse her zaman yukarıdaki Kimden sahtekârlığı anti-kalıbı ya da SPF’nin sizin alan adınız yerine barındırıcının Return-Path alan adı için geçmesidir. Önce Kimden/Yanıtla’yı düzeltin; hâlâ başarısızsa eksik parça hizalanmış bir DKIM imzasıdır — bkz. “DKIM imzası geçerli değil”. Web sitesinin ötesinde SaaS araçları da başarısız oluyorsa, SaaS için SPF başarısız kılavuzu çözüm sırasını kapsar.

Az trafikli bir iletişim formu için tüm bunlar değer mi? Form genellikle paranın girdiği yerdir — kaçırılan bir sorgulama, hiç tanımadığınız bir müşteridir. Ve çözüm ücretsizdir; engel, web sunucusunun başından beri kimlik doğrulamasız gönderici olduğunu bilmemekti.

Raporu sahibine gönderin

Geliştirici veya müteahhit olarak bunu düzeltiyorsanız: test gönderimi geçtiğinde ücretsiz taramayı yeniden çalıştırın ve derecelendirilmiş raporu sitenin sahibine iletin — alan adının doğru kimlik doğrulama yaptığına dair tarihli, açık dilli bir kayıt ve bir sonraki siber sigorta yenilemesinde veya müşteri güvenlik anketinde ihtiyaç duyacakları belge. Sorgulama durduğu için bunu okuyan sahipseniz: bu sayfayı ve tarama raporunuzu web sitenizi yöneten kişiye gönderin — gösterebilecekleri öncesi ve sonrası olan yarım günlük bir iş.

Alan adınızı kontrol edin → · SaaS araçlarınız için SPF başarısız mı? → · SPF düzelt → · Nasıl derecelendiriyoruz → · Yalnızca toplu veriler. Veriler AB’de depolanır ve işlenir.