hata-cozum·
29 Haziran 2026
E-posta Gönderemiyorum: 10 Adımda Teşhis
E-posta gönderme sorunları onlarca farklı nedenden kaynaklanabilir. Bu rehber, sorunu sistematik biçimde 10 adımda teşhis etmenizi sağlar.
E-posta gönderme sorunları onlarca farklı nedenden kaynaklanabilir. Bu rehber, sorunu sistematik biçimde 10 adımda teşhis etmenizi sağlar.
E-posta gönderme sorunları; yanlış yapılandırılmış DNS kayıtlarından kara listeye alınmış IP'lere, hatalı SMTP kimlik bilgilerinden port engellerine kadar onlarca farklı nedenden kaynaklanabilir. Bu rehber, sorunu sistematik biçimde dakikalar içinde teşhis etmenizi sağlar.
Bir e-posta göndermek tek bir teknik işlemden ibaret değildir. RFC 5321'e göre SMTP protokolü, gönderici ile alıcı MTA (Mail Transfer Agent) arasında çok aşamalı bir el sıkışma gerektirmektedir. Bu sürecin herhangi bir noktasındaki aksaklık, mesajın iletilememesine yol açar. Aşağıdaki 10 adım, olası arıza noktalarını en yaygından en karmaşığa doğru sıralayarak hızlı bir teşhis yolu sunar.
Teşhise başlamadan önce tam hata metnini kaydedin. SMTP durum kodları üç basamaklıdır ve RFC 5321 §4.2 uyarınca belirli anlam kümelerine ayrılır:
| Kod Aralığı | Anlam | Örnek |
|---|---|---|
| 2xx | Başarılı | 250 OK |
| 4xx | Geçici hata (yeniden dene) | 421 Service temporarily unavailable |
| 5xx | Kalıcı hata (bounce) | 550 User unknown |
4xx hataları genellikle sunucu yükü veya geçici ağ sorunlarına işaret eder; birkaç saat içinde kendiliğinden çözülür. 5xx hataları ise kalıcıdır ve müdahale gerektirir.
İstemcinin SMTP sunucusuna fiziksel olarak erişip erişemediğini doğrulamak için aşağıdaki komutu kullanın:
telnet mail.sirketiniz.com.tr 587Bağlantı kurulamazsa sorun; güvenlik duvarı kurallarında, ISP'nin port 25/587/465 engelinde veya SMTP sunucusunun çevrimdışı olmasında yatıyor olabilir. Microsoft'un resmi teknik belgelerine göre Exchange Online, port 587 üzerinden STARTTLS zorunlu kılmaktadır. Port 25 ise sunucudan sunucuya iletim (MTA-to-MTA) için ayrılmıştır ve son kullanıcı istemcilerinde kullanılmamalıdır.
Kullanıcı adı veya parola hatalıysa sunucu 535 Authentication credentials invalid döner. Yaygın nedenler:
Alıcı sunucu, gönderen etki alanının MX kaydını ve sunucunun PTR (ters DNS) kaydını doğrulayarak mesajı kabul edip etmemeye karar verir. RFC 1912 §2.1, her A kaydının eşleşen bir PTR kaydına sahip olması gerektiğini belirtir. PTR kaydı yoksa pek çok büyük sağlayıcı (Gmail, Outlook.com) mesajı reddeder.
nslookup -type=MX sirketiniz.com.tr
nslookup -type=PTR 1.2.3.4MX kaydı yoksa veya yanlış sunucuya işaret ediyorsa e-posta teslim edilemez. DNS değişikliklerinin yayılması TTL değerine bağlı olarak 15 dakikadan 48 saate kadar sürebilir.
RFC 7208 (SPF) ve RFC 6376 (DKIM) standartlarına göre, göndericinin kimliğini doğrulayan bu üç kayıt eksikse ya da hatalıysa mesajlar istenmeyen posta klasörüne düşer veya reddedilir. Google ve Yahoo, Şubat 2024 itibarıyla günlük 5.000'den fazla e-posta gönderen tüm alan adları için SPF, DKIM ve DMARC zorunlu kılmıştır.
| Kayıt | Kontrol Komutu | Beklenen Çıktı |
|---|---|---|
| SPF | nslookup -type=TXT sirketiniz.com.tr |
v=spf1 ... ~all veya -all |
| DKIM | nslookup -type=TXT selector._domainkey.sirketiniz.com.tr |
v=DKIM1; k=rsa; p=... |
| DMARC | nslookup -type=TXT _dmarc.sirketiniz.com.tr |
v=DMARC1; p=quarantine veya reject |
Gönderen IP'nin kara listeye alınması, mesajların toplu olarak reddedilmesinin en sık karşılaşılan nedenlerinden biridir. Spamhaus, SORBS ve Barracuda gibi farklı DNSBL (DNS-based Blackhole List) sağlayıcıları bağımsız veritabanları tutar. MXToolbox'ın Blacklist Check aracı, tek sorguda 100'den fazla listeyi aynı anda kontrol etmenizi sağlar.
Kara listeye alınmanın en yaygın nedenleri: güvenliği ihlal edilmiş kullanıcı hesabı, hatalı yapılandırılmış açık röle (open relay) ve toplu spam gönderimi. Sophos resmi teknik belgelerine göre, tek bir güvenliği ihlal edilmiş hesap saniyeler içinde binlerce spam iletisi gönderebilir.
Kara listeden çıkış (delisting) süreci sağlayıcıya göre 24 saatten birkaç güne kadar sürebilir. Temel sorun giderilmeden delisting talebinde bulunmak kalıcı engellemeye yol açabilir.
Bulut e-posta sağlayıcıları, kötüye kullanımı önlemek amacıyla dakika, saat veya günlük gönderim limitleri uygular. Microsoft 365 teknik dokümantasyonuna göre Exchange Online'da tek bir kullanıcı hesabından günde en fazla 10.000 alıcıya mesaj gönderilebilir; dakika başına ise 30 mesaj sınırı bulunmaktadır. Google Workspace'te benzer kısıtlamalar mevcuttur.
Limit aşımı genellikle 550 5.4.5 Daily sending quota exceeded veya 421 Too many connections hataları ile kendini gösterir. Çözüm: gönderimi zaman içine dağıtmak veya toplu iletiler için ayrı bir transactional e-posta servisi (örneğin dedicated SMTP relay) kullanmaktır.
RFC 5321 §4.5.3.1, SMTP sunucularının minimum 64 KB mesaj boyutunu desteklemesini zorunlu kılar; ancak modern sunucular çok daha yüksek limitler uygular. Yaygın limitler:
Base64 kodlaması nedeniyle ekler yaklaşık %33 daha büyük aktarılır. 10 MB'lık bir dosya SMTP üzerinden ~13,3 MB olarak iletilir.
Sorun kendi altyapınızda değil, alıcının e-posta güvenlik katmanlarında olabilir. Kurumsal alıcılar; Secure Email Gateway (SEG), gelişmiş spam filtreleri ve içerik analizi motorları kullanır. Barracuda, Proofpoint veya Cisco IronPort gibi çözümler, politikaya göre mesajları sessizce silip bounce göndermeyebilir.
Bu durumu anlamanın en güvenilir yolu, alıcıdan kendi sunucusunun e-posta günlüklerini (mail log) kontrol etmesini istemektir. Mesajın sunucularına hiç ulaşmadığı tespit edilirse sorun gönderen taraftadır; sunucuya ulaşıp reddedildiyse alıcı politikası devrededir.
Yukarıdaki adımların hiçbiri kesin sonuç vermiyorsa SMTP sunucusunun tam günlüğüne bakmanız gerekir. Postfix'te /var/log/mail.log, Exchange'de Event Viewer ve Message Tracking Log Center, Microsoft 365'te Exchange Admin Center > Mail Flow > Message Trace bu amaçla kullanılır.
Günlüklerde aranacak anahtar ifadeler:
| İfade | Anlamı |
|---|---|
status=bounced |
Kalıcı teslimat hatası |
status=deferred |
Geçici hata, kuyrukta bekliyor |
Connection refused |
Alıcı sunucuya erişilemiyor |
Relay access denied |
SMTP kimlik doğrulama başarısız |
TLS handshake failed |
Şifreleme müzakeresi hatası |
| Adım | Kontrol Edilen | Tipik Hata Kodu | Araç |
|---|---|---|---|
| 1 | Hata mesajı | 4xx / 5xx | İstemci / NDR |
| 2 | SMTP bağlantısı | Connection refused | telnet / openssl |
| 3 | Kimlik doğrulama | 535 | Yönetici paneli |
| 4 | DNS (MX/PTR) | 550 / 421 | nslookup / dig |
| 5 | SPF/DKIM/DMARC | 550 SPF fail | MXToolbox |
| 6 | Kara liste | 550 blocked | MXToolbox Blacklist |
| 7 | Gönderim limiti | 550 5.4.5 / 421 | Admin Center |
| 8 | Mesaj boyutu | 552 Message too large | İstemci / sunucu |
| 9 | Alıcı politikası | Sessiz ret / spam | Alıcı log talebi |
| 10 | Sunucu günlüğü | Tüm kodlar | mail.log / Message Trace |
Bu durum genellikle alıcının Secure Email Gateway'inin mesajı sessizce silmesinden (silent drop) kaynaklanır. Alıcı taraf mesajın kendi sunucularına hiç ulaşmadığını teyit ederse sorun gönderici altyapısındadır (kara liste veya itibar puanı). Sunucularına ulaşıp kayboluyorsa alıcının spam filtresi veya karantina politikası devrededir. Her iki durumda da Message Trace ve SMTP günlükleri kesin yanıt verir.
SPF tek başına yeterli değildir. RFC 7489 (DMARC) uyarınca, SPF ve DKIM'in ikisinin de geçmesi ve DMARC politikasıyla hizalanmış (aligned) olması gerekir. Bunun yanı sıra gönderen IP'nin itibar puanı (reputation score), mesaj içeriğinin spam özelliği taşıyıp taşımadığı ve gönderim hacminin ani artışı da filtreleme kararını etkiler. DKIM imzası eksikse veya başlık hizalaması (header alignment) sağlanamıyorsa DMARC kontrolü başarısız olur.
Microsoft, güvenlik varsayılanlarını (Security Defaults) etkinleştirdiğinde kiracı genelinde eski kimlik doğrulama protokollerini devre dışı bırakabilir. Exchange Admin Center > Settings > Mail Flow bölümünden SMTP AUTH'un etkinleştirildiğini doğrulayın. MFA kullanıyorsanız e-posta istemcisi için Azure AD üzerinden uygulama parolası (App Password) oluşturmanız gerekir. Microsoft'un resmi teknik belgelerine göre Modern Authentication (OAuth 2.0) destekleyen istemcilerde uygulama parolası yerine doğrudan OAuth akışı tercih edilmelidir.
Süre, kara liste sağlayıcısına göre büyük farklılık gösterir. Spamhaus'un PBL (Policy Block List) listesi için otomatik delisting 28 gün içinde gerçekleşebilir; ancak SBL (Spamhaus Block List) için manuel başvuru ve onay süreci gerekir ve birkaç günden birkaç haftaya uzayabilir. SORBS ve Barracuda gibi sağlayıcılar kendi başvuru portalları üzerinden genellikle 24–72 saat içinde işlem yapar. Kara listeden çıkmadan önce kötüye kullanıma neden olan güvenlik açığını kapatmak zorunludur; aksi takdirde aynı IP tekrar listeye alınır.
Evet, tüm adımlar hem bulut (Microsoft 365, Google Workspace) hem de şirket içi (Exchange Server, Postfix, Zimbra) altyapılar için uygulanabilir. Şirket içi kurulumlarda PTR kaydının ISP'den talep edilmesi, günlük rotasyon politikası ve firewall kurallarının yönetimi doğrudan BT ekibinin sorumluluğundadır. Bulut servislerinde bu sorumluluklar büyük ölçüde servis sağlayıcısına aittir; ancak DNS yönetimi ve kimlik doğrulama politikaları müşteri tarafında kalır.
Bu durum genellikle alıcının Secure Email Gateway'inin mesajı sessizce silmesinden (silent drop) kaynaklanır. Alıcı taraf mesajın kendi sunucularına hiç ulaşmadığını teyit ederse sorun gönderici altyapısındadır. Sunucularına ulaşıp kayboluyorsa alıcının spam filtresi veya karantina politikası devrededir. Her iki durumda da Message Trace ve SMTP günlükleri kesin yanıt verir.
SPF tek başına yeterli değildir. RFC 7489 (DMARC) uyarınca, SPF ve DKIM'in ikisinin de geçmesi ve DMARC politikasıyla hizalanmış olması gerekir. DKIM imzası eksikse veya başlık hizalaması sağlanamıyorsa DMARC kontrolü başarısız olur.
Exchange Admin Center > Settings > Mail Flow bölümünden SMTP AUTH'un etkinleştirildiğini doğrulayın. MFA kullanıyorsanız Azure AD üzerinden uygulama parolası (App Password) oluşturmanız gerekir. Microsoft'un resmi teknik belgelerine göre Modern Authentication destekleyen istemcilerde OAuth 2.0 akışı tercih edilmelidir.
Spamhaus PBL için otomatik delisting 28 gün içinde gerçekleşebilir; SBL için manuel başvuru ve onay süreci birkaç günden birkaç haftaya uzayabilir. SORBS ve Barracuda genellikle 24–72 saat içinde işlem yapar. Kara listeden çıkmadan önce güvenlik açığını kapatmak zorunludur.
Evet, tüm adımlar hem bulut (Microsoft 365, Google Workspace) hem de şirket içi (Exchange Server, Postfix, Zimbra) altyapılar için uygulanabilir. Şirket içi kurulumlarda PTR kaydının ISP'den talep edilmesi ve firewall kuralları doğrudan BT ekibinin sorumluluğundadır.
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.