Destek e-postalarınız neden spam'e düşüyor? SPF, DKIM ve DMARC rehberi

"Cevap gelmedi" diyen müşteri, "gönderdik" diyen ekip

Destek ekiplerinin en sinir bozucu konuşmalarından biri şudur. Müşteri ikinci kez yazar ve iki gündür cevap beklediğini söyler. Temsilci gönderilmiş öğeler klasörünü açar, yanıtın aynı gün gittiğini görür. İkisi de haklıdır. Yanıt gönderilmiştir ama müşterinin gelen kutusuna değil, önemsiz klasörüne ulaşmıştır.

Bu durumun sebebi çoğu zaman yanıtın içeriği değil, gönderen alan adının kimliğini kanıtlayamamasıdır. Büyük e-posta sağlayıcıları son iki yılda bu konuda kuralları belirgin şekilde sıkılaştırdı. Bu yazıda SPF, DKIM ve DMARC'ın ne olduğunu, Gmail ve Outlook'un hangi kuralları getirdiğini ve destek kutusuna helpdesk, CRM ya da yapay zeka asistanı gibi yeni bir gönderen eklerken neyin kontrol edilmesi gerektiğini anlatıyoruz.

Kuralları kim, ne zaman değiştirdi?

Google'ın e-posta gönderen yönergelerine göre 1 Şubat 2024'ten itibaren kişisel Gmail hesaplarına e-posta gönderen herkes için şu şartlar geçerli:

• SPF veya DKIM ile kimlik doğrulama
• Gönderen sunucular için geçerli ileri ve ters DNS kaydı
• İletim sırasında TLS bağlantısı
• Postmaster Tools'ta ölçülen spam şikayet oranının yüzde 0,3'ün altında kalması

Günde 5.000'e yakın ya da daha fazla ileti gönderen toplu göndericiler için çıta daha yüksek. Bu alan adlarından SPF ve DKIM'in birlikte kurulması, en az "none" politikalı bir DMARC kaydı, gönderen adresindeki alan adının SPF ya da DKIM alan adıyla hizalanması ve pazarlama iletilerinde tek tıkla abonelikten çıkma bekleniyor.

İki ayrıntı destek ekipleri için özellikle önemli. Google'ın toplu gönderici sorularına verdiği cevaplarda belirttiğine göre 5.000 eşiği hesaplanırken aynı ana alan adından gönderilen bütün iletiler sayılıyor; alt alan adlarından çıkan iletiler de bu toplama giriyor. Ayrıca toplu gönderici statüsünün bir bitiş tarihi yok. Bir kez bu gruba giren alan adı kalıcı olarak toplu gönderici sayılıyor.

Microsoft da benzer bir adım attı. Microsoft'un duyurusuna göre 5 Mayıs 2025'ten itibaren Outlook.com, Hotmail ve Live adreslerine günde 5.000'den fazla ileti gönderen alan adlarından SPF, DKIM ve DMARC şartı aranıyor. Şartı karşılamayan iletiler önce önemsiz klasörüne yönlendiriliyor, ardından reddediliyor.

SPF: adınıza kim gönderebilir?

SPF, alan adınızın DNS kayıtlarına eklenen bir TXT kaydıdır. Bu kayıt "benim alan adımdan e-posta gönderme yetkisi şu sunuculardadır" der. Alıcı sunucu gelen iletinin hangi sunucudan çıktığına bakar ve bu listeyle karşılaştırır.

Destek ekiplerinde SPF'in en sık bozulduğu an yeni bir araç eklendiği andır. Şirketin e-posta altyapısı Google Workspace ya da Microsoft 365 üzerindedir ve SPF kaydı buna göre yazılmıştır. Sonra bir helpdesk eklenir, ardından bir CRM, bir faturalama aracı, bir bülten servisi. Her biri müşteriye sizin adresinizden e-posta gönderir ama hiçbiri SPF kaydına eklenmemişse alıcı sunucu bu iletileri yetkisiz gönderim olarak görür.

İkinci tuzak sınırdır. SPF standardı olan RFC 7208, bir SPF kaydının değerlendirilmesi sırasında yapılabilecek DNS sorgusu sayısını 10 ile sınırlar. Her yeni servisi "include" ile eklemeye devam eden şirketler bir noktada bu sınırı aşar ve kayıt bütünüyle geçersiz sayılabilir. Kayıt büyüdükçe kullanılmayan servisleri temizlemek, gerekiyorsa gönderimi alt alan adlarına bölmek gerekir.

DKIM: iletinin imzası

DKIM, giden her iletiye kriptografik bir imza ekler. İmzanın doğrulanması için gereken açık anahtar alan adınızın DNS'inde yayımlanır. Alıcı sunucu imzayı bu anahtarla kontrol eder ve iki şeyi öğrenir: ileti gerçekten bu alan adı adına imzalanmış mı ve yolda değiştirilmiş mi?

SPF'ten farklı olarak DKIM, ileti başka bir sunucu üzerinden yönlendirildiğinde de çoğu zaman geçerliliğini korur. Bu yüzden helpdesk ve otomasyon araçlarında DKIM'i kendi alan adınızla kurmak önemlidir. Birçok servis varsayılan olarak kendi alan adıyla imza atar. Bu durumda imza geçerlidir ama sizin alan adınızla hizalı değildir ve DMARC açısından işe yaramaz. Her gönderen servis için kendi alan adınıza ait bir DKIM anahtarı tanımlanmalıdır.

DMARC: politika, hizalama ve raporlar

DMARC, SPF ve DKIM'in sonucunu müşterinin gördüğü gönderen adresiyle eşleştirir. Bu eşleşmeye hizalama denir. Müşteri "destek@firma.com" adresinden gelen bir ileti görüyorsa, SPF ya da DKIM kontrolünün de firma.com adına geçmesi gerekir.

DMARC kaydı üç politikadan birini söyler. "none" yalnızca izler ve rapor ister, iletiye müdahale etmez. "quarantine" doğrulamayı geçemeyen iletinin şüpheli muamelesi görmesini, genellikle önemsiz klasörüne gitmesini ister. "reject" bu iletinin reddedilmesini ister. Google'ın toplu gönderici şartı için "none" yeterlidir ama asıl değer raporlardadır. DMARC raporları alan adınız adına kimlerin e-posta gönderdiğini, hangisinin doğrulamayı geçtiğini ve hangisinin geçemediğini gösterir. Unutulmuş bir faturalama aracı ya da alan adınızı taklit eden bir oltalama girişimi bu raporlarda görünür hale gelir.

Destek yanıtı neden bültenin bedelini öder?

Çoğu şirkette destek yanıtları ile pazarlama gönderimleri aynı alan adından çıkar. Bülten trafiği büyükken destek trafiği küçüktür ve görünürde ikisi birbirinden bağımsızdır. Oysa alıcı sunucu açısından ikisi aynı göndericidir.

Google'ın hesaplama mantığı bunu netleştiriyor. 5.000 eşiği ana alan adından çıkan tüm iletiler toplanarak hesaplandığı için bir kampanya günü alan adını kalıcı olarak toplu gönderici statüsüne taşıyabilir. Bu andan itibaren destek yanıtları da toplu gönderici şartlarına göre değerlendirilir. Bülten tarafında yükselen spam şikayet oranı da aynı alan adının itibarını etkiler.

Alt alan adı kullanmak 5.000 eşiğinden kaçmanın yolu değildir, çünkü alt alan adları da ana alan adının toplamına girer. Ancak bülten ve destek trafiğini ayrı alt alan adlarına ve ayrı DKIM anahtarlarına ayırmak, DMARC raporlarında hangi trafiğin sorun çıkardığını görmeyi kolaylaştırır. Destek yanıtının teslimi bir pazarlama kararının yan etkisi olmamalı.

Abonelikten çıkma ve İYS: destek e-postasını ne ilgilendirir?

Tek tıkla abonelikten çıkma şartı destek yanıtları için geçerli değildir. Google'ın açıklamasına göre bu şart yalnızca pazarlama ve tanıtım iletileri için aranır; şifre sıfırlama ya da rezervasyon onayı gibi işlem iletileri kapsam dışındadır.

Türk mevzuatında da benzer bir ayrım var. 6563 sayılı Kanun ve İleti Yönetim Sistemi kuralları gereği kampanya, indirim ve tanıtım içeren ticari e-postalar için alıcının önceden onayı ve bu onayın İYS'de kayıtlı olması gerekir. Sipariş, fatura, şifre ve destek yanıtı gibi müşterinin mevcut işlemiyle ilgili bilgilendirmeler ise onaya tabi değildir.

Destek ekipleri için pratik kural basit: destek yanıtına kampanya içeriği eklemeyin. "Sorununuz çözüldü, bu arada yeni koleksiyonumuza göz atın" cümlesi, işlem e-postasını ticari iletiye dönüştürür. O andan sonra İYS onayı, abonelikten çıkma bağlantısı ve spam şikayeti riski devreye girer.

Yapay zeka asistanı eklerken kontrol listesi

Destek kutusuna gelen e-postaları yanıtlayan bir yapay zeka asistanı da teknik olarak yeni bir gönderen servistir. Yanıtlar sizin alan adınızdan ve sizin imzanızla gider. Bu yüzden kurulumdan önce şu adımlar kontrol edilmelidir:

1. SPF kaydı: Asistanın gönderim yolu SPF kaydına eklendi mi, kayıt 10 DNS sorgusu sınırının altında mı?
2. DKIM anahtarı: Asistanın gönderdiği yanıtlar sizin alan adınıza ait bir anahtarla mı imzalanıyor?
3. DMARC hizalaması: Gönderen adresindeki alan adı ile SPF ya da DKIM alan adı eşleşiyor mu? Raporlarda asistanın trafiği "geçti" olarak görünüyor mu?
4. Zincir bütünlüğü: Yanıt yeni bir e-posta olarak değil, müşterinin yazdığı zincirin içine mi gidiyor? Zincir dışı yanıtlar müşteri tarafında hem kafa karıştırır hem de şüpheli görünür.
5. İçerik disiplini: Asistanın yanıt şablonlarında kampanya, indirim ya da tanıtım içeriği var mı? Varsa çıkarılmalı.
6. Takip e-postaları: Açık talep hatırlatmaları ve memnuniyet soruları işlem e-postası sınırında mı kalıyor?

Bu kontroller yalnızca yapay zeka için değil, destek kutusuna eklenen her araç için geçerlidir. Fark şu ki asistan rutin soruları kendisi yanıtladığında gönderilen yanıt sayısı artar ve teslim edilebilirlik sorunu daha hızlı görünür hale gelir.

Sonuç: iyi yazılmış yanıt, ulaşmadıysa yazılmamış sayılır

Destek ekipleri yanıtın içeriğine, tonuna ve doğruluğuna büyük emek verir. Bu emeğin karşılığı yanıtın müşterinin gelen kutusuna ulaşmasıyla alınır. SPF, DKIM ve DMARC bu yolun altyapısıdır ve Gmail ile Outlook'un son kurallarıyla artık tercih değil, ön koşuldur.

Destek kutunuzu okuyan, cevabı bilgi tabanınızdan çözümle yazan ve yanıtlarını alan adınızın kimlik doğrulama kayıtlarıyla uyumlu gönderen bir asistanın nasıl kurulduğunu e-posta asistanı sayfamızda anlattık. Kendi kutunuzun yapısını konuşmak için iletişim formunu doldurabilirsiniz.