E-postalar neden spam klasörüne düşer? Şirketler için teşhis sırası
Teklifiniz görünmediğinde konu satırını sürekli değiştirmek veya bütün DNS kayıtlarını yeniden yazmak en kısa yol değildir. Aynı şirketin farklı mesajları farklı sonuçlar alabilir. Alıcı alan adı, tarih, gönderim kaynağı ve hata bilgisiyle başlayan bir inceleme, sorunun nerede oluştuğunu daha iyi gösterir.
Bir e-postanın spam klasörüne düşmesi tek bir nedene bağlı değildir. Alıcı hizmet; alan adı doğrulamasını, gönderici itibarını, mesajın yapısını ve kullanıcı geri bildirimlerini birlikte değerlendirebilir. Önce spam sınıflandırmasını teslimat reddinden ayırın, sonra gerçek mesajın başlıklarıyla kontrol edin.
Bu rehber kimler için? Teklif ve müşteri yazışmalarında teslimat sorunu yaşayan şirketler ve IT ekipleri
1. Spam, red ve gecikmeyi ayırın
Alıcının spam klasöründe görünen mesaj sunucuya ulaşmış, ancak farklı sınıflandırılmıştır. Göndericiye dönen bir hata raporu ise teslimatın reddedildiğini veya başarısız olduğunu gösterebilir. Uygulamanın giden kutusunda bekleyen mesaj henüz gönderilmemiş de olabilir. Bu üç duruma aynı DNS değişikliğiyle yaklaşmayın.
Önce hangi sonucun gerçekleştiğini sorumlu kişilerle doğrulayın. Alıcının adresi doğru mu, kutusu dolu mu, mesaj karantinada mı? Aynı göndericiden her alıcıya mı sorun var, yoksa belirli bir şirkete mi? Destek kaydında konu ve tarih gibi ayırt edici bilgileri tutun. Tam mesaj içeriğini yayımlamak yerine gerekli teknik bilgileri yetkili destek kanalından paylaşın.
2. Gönderim kaynağına göre kimlik doğrulamasını inceleyin
Bir çalışan kutusundan gönderilen mesaj ile web sitesinin form bildirimi farklı sunuculardan çıkabilir. Hangi uygulamanın gönderdiğini belirleyin ve o kaynağın test mesajını inceleyin. Son alıcıdaki güvenilir Authentication-Results başlığı, SPF, DKIM ve DMARC değerlendirmesini görmeye yardım eder. DNS panelindeki yeşil bir kontrol, her yazılımın aynı kimliği kullandığını garanti etmez.
Google kişisel Gmail hesaplarına gönderim için bütün göndericilerden SPF veya DKIM, geçerli ileri ve geri DNS ile TLS gibi koşullar ister; daha yüksek hacimler için ek şartlar vardır. Şirketinize ait DNS kayıtlarını kontrol ederken altyapıdaki PTR sorumluluğunu da sağlayıcıyla ayırın. PTR değerini sıradan bir TXT kaydı ekleyerek değiştiremezsiniz. Kesin çözüm için hangi katmanda hata olduğu anlaşılmalıdır.
| Gözlem | İlk kontrol | Örnek inceleme sorusu |
|---|---|---|
| Sadece form mesajları sorunlu | Formun gönderim sunucusu ve kimliği | Uygulama yetkili SMTP ile mi gönderiyor? |
| Belirli alıcı şirket sorunlu | Alıcının filtreleri ve red bilgisi | Mesaj spamda mı, karantinada mı, reddedildi mi? |
| DNS değişiminden sonra sorun | SPF, DKIM ve uyum | Eski göndericiler kayıtta yanlış mı kaldı? |
| Mesaj giden kutusunda bekliyor | İstemci SMTP bağlantısı | Sunucuya gönderim tamamlandı mı? |
3. Mesajın okunabilirliğini ve bağlantılarını kontrol edin
Alıcıya göndericiyi, yazışmanın nedenini ve beklenen yanıtı açıkça anlatan kısa bir mesaj yazın. Yanıltıcı görünen konu satırları, gereksiz aciliyet ve gerçek bir önceki yazışma yokken cevap izlenimi veren ifadeler güveni azaltabilir. Bir teklifin ne hakkında olduğu konu ve ilk paragrafta anlaşılmalıdır. Her kurum için kesin bir yasak kelime listesi yoktur.
Mesajın tamamını tek büyük görsel olarak göndermek yerine önemli bilgileri metinde de verin. Bağlantının gideceği adresin anlaşılır olmasına dikkat edin; gereksiz kısaltıcılar ve açıklamasız çok sayıda bağlantı kullanmayın. Ekler büyükse alıcının kurallarını ve sağlayıcının sınırlarını kontrol edin. Mesajın başarılı olması yalnızca tasarımın gösterişli görünmesine değil, alıcının beklediği iş yazışmasına uymasına da bağlıdır.
Konu: Ofis ağ kurulumu teklifi — görüşmemize istinaden İlk paragraf: Bugünkü görüşmemizde paylaştığınız ihtiyaçlara göre hazırladığımız teklif ektedir. Kapsam, teslim süresi ve ücret kalemleri dosyada ayrı gösterilmiştir. Bu metin bir yazışma örneğidir; belirli ifadelerin spam filtresini aşacağını vaat etmez.
4. Gönderim alışkanlıklarını ve izinleri gözden geçirin
Satın alınan adres listeleri, beklenmeyen kampanyalar ve ani yüksek hacim alıcı şikâyetlerine neden olabilir. İş yazışmaları ile toplu pazarlama gönderimleri farklı ihtiyaçlardır. TekPosta şirketlerin günlük e-posta kullanımına yöneliktir; kampanya dağıtım aracı gibi kullanmayın. Kampanyalar için izin yönetimi ve abonelikten çıkma akışı olan uygun bir platform gerekir.
Kullanıcı kutusundan alışılmadık sayıda mesaj çıkıyorsa yalnızca teslimat sorunu olarak görmeyin. Yetkisiz erişim veya bir uygulamanın yanlış çalışması da araştırılmalıdır. Etkilenen cihazı, uygulama şifrelerini ve gönderim kaynağını inceleyin. Düzenli bir takip kaydı, sorun düzeldiğinde gönderim davranışının gerçekten normale döndüğünü görmenizi sağlar. İtibarın yeniden değerlendirilmesi her alıcı sisteminde aynı hızda olmaz.
5. Kontrollü test yapın; aynı mesajı durmadan göndermeyin
Küçük bir test grubunda kısa metin, ekli mesaj ve normal iş mesajı için ayrı örnekler kullanın. Her denemede yalnızca bir anlamlı değişiklik yapın; gönderici, içerik ve DNS aynı anda değişirse hangi düzeltmenin etkili olduğu anlaşılmaz. Başarısız bir mesajı çok sayıda kişiye yeniden göndermek sorunu incelemek yerine büyütebilir.
Birden fazla alıcı sağlayıcısındaki sonucu karşılaştırın. Tek bir denemenin gelen kutusuna ulaşması bütün şirket için kalıcı garanti değildir. Aynı şekilde bir spam sonucu tek başına bütün altyapının hatalı olduğunu kanıtlamaz. Alıcıdan mesajı ve başlık bilgisini yetkili biçimde incelemek için yardım isteyin. Gerçek bir yazışmada alıcının göndereni tanıması ve doğru adresi kullanması da önemlidir.
6. Destek ekibine karar verdiren bilgileri verin
Faydalı bir destek kaydı, sorunun ne zaman ve hangi iş akışında ortaya çıktığını gösterir. Gönderici adresi, alıcı alan adı, yaklaşık saat, varsa Message-ID ve tam hata kodu incelemeyi hızlandırır. Ekran görüntüsü alıyorsanız şifreleri, özel içerikleri ve gereksiz kişisel bilgileri kapatın. Mesaj başlıklarını herkese açık bir forumda paylaşmayın.
Düzeltmeden sonra aynı iş akışını yeniden test edin ve sonucu kayıt altına alın. DNS değişikliği yapıldıysa yayını, uygulama ayarı değiştiyse gerçek gönderim kaynağını yeniden doğrulayın. Hedef yalnızca bir örnek mesajın ulaşması değil, şirketin normal yazışmasının anlaşılır ve sürdürülebilir biçimde devam etmesidir.
- Spam klasörü mü, red raporu mu, gönderim kuyruğu mu?
- Hangi uygulama ve hangi alıcı alan adı etkileniyor?
- Doğrulama sonuçları ve hata kodu ne söylüyor?
- Sorundan hemen önce DNS veya gönderim davranışı değişti mi?
- Düzeltme aynı iş akışında yeniden denendi mi?
Sık sorulan sorular
DNS kayıtları doğruyken neden spam sonucu olur?
DNS doğrulaması tek değerlendirme değildir. Alıcı hizmetin itibara, içeriğe ve kullanıcı davranışına ilişkin filtreleri de sonucu etkiler; gerçek mesajın bağlamı incelenmelidir.
Konu satırını değiştirirsem sorun kesin çözülür mü?
Hayır. Kesin bir kelime veya konu formülü yoktur. Önce kimlik doğrulama ve gönderim kaynağı kontrol edilmeli, içerik açık ve beklenen iş yazışmasına uygun olmalıdır.
Teslimat sorunu için hangi bilgileri saklamalıyım?
Gönderici, alıcı alan adı, tarih ve saat, uygulama adı, varsa Message-ID ve tam hata kodu. Şifreler ve özel mesaj içeriği destek kaydına gereksiz yere eklenmemelidir.
Kaynaklar ve doğrulama
Teknik adımları uygularken aşağıdaki kaynakları ve kullandığınız sağlayıcının güncel ayarlarını birlikte kontrol edin. Örnek kayıtlar kendi domaininiz için panelde üretilen değerlerin yerine geçmez.
Şirketinizin e-postasını kendi domaininizde yönetin
TekPosta'da domain, DNS doğrulama, mail adresleri, uygulama şifreleri ve taşıma adımlarını aynı panelden takip edebilirsiniz. Ekibinizin ihtiyacına uygun planı inceleyin veya geçiş planınızı bizimle paylaşın.