İçeriğe geç
ServerPlus FırsatıYüksek performanslı VDS sunucularda avantajlı fiyatlarTürkiye lokasyon, NVMe disk ve güçlü altyapıyla projelerinizi hızlandırın.
Kampanyayı İncele
cPanel

cPanel E-posta Gönderememe ve SMTP Hata Kayıtlarını Çözme Rehberi

22 Ekim 2026·Güncelleme: 22 Ekim 2026·11 dk okuma

cPanel’de e-posta gönderilemiyorsa Exim SMTP kayıtlarını okuyarak kimlik doğrulama, kuyruk, DNS, IP itibarı ve bağlantı sorunlarını güvenle teşhis edin.

cPanel e-posta gönderememe sorunu, iletinin webmail veya e-posta istemcisinden çıkmaması, kuyrukta beklemesi ya da alıcı sunucu tarafından reddedilmesi şeklinde görünür. cPanel & WHM sunucularında posta aktarımını çoğunlukla Exim yürüttüğü için doğru çözüm, önce SMTP hata metnini ve Exim teslimat kaydını eşleştirmekten geçer. 535 Authentication failed, 550 relay not permitted, 451 temporary local problem ve bağlantı zaman aşımı aynı belirtiyi üretse de nedenleri farklıdır. Bu rehber, gönderim yolundaki hatayı güvenli biçimde ayırmayı; kullanıcı, DNS, kuyruk, ağ ve sunucu yapılandırması katmanlarında düzeltmeyi açıklar.

Belirti, kapsam ve ilk güvenlik notları

Sorunun kapsamını değiştirecek ilk ayrım şudur: Yalnızca bir posta kutusu mu, aynı alan adındaki tüm hesaplar mı, yoksa sunucudaki tüm alan adları mı gönderemiyor? Webmail üzerinden gönderim başarılı fakat Outlook, Thunderbird veya uygulama SMTP’si başarısızsa öncelik istemci ayarları ve SMTP kimlik doğrulamasıdır. Webmail de başarısızsa Exim kuyruğu, teslimat kaydı, DNS ve sunucu politikaları incelenmelidir.

Yönetici erişimi olan sistemlerde kuyruk temizleme, Exim yapılandırmasını değiştirme veya hizmeti yeniden başlatma, aktif posta trafiğini etkileyebilir. Üretim sunucusunda bakım penceresi belirleyin; mevcut Exim ayarlarının, DNS bölgelerinin ve ilgili kullanıcı yapılandırmalarının yedeğini alın. Hata görülmeden toplu kuyruk silme uygulamayın: kuyruktaki iletiler iş açısından gerekli olabilir.

cPanel e-posta gönderememe için hızlı teşhis özeti

  • Gönderim hatasının tam metnini, saati, göndereni ve alıcıyı kaydedin.
  • Webmail ve harici SMTP istemcisiyle aynı posta kutusunda kontrollü test yapın.
  • WHM erişiminiz varsa Exim ana günlükte ilgili zaman aralığını filtreleyin.
  • İleti kuyrukta mı, reddedildi mi, yoksa uzak sunucuya ulaşılamıyor mu ayırın.
  • Kimlik doğrulama, gönderici/alıcı yönlendirmesi, DNS, IP itibarı ve ağ çıkışını hata metnine göre inceleyin.
  • Düzeltmeden sonra yeni bir test iletisi gönderin; eski kuyruk iletilerinin durumunu ayrıca doğrulayın.

SMTP hata metinleri ne anlatır?

Hata örneği Genel anlamı İlk inceleme noktası
535 Authentication failed SMTP kullanıcı adı, parola veya kimlik doğrulama yöntemi kabul edilmedi. Posta kutusu parolası, tam e-posta adresiyle kullanıcı adı, port ve TLS ayarı.
550 relay not permitted Sunucu, istemciyi bu gönderim için yetkili görmüyor. SMTP Authentication, doğru giden sunucu adı ve SMTP portu.
550 rejected / 550 blocked Uzak alıcı sunucu iletiyi kalıcı olarak reddetti. Red gerekçesi, gönderen IP itibarı, SPF/DKIM/DMARC ve içerik.
451, 421 veya 4xx Geçici hata; uzak sistem, kaynak veya yerel servis sorunu olabilir. Exim kuyruğu, disk alanı, DNS çözümleme ve uzak MX bağlantısı.
Connection timed out Uzak SMTP sunucusuna ağ bağlantısı kurulamıyor. TCP/25 çıkışı, güvenlik duvarı, sağlayıcı kısıtı ve hedef MX erişimi.

Not: 4xx kodları çoğunlukla yeniden denemeye uygundur; 5xx kodları ise düzeltme yapılmadan tekrar deneme ile sonuçlanmaz. Ancak hata kodu tek başına yeterli değildir; Exim günlüğündeki açıklama belirleyicidir.

Exim SMTP loglarıyla güvenli teşhis

WHM ve cPanel arayüzünden kayıtları inceleme

Root veya reseller yetkiniz yoksa önce cPanel içindeki Email Delivery Reports bölümünü açın. Gönderen, alıcı, tarih ve teslimat sonucu üzerinden ilgili iletiyi bulun. İleti reddedilmişse hata satırını eksiksiz kopyalayın. Kullanıcı, mesajı webmail yerine SMTP istemcisinden yolluyorsa istemcinin hata penceresindeki sunucu yanıtını da saklayın.

WHM yöneticileri, Email > Mail Delivery Reports ile teslimat durumunu; kuyruk durumu için ilgili Exim araçlarını inceleyebilir. Arayüzdeki sonuçları sunucu günlükleriyle karşılaştırmak, özellikle aynı anda çok sayıda gönderim sorunu yaşanıyorsa faydalıdır.

SSH üzerinden temel Exim kontrolleri

Aşağıdaki komutlar root yetkisi gerektirir. cPanel & WHM sunucularında Exim ana günlüğünün yaygın konumu /var/log/exim_mainlog yoludur. Dağıtımınıza ve logrotate politikanıza göre eski kayıtlar sıkıştırılmış dosyalarda bulunabilir.

# Son Exim olaylarını inceleyin
sudo tail -n 100 /var/log/exim_mainlog

# Belirli bir gönderen veya alıcı için günlüğü filtreleyin
sudo grep -F 'kullanici@example.com' /var/log/exim_mainlog | tail -n 100

# Exim kuyruğunu listeleyin ve kuyruktaki ileti sayısını görün
sudo exim -bp
sudo exim -bpc

# Belirli ileti kimliğinin başlıklarını ve teslimat günlüğünü görüntüleyin
sudo exim -Mvh MESAJ-KIMLIGI
sudo exim -Mlog MESAJ-KIMLIGI

MESAJ-KIMLIGI değerini exim -bp çıktısından alın. exim -Mlog çıktısında hedef sunucu adı, SMTP yanıtı ve geçici ya da kalıcı başarısızlık nedeni görünür. Kuyruğu silmek veya tüm iletileri zorla yeniden denemek yerine önce tek bir test iletisinin akışını takip edin.

Hizmet ve kaynak kontrolleri

Sunucuda tüm alan adları etkileniyorsa Exim’in çalışır durumda olup olmadığını, disk alanını ve DNS çözümlemesini kontrol edin. cPanel kurulumlarında servis işlemleri için cPanel’in komutlarını tercih edin. Bazı işletim sistemlerinde systemd birim adı farklı olabileceğinden, servis adını tahmin ederek yeniden başlatma yapmayın.

# Exim hizmet durumunu cPanel servis aracıyla görüntüleyin
sudo /scripts/restartsrv_exim --status

# Bölüm doluluğu ve inode tüketimini kontrol edin
sudo df -h
sudo df -i

# Hedef alan adının MX kaydını sorgulayın
 dig +short MX example.net

# Sunucunun kullandığı çözümleyicinin yanıtını kontrol edin
getent hosts example.net

df -h veya df -i çıktısında özellikle posta verisinin bulunduğu bölüm doluysa Exim geçici hatalar üretebilir. Alan açmak için log veya kuyruk silmeden önce hangi dosyanın büyüdüğünü belirleyin ve geçerli saklama politikanıza uyun.

Olası nedenlere göre adım adım çözüm

1. 535 kimlik doğrulama hatası

İstemcide kullanıcı adı olarak yalnızca kullanici yerine tam e-posta adresini kullanın. Güncel parolayı cPanel’de ilgili posta hesabı üzerinden doğrulayın veya kontrollü olarak değiştirin. Ardından istemcide eski kayıtlı parolayı silip tekrar girin. Giden posta sunucusunda SMTP kimlik doğrulamasının etkin olduğundan emin olun.

Port ve şifreleme seçimi, sunucunun ilan ettiği ayarla uyumlu olmalıdır. Yaygın yapılandırmalar 465/TLS veya 587/STARTTLS’tir; ancak kesin değer için alan adınızın cPanel’deki Configure Mail Client bilgilerini kullanın. Sertifika adıyla uyuşmayan rastgele bir sunucu adı kullanmak, TLS doğrulama hatasına yol açabilir.

2. 550 relay not permitted veya relay access denied

Bu hata genellikle istemcinin doğrulanmadan relay yapmaya çalıştığını gösterir. E-posta istemcisinde giden sunucu için “gelen sunucuyla aynı kimlik bilgilerini kullan” benzeri SMTP authentication seçeneğini etkinleştirin. Doğru sunucu adını, kullanıcı adını ve portu cPanel’in istemci yapılandırma ekranından alın.

Sunucu yöneticisiyseniz açık relay oluşturacak istisnalar eklemeyin. Bir IP adresini geniş güven listelerine eklemek yerine, neden kimlik doğrulamasının gerçekleşmediğini logdan bulun. Açık relay, kötüye kullanım ve IP itibar kaybı riski doğurur.

3. Uzak alıcının 550 reddi: SPF, DKIM, DMARC ve itibar

Exim günlüğünde uzak tarafın yanıtı SPF fail, DKIM, DMARC, spam veya IP blocklist gerekçesi taşıyabilir. Bu, yerel Exim’in bozuk olduğu anlamına gelmez; alıcı sunucunun politikasına takılan bir teslimattır. Önce alıcı sunucunun verdiği tam yanıtı not edin.

cPanel’de alan adının e-posta teslim edilebilirlik ekranından SPF ve DKIM durumunu kontrol edin. DNS kaydı sunucunuzdan farklı bir yerde yönetiliyorsa, önerilen kaydı DNS sağlayıcısında yayımlayın ve yayılımı doğrulayın. DMARC kaydını değiştirmeden önce kullanılan gönderim kaynaklarını değerlendirin; yanlış ve katı bir politika meşru gönderimleri de etkileyebilir. IP engeli şüphesinde kuyruk tekrarlarıyla sorunu büyütmeyin; hata metniyle birlikte ilgili alıcı tarafı veya IP sağlayıcısı sürecini izleyin.

4. 421, 451 ve zaman aşımı hataları

Geçici SMTP hatalarında kuyruk mekanizması normalde tekrar dener. Önce hedef alan adının MX kaydının çözüldüğünü, ardından sunucudan hedef MX’in TCP 25 portuna erişilebildiğini doğrulayın. Ağ testini yalnızca yetkili olduğunuz sunucuda yapın.

# MX kaydından dönen hedef adını kullanın
nc -vz mail.example.net 25

nc sisteminizde kurulu değilse paket kurmak yerine mevcut ağ izleme araçları veya sağlayıcı panelindeki ağ politikalarını kullanın. Bağlantı kurulamıyorsa çıkış TCP/25, güvenlik duvarı veya veri merkezi/sağlayıcı tarafından sınırlanmış olabilir. Bağlantı kurulduğu hâlde uzak taraf geçici hata veriyorsa teslimatı zorla tekrarlamak yerine uzak sistemin geçici politikasının kalkmasını beklemek daha güvenlidir.

5. Yerel disk, kuyruk veya Exim hizmeti sorunu

Exim çalışmıyorsa, logda yerel teslimat hataları varsa veya disk doluysa önce kök nedeni giderin. Alan açma işlemi öncesinde büyük dosyaları ve posta kuyruğunun neden büyüdüğünü inceleyin. Hizmet gerçekten durmuşsa cPanel’in servis aracıyla kontrollü yeniden başlatma yapılabilir:

sudo /scripts/restartsrv_exim

Bu işlem bekleyen bağlantıları etkileyebilir. Yeniden başlatma sonrası hemen logları izleyin; servis kalkmış olsa bile alıcı reddi, DNS veya kimlik doğrulama hatası otomatik olarak çözülmüş sayılmaz.

Çözümü doğrulama

Düzeltme sonrasında hem webmail hem de sorun yaşanan SMTP istemcisinden farklı bir harici alan adına kısa bir test iletisi gönderin. Teslimat raporunda başarılı sonuç arayın ve gerekirse Exim günlüğünde ilgili mesaj kimliği için => ile başlayan başarılı teslimat satırını kontrol edin. Test iletisini aynı alan adı içindeki bir alıcıya değil, harici bir sağlayıcıdaki kontrollü adrese göndermek; dış teslimat, DNS ve alıcı politikalarını birlikte sınar.

Eski kuyruk iletilerinin durumu ayrı değerlendirilmelidir. Yeni test başarılıyken eski iletiler hâlâ belirli bir 5xx hatasıyla bekliyorsa, o iletilerin alıcı reddi veya içerik/gönderici koşulları farklı olabilir.

Tekrarını önleme

  • Posta istemcilerini cPanel’de üretilen güncel bağlantı ayarlarıyla kurun; kullanıcı adı olarak tam e-posta adresi kullanın.
  • SPF ve DKIM kayıtlarını DNS değişikliklerinden sonra kontrol edin; DMARC politikasını aşamalı uygulayın.
  • Exim kuyruğu, disk alanı ve inode kullanımını düzenli izleyin.
  • Başarısız SMTP oturumları veya olağandışı kuyruk artışları için uyarı eşiği tanımlayın.
  • Parola değişiminde eski istemci oturumlarının güncellenmesini sağlayın; gereksiz SMTP istisnaları tanımlamayın.

Sık sorulan sorular

cPanel’de e-posta alınıyor ama gönderilemiyor; neden?

Gelen ve giden posta yolları farklıdır. SMTP kimlik doğrulaması, çıkış portu, Exim kuyruğu, hedef MX erişimi veya alıcı tarafı reddi yalnızca gönderimi etkileyebilir.

Exim kuyruğunu boşaltmak sorunu çözer mi?

Hayır. Kuyruk, sorunun kaynağı değil sonucudur. Hata nedeni düzeltilmeden kuyruk silmek iletileri kaybettirebilir; toplu yeniden deneme de uzak sunucunun sınırlarını tetikleyebilir.

535 hatasında yalnızca parola değiştirmek yeterli midir?

Her zaman değil. Tam e-posta adresiyle kullanıcı adı, SMTP authentication, doğru port ve TLS ayarı da doğrulanmalıdır. İstemcide kayıtlı eski parola kalmış olabilir.

550 hatası sunucumun kara listede olduğunu kesin gösterir mi?

Hayır. 550 çok geniş bir red sınıfıdır. Kesin neden, uzak alıcının SMTP yanıtındaki açıklamadır; adres bulunamaması, politika ihlali, SPF/DKIM/DMARC veya itibar gerekçesi olabilir.

Sonuç

cPanel e-posta gönderememe sorununda en hızlı ve düşük riskli yaklaşım, tahminle ayar değiştirmek yerine SMTP hata metnini Exim teslimat günlüğüyle doğrulamaktır. 535 ve relay hatalarında istemci kimlik doğrulamasına, 4xx hatalarında kuyruk ile ağ koşullarına, 5xx uzak redlerinde ise alıcının ayrıntılı gerekçesi ile alan adı kimlik doğrulamasına odaklanın. Her değişiklikten sonra tek, izlenebilir bir test iletisiyle sonucu doğrulayın.

ServerPlus Teknik Ekibi

Sunucu, hosting, sanallaştırma ve veri merkezi operasyonlarından edinilen bilgileri uygulanabilir teknik rehberlere dönüştürür.