Sorun Giderme·
16 Haziran 2026
E-posta gönderirken alınan "554 Message Rejected" hatası, alıcı sunucunun mesajı kalıcı olarak reddettiğini bildiren bir SMTP yanıt kodudur. Bu hata, spam filtrelerinden kimlik doğrulama sorunlarına kadar pek çok farklı nedenden kaynaklanabilir. Yazımızda hatanın kök nedenlerini, alıcı sunucu mantığını ve adım adım çözüm yollarını ayrıntılı biçimde ele alıyoruz.
RFC 5321 (Simple Mail Transfer Protocol), SMTP yanıt kodlarını üç basamaklı sayılarla tanımlar. İlk basamak işlem sınıfını belirtir: 2xx başarı, 4xx geçici hata, 5xx kalıcı hata anlamına gelir. 554, "Transaction failed" (işlem başarısız) kategorisine girer ve alıcı sunucunun mesajı geri çevirmek için yeteri kadar güçlü bir gerekçe bulduğunu gösterir. RFC 5321'in 4.2.3 bölümüne göre 5xx kodları, gönderen istemcinin aynı mesajı yeniden denemesine gerek olmadığını açıkça belirtir; yani mesaj kuyruğundan kalıcı olarak çıkarılır.
Hatanın bir diğer kritik özelliği "kalıcılık" (permanent failure) niteliğidir. 4xx (örneğin 421 veya 450) geçici bir ret anlamına gelirken, 554'te yeniden gönderim otomatik olarak başarıya ulaşmaz; kök neden giderilmeden tekrar denenmesi sadece sunucu kaynaklarını tüketir ve gönderen itibarını daha da zayıflatır.
Pek çok sunucu, 554 yanıtını daha açıklayıcı bir alt mesajla tamamlar. Aşağıdaki tablo, sık karşılaşılan varyantları ve olası nedenlerini özetlemektedir:
| Alt Mesaj / Örnek Yanıt | Tipik Neden | İlk Kontrol Noktası |
|---|---|---|
554 5.7.1 Message rejected as spam |
İçerik veya başlık spam filtresi tarafından işaretlendi | E-posta içeriği, konu satırı, bağlantı sayısı |
554 5.7.1 SPF check failed |
Gönderen IP, alan adının SPF kaydında tanımlı değil | DNS TXT kaydı (v=spf1 ...) |
554 5.7.5 DKIM signature invalid |
DKIM imzası doğrulanamadı veya eksik | Seçici (selector) DNS kaydı ve özel anahtar uyumu |
554 5.7.1 Rejected due to DMARC policy |
DMARC politikası p=reject ve SPF/DKIM hizalanması başarısız |
_dmarc.alanadi.com TXT kaydı |
554 5.7.1 [IP] listed on Spamhaus SBL |
Gönderen IP kara listeye alınmış | MXToolbox veya Spamhaus sorgulama araçları |
554 5.1.8 Sender address rejected: Domain not found |
Gönderen alan adı DNS'te mevcut değil | Alan adı tescil ve DNS yayılımı |
554 5.6.1 Attachment type not allowed |
Ek dosya uzantısı alıcı politikasınca yasak | .exe, .bat, .js, makro içeren .docm gibi uzantılar |
Modern e-posta altyapısının üç temel kimlik doğrulama standardı olan SPF, DKIM ve DMARC, 554 hatalarının en büyük tetikleyicileri arasında yer alır. Her birinin işlevi ve kontrol yöntemi farklıdır.
RFC 7208 tarafından tanımlanan SPF, alan adı sahibinin hangi IP adreslerinin o alan adı adına e-posta göndermeye yetkili olduğunu ilan etmesini sağlar. Alıcı sunucu, gelen mesajın kaynak IP adresini gönderenin alan adına ait DNS TXT kaydıyla karşılaştırır. Kaydın bulunmaması ya da IP'nin kayıtta yer almaması durumunda SPF fail sonucu üretilir ve DMARC politikasına bağlı olarak mesaj reddedilebilir. Kayıt örneği:
v=spf1 ip4:203.0.113.0/24 include:spf.connect365.com.tr ~allBurada ~all "softfail", -all ise "hardfail" anlamına gelir. Üretim ortamlarında -all kullanılması önerilir ancak bu değişiklikten önce tüm gönderim kaynaklarının kayda eklenmiş olduğundan emin olunmalıdır.
RFC 6376 ile standartlaştırılan DKIM, mesaj başlıklarına ve gövdesine kriptografik imza ekler. İmza, alan adı DNS'ine yayımlanan açık anahtar kullanılarak doğrulanır. Connect365 gibi bulk e-posta altyapıları, her müşteri alan adı için ayrı bir DKIM seçicisi (selector) oluşturur; bu seçicinin DNS'te aktif olması zorunludur. Yaygın sorunlar şunlardır: DNS yayılımının tamamlanmamış olması, özel anahtarın yanlış yapılandırılmış olması ve mesaj geçişte (örneğin mailing list yeniden yazımı) değiştirilmesi.
RFC 7489 kapsamında tanımlanan DMARC, SPF ve DKIM sonuçlarını yorumlamak için bir politika katmanı ekler ve alan adı sahibine raporlama imkânı sunar. DMARC'ın temel mantığı "hizalama" (alignment) üzerine kuruludur: RFC 5322'deki From: adresi, SPF veya DKIM tarafından doğrulanmış alan adıyla uyuşmalıdır. p=reject politikasına sahip bir alıcı alan adına gönderilen ve hizalamayı geçemeyen mesajlar, 554 hatası alarak doğrudan reddedilir. Google ve Yahoo, 2024 itibarıyla günde 5.000'den fazla mesaj gönderen göndericiler için DMARC politikası zorunluluğunu hayata geçirmiştir; bu değişiklik, Microsoft 365 yöneticilerinin de benzer kısıtlamaları uygulayacağına ilişkin sinyallerle birlikte değerlendirilmelidir.
Gönderen sunucunun IP adresi, alıcı e-posta sistemleri tarafından sürekli değerlendirilen bir itibar göstergesidir. Spamhaus, SURBL ve Barracuda gibi kara liste sağlayıcıları, kötüye kullanım şikayeti alan ya da spam aktivitesi tespit edilen IP adreslerini listelerine ekler. Bir IP kara listeye girdiğinde, o IP üzerinden gönderilen tüm mesajlar büyük olasılıkla 554 koduyla reddedilir.
IP itibarını kontrol etmek için kullanılabilecek araçlar arasında MXToolbox Blacklist Checker, Google Postmaster Tools ve Microsoft's Smart Network Data Services (SNDS) öne çıkar. Kara listeden çıkarılma (delisting) süreci her sağlayıcıya göre farklıdır; Spamhaus için doğrudan delisting talebi sayfası üzerinden başvuru yapılabilir, ancak sorun giderilmeden yapılan başvurular genellikle reddedilir.
Alıcı sunucu tarafındaki içerik filtreleri, mesaj metnini, HTML yapısını, gömülü bağlantıları ve ek dosyaları analiz eder. Microsoft Exchange Online Protection (EOP) ve Google Gmail, içerik filtreleme için makine öğrenmesi tabanlı motorlar kullanır; bu motorlar belirli kalıpları spam ya da kötü amaçlı yazılım taşıyıcısı olarak işaretleyebilir. Yüksek riskli durumlar şunlardır:
554 hatası aldığınızda sistematik bir yaklaşım benimsemek zaman kaybını önler. Aşağıdaki adımları sırasıyla uygulayın:
dig TXT alanadi.com ve dig TXT _dmarc.alanadi.com komutlarıyla SPF ve DMARC kayıtlarının mevcut ve doğru olduğunu doğrulayın. DKIM seçicisi için dig TXT selector._domainkey.alanadi.com sorgusunu çalıştırın.554, kalıcı bir red kodudur (permanent failure). RFC 5321'e göre 5xx yanıtları alındığında mesaj kuyruğundan silinmeli, gönderici sorunun nedenini tespit edip giderdikten sonra yeniden denemelidir. Otomatik yeniden gönderim denemeleri sonuç vermez; aksine gönderen itibarını olumsuz etkileyebilir.
SPF kaydının doğru olması tek başına yeterli değildir. DMARC politikası SPF hizalaması (alignment) gerektirir; yani RFC 5322 From: başlığındaki alan adının SPF tarafından doğrulanan alan adıyla eşleşmesi şarttır. Üçüncü taraf bir gönderim sistemi kullanıyorsanız ve From adresi sizin alan adınızdan geliyorsa, bu sistemin IP'lerinin de SPF kaydınızda tanımlı olması ya da alt alan adınızda ayrı bir DKIM imzası kullanması gerekir.
Bu süre kara liste sağlayıcısına ve ihlal şiddetine göre değişir. Spamhaus SBL'de otomatik temizlenme genellikle aktif spam faaliyeti durduğunda gerçekleşir; manuel delisting talebi ise birkaç saatla birkaç iş günü arasında sonuçlanabilir. Microsoft SNDS ve Google Postmaster'da itibar, şikayet oranı düştükçe kademeli olarak iyileşir; bu süreç birkaç haftayı bulabilir.
SMTP gelişmiş durum kodları (enhanced status codes) RFC 3463 ile tanımlanmıştır. 5.7.1 genel bir politika reddi ya da SPF/DMARC başarısızlığını, 5.7.5 ise kriptografik kimlik doğrulama hatalarını (genellikle DKIM) işaret eder. Her iki durumda da hata kalıcıdır; ancak çözüm yolu farklıdır.
En yaygın nedenler şunlardır: DNS'teki açık anahtarın sunucudaki özel anahtarla eşleşmemesi, mesajın iletim sırasında değiştirilmesi (örneğin mailing list uygulamalarının başlık eklemesi), seçici (selector) DNS kaydının yanlış biçimlendirilmesi veya TTL süresi dolmadan yapılan anahtar rotasyonu. DKIM doğrulamasını test etmek için opendkim-testkey aracından ya da mail-tester.com gibi çevrimiçi hizmetlerden yararlanabilirsiniz.
Google (Gmail) ve Microsoft (Exchange Online/Outlook.com) en sıkı DMARC ve içerik filtreleme politikalarına sahip sağlayıcılar arasındadır. 2024'te Gmail ve Yahoo'nun uygulamaya koyduğu zorunlu gönderici gereksinimleri, DMARC politikasını p=none değil en az p=quarantine düzeyinde belirlemiş alan adlarına mesaj iletimini kolaylaştırmaktadır. SPF ve DKIM kayıtlarınızın eksiksiz ve hizalı olması bu platformlara teslimatta belirleyici rol oynar.
Toplu gönderimde alınabilecek önlemler şunlardır: ısınma (IP warming) sürecine uygun göndermek, liste hijyenini koruyarak geçersiz adresleri düzenli aralıklarla temizlemek, abonelik kaldırma (unsubscribe) mekanizmasını RFC 8058'e uygun biçimde uygulamak, şikayet oranını izlemek ve eşik değerleri aşıldığında gönderimi durdurmak. Connect365 gibi platformlar bu süreçleri otomatikleştiren araçlar sunar.
"Policy Violation" ifadesi çoğunlukla alıcı organizasyonun kendi e-posta güvenlik politikasını (örneğin Exchange Transport Rule veya SEG kuralı) devreye girmesiyle üretilir. Bu durumda sorun genellikle kimlik doğrulama değil, içerik veya gönderim davranışı ile ilgilidir. Hatanın tam metninde belirtilen politika kodu ya da referans numarasını alıcı BT ekibiyle paylaşarak netlik kazanabilirsiniz.
Önleyici yaklaşım üç katmanda ele alınabilir: teknik (SPF, DKIM, DMARC'ın eksiksiz yapılandırılması ve periyodik doğrulanması), operasyonel (gönderim listelerinin güncellenmesi, şikayet oranının izlenmesi, IP itibar araçlarıyla düzenli tarama) ve içerik odaklı (spam-trigger kelimelerden kaçınma, metin-görsel oranının dengelenmesi, kısa URL'ler yerine tam bağlantıların kullanılması). Bu üç katmanı birlikte yönetmek, 554 hatasıyla karşılaşma olasılığını önemli ölçüde azaltır.
554 kalıcı bir ret olduğundan, orijinal mesaj sunucu kuyruğundan silinmiş olacaktır. Sorunu giderdikten sonra mesajı yeni bir gönderim olarak oluşturup tekrar göndermeniz gerekir. Otomatik yeniden deneme (retry) mekanizması 5xx kodlarında çalışmaz; bu davranış RFC 5321'in 4.5.4 bölümünde açıkça belirtilmiştir.
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.