Gönderdiğiniz mailler neden spama düşüyor? SPF, DKIM ve DMARC
Mailleriniz karşı tarafta spama düşüyorsa ilk bakılacak yer SPF, DKIM ve DMARC kayıtlarıdır. Gmail ve Microsoft'un kuralları ve adım adım kontrol.
Mailler karşı tarafta spama düşüyorsa sebep çoğu zaman alan adınızda SPF, DKIM ya da DMARC kaydının eksik veya hatalı olmasıdır. Alıcının sunucusu bu kayıtlara bakarak maili gerçekten sizin gönderip göndermediğinizi anlar. Kayıt yoksa ya da hatalıysa maili şüpheli sayar. İlk iş alan adınızın DNS kayıtlarını kontrol etmektir.
SPF, DKIM ve DMARC ne işe yarar?
Üçü de “bu mail gerçekten bu alan adından mı geldi?” sorusunu cevaplar. SPF, alan adınız adına hangi sunucuların mail gönderebileceğini listeler. DKIM, giden maile bir imza ekler; alıcı bu imzayı DNS’teki anahtarla doğrular. DMARC ise ilk ikisinden geçemeyen maile ne yapılacağını söyler ve size rapor gönderir.
Kısaca her biri:
- SPF: Alan adınızda tek bir TXT kaydıdır. Yalnız Microsoft 365’ten mail gönderiyorsanız Microsoft’un önerdiği kayıt şudur:
v=spf1 include:spf.protection.outlook.com -all - DKIM: Microsoft 365’te özel alan adınız için iki CNAME kaydı eklersiniz (
selector1._domainkeyveselector2._domainkey). Sonra imzalamayı Microsoft Defender portalından açarsınız. - DMARC:
_dmarcadında bir TXT kaydıdır. İçinde politika (p=none,p=quarantineya dap=reject) ve raporların gideceği adres (rua=) yazar.
Microsoft’un belgesi, özel alan adlarında SPF’nin yanına DKIM ve DMARC kaydının da eklenmesini istiyor.
Gmail ve Microsoft bu kayıtları istiyor mu?
Evet. Google, kişisel Gmail adreslerine mail gönderen herkesten SPF ya da DKIM kaydı istiyor. Günde 5.000’den fazla mail gönderenlerden SPF, DKIM ve DMARC’ın üçünü birden istiyor; bu durumda DMARC politikası none olabilir. Microsoft da özel alan adı kullanan her Microsoft 365 hesabında üçünün birlikte kurulmasını öneriyor.
Google’ın tüm gönderenler için saydığı diğer şartlar şunlar:
- Gönderen sunucunun IP adresi için geçerli ters DNS (PTR) kaydı olmalı.
- Mailler TLS ile şifreli bağlantı üzerinden gönderilmeli.
- Postmaster Tools’ta görünen spam şikâyet oranı %0,3’ün altında kalmalı.
Gönderdiğiniz mailler bir Gmail alıcısında spama düşüyorsa önce bu listeye bakın.
Mailler neden spama düşüyor, nasıl kontrol edersiniz?
Spama düşen bir mailin başlık bilgisinde (Outlook’ta “ileti kaynağı” ya da “ileti ayrıntıları”) Authentication-Results satırını bulun. Burada spf=, dkim= ve dmarc= sonuçları yazar. Hangisi fail diyorsa sorun oradadır. Bu satırı okumak, tahminle kayıt değiştirmekten daha hızlı sonuç verir.
Elinizde spama düşen bir mail yoksa kendiniz deneyin. Kendi alan adınızdan bir Gmail adresine mail gönderin. Gmail’de maili açıp “Orijinali göster” seçeneğine tıklayın. Açılan sayfanın üstünde SPF, DKIM ve DMARC sonuçları ayrı ayrı yazar. Üçü de PASS diyorsa kayıtlarınız Gmail tarafında doğru görünüyor demektir.
Sık karşılaşılan hatalar:
- İki SPF kaydı. Microsoft’un belgesine göre bir alan adında birden fazla SPF kaydı olursa SPF
permerrorverir. Bütün kaynakları tek kayıtta birleştirin. - Eksik gönderen. Faturaları muhasebe programınız, bültenleri bir pazarlama hizmeti gönderiyorsa bunların da SPF kaydında olması gerekir.
- 10 sorgu sınırı. SPF kaydı kontrol edilirken 10’dan fazla DNS sorgusu gerekirse SPF kalıcı hata verir. Her
include:en az bir sorgu sayılır. - DKIM kapalı. Microsoft’un belgesine göre özel alan adından giden mailler şu an kendiliğinden DKIM ile imzalanmıyor. İmzalamayı siz açmalısınız. DMARC’tan geçmek için imzayı atan alan adı, Kimden adresindeki alan adıyla eşleşmelidir.
- DMARC hiç yok. Kayıt yoksa alıcı tarafın kendi kuralları geçerli olur ve size hiçbir rapor gelmez.
DMARC kaydına nasıl başlanır?
Microsoft, DMARC’a p=none politikasıyla başlamayı ve raporları izlemeyi öneriyor. Raporlar, alan adınız adına hangi sunucuların mail gönderdiğini gösterir. Gerçek gönderenlerin hepsi SPF ya da DKIM’den geçtikten sonra p=quarantine, en sonunda p=reject politikasına geçersiniz. Bu sırayla gitmek, kendi maillerinizin reddedilmesini önler.
Başlangıç için örnek kayıt:
_dmarc TXT v=DMARC1; p=none; rua=mailto:[email protected]
Birkaç öneri:
- Raporları bir çalışanın kişisel kutusuna değil, ayrı bir posta kutusuna yönlendirin. Raporlar her gün gelir ve XML biçimindedir.
- Mail göndermediğiniz alan adlarınız varsa onlara
v=DMARC1; p=reject;kaydı ekleyin. Microsoft bunu kullanılmayan alan adları için öneriyor. - Toplu mail hizmetleri için ana alan adınız yerine bir alt alan adı kullanın. O hizmetteki bir sorun çalışanlarınızın maillerini etkilemez.
Kayıtlar tamam ama mailler hâlâ spama düşüyorsa?
Kayıtlar doğruysa sorun çoğu zaman gönderim alışkanlığındadır. Alıcılar maillerinizi spam diye işaretledikçe şikâyet oranı yükselir ve Gmail’in %0,3 sınırına yaklaşır. Günde 5.000’den fazla mail gönderiyorsanız Google, pazarlama maillerinde başlık bilgisinde abonelikten çıkma desteği (one-click unsubscribe) ve mail gövdesinde görünür bir çıkış bağlantısı da istiyor.
Bu noktada maili alan tarafla konuşmak da işe yarar. Karşı firmanın IT sorumlusu, mailin neden spama gittiğini kendi kayıtlarında görebilir.
SPF, DKIM ve DMARC kayıtlarını e-posta güvenliği kapsamında kuruyor, spama düşen mailleri inceliyoruz. Microsoft 365’e geçiyorsanız bu kayıtları Microsoft 365 kurulumunun ilk gününde ekliyoruz. Sahte e-postaya karşı diğer önlemleri siber saldırılara karşı koruma sayfasında anlattık.
Sık sorulan sorular
SPF kaydım var, yine de mailler spama düşüyor. Neden?
SPF tek başına yetmez. DKIM imzası ve DMARC kaydı da gerekir. Microsoft da yalnız SPF'nin yetmediğini yazıyor. Ayrıca alan adında birden fazla SPF kaydı varsa SPF hata verir.
DMARC kaydını eklersem maillerim reddedilir mi?
p=none ile başlarsanız hayır. Bu politika yalnız rapor toplar, maillere bir işlem uygulatmaz. Raporlar temiz çıktıkça quarantine ve reject politikasına adım adım geçersiniz.
Bu kayıtları nereye ekliyoruz?
Alan adınızın DNS kayıtlarını yönettiğiniz yere, çoğunlukla alan adını aldığınız firmanın paneline eklenir. Microsoft 365'te özel alan adları için SPF ve DMARC kaydını eklemenin bir panel ayarı yok.
Bülten ve kampanya maillerimizi başka bir hizmetten gönderiyoruz. Ne yapmalıyız?
Microsoft, doğrudan kontrol etmediğiniz toplu gönderim hizmetleri için ana alan adınız yerine ayrı bir alt alan adı kullanmanızı öneriyor. Böylece o hizmetteki bir sorun çalışanlarınızın maillerini etkilemez.