Sorun Giderme·
18 Haziran 2026
Gönder düğmesine bastınız, sisteminiz "Gönderildi" dedi; ama alıcı e-postayı hiç görmedi. Bu durum kurumsal iletişimde ciddi sorunlara yol açabilir. E-postanın kaybolma nedenlerini teknik düzeyde anlamak ve kalıcı çözümler üretmek için doğru yerdesiniz.
E-posta istemcinizin "Gönderildi" demesi, mesajın alıcıya ulaştığı anlamına gelmez. RFC 5321 standardına göre SMTP iletimi birkaç aşamadan oluşur: mesaj önce yerel MTA'nıza (Mail Transfer Agent) iletilir, MTA alıcı alan adının MX kaydını sorgular, ardından alıcı sunucuyla bir bağlantı kurarak mesajı aktarmayı dener. Bu zincirin herhangi bir halkasında kopukluk yaşanabilir.
İlk adımınız gönderim kuyruğunu ve sunucu loglarını incelemek olmalıdır. Eğer mesaj kuyruğa alındıysa ama iletilemediyse, sunucu belirli aralıklarla yeniden denemeye devam eder — genellikle bu süre RFC 5321'in önerdiği gibi en az 4-5 gün boyunca sürer. Süre dolduğunda size bir "Delivery Status Notification (DSN)" ya da halk arasında bilinen adıyla bounce mesajı gelir.
Bounce mesajları, sorunun tam kaynağını gösteren üç haneli SMTP hata kodları içerir. RFC 5321 ve RFC 3463 bu kodları ayrıntılı olarak tanımlar. Hata kodunu doğru okumak sizi gereksiz denemelerden kurtarır.
| Hata Kodu | Tür | Anlam | Yapılması Gereken |
|---|---|---|---|
| 421 | Geçici (Soft) | Alıcı sunucu şu an hizmet veremiyor; daha sonra tekrar deneyin. | Birkaç saat bekleyin, otomatik yeniden deneme devreye girecektir. |
| 450 | Geçici (Soft) | Posta kutusu geçici olarak kullanılamıyor (tam dolu veya kilitli). | Geçici hata; MTA otomatik denemeye devam eder. |
| 550 | Kalıcı (Hard) | Posta kutusu bulunamadı veya politika gereği reddedildi. | Adres doğrulaması yapın; varsa spam politikası hatası giderin. |
| 551 | Kalıcı (Hard) | Kullanıcı yerel değil; yönlendirme bilgisi sunulabilir. | Alıcı adresi güncelleyin veya önerilen adrese gönderin. |
| 552 | Kalıcı (Hard) | Mesaj boyutu alıcı sunucunun izin verdiği sınırı aşıyor. | Ek dosyaları sıkıştırın veya bulut bağlantısıyla paylaşın. |
| 553 | Kalıcı (Hard) | Posta kutusu adı sözdizimi hatalı (RFC 5322 ihlali). | Alıcı adresindeki yazım hatalarını düzeltin. |
| 554 | Kalıcı (Hard) | İşlem başarısız; çoğunlukla spam veya kötü amaçlı içerik tespiti. | İçerik, bağlantı ve IP itibarını gözden geçirin. |
| 535 | Kalıcı (Hard) | Kimlik doğrulama başarısız. | SMTP kullanıcı adı ve parolasını kontrol edin. |
Kodun ilk hanesi genel kategoriyi belirtir: 4xx geçici (soft bounce), 5xx kalıcı (hard bounce) hatadır. Soft bounce'larda MTA yeniden denemeye devam eder; hard bounce'larda ise mesaj teslim edilemez olarak işaretlenir ve tekrar deneme yapılmaz.
Modern e-posta altyapısında bir mesajın teslim edilebilmesi için gönderici alan adının doğru yapılandırılmış kimlik doğrulama kayıtlarına sahip olması zorunludur. Bu üç mekanizma birbirini tamamlar.
RFC 7208 tarafından tanımlanan SPF, alan adınız adına e-posta göndermeye yetkili IP adreslerini listeleyen bir DNS TXT kaydıdır. Alıcı sunucu, gelen mesajın geldiği IP'nin bu listede olup olmadığını kontrol eder. Kayıt yoksa veya gönderici IP listede yer almıyorsa mesaj reddedilebilir ya da spam klasörüne düşebilir.
Örnek bir SPF kaydı şu şekilde görünür: v=spf1 ip4:203.0.113.10 include:mail.connect365.com.tr ~all. Buradaki ~all "softfail" anlamına gelir; -all ise sert reddi ifade eder. SPF kaydınızı dig TXT alanadi.com komutuyla doğrulayabilirsiniz.
RFC 6376 ile standartlaştırılan DKIM, mesaj başlıklarına ve gövdesine kriptografik bir imza ekler. Alıcı sunucu bu imzayı alan adınızın DNS'indeki açık anahtar ile doğrular. İmza uyuşmazsa mesaj güvensiz kabul edilir. DKIM'in en yaygın başarısızlık nedenleri şunlardır: özel anahtarın gönderici sunucuda yanlış yapılandırılmış olması, mesajın iletim sırasında değiştirilmesi (örneğin bir posta listesi uygulamasının konuya ekleme yapması) ve DNS'teki açık anahtarın süresi dolmuş olması.
RFC 7489 ile tanımlanan DMARC, SPF ve DKIM'in üzerine bir politika katmanı ekler. Hangi mesajların kabul edileceğini, reddedileceğini veya karantinaya alınacağını belirler ve alan adı sahibine raporlama imkânı sunar. p=reject politikası en katı korumayı sağlar; ancak SPF ve DKIM doğru yapılandırılmadan bu politikaya geçilmesi meşru e-postaların da reddedilmesine yol açar.
Gönderici IP adresiniz bir kara listede (blacklist/blocklist) yer alıyorsa gönderdiğiniz hiçbir mesaj alıcıya ulaşamaz. Bu durum özellikle paylaşımlı hosting ortamlarında yaygındır; aynı IP'yi kullanan başka bir hesabın kötüye kullanımı sizi de etkiler.
IP itibarınızı kontrol etmek için MXToolbox, Spamhaus veya Barracuda Central gibi araçları kullanabilirsiniz. Kara listeden çıkma (delisting) süreci her liste için farklıdır; bazıları otomatik olarak düşerken bazıları manuel başvuru gerektirir. Önemli olan, önce kara listeye girme nedenini ortadan kaldırmaktır — aksi hâlde kısa sürede yeniden listelenirsiniz.
Alıcı sunucular, SpamAssassin veya benzeri sistemler aracılığıyla gelen mesajlara bir spam puanı biçer. Bu puan belirli bir eşiği aşarsa mesaj spam klasörüne yönlendirilir ya da doğrudan reddedilir. İçerik kaynaklı sorunların başında şunlar gelir:
Sorun her zaman gönderici tarafında değildir. Alıcının posta kutusu dolu olabilir (552 hata kodu), kurumsal güvenlik duvarları belirli ekleri engelliyor olabilir ya da alıcı kurumun e-posta politikası şifreli olmayan bağlantıları reddediyor olabilir. Bazı kurumlar TLS zorunluluğu getirir; RFC 3207 (STARTTLS) uyumlu olmayan gönderici sunuculardan gelen mesajlar bu ortamlarda iletilmez.
Alıcıyla alternatif bir kanaldan (telefon, farklı e-posta adresi) iletişime geçerek mesajı almadığını teyit ettikten sonra yukarıdaki kontrollere geçmek, gereksiz zaman kaybını önler.
RFC 5321, MTA'ların başarısız gönderim denemelerini en az 4-5 gün süre boyunca yinelemesini önerir. Bu süre zarfında geçici (soft bounce) hatalar otomatik olarak çözülmeye çalışılır. 5 gün sonunda hâlâ teslim edilemeyen mesajlar için size bir "undeliverable" bildirimi gelir.
Bu durum çoğunlukla mesajın spam veya gereksiz e-posta klasörüne düşmesi anlamına gelir. Alıcıdan spam klasörünü kontrol etmesini isteyin. Alıcı kurumun bazı güvenlik sistemleri mesajı sessizce silip sizi bilgilendirmeyebilir; bu durumda alıcı BT ekibiyle log incelemesi yapılması gerekir.
SPF tek başına yeterli değildir. Alıcı sunucu DMARC politikanıza bakıyor olabilir ve DKIM imzası eksik olduğunda SPF geçse bile DMARC başarısız olabilir. Ayrıca SPF kaydında include: zincirinin 10 DNS sorgusunu aşmaması gerekir (RFC 7208 §4.6.4); aşılırsa "PermError" ile karşılaşırsınız.
En yaygın nedenler şunlardır: posta listesi yazılımının mesaj başlığını değiştirmesi, iletim sırasında mesaj gövdesine ekleme yapılması (örneğin bir footer eklenmesi) ve DNS'teki DKIM anahtarının süresi dolmuş olması. MXToolbox DKIM Lookup aracıyla anahtarın geçerliliğini kontrol edebilirsiniz.
Önce kara listeye girme nedenini bulun: sunucunuzda açık relay (open relay) yapılandırması mı var, hesaplardan biri ele mi geçirildi, kısa sürede çok fazla mesaj mı gönderildi? Sorunu çözdükten sonra ilgili kara liste sağlayıcısının delisting başvuru sayfasından talepte bulunun. Spamhaus için bu süreç genellikle birkaç saati bulur.
Kurumsal ortamlar (Microsoft 365, Google Workspace ve yerinde Exchange sunucuları) tüketici servislerine kıyasla çok daha katı filtreleme politikaları uygular. Özellikle finansal ve sağlık sektörü kuruluşları ek güvenlik katmanları (Proofpoint, Mimecast vb.) kullanır. Bu ortamlara gönderim yapıyorsanız SPF, DKIM ve DMARC'ın eksiksiz yapılandırılması zorunludur; ayrıca gönderici alan adınızın yaşı ve itibarı da değerlendirme kriterlerinden biridir.
Yürütülebilir dosyalar (.exe, .bat, .js, .vbs), makro içeren Office belgeleri ve parola korumalı arşivler birçok güvenlik sisteminde otomatik olarak engellenir. RFC 2183 (Content-Disposition) ve MIME standartlarına uygun olunsa bile içerik tabanlı engellemeye takılabilirsiniz. Hassas dosyaları güvenli bir bulut depolama bağlantısıyla paylaşmak bu sorunu ortadan kaldırır.
RFC 3207 ile tanımlanan STARTTLS, SMTP bağlantısını şifreler. Bazı kurumsal alıcılar TLS zorunluluğu getirir; TLS desteklemeyen gönderici sunuculardan gelen bağlantıları reddederler. Sunucunuzun TLS'yi desteklediğini ve geçerli bir SSL sertifikasına sahip olduğunu doğrulamanız gerekir.
Google Postmaster Tools (Google'a gönderim itibarı için), Microsoft SNDS (Outlook/Hotmail için) ve MXToolbox Blacklist Check araçlarını düzenli olarak kullanmanızı öneririz. DMARC raporlarını toplamak ve analiz etmek için dmarcian veya EasyDMARC gibi platformlar gönderici alan adınız adına yapılan tüm gönderim girişimlerini görselleştirir.
Connect365, her müşteri için ayrı gönderici IP havuzu, otomatik SPF/DKIM yapılandırması ve gerçek zamanlı bounce yönetimi sunar. Hard bounce olan adresleri gönderim listelerinizden otomatik olarak ayırır; bu sayede IP itibarınız korunur ve teslim edilebilirlik oranınız yüksek kalır. Ayrıca platform içi raporlar aracılığıyla hangi alan adlarında sorun yaşandığını anlık olarak takip edebilirsiniz.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.
Kurulum + migrasyon ücretsiz. KVKK uyumlu, Türkiye'de barındırma. 7/24 Türkçe destek.
Kampanya 30 Haziran'a kadar geçerlidir.