SMTP Hata Kodları ve Anlamları (550, 554, 421, 452)

Mail programınızın açtığı kutuda ya da geri dönen bildirimin içinde üç haneli bir sayı görürsünüz: 550, 554 5.7.1, 421, 452. Bu sayılar rastgele değildir; SMTP protokolünün kendi dilidir ve her biri "ne oldu, kim yaptı, tekrar denemeye değer mi" sorularının üçüne birden cevap verir. SMTP hata kodları konusunda arama yaptığınızda karşınıza çıkan sonuçların neredeyse tamamı İngilizcedir; Türkçe kaynaklarda 550 5.7.1 relay access denied gibi günlük hayatta en çok görülen ifadelerin karşılığı bile yoktur. Bu yüzden kullanıcı, ekrandaki kodu anlamadan doğrudan destek talebine yönelir.

Bu yazı o boşluğu doldurmak için yazıldı: SMTP yanıt kodlarının yapısını, hangi ailenin ne anlama geldiğini, 4xx ile 5xx arasındaki temel farkı, genişletilmiş X.Y.Z kodlarının nasıl okunacağını ve en sık karşılaşılan on beş kadar kodun her biri için somut çözümü bulacaksınız. Ayrıca kendi sunucunuzdan elle bir SMTP oturumu açıp kodu canlı olarak üretmeyi de göstereceğim — çünkü hata kodunu tahmin etmek yerine görmek, teşhis süresini dakikalardan saniyelere indirir.

SMTP Yanıt Kodu Nasıl Okunur#

Her SMTP yanıtı üç haneli bir sayıyla başlar ve ilk hane sonucu belirler. Bu hane, tekrar deneyip denememeniz gerektiğini tek başına söyler.

İkinci ve üçüncü haneler konuyu daraltır: x0x sözdizimi, x1x bilgi, x2x bağlantı, x5x posta sistemi ile ilgilidir. Ancak pratikte asıl bilgiyi üç haneli koddan sonra gelen ikinci sayı taşır.

Modern sunucular, üç haneli kodun ardından 5.7.1 biçiminde bir genişletilmiş durum kodu (DSN) da verir. Bu kod X.Y.Z yapısındadır:

• X kalıcılığı söyler: 2 başarılı, 4 geçici, 5 kalıcı.
• Y sınıfı söyler: 0 genel, 1 adresleme, 2 posta kutusu, 3 sistem, 4 ağ, 5 protokol, 7 güvenlik ve politika.
• Z ayrıntıdır ve sunucudan sunucuya küçük farklar gösterebilir.

Bu yüzden 550 5.1.1 ile 550 5.7.1 bambaşka iki sorundur; her ikisi de 550 olsa bile birincisi "alıcı yok", ikincisi "sana izin yok" demektir. Yalnızca üç haneli koda bakıp işlem yapmak, en sık yapılan teşhis hatasıdır. Geri dönen bildirim içinde bu kodun tam olarak nerede durduğunu görmek için mail geri dönüyor: bounce mesajı nasıl okunur yazısındaki satır anatomisine bakabilirsiniz.

Başarı ve Ara Adım Kodları (2xx, 3xx)#

Hata avlarken bu kodları da tanımanız gerekir, çünkü elle test yaparken oturum bu kodlarla ilerler.

Elle test sırasında AUTH LOGIN komutundan sonra 334 yerine 503 görüyorsanız, sunucu kimlik doğrulamayı o aşamada beklemiyordur; 235 yerine 535 görüyorsanız kullanıcı adı veya parola reddedilmiştir.

4xx Geçici Hatalar: 421, 450, 451, 452#

4xx ailesi "şu an olmaz, sonra dene" demektir ve gönderim sunucunuz bu mesajı kuyrukta tutarak günlerce yeniden dener. Bu ailedeki bir kod gördüğünüzde çoğu zaman yapılacak en doğru şey beklemektir.

421 ailesini görünce yapılan en yaygın hata, "gitmedi" diye aynı maili elle tekrar tekrar göndermektir. Bu davranış karşı sunucunun eşik sayaçlarını doldurur ve geçici sınırı kalıcı bloka çevirebilir. Toplu gönderim yapıyorsanız 421 doğrudan hızınızı düşürmeniz gerektiğinin işaretidir.

Gri listeleme (450 4.7.1) aslında bir hata değildir: karşı sunucu, daha önce hiç görmediği gönderici/alıcı/IP üçlüsünü bilerek erteler, çünkü spam yazılımlarının çoğu tekrar denemez. Meşru bir sunucu birkaç dakika sonra tekrar dener ve mail geçer; ilk maildeki kısa gecikme normaldir.

5xx Kalıcı Hatalar: 550, 551, 552, 553, 554#

5xx ailesinde sunucu kararını vermiştir; tekrar denemek sonucu değiştirmez.

Bu tablonun son sütunu, destek talebini nereye açacağınızı belirler. "Sorun kimde" hanesinde Gönderen yazan her satır, kendi tarafınızda düzeltilebilir bir yapılandırma hatasıdır.

550 5.7.1 Relay Access Denied Ne Demek#

550 5.7.1 Relay access denied, sunucunun "senin adına, senin olmayan bir alan adına mail taşımam" demesidir ve neredeyse her zaman kimlik doğrulamasız bağlanmaktan kaynaklanır.

Bir SMTP sunucusu iki tür mesajı kabul eder: kendi barındırdığı alan adlarına gelen mesajlar ve kimliği doğrulanmış bir kullanıcının gönderdiği mesajlar. Bu ikisinin dışındaki her istek "relay" (aktarım) sayılır ve reddedilir, çünkü aksi hâlde sunucu açık relay olur ve saatler içinde spam kaynağına dönüşerek kara listeye girer. Yani bu hata bir arıza değil, bilinçli bir korumadır.

Bu hatayı gördüğünüzde sırayla kontrol edin:

1. Giden sunucu kimlik doğrulaması açık mı? Outlook'ta Hesap Ayarları → Diğer Ayarlar → Giden Sunucu sekmesindeki "Giden sunucum (SMTP) kimlik doğrulaması gerektiriyor" kutucuğu işaretli olmalıdır. Thunderbird'de aynı ayar hesabın Giden Sunucu (SMTP) tanımında "Kimlik doğrulama yöntemi: Normal parola" olarak görünür.
2. Kullanıcı adı tam e-posta adresi mi? Birçok sunucu yalnızca muhasebe yerine [email protected] biçimini kabul eder.
3. Doğru sunucu adına mı bağlanıyorsunuz? Alan adınızın MX kaydı bir yere, gönderim sunucunuz başka bir yere işaret ediyor olabilir. Gönderim için genellikle mail.alanadiniz.com ya da hosting firmanızın verdiği sunucu adı kullanılır.
4. Port ve şifreleme uyumlu mu? 587 STARTTLS, 465 doğrudan (implicit) TLS içindir. Portla şifreleme türü çaprazlanırsa oturum kimlik doğrulamaya bile gelemeden kopabilir.
5. Web formundan gönderiyorsanız kodunuzdaki SMTP kütüphanesinde SMTPAuth açık mı? PHP tarafında bu ayar kapalıyken tam olarak bu hata alınır.

Bu adımların ayrıntılı hâli ve her birinin nasıl doğrulanacağı SMTP kimlik doğrulama hatası yazısında adım adım anlatılıyor.

550 5.7.1 metninin ikinci bir varyantı da vardır: Sender address rejected: not owned by user. Burada kimlik doğrulaması başarılıdır ama giriş yaptığınız hesapla From alanında yazan adres farklıdır. Örneğin bilgi@ hesabıyla giriş yapıp muhasebe@ adına gönderiyorsanız sunucu bunu reddeder. Çözüm, gönderen adresini giriş yapılan hesapla aynı yapmak ya da o hesaba takma ad (alias) yetkisi tanımlamaktır.

554 Ailesi: Politika, İtibar ve Kara Liste Reddi#

554 genellikle mesajın tamamen reddedildiği, çoğu zaman içerik veya itibar temelli bir karardır.

En sık görülen biçim, IP tabanlı bloklamadır:

554 5.7.1 Service unavailable; Client host [203.0.113.45] blocked using zen.spamhaus.org;
    https://check.spamhaus.org/

Buradaki mesaj açıktır: gönderim yaptığınız IP bir kara listededir. Kimlik doğrulamanız, SPF kaydınız, her şey doğru olsa bile mail girmez. Yapılacak iki iş vardır ve sırası önemlidir: önce listelenme sebebini ortadan kaldırın (sunucudaki bir sitenin ele geçirilip spam göndermesi, sızdırılmış bir mail hesabı, güvensiz bir iletişim formu), sonra listeden çıkma talebi gönderin. Sebep durduğu sürece listeden çıksanız bile birkaç saat içinde yeniden girersiniz. Süreç mail blacklist sorgulama ve çıkma yazısında ayrıntılı anlatılıyor.

İkinci biçim içerik reddidir: 554 5.7.1 Message rejected due to content restrictions. Burada mesajın içindeki bir bağlantı, ek türü ya da kalıp filtreyi tetiklemiştir. Aynı maili sade metinle, ek olmadan göndererek test edin; geçiyorsa sorun içeriktedir.

Üçüncü biçim ise gönderen kimliğiyle ilgilidir. Alan adınız için SPF, DKIM ve DMARC kayıtları eksik ya da hatalıysa büyük sağlayıcılar 554 veya 550 5.7.26 ile reddeder. Bu üç kaydın nasıl kurulacağı ve hangi hatanın hangisinden kaynaklandığı SPF, DKIM ve DMARC yazısında anlatılıyor; kendi IP'nizden gönderim yapıyorsanız ayrıca PTR kaydı ve ters DNS tanımını da tamamlamanız gerekir.

452 ve Kaynak Sınırı Hataları#

452, "kaynağım yetmiyor" ailesidir ve iki farklı sebebi vardır.

Birincisi depolama: 452 4.2.2 Insufficient system storage. Alıcı sunucuda disk dolmuş ya da alıcının posta kutusu kotası aşılmıştır. Bu geçici bir koddur; alıcı kutusunu boşalttığında kuyruktaki mesaj teslim edilir.

İkincisi alıcı sayısıdır: 452 4.5.3 Too many recipients. Bir SMTP oturumunda kabul edilen RCPT TO sayısının üstüne çıkmışsınızdır. Toplu gönderimlerde çok yaygındır ve çözümü listeyi parçalara bölmektir. Çoğu sunucu tek oturumda kabul edilen alıcı sayısını sınırlar; bu değeri bilmiyorsanız her mesajda yirmi-otuz alıcıyı geçmemek pratik bir alışkanlıktır. Daha temiz yöntem ise her alıcıya ayrı mesaj göndermektir — hem bu hatayı hem de alıcıların birbirinin adresini görmesini engeller.

Kendi sunucunuzu yönetiyorsanız bu sınırları Postfix tarafında görebilirsiniz:

# Tek oturumda izin verilen alıcı sayısı
postconf smtpd_recipient_limit

# Mesaj boyut sınırı (bayt)
postconf message_size_limit

# Posta kutusu boyut sınırı
postconf mailbox_size_limit

Değeri değiştirmek isterseniz postconf -e "message_size_limit = 52428800" komutuyla ayarlayıp systemctl reload postfix demeniz yeterlidir. Ancak alıcı sunucunun kendi sınırı da geçerlidir; sizin büyük ekleri kabul etmeniz, karşı tarafın da kabul edeceği anlamına gelmez ve 552 5.3.4 yine gelebilir.

Hata Kodunu Kendiniz Üretmek: Elle SMTP Oturumu#

Bounce bildirimini beklemek yerine kodu doğrudan üretebilirsiniz. Şifreli bir SMTP oturumunu terminalden açmak için:

openssl s_client -starttls smtp -crlf -connect mail.ornekfirma.com.tr:587

Bağlantı kurulduğunda sunucu 220 ile karşılar. Ardından sırayla:

EHLO test.ornekfirma.com.tr
AUTH LOGIN
<base64 kullanıcı adı>
<base64 parola>
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: test

deneme
.
QUIT

Her satırdan sonra sunucunun döndüğü kodu canlı görürsünüz ve hatanın hangi adımda çıktığı bellidir: AUTH LOGIN sonrası 535 alıyorsanız sorun parolada, RCPT TO sonrası 550 5.7.1 alıyorsanız relay izninde, 550 5.1.1 alıyorsanız alıcı adresindedir. Base64 değerlerini printf '[email protected]' | base64 komutuyla üretebilirsiniz.

Bu diziyi elle yazmak yerine swaks aracını kullanmak daha pratiktir:

swaks --to [email protected] \
      --from [email protected] \
      --server mail.ornekfirma.com.tr:587 \
      --tls --auth LOGIN --auth-user [email protected]

Parolayı komut satırına yazmayın; swaks sormadığında --auth-password yerine etkileşimli sormasını beklemek daha güvenlidir. Hangi portu ve şifreleme türünü kullanmanız gerektiğinden emin değilseniz SMTP test aracı port/TLS uyumunu kontrol eder ve size çalıştırılabilir komutları hazır üretir.

Hangi Kodda Kime Başvurulur#

Aşağıdaki sıralama, destek talebi açmadan önce beş saniyede karar vermenizi sağlar.

1. Kod 4 ile başlıyorsa kimseye başvurmayın; bekleyin. Birkaç gün sürerse ve 4.4.x ise ağ tarafına, 4.2.x ise alıcıya bakılır.
2. Kod 5.1.x veya 5.2.x ise alıcıyla iletişime geçin; adres yanlıştır ya da kutusu doludur.
3. Kod 5.7.x ise kendi tarafınıza bakın; kimlik doğrulama, DNS kayıtları veya IP itibarı sorunludur.
4. Kod 5.3.4 veya 552 ise mesajı küçültün; ek boyutu sınırın üstündedir.
5. Kod 535 veya 530 ise mail programınızın ayarlarına bakın; sunucuya bile giremiyorsunuz.
6. Aynı hata farklı sağlayıcılardaki tüm alıcılara geliyorsa sorun sistemiktir; tek bir alıcıya geliyorsa o adrese özeldir.

Sıkça Sorulan Sorular#

550 hatası ne demek#

550, sunucunun isteği kalıcı olarak reddettiği anlamına gelir ve tekrar denemek sonucu değiştirmez. Ancak 550 tek başına yeterli bilgi vermez; asıl anlamı yanındaki genişletilmiş kod belirler. 550 5.1.1 alıcının var olmadığını, 550 5.7.1 sizin gönderim yetkinizin olmadığını, 550 5.7.26 ise alan adınızın kimlik doğrulama kayıtlarının eksik olduğunu söyler. Bu üçünün çözümü tamamen farklıdır, bu yüzden kodun ikinci bölümünü mutlaka okuyun.

554 5.7.1 relay access denied nasıl düzeltilir#

Bu hata, mail programınızın giden sunucuya kimliğini doğrulatmadan bağlandığını gösterir. Önce mail programınızda "giden sunucu kimlik doğrulaması gerektirir" seçeneğini açın ve kullanıcı adını tam e-posta adresi olarak girin. Ardından port ile şifreleme türünün eşleştiğini doğrulayın: 587 portu STARTTLS, 465 portu doğrudan TLS ile kullanılır. Bir web formundan gönderiyorsanız SMTP kütüphanenizde kimlik doğrulama seçeneğinin etkin olduğundan emin olun. Bu üç kontrol vakaların büyük çoğunluğunu çözer.

421 hatası alıyorum, ne yapmalıyım#

421, sunucunun şu an hizmet veremediğini bildiren geçici bir koddur ve doğru davranış beklemektir. Kod genellikle aşırı gönderim hızı, sunucu üzerindeki geçici yük ya da alıcı tarafın hız sınırı nedeniyle gelir. Aynı maili elle tekrar tekrar göndermek en kötü tepkidir, çünkü karşı sunucu bunu ısrarcı davranış sayarak geçici sınırı kalıcı engele çevirebilir. Toplu gönderim yapıyorsanız dakikadaki mesaj sayısını düşürün ve gönderimi zamana yayın.

4xx ile 5xx kodları arasındaki fark nedir#

4xx geçici, 5xx kalıcı hatadır. 4xx aldığınızda gönderim sunucunuz mesajı kuyrukta tutar ve genellikle birkaç gün boyunca artan aralıklarla yeniden dener; bu sürede sorun kendiliğinden düzelirse mail teslim edilir ve size hiçbir bildirim gelmez. 5xx aldığınızda ise sunucu kararını vermiştir, hiçbir yeniden deneme yapılmaz ve mesaj doğrudan iade edilir. Bu yüzden 4xx kodlarında müdahale etmemek, 5xx kodlarında ise mutlaka bir düzeltme yapmak gerekir.

452 too many recipients hatasının çözümü nedir#

Bu hata, tek bir SMTP oturumunda sunucunun kabul ettiğinden fazla alıcı tanımladığınızı gösterir ve çözümü listeyi bölmektir. Toplu duyuru gönderiyorsanız alıcıları yirmi-otuz kişilik gruplara ayırın ya da her alıcıya ayrı bir mesaj gönderecek şekilde yapılandırın. İkinci yöntem hem bu sınırı aşar hem de alıcıların birbirinin adresini görmesini engeller. Kendi sunucunuzu yönetiyorsanız sınırı postconf smtpd_recipient_limit komutuyla görebilir, gerekirse yükseltebilirsiniz; ancak alıcı sunucunun kendi sınırı da geçerli olduğu için bu her zaman çözüm olmaz.

535 authentication failed hatası neden alınır#

535, sunucunun gönderdiğiniz kullanıcı adı ve parolayı reddettiğini gösterir. En yaygın sebep parolanın yanlış olması değil, kullanıcı adının eksik yazılmasıdır: birçok sunucu yalnızca hesap adını değil tam e-posta adresini kabul eder. İkinci sık sebep, parolanın kopyalanırken sonuna görünmez bir boşluk ya da satır sonu karakteri eklenmesidir. Üçüncüsü, hesabın çok sayıda başarısız denemeden sonra sunucu tarafında geçici olarak kilitlenmiş olmasıdır; bu durumda parola doğru olsa bile reddedilirsiniz.

Greylisting hatası aldım, kaç dakika beklemeliyim#

Gri listeleme genellikle beş ila on beş dakika içinde kendiliğinden çözülür ve sizin bir işlem yapmanız gerekmez. Karşı sunucu, daha önce hiç görmediği gönderici-alıcı-IP üçlüsünü bilerek bir kez erteler; meşru gönderim sunucuları otomatik olarak tekrar dener ve ikinci denemede mesaj kabul edilir. Aynı gönderici ile aynı alıcıya sonraki mailleriniz gecikmeden geçer, çünkü üçlü artık tanınmıştır. Sadece ilk mailde gecikme yaşamak bu mekanizmanın normal davranışıdır.

Hata kodunu göremiyorum, sadece "gönderilemedi" yazıyor#

Mail programları hata metnini çoğu zaman gizler; ham kodu görmek için istemcinin günlük kaydını açmanız gerekir. Outlook'ta Dosya → Seçenekler → Gelişmiş altındaki "Sorun giderme günlüğünü etkinleştir" seçeneği, Thunderbird'de ise hata konsolu ham SMTP diyaloğunu gösterir. Daha hızlı yol, terminalden openssl s_client -starttls smtp -connect sunucu:587 komutuyla elle bağlanıp aynı adımları tekrarlamaktır; sunucunun döndüğü kodu doğrudan ekranda görürsünüz. Sunucu tarafında erişiminiz varsa posta logları da her denemenin kodunu saklar.

Kapanış#

SMTP hata kodları ilk bakışta anlamsız sayılar gibi görünse de son derece düzenli bir yapıya sahiptir: ilk hane tekrar deneyip denemeyeceğinizi, genişletilmiş kodun ikinci hanesi sorunun sınıfını, yanındaki metin ise gerçek sebebi söyler. 4 ile başlayan kodlarda beklemek, 5.1.x ve 5.2.x kodlarında alıcıya dönmek, 5.7.x kodlarında ise kendi yapılandırmanıza bakmak neredeyse her zaman doğru karardır. Bu ayrımı bir kez oturttuğunuzda, daha önce hiç görmediğiniz bir kodu bile doğru sınıfa yerleştirebilirsiniz.

Düzenli olarak yüksek hacimli gönderim yapıyor ve hız sınırı, itibar ya da kimlik doğrulama kodlarıyla sürekli boğuşuyorsanız, gönderimi paylaşımlı bir ortamdan ayırmak kalıcı çözümdür; SMTP sunucu paketleri Postfix, DKIM imzalama ve rDNS tanımı yapılmış hâlde teslim edilir. Yalnızca kurumsal yazışma için düzgün çalışan bir posta altyapısı arıyorsanız kurumsal e-posta çözümleri kayıt kurulumunu da kapsar. Site ve posta trafiğini tek panelden yönetmek isteyen firmalar için kurumsal hosting paketleri teslimat izleme araçlarıyla birlikte gelir.