E-postanın ilk tasarımında göndericinin kimliğini doğrulayan bir mekanizma yoktu. Herkes, herhangi bir adres adına e-posta gönderebiliyordu. SPF, DKIM ve DMARC bu açığı kapatmak için geliştirilen üç DNS kaydıdır. Birlikte, alıcı sunucuya “bu e-posta gerçekten bu alan adından geldi ve yolda değiştirilmedi” der. Eksik ya da hatalı olduklarında e-postalarınız spam klasörüne düşer, reddedilir ya da alan adınız sahte e-postalarda kullanılır. Bu rehberde üç kaydı sırasıyla açıklıyor, örnek değerler veriyor ve kurulum sırasını adım adım anlatıyoruz. Kurumsal e-posta altyapısının genel çerçevesi için kurumsal e-posta sayfamıza bakabilirsiniz.
Neden artık zorunlu?
Bu kayıtlar uzun yıllar “olsa iyi olur” kategorisindeydi. Büyük e-posta sağlayıcıları bunu değiştirdi:
- Google: Gmail’in gönderici yönergelerine göre kişisel Gmail hesaplarına e-posta gönderen herkes en az SPF ya da DKIM kurmalı, geçerli ileri ve ters DNS (PTR) kayıtlarına sahip olmalı ve TLS bağlantısı kullanmalıdır. Günde 5.000’den fazla Gmail adresine gönderim yapan toplu göndericiler SPF, DKIM ve DMARC’ın üçünü birden kurmalı, pazarlama e-postalarında tek tıkla abonelikten çıkmayı desteklemelidir. Google, Kasım 2025’ten itibaren gereksinimlere uymayan trafiğe yönelik uygulamayı sıkılaştırdığını, bu e-postaların geçici ya da kalıcı olarak reddedilebileceğini belirtir.
- Yahoo: Yahoo Sender Hub’a göre tüm göndericiler en az SPF ya da DKIM uygulamalıdır. Toplu göndericiler ise SPF ve DKIM’in ikisini de kurmalı, en az p=none politikalı bir DMARC kaydı yayımlamalı ve abonelikten çıkma taleplerini iki gün içinde işlemelidir.
- Microsoft: Microsoft, Outlook.com adreslerine günde 5.000’den fazla e-posta gönderen alan adları için SPF, DKIM ve DMARC’ı zorunlu kıldığını duyurdu. Uyumsuz toplu gönderimler önce önemsiz klasörüne yönlendirildi, kimlik doğrulamasını geçemeyen e-postalar ise reddedilir.
Her gün toplu gönderim yapmıyor olabilirsiniz. Ancak aynı kayıtlar küçük bir işletmenin teklif ve fatura e-postalarının da güvenilir görünmesini sağlar. Bu yüzden her kurumsal alan adında üçünü de kurmanızı öneriyoruz.
SPF: Kim gönderebilir?
SPF (Sender Policy Framework), alan adınız adına e-posta göndermeye yetkili sunucuların listesidir. Alan adınızın DNS’ine TXT kaydı olarak eklenir. Alıcı sunucu, gelen e-postanın gönderildiği IP adresini bu listeyle karşılaştırır.
Örnek SPF kaydı (TXT, ad: alanadiniz.com.tr): v=spf1 ip4:203.0.113.10 include:gonderim.saglayiciniz.com -all
| Parça | Anlamı |
|---|---|
| v=spf1 | Kaydın bir SPF kaydı olduğunu belirtir. |
| ip4:203.0.113.10 | Bu IP adresi alan adınız adına gönderim yapabilir (örneğin kendi e-posta sunucunuz). |
| include:... | Başka bir hizmetin SPF listesini dahil eder: e-posta sağlayıcınız, bülten aracınız, muhasebe yazılımınız. |
| -all | Listede olmayan her kaynağı reddet. Daha yumuşak seçenek ~all’dır (şüpheli olarak işaretle). |
Dikkat edilecek noktalar: Bir alan adında yalnızca bir SPF kaydı olmalıdır; iki ayrı kayıt SPF’i geçersiz kılar. SPF kontrolü en fazla 10 DNS sorgusuna izin verir, çok sayıda include eklendiğinde bu sınır aşılabilir. Fatura gönderen ERP’nizi, web sitenizin iletişim formunu ve bülten aracınızı listeye eklemeyi unutmayın.
DKIM: Yolda değişti mi?
DKIM (DomainKeys Identified Mail), giden her e-postaya dijital bir imza ekler. İmza, gönderen sunucudaki özel anahtarla oluşturulur; alıcı sunucu, DNS’te yayımlanan açık anahtarla imzayı doğrular. İmza doğrulanıyorsa e-posta gerçekten alan adınız adına gönderilmiştir ve içeriği yolda değiştirilmemiştir.
Örnek DKIM kaydı (TXT, ad: secici1._domainkey.alanadiniz.com.tr): v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(açık anahtarın devamı)
Kaydın adındaki “secici1” bölümü seçicidir (selector). Farklı gönderim hizmetleri farklı seçicilerle kendi anahtarlarını kullanabilir. Açık anahtarı siz üretmezsiniz; e-posta sunucunuz ya da sağlayıcınız üretir, siz yalnızca DNS’e eklersiniz. Güncel uygulamada en az 2048 bit RSA anahtar kullanılması önerilir.
DMARC: Doğrulama başarısız olursa ne olsun?
DMARC, SPF ve DKIM’i birbirine bağlar ve alıcı sunucuya iki soru için talimat verir: Doğrulama başarısız olursa e-postaya ne yapılsın? Sonuçlar kime raporlansın? DMARC’ın kritik şartı hizalamadır (alignment): alıcının gördüğü “Kimden” adresindeki alan adı, SPF ya da DKIM ile doğrulanan alan adıyla eşleşmelidir.
Örnek DMARC kaydı (TXT, ad: _dmarc.alanadiniz.com.tr): v=DMARC1; p=none; rua=mailto:dmarc-rapor@alanadiniz.com.tr
| Politika | Alıcı sunucu ne yapar? | Ne zaman kullanılır? |
|---|---|---|
| p=none | Hiçbir işlem yapmaz, yalnızca raporlar. | Başlangıç: kimlerin adınıza e-posta gönderdiğini görmek için. |
| p=quarantine | Doğrulanamayan e-postayı spam klasörüne alır. | Raporlar temizlendikten sonra ara aşama. |
| p=reject | Doğrulanamayan e-postayı reddeder. | Hedef: alan adınızın sahte e-postalarda kullanılmasını engellemek. |
Adım adım kurulum sırası
- Göndericileri listeleyin. Alan adınız adına e-posta gönderen her şeyi yazın: e-posta sunucusu, web sitesi formları, CRM, ERP, fatura yazılımı, bülten aracı, yazıcı ve tarayıcılar.
- SPF kaydını oluşturun. Tüm meşru kaynakları tek bir kayıtta toplayın. İlk aşamada ~all ile başlayıp her şey doğrulandıktan sonra -all’a geçebilirsiniz.
- DKIM’i etkinleştirin. Her gönderim hizmetinde DKIM imzalamayı açın ve verdiği açık anahtarı DNS’e ekleyin.
- DMARC’ı p=none ile yayımlayın. Rapor adresini tanımlayın ve birkaç hafta boyunca raporları izleyin. Listede unuttuğunuz bir gönderici varsa raporlarda görünecektir.
- Politikayı kademeli sıkılaştırın. Meşru tüm kaynaklar doğrulandığında p=quarantine’e, ardından p=reject’e geçin.
- Test edin ve izlemeye devam edin. Kendi adresinize ve Gmail, Outlook gibi hesaplara test e-postası gönderin; e-posta başlığında SPF, DKIM ve DMARC sonuçlarının “pass” olduğunu kontrol edin. Yeni bir yazılım eklendiğinde kayıtları güncelleyin.
Kayıtlar doğru olduğu hâlde e-postalarınız hâlâ spam’e düşüyorsa sorun başka bir yerde olabilir. E-postalarım neden spam klasörüne düşüyor? yazımızda diğer yaygın nedenleri ele aldık.
Sık yapılan hatalar
- İki ayrı SPF kaydı yayımlamak. Yeni bir hizmet eklenirken mevcut kayda ekleme yapmak yerine ikinci bir TXT kaydı oluşturulur. Sonuç: SPF tamamen geçersiz olur.
- DMARC’ı doğrudan p=reject ile başlatmak. Listede unutulmuş bir fatura yazılımı ya da bülten aracı varsa bu e-postalar bir anda reddedilir. Önce izleyin, sonra sıkılaştırın.
- Raporları hiç okumamak. DMARC raporları XML biçiminde gelir ve okunması zordur. Raporları anlaşılır hâle getiren bir araç ya da bir destek ortağı olmadan p=none aşaması sonsuza kadar sürer.
- Alt alan adlarını unutmak. Bülten gönderimleri için kullanılan alt alan adları da kendi kayıtlarına ihtiyaç duyar.
- Yönlendirilen e-postaları gözden kaçırmak. Bir e-posta başka bir adrese otomatik yönlendirildiğinde SPF kontrolü başarısız olabilir. DKIM imzası bu durumda da geçerli kaldığı için DKIM’i her zaman SPF ile birlikte kurun.
- Kayıtları bir kez kurup unutmak. Yeni bir CRM ya da e-fatura hizmeti devreye alındığında kayıtların güncellenmesi gerekir.
Unna ile e-posta kimlik doğrulaması
Unna Kurumsal Mail ile SPF, DKIM ve DMARC kayıtları kurulumla birlikte yapılandırılır. Kendi e-posta sunucusunu işleten kurumlarda ise MailChannels ile giden e-postayı filtreleyerek ele geçirilmiş bir hesabın IP itibarınızı zedelemesini önleriz. Mevcut kayıtlarınızı inceleyip eksikleri çıkarmamızı isterseniz bize yazın. Alan adınız adına kimlerin e-posta gönderdiğini birlikte bulur, DMARC politikanızı işinizi aksatmadan adım adım sıkılaştırırız.
