İçindekiler
- 1 E‑posta hata kodları neden bu kadar can sıkıcı ama bir o kadar da değerli?
- 2 SMTP ve bounce mantığını kısaca anlamak
- 3 En sık görülen hata kodları: 550, 554, 421 ve diğerleri
- 4 Gelen bounce mesajını doğru okumak
- 5 Adım adım teşhis rehberi: Hata kodundan çözüme giden yol
- 5.1 1. Hata kodunu ve Diagnostic-Code satırını not edin
- 5.2 2. Adres hatası mı, alan adı hatası mı?
- 5.3 3. SPAM / politika kaynaklı mı?
- 5.4 4. İçerik ve ek boyutlarını gözden geçirin
- 5.5 5. Rate limit ve bağlantı sınırlarını kontrol edin
- 5.6 6. Sorun sizde değil karşı tarafta olabilir
- 5.7 7. İtibar sorunu derinse, kurtarma planı yapın
- 6 Bu hataların sürekli tekrarlanmaması için önleyici adımlar
- 7 Sonuç ve DCHost ile yol haritanız
E‑posta hata kodları neden bu kadar can sıkıcı ama bir o kadar da değerli?
E‑posta gönderiyorsunuz, özellikle de kurumsal tarafta; teklif, fatura, şifre sıfırlama, bildirim… Ve bir bakıyorsunuz, müşteriden yanıt gelmek yerine posta kutunuza karmaşık bir geri dönüş iletisi düşmüş: “550 5.1.1 User unknown”, “554 5.7.1 Message rejected” ya da “421 4.7.0 Temporary rate limit”. İlk bakışta şifre gibi görünen bu hata kodları, aslında size e‑posta altyapınız hakkında son derece kritik bilgiler veriyor.
DCHost tarafında yüzlerce alan adı ve e‑posta altyapısı yönetirken en sık gördüğümüz sorunlardan biri, bu hata mesajlarının yok sayılması ya da yanlış yorumlanması. Oysa çoğu zaman, bounce mesajına dikkatlice bakarak sorunun spam filtreleri mi, yanlış adres mi, IP itibarınız mı yoksa DNS/SPF/DKIM yapılandırması mı kaynaklı olduğunu birkaç dakikada anlamak mümkün.
Bu yazıda, özellikle 550, 554 ve 421 başta olmak üzere yaygın e‑posta hata kodlarını sade bir dille açıklayacağız, gelen bounce mesajını satır satır nasıl okumanız gerektiğini göstereceğiz ve DCHost ekibinin sahada kullandığı adım adım teşhis ve çözüm rehberini paylaşacağız. Böylece her yeni hatada paniklemek yerine, sistematik bir checklist ile ilerleyebilir hale geleceksiniz.
SMTP ve bounce mantığını kısaca anlamak
Hata kodlarını çözebilmek için önce e‑postanın arka planda nasıl iletildiğini anlamak gerekiyor. E‑posta gönderimi SMTP adlı protokol üzerinden yürür. Gönderen sunucu ile alıcı sunucu arasında, tıpkı web isteklerindeki HTTP durum kodları gibi, 3 basamaklı durum kodları kullanılır.
SMTP durum kodlarının yapısı: 2xx, 4xx, 5xx
- 2xx (Başarılı): İşlem başarılı. Örneğin 250 OK.
- 4xx (Geçici hata): Soft hata. Alıcı sunucu “şu an kabul edemiyorum ama sonra tekrar dene” diyor. Örneğin 421 4.7.0 Temporary failure.
- 5xx (Kalıcı hata): Hard hata. “Bu mesajı asla kabul etmeyeceğim” anlamına gelen kalıcı ret. Örneğin 550 5.1.1 User unknown veya 554 5.7.1 Message rejected.
Modern sunucular, bu 3 basamaklı koda ek olarak gelişmiş durum kodları da döner: 5.1.1, 5.2.2, 5.7.1 gibi. Bunlar hatanın nedenini daha net ifade eder:
- 5.1.x: Adresleme (yanlış/var olmayan adres, alan adı problemi)
- 5.2.x: Mail kutusu (dolu, devre dışı, kota aşımı)
- 5.7.x: Yetki/spam politikaları (IP kara listede, SPF/DKIM uyumsuz, politikaya takılma)
Hard bounce vs soft bounce
Hata kodlarını pratikte iki ana grupta düşünmek faydalı:
- Soft bounce (4xx kodlar): Geçici sorun. Örnekler:
- Alıcı sunucu yoğun veya bakımda
- Rate limit’e takılmışsınız
- DNS/geçici ağ sorunları
Çoğu MTA aynı mesajı birkaç defa otomatik yeniden dener.
- Hard bounce (5xx kodlar): Kalıcı sorun. Örnekler:
- Adres hatalı veya hiç yok (550 5.1.1)
- Spam politikasına takılmışsınız (554 5.7.1)
- Alıcı alan adı yok veya MX kaydı hatalı
Bu tip adresleri listelerinizden çıkarmamanız, hem itibarınızı hem de teslim edilebilirliği bozar.
Daha protokol seviyesi detaylara girmek isterseniz, hazırladığımız SMTP hata kodları ve bounce mesajları rehberimizde RFC seviyesinde açıklamalar da bulabilirsiniz. Bu yazıda ise odak noktamız, bu hataları gerçek dünyada nasıl teşhis edip çözeceğiniz olacak.
En sık görülen hata kodları: 550, 554, 421 ve diğerleri
550 serisi hatalar: Yanlış adres mi, politika mı, DNS mi?
550 ile başlayan hatalar, en sık gördüğümüz hard bounce türlerinden. En yaygın varyasyonlar:
- 550 5.1.1 User unknown
Alıcı e‑posta adresi yok. Örneğin[email protected]adresi hiç oluşturulmamış ya da silinmiş. - 550 5.1.0 Address rejected
Adres biçimi yanlış, alan adı hatalı yazılmış (gnail.comgibi) veya alıcı sunucu bu alan adına mail kabul etmiyor. - 550 5.2.2 Mailbox full
Alıcı posta kutusunun kotası dolmuş. Özellikle küçük işletmelerde sık görülür. - 550 5.7.1 Relaying denied / Message rejected
Genellikle yetkilendirme ve güvenlik politikaları ile ilgilidir. Yanlış SMTP portu/şifre ile relay etmeye çalışmak, açık relay denemeleri veya SPF/DKIM uyumsuzlukları tetikleyebilir.
Nasıl yaklaşmalı?
- Önce hata mesajındaki “User unknown” / “No such user” gibi net ipuçlarını okuyun.
- Eğer adres gerçekten yanlışsa, adres listesini temizleyin. Bu adreslere tekrar mail atmayın.
- “Mailbox full” ise karşı tarafla farklı bir kanaldan iletişime geçip durumu haber verin.
- “Relaying denied” gibi bir hata, genellikle sizin SMTP kimlik doğrulama ya da sunucu ayarlarınızda sorun olduğuna işaret eder.
554 hataları: Spam, politika ve itibar duvarı
554 kodu, çoğu zaman spam politikası kaynaklı red anlamına gelir. Örnekler:
- 554 5.7.1 Message rejected due to content restrictions
- 554 5.7.1 Service unavailable; Client host blocked
- 554 5.7.1 Your IP is listed in RBL
Bu tip hatalar genellikle şunlarla bağlantılıdır:
- IP adresiniz bir kara listede (RBL)
- SPF, DKIM, DMARC kayıtlarınız eksik ya da hatalı
- Alan adınızın geçmişi kötü (daha önce spam için kullanılmış olabilir)
- İçerik tarafında tetikleyici anahtar kelimeler, ekler veya linkler bulunuyor
DNS tabanlı doğrulama ayarlarınızın sağlam olduğundan emin olmak için, adım adım anlatımlı SPF, DKIM ve DMARC kurulum rehberimizi mutlaka incelemenizi öneririz.
421 hataları: Sunucu yoğunluğu ve rate limit problemleri
421 kodu, geçici (soft) hata sınıfında yer alır. Örnek iletiler:
- 421 4.7.0 Temporary server error. Please try again later.
- 421 4.7.0 Too many connections from your IP
- 421 4.4.2 Connection dropped
Çoğunlukla:
- Alıcı sunucunun yoğun olması
- Sizden gelen bağlantı sayısının limitleri aşması (rate limit)
- Alıcı tarafın bakım veya geçici ağ sorunları yaşaması
DCHost altyapısında, bu tip hatalarda MTA’lar otomatik retry yapar. Ancak:
- Kısa sürede çok yüksek hacimli gönderim yapıyorsanız (kampanya, bülten vb.), alıcı sunucu sizi yavaşlatmak için 421 döndürebilir.
- Toplu gönderimler için bağlantı ve gönderim hızlarını kademeli artırmak ve gerekiyorsa dedicated IP ısıtma ve itibar yönetimi stratejileri kullanmak gerekir.
450 / 451 / 452: Yine soft bounce ama dikkate alınmalı
- 450 4.2.0 Mailbox temporarily unavailable
Alıcı kutusu geçici olarak kilitli veya kullanılamıyor. - 451 4.3.0 Temporary local problem
Alıcı sunucunun iç problemi (disk, servis, konfigürasyon). Genelde sizlik bir durum yoktur. - 452 4.2.2 Insufficient system storage
Alıcı sunucuda disk/kota problemi.
Bu kodları görüyorsanız, MTA’nız zaten tekrar deneyecektir. Ancak aynı alıcıya günlerce hep aynı kod dönüyorsa, listelerde bu adresleri “sorunlu” işaretleyip manuel takip etmekte fayda var.
552 / 553 ve diğerleri: Kota, boyut ve adres hataları
- 552 5.2.2 Over quota / Mailbox full
Alıcı kutusunun kotası tamamen dolu. - 552 5.3.4 Message size exceeds fixed limit
Ekleriniz veya mailiniz alıcı sunucunun izin verdiğinden büyük. - 553 5.1.1 Mailbox name not allowed
Adres formatı desteklenmiyor ya da politikaya aykırı.
Özellikle büyük ekler içeren tasarım dosyaları, katalog PDF’leri vb. paylaşıyorsanız, 552 kodlarını sık görebilirsiniz. Bu durumda ekleri doğrudan göndermek yerine, download linki paylaşmak daha sağlıklı olur.
Gelen bounce mesajını doğru okumak
Çoğu kullanıcı, posta kutusuna düşen geri dönüş iletisini görür görmez kapatıyor. Oysa asıl altın madeniniz, bu bounce mail’in tam metni içinde saklı.
Hangi alanlara bakmalısınız?
- Subject: Çoğunlukla “Mail delivery failed”, “Undelivered Mail Returned to Sender” gibi başlıklar görürsünüz.
- Final-Recipient: Tam olarak hangi adrese teslim edilemediğini gösterir.
- Action: Genellikle failed, delayed veya relayed yazar. “failed” → hard bounce.
- Status: Gelişmiş durum kodu (ör. 5.1.1, 4.7.0).
- Diagnostic-Code: En kritik bölüm. Asıl hata mesajı burada.
- Remote-MTA: Hangi uzak sunucudan hata döndüğünü gösterir.
Örnek bir bounce mesajı nasıl görünür?
Final-Recipient: rfc822; [email protected] Action: failed Status: 5.1.1 Remote-MTA: dns; mx.ornekfirma.com Diagnostic-Code: smtp; 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown
Bu mesajdan net olarak şunları çıkarabiliriz:
- Adres:
[email protected] - Hata tipi: 5.1.1 → kullanıcı yok
- Sunucu:
mx.ornekfirma.combu cevabı döndürmüş
Dolayısıyla bu adresi liste dışına almanız, hem gereksiz tekrar denemeleri hem de itibar kaybını önleyecektir.
Adım adım teşhis rehberi: Hata kodundan çözüme giden yol
Şimdi pratik bir checklist üzerinden gidelim. DCHost tarafında bir müşterimizin e‑posta problemi olduğunda biz genellikle şu sırayla ilerliyoruz:
1. Hata kodunu ve Diagnostic-Code satırını not edin
- Önce 3 basamaklı kodu (421, 550, 554…) ve varsa 5.x.x / 4.x.x detayını not alın.
- Ardından Diagnostic-Code satırındaki cümleyi kelime kelime okuyun. “User unknown”, “Mailbox full”, “Client host blocked”, “Spam content” gibi anahtar kelimeler size doğrudan sebebi söyler.
2. Adres hatası mı, alan adı hatası mı?
- 5.1.1 / User unknown ise: Adres bozuk ya da alıcı yok. Listenizi temizleyin.
- Aynı etki alanındaki tüm adreslerde hata alıyorsanız, alan adının MX kayıtlarını kontrol edin.
- Alan adı yazım hatalarını (ör.
hotmial.com) gözden geçirin.
DNS tarafta neyin nasıl olması gerektiğini bilmiyorsanız, DNS kayıtları A, MX, CNAME ve TXT rehberimiz burada çok işinize yarayacaktır.
3. SPAM / politika kaynaklı mı?
Diagnostic-Code içinde şu kelimeleri görüyorsanız:
- “blocked”, “blacklisted”, “RBL”, “spam”, “policy”, “5.7.1”
Bu, büyük ihtimalle:
- IP’nizin veya alan adınızın itibar problemi olduğu
- SPF/DKIM/DMARC kayıtlarınızın eksik ya da çelişkili olduğu
- Aşırı agresif içerik/spam filtrelerine takıldığınız
anlamına gelir. Bu noktada şu adımları takip etmek iyi bir başlangıçtır:
- SPF, DKIM, DMARC kayıtlarını güncelleyin ve test edin. Bunun için hem temel hem gelişmiş seviye rehberler hazırladık:
- IP’nizi hangi RBL listelerinde gördüğünüzü kontrol edin ve gerekiyorsa delist başvurusu yapın.
- Gönderim hızını ve hacmini kademeli artırın, özellikle yeni bir IP veya alan adı kullanıyorsanız dedicated IP ısıtma ve itibar yönetimi kurallarına uyun.
4. İçerik ve ek boyutlarını gözden geçirin
- “Message size exceeds” veya 552 5.3.4 görüyorsanız, eklerinizi küçültün ya da linkle paylaşın.
- Şüpheli görülebilecek kelimeleri, aşırı sayıda linki ve yürütülebilir ek uzantılarını (exe, js, scr vb.) temizleyin.
- HTML e‑postanızda mail body’nin çok dağınık/bozuk olmamasına dikkat edin; bazı spam filtreleri “garip” HTML yapısını riskli görür.
5. Rate limit ve bağlantı sınırlarını kontrol edin
421 veya 4.7.x ile birlikte “too many connections”, “rate limit exceeded” gibi ifadeler varsa:
- Toplu gönderim yapan uygulamanızın saniyedeki mail sayısını düşürün.
- Aynı alıcı alan adına kısa sürede aşırı mail göndermeyin; gönderimi zamana yayın.
- SMTP oturumlarını daha verimli kullanın (tek bağlantıda birden fazla mail göndermek gibi).
6. Sorun sizde değil karşı tarafta olabilir
“Temporary local problem”, “insufficient system storage” gibi iletiler genellikle alıcı sunucunun iç meselesidir. Yine de:
- Önemli bir müşteri ise, onlara ekran görüntüsüyle birlikte hata detayını iletip kendi BT ekiplerine paslayın.
- Kritik operasyonel mailler (fatura, şifre sıfırlama vb.) için, bu tip durumlarda yedek alıcı adres veya farklı kanal (SMS, portal bildirimi) gibi alternatifler oluşturun.
7. İtibar sorunu derinse, kurtarma planı yapın
Eğer çok sayıda alıcıdan 554 5.7.1 benzeri retler geliyorsa, bu artık sadece tekil bir sorun değil, genel e‑posta itibarınızın zarar gördüğü anlamına gelir. Böyle durumlar için hazırladığımız e‑posta itibarını kurtarma rehberinde blacklist’ten çıkış, postmaster araçları ve güvenli IP ısıtma adımlarını uçtan uca bulabilirsiniz.
Bu hataların sürekli tekrarlanmaması için önleyici adımlar
Temiz liste yönetimi ve hard bounce’ları hızlıca ayıklama
- Hard bounce (5xx) dönen adresleri düzenli aralıklarla listelerinizden çıkarın.
- Eski ve pasif listeleri tekrar tekrar kullanmayın; çift onaylı (double opt‑in) sistemler tercih edin.
- “User unknown” hatası aldığınız adreslere asla tekrar mail göndermeyin; bu, spam skorunuzu olumsuz etkiler.
DNS ve doğrulama kayıtlarını bir kere düzgün kurup izleyin
- Alan adınızın SPF, DKIM, DMARC, rDNS kayıtlarını bir defa doğru kurup, değişiklik yaptığınızda mutlaka tekrar test edin.
- DMARC raporlarını (RUA/RUF) analiz ederek kimler adınıza mail gönderiyor, hangi sunucular sık hata alıyor görebilirsiniz. Bu konuda daha derinlemesine bilgi için DMARC raporları ile p=none’dan p=reject’e geçiş rehberimizi inceleyebilirsiniz.
Altyapıyı iş yüküne göre planlayın
Küçük hacimli kurumsal mailler için paylaşımlı hosting üzerindeki standart mail servisi çoğu zaman yeterli olur. Ancak:
- Yoğun transactional mail (şifre sıfırlama, sipariş bildirimleri)
- Yüksek hacimli pazarlama kampanyaları
- Birden çok markanın aynı IP’den mail atması
gibi senaryolarda, ayrı bir e‑posta sunucusu, VPS veya dedicated sunucu üzerinde daha kontrollü bir SMTP altyapısı kurmak çok daha sağlıklı olabilir. DCHost olarak bu tip senaryolarda; IP planlaması, reverse DNS, SPF/DKIM/DMARC, rate limit ve yedeklilik tasarımını birlikte kurguluyoruz.
İzleme ve log analizi kültürü oluşturun
- Mail kuyruğu boyutlarını ve hata oranlarını düzenli takip edin.
- Belirli bir alıcı alan adına gönderilen maillerde hata oranı hızla yükseliyorsa, otomatik alarm kurun.
- Logları sadece “sorun çıktığında” değil, periyodik olarak da kontrol etmek, itibar problemleri büyümeden müdahale etmenizi sağlar.
Sonuç ve DCHost ile yol haritanız
E‑posta hata kodları ilk bakışta karmaşık görünebilir; ama aslında her biri, altyapınızın size gönderdiği detaylı bir sağlık raporu gibidir. 550 size adres veya kullanıcı sorunu olduğunu, 554 itibar ve politika duvarına çarptığınızı, 421 ise çoğu zaman hız veya geçici sunucu problemlerini anlatır. Bu kodları doğru okuyabildiğinizde, hem müşterilerinizle iletişiminiz kesintiye uğramaz hem de alan adınızın ve IP’lerinizin itibarını uzun vadede korumuş olursunuz.
DCHost ekibi olarak, sadece sunucu ve hosting sağlamakla kalmıyor; e‑posta teslim edilebilirliği, SPF/DKIM/DMARC yapılandırması, IP ısıtma ve itibar yönetimi gibi konularda da yanınızda duruyoruz. İster paylaşımlı hosting, ister VPS, dedicated sunucu ya da colocation altyapısı kullanın; mail trafiğinizi sağlıklı tutmak için yukarıdaki adımları uygulamanız ve düzenli olarak loglara/bounce mesajlarına bakmanız yeterli.
Eğer elinizde çözemediğiniz karmaşık bir bounce örneği varsa, DCHost paneliniz üzerinden destek talebi açıp ilgili hata mesajını bizimle paylaşabilirsiniz. Birlikte, kodu → sebebi → çözümü netleştirecek ve e‑posta altyapınızı uzun vadede sorunsuz çalışacak şekilde güçlendireceğiz.
