İletişim formu çalışmıyor: e-postalar neden ulaşmıyor?

Önce test edin: İleti gerçekten ulaşıyor mu?

Sayfadaki başarı mesajına güvenmeyin. Yolu gelen kutusuna kadar kontrol edin.

1. Yabancı bir adresle doldurunFormu başka bir sağlayıcıdan bir adresle doldurun; örneğin özel bir GMX, WEB.DE ya da Gmail hesabıyla. Alıcı adresinin kendisini kullanmayın: Aksi hâlde gönderen adresindeki hata fark edilmez.
2. Gelen kutusunu ve spam klasörünü kontrol edinEn fazla 15 dakika bekleyin. Gelen kutusuna, spam (istenmeyen e-posta) klasörüne ve varsa karantina ya da filtre klasörlerine bakın.
3. Gönderen doğrulamasına bakınİleti ulaşırsa, iletinin üstbilgisindeki (header) doğrulama sonuçlarına bakın. Gmail’de bunun için “Orijinali göster” (Show original) seçeneğini açın; diğer sağlayıcılar üstbilgiyi (“Header”) benzer adlarla gösterir. Orada SPF, DKIM ve DMARC sonuçları (PASS veya FAIL) yer alır.
4. Gönderirken hata olup olmadığına dikkat edinGöndermeden önce tarayıcının geliştirici araçlarını (F12) ve “Ağ” (Network) sekmesini açın. Gönderim sırasında istek 403, 404 ya da 500 gibi bir durum koduyla başarısız olursa sorun zaten formun kendisindedir.
5. İkinci bir alıcı adresi deneyinDeneme amacıyla başka bir sağlayıcıdan ikinci bir alıcı adresi tanımlayın. İleti orada ulaşıyorsa sorun kendi posta kutunuzda, filtrelerinde ya da yönlendirmelerindedir.

En sık görülen yedi neden

1. Basit PHP işlevi mail() ile gönderim

Başka bir kurulum yapılmadıysa birçok form e-postalarını web sunucusunun mail() işleviyle gönderir. WordPress de varsayılan olarak böyle yapar. Sorun şu: İşlev, sunucu iletiyi kabul eder etmez “başarılı” bildirir. PHP el kitabı bunun iletinin alıcıya ulaştığı anlamına gelmediğini açıkça belirtir. WordPress belgeleri de wp_mail() işlevinin olumlu dönüş değerinin yalnızca isteğin hatasız işlendiği anlamına geldiğini netleştirir.

Buna şu da eklenir: Web sunucusu çoğu zaman alan adınız adına yetkili gönderen olarak kayıtlı değildir (bkz. 3. neden) ve bazı barındırma paketleri gönderimi kısıtlar ya da mail() işlevini kapatır. Barındırma sağlayıcınıza gönderimin izinli olup olmadığını ve hangi sınırların geçerli olduğunu sorun.

2. Gönderen adresi alan adınıza ait değil

Birçok form, gönderen (From) olarak ziyaretçinin girdiği adresi yazar. Alıcı sunucu için bu, web sunucunuzun gmx.de ya da yahoo.com adına ileti göndermiş olması gibi görünür. Tam da sahteciliğin kalıbı budur: Sunucunuz bu alan adları için gönderen olarak kayıtlı değildir; bu yüzden doğrulama başarısız olur.

Sonrasında ne olacağını, ziyaretçinin sağlayıcısı DMARC politikasıyla belirler. Herkese açık DNS kayıtları şunu gösteriyor (Ekim 2026 itibarıyla): Yahoo p=reject ister, yani alıcı sunucular bu iletileri reddetmelidir. GMX ve WEB.DE p=quarantine uygular; bu iletiler şüpheli sayılır ve çoğunlukla spam klasörüne düşer. Gmail, Outlook.com ve T-Online şu anda p=none kullanıyor. Hatanın çoğu zaman fark edilmemesinin nedeni budur: Yalnızca belirli sağlayıcıların ziyaretçilerini etkiler ve kendi adresinizle yapılan test çalışır.

Çözüm: Gönderen (From) olarak her zaman kendi alan adınızdaki bir adresi kullanın ve ziyaretçinin adresini yanıt adresi (Reply-To) olarak girin. Böylece “Yanıtla” rahat kalır ve ileti doğrulamayı geçer.

From: Web sitesi formu <form@alanadiniz.de>
To: info@alanadiniz.de
Reply-To: ziyaretci@ornek.de

Gönderen adresi, alan adınızda gerçek bir posta kutusu olmalıdır. Var olmayan bir adres, bazı alıcıların iletiyi reddetmesine yol açar.

3. E-posta kimlik doğrulaması eksik ya da hatalı (SPF, DKIM, DMARC)

Alan adınızın DNS’inde üç kayıtla iletinin gerçekten sizden geldiğini kanıtlarsınız. Bunlar olmadan alıcılar iletilerinizi daha kolay şüpheli sayar. Google, 1 Şubat 2024’ten beri Gmail adreslerine gönderen herkesten en az SPF veya DKIM ister. Gmail adreslerine günde 5.000 veya daha fazla ileti gönderenlerin SPF ve DKIM’in yanı sıra DMARC de kurması gerekir. Gönderenler bunu karşılamazsa iletileri spam olarak işaretlenebilir veya beklendiği gibi teslim edilmeyebilir.

Kayıtların nasıl göründüğünü SPF, DKIM ve DMARC kurulumu bölümü gösterir.

4. Alıcı, posta kutusu ya da filtre

• Alıcı adresinde yazım hatası; örneğin alan adı değişikliğinden sonra ya da eski bir çalışanın adresinde.
• Posta kutusu dolu ya da adres artık yok. İleti o zaman geri döner ya da kaybolur.
• Posta kutusundaki kurallar, spam filtreleri ya da yönlendirmeler form iletilerini taşır veya siler.
• Web sitesi oluşturucularda alıcı adresi oluşturucunun form ayarlarında yazılıdır. Hesap ya da alan adı değişikliğinden sonra eski kalmış olabilir.

5. Eklenti, betik ya da güvenlik duvarı çakışmaları

Modern formlar arka planda JavaScript ile, AJAX ya da bir REST arayüzü üzerinden gönderir. Bir güvenlik duvarı, güvenlik eklentisi ya da önbellek eklentisi bu isteği engellerse ya da başka bir betik JavaScript hatası üretirse “Gönder”e tıkladığınızda hiçbir şey olmaz ya da genel bir hata mesajı çıkar. Geliştirici araçlarındaki Ağ sekmesi, hangi isteğin hangi durum koduyla başarısız olduğunu gösterir.

Test amacıyla güvenlik, önbellek ve optimizasyon alanlarındaki eklentileri sırayla devre dışı bırakın; mümkünse önce sitenin bir kopyasında. Öncesinde bir yedek alın.

6. Spam koruması çok katı ya da yanlış kurulmuş

Captcha hizmetleri, gizli tuzak alanları (“honeypot”) ve spam filtreleri botlara karşı korur ancak gerçek talepleri de engelleyebilir: Bir captcha hizmetinin anahtarları (artık) doğru değilse, doğrulama tarayıcı ayarları ya da eklentiler yüzünden yapılamıyorsa ya da bir filtre gerçek iletileri spam sayıyorsa. Eklentinizin spam işaretli iletileri ayrı bir yerde toplayıp toplamadığına bakın ve captcha hizmetinin anahtarlarını kontrol edin.

7. Formun kendisinde teknik hatalar

• Form hedef olarak mailto: kullanır. O zaman kendisi hiçbir şey göndermez: Tarayıcıya göre bir e-posta programı açılır ya da hiçbir şey olmaz.
• İletiyi işleyen betik taşıma sonrasında eksiktir ya da daha yeni bir PHP sürümünde artık çalışmaz.
• Sayfa HTTPS ile yüklenmesine rağmen form http:// ile başlayan bir adrese gönderir. Tarayıcılar bu konuda uyarır ya da göndermeyi engeller. Ayrıntılar için Almanca rehberimize bakın: HTTPS ve SSL hataları (Almanca).
• Zorunlu alanlar ya da bir gizlilik onay kutusu telefonda kullanılamaz; örneğin başka bir öğe üstünü kapattığı için. Formu bu yüzden mobil cihazda da test edin.

Gönderimi kalıcı olarak güvenilir hâle getirmek

1. Gönderen posta kutusu oluşturun: E-posta sağlayıcınızda alan adınızda ayrı bir posta kutusu açın; örneğin form@alanadiniz.de.
2. Üstbilgileri doğru ayarlayın: From bu posta kutusudur, Reply-To form alanındaki adres, To ise sizin alıcı posta kutunuzdur.
3. SMTP ile gönderin: Formun iletiyi mail() yerine bu posta kutusu üzerinden SMTP ile göndermesini sağlayın. Sunucuyu, kullanıcı adını ve şifrelemeyi e-posta sağlayıcınız bildirir. WordPress’te bunu bir SMTP eklentisi üstlenir.
4. DNS kayıtlarını kontrol edin: Alan adınız için SPF, DKIM ve DMARC kurulu olmalıdır (aşağıya bakın).
5. İletileri ek olarak saklayın: Contact Form 7’de bunu örneğin Flamingo eklentisi üstlenir; diğer form eklentilerinin kendi kayıt listesi vardır. Böylece gönderim aksadığında hiçbir talep kaybolmaz.
6. Ziyaretçiye geri bildirim verin: Net bir başarı mesajı ya da teşekkür sayfası gösterin; hata olduğunda e-posta adresinizi bir çıkış yolu olarak içeren anlaşılır bir mesaj verin.
7. Yeniden test edin: Testi en az iki yabancı adresle tekrarlayın ve SPF, DKIM ve DMARC’ın “PASS” gösterip göstermediğine bakın.
8. Sürekli kontrol edin: Takviminize, formu her ay ve ayrıca barındırma, alan adı, e-posta sağlayıcısı ya da eklentilerde her değişiklikten sonra test etmek için sabit bir tarih yazın.

SPF, DKIM ve DMARC kurulumu

Kayıtları alan adınızın DNS’inde oluşturursunuz. Tam değerleri e-posta sağlayıcınız bildirir; buradaki örnekler yer tutucudur.

• Alan adı başına yalnızca bir SPF kaydı olabilir. Standarda (RFC 7208) göre birden çok kayıt hataya yol açar. Tüm gönderenleri ortak bir kayda yazın.
• SPF en fazla on DNS sorgusuna izin verir (include, a, mx ve diğerleri sayılır). Tek kayıtta çok fazla hizmet, kaydı geçersiz kılar.
• DMARC’a p=none ile başlayın: Politika yalnızca gözlemler ve rapor üretir. Raporlar temizse quarantine ya da reject seviyesine sıkılaştırılabilir.

İletişim formunda veri koruma

• Formun hemen yanında gizlilik politikanıza (Datenschutzerklärung) bağlantı verin. Bu yaygındır ve veri toplanırken bilgilendirme yükümlülüğünü karşılar (DSGVO madde 13).
• Yalnızca yanıtlamak için gereken bilgileri isteyin.
• Saklanan iletilerin ne kadar süre tutulacağını belirleyin ve sonrasında silin.
• Gönderim, spam koruması ya da saklama için harici hizmetler kullanıyorsanız bunlar gizlilik politikasında yer almalıdır. Sağlayıcıyla genellikle DSGVO madde 28 uyarınca bir veri işleme sözleşmesi (Auftragsverarbeitungsvertrag) gerekir. Bazı captcha hizmetlerinde ayrıca onay gerekebilir.

Bu genel bir yönlendirmedir, hukuki danışmanlık değildir. Özel soruları uzman bir kuruluşla netleştirin.

Ne zaman yardım almalısınız?

Testlerden sonra neden belirsiz kalıyorsa, DNS yönetimine ya da posta kutusuna erişiminiz yoksa ya da iletiler yalnızca bazı gönderenlerde eksikse yardım almak mantıklıdır.

İletişim formu sorunları Hızlı düzeltme hizmetimizin kapsamındadır (149 €, 2 iş günü). Birden fazla sorun bir araya geliyorsa Site onarımı (349 €) uygundur. Fiyatlar nettir; %19 KDV eklenir. Hangi paketin uygun olduğunu ücretsiz kontrolden sonra söyleriz.

Sık sorulan sorular

Devamını okuyun