SPF, DKIM, DMARC nedir? Ayar rehberi

SPF, DKIM ve DMARC; alan adınız üzerinden gönderilen e-postaların gerçekten sizin tarafınızdan gönderildiğini kanıtlayan üç kimlik doğrulama kaydıdır. Doğru kurulduklarında hem sizin adınıza sahte e-posta gönderilmesini (spoofing) zorlaştırır hem de mesajlarınızın spam klasörü yerine gelen kutusuna ulaşma olasılığını artırır. Bu rehberde her birini örnek kayıtlarla, sık yapılan hatalarıyla ve 2024’te yürürlüğe giren Gmail/Yahoo zorunluluklarıyla birlikte ele alıyoruz.

Neden SPF, DKIM ve DMARC gerekli?

E-posta protokolü (SMTP) tasarımı gereği gönderici adresini doğrulamaz; yani teknik olarak herhangi biri, sizin alan adınızmış gibi görünen bir e-posta gönderebilir. Kimlik doğrulama kayıtları bu boşluğu üç katmanda kapatır:

• Spoofing ve kimlik avını zorlaştırır: Alıcı sunucu, gelen iletinin gerçekten sizin izin verdiğiniz bir kaynaktan geldiğini doğrulayabilir.
• Teslim edilebilirliği artırır: Kimliği doğrulanmış e-postalar, spam filtrelerinde daha az takılır.
• Markanızı korur: Adınıza gönderilen sahte e-postalar, müşteri güvenini ve alan adınızın itibarını zedeler; bu kayıtlar bu riski azaltır.

Kimlik avı ve BEC: gerçek maliyet

Bu kayıtların önemini abartmıyoruz. Kimlik doğrulaması olmayan bir alan adı, “işletme e-postası dolandırıcılığı” (BEC) için açık hedeftir: saldırgan, patronunuz ya da tedarikçiniz gibi görünen bir e-posta gönderip para transferi veya gizli bilgi talep edebilir. Bu tür saldırılar teknik olarak basit ama mali olarak yıkıcıdır. SPF, DKIM ve DMARC üçlüsü, alan adınızın taklit edilmesini zorlaştırarak bu saldırı yüzeyini daraltır. Yani bu kayıtlar yalnızca teslim edilebilirlik için değil, doğrudan güvenlik için de gereklidir.

Kimlik doğrulama bu saldırıların tümünü tek başına engellemez. Ama en yaygın ve en ucuz varyantına, yani alan adınızın doğrudan taklit edildiği “exact-domain spoofing” saldırısına karşı güçlü bir kalkandır. DMARC reject politikası devredeyken, sizin alan adınızdan geliyormuş gibi görünen sahte e-postalar alıcıya hiç ulaşmaz.

Üçü birlikte nasıl çalışır?

Üç kaydı ayrı ayrı düşünmek kafa karıştırıcı olabilir; oysa birlikte tek bir doğrulama zinciri kurarlar. Bir e-posta gönderdiğinizde alıcı sunucu sırasıyla şunları yapar:

1. SPF kontrolü: İletinin geldiği sunucunun IP’si, gönderen alan adının SPF kaydında yetkili mi?
2. DKIM kontrolü: İletideki dijital imza, alan adının DNS’teki açık anahtarıyla doğrulanıyor mu?
3. DMARC kontrolü: SPF veya DKIM geçti mi ve geçen kayıt, görünen From alan adıyla hizalı mı? Değilse DMARC politikanız devreye girer (izle, karantina ya da reddet).

Bu yüzden en sağlam kurulum üçünü birlikte yapmaktır: SPF ve DKIM kimliği kanıtlar, DMARC ise bu kanıtları bir politika ve raporlama çerçevesine bağlar.

SPF nedir ve nasıl ayarlanır?

SPF (Sender Policy Framework), alan adınız adına hangi sunucuların e-posta göndermeye yetkili olduğunu belirten bir DNS TXT kaydıdır. Alıcı sunucu, gelen e-postanın IP adresini bu listeyle karşılaştırır; kayıtta yoksa iletiyi şüpheli sayar.

SPF örnek kaydı

Alan adınızın kök (root) TXT kaydına şuna benzer bir değer eklenir:

v=spf1 include:_spf.saglayici.com ~all

Bileşenlerin anlamı:

• v=spf1 her SPF kaydının başladığı sürüm etiketidir.
• include:... sağlayıcınızın gönderim sunucularını yetkilendirir; doğru değeri sağlayıcınız verir.
• ip4: / ip6: kendi gönderim sunucunuzun IP adreslerini eklemek için kullanılır.
• ~all (softfail) listede olmayan kaynakları “şüpheli” işaretler; -all (hardfail) ise reddeder. Kurulumu ~all ile başlatıp, emin olduğunuzda -all’a geçmek yaygın bir yaklaşımdır.

SPF mekanizmaları ve nitelikleri

SPF kaydında include dışında başka mekanizmalar da kullanabilirsiniz:

• a — alan adının A/AAAA kaydındaki IP’lerin göndermesine izin verir.
• mx — alan adının MX (posta) sunucularının göndermesine izin verir.
• ip4: / ip6: — belirli IP adreslerini ya da bloklarını yetkilendirir.
• include: — başka bir alan adının SPF kaydını dahil eder (sağlayıcılar için tipiktir).

Her mekanizmanın başına bir nitelik (qualifier) gelir: + (izin ver, varsayılan), - (reddet), ~ (yumuşak başarısızlık) ve ? (nötr). Kaydın sonundaki all mekanizması, listede olmayan tüm kaynaklar için varsayılan davranışı belirler.

On sorgu limitine takılırsanız iki çözüm vardır: gereksiz include zincirlerini temizlemek ya da “SPF düzleştirme” (flattening) ile include’ları doğrudan IP listesine çevirmek. Ayrı e-posta gönderen alt alan adlarınız (ör. kampanya.sirketiniz.com) varsa, her birinin kendi SPF kaydına ihtiyacı olduğunu unutmayın.

DKIM nedir ve nasıl ayarlanır?

DKIM (DomainKeys Identified Mail), giden her e-postaya kriptografik bir dijital imza ekler. Sağlayıcınız iletiyi özel anahtarla imzalar; alıcı sunucu, DNS’te yayımladığınız açık anahtarla bu imzayı doğrular. İmza tutarsa iletinin yolda değiştirilmediği ve gerçekten sizin alan adınızdan geldiği kanıtlanır.

DKIM kaydı, bir “selektör” (selector) alt alan adı altında TXT kaydı olarak yayımlanır. Biçim şuna benzer:

selector._domainkey.sirketiniz.com TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

Buradaki p= değeri, sağlayıcınızın ürettiği açık anahtardır. Selektör adını ve anahtarı sağlayıcınız verir; sizin işiniz bu kaydı DNS’e eklemektir. Güvenlik için anahtarların periyodik olarak yenilenmesi (rotasyon) iyi bir uygulamadır.

DKIM’de dikkat edilecekler

• Anahtar uzunluğu: 1024 bit yerine 2048 bit anahtarlar daha güçlüdür ve artık standarttır.
• Birden çok selektör: Farklı selektörler tanımlamak, anahtar rotasyonunu kesintisiz yapmanızı sağlar.
• Yönlendirme (forwarding): Bir ileti otomatik yönlendirildiğinde SPF bozulabilir; DKIM imzası ise genellikle korunur. Bu yüzden DKIM, yönlendirme senaryolarında daha dayanıklıdır.

DMARC nedir ve nasıl ayarlanır?

DMARC (Domain-based Message Authentication, Reporting and Conformance), SPF ve DKIM’in üzerine kurulan politika katmanıdır. İki şeyi yapar: (1) doğrulamayı geçemeyen e-postalara ne yapılacağını söyler ve (2) alan adınız adına gönderilen iletiler hakkında size rapor gönderilmesini sağlar. DMARC ayrıca “hizalama” (alignment) ister: iletide görünen From alan adı, SPF/DKIM’in doğruladığı alan adıyla eşleşmelidir.

DMARC kaydı _dmarc.sirketiniz.com altında bir TXT kaydıdır:

v=DMARC1; p=none; rua=mailto:dmarc@sirketiniz.com; fo=1

none, quarantine, reject: hangi politika?

DMARC politikası (p=) üç değer alabilir; doğru yol kademeli ilerlemektir:

1. p=none — İzleme modu. Hiçbir ileti engellenmez; yalnızca rapor toplarsınız. Kuruluma buradan başlayın ve raporları birkaç hafta izleyin.
2. p=quarantine — Doğrulamayı geçemeyen iletiler spam/karantina klasörüne alınır. Meşru göndericilerinizi none aşamasında tespit edip düzelttikten sonra geçin.
3. p=reject — En güçlü politika. Doğrulamayı geçemeyen iletiler tamamen reddedilir. Hedefiniz burasıdır; ama yalnızca tüm meşru kaynaklarınızın doğru imzalandığından emin olduğunuzda geçin.

İleri DMARC ayarları

Temel politikanın yanında birkaç parametre, kurulumu ince ayarlamanızı sağlar:

• rua= — toplu (aggregate) raporların gönderileceği adres. Alan adınızı kimlerin, hangi sonuçlarla kullandığını buradan görürsünüz.
• ruf= — adli (forensic) raporlar; tekil başarısızlıkların ayrıntısı. Gizlilik nedeniyle her sağlayıcı göndermez.
• pct= — politikanın iletilerin yüzde kaçına uygulanacağı. pct=25 gibi bir değerle karantina/reddi kademeli devreye alabilirsiniz.
• sp= — alt alan adları için ayrı politika.
• adkim / aspf — hizalama modu: r (relaxed, esnek) ya da s (strict, katı).

Raporları okumak

DMARC’ın en değerli yanı raporlamadır. p=none aşamasında toplanan XML raporlar, alan adınız adına gönderim yapan tüm kaynakları (meşru sistemleriniz dahil) ortaya çıkarır. Raporları okunur hâle getiren birçok araç vardır; amaç, karantina veya reddine geçmeden önce hiçbir meşru göndericinin dışarıda kalmadığından emin olmaktır.

Kademeli DMARC yol haritası

DMARC’ı güvenle uygulamaya almanın kanıtlanmış bir yolu vardır; acele etmeden şu adımları izleyin:

1. İzleyin: p=none ile yayımlayın ve birkaç hafta boyunca rua raporlarını toplayın.
2. Envanter çıkarın: Raporlarda görünen tüm meşru göndericileri (CRM, fatura, pazarlama araçları) belirleyin.
3. Yetkilendirin: Her meşru kaynağın SPF ve/veya DKIM ile doğru imzalandığından emin olun.
4. Sıkılaştırın: p=quarantine seviyesine geçin; gerekirse pct ile kademeli uygulayın.
5. Zorunlu kılın: Her şey yolundaysa p=reject ile tam korumaya ulaşın.

Bu sıralama haftalar sürebilir. Aceleyle atlanan her adım, meşru e-postalarınızın engellenme riskini artırır.

Üçüncü taraf gönderenler ve alt alan adları

E-postalarınızı yalnızca kendi sunucunuz göndermez: fatura sistemleri, CRM, pazarlama araçları ve yardım masası yazılımları da sizin adınıza e-posta gönderir. Bu kaynakların her biri ya SPF’inize eklenmeli ya da kendi DKIM imzalarıyla yetkilendirilmelidir. Yaygın bir yaklaşım, pazarlama e-postalarını ayrı bir alt alan adından (ör. haber.sirketiniz.com) göndermektir; böylece ana alan adınızın itibarı, toplu gönderimlerden etkilenmez. Her alt alan adının kendi SPF, DKIM ve DMARC kayıtlarına ihtiyacı olduğunu unutmayın.

Gmail ve Yahoo’nun 2024 gönderici zorunlulukları

Google ve Yahoo, Şubat 2024’te yürürlüğe giren ortak gönderici kurallarıyla e-posta kimlik doğrulamasını fiilen zorunlu hâle getirdi. Özellikle günde 5.000’den fazla ileti gönderen toplu göndericiler için kurallar nettir:

• SPF ve DKIM ile kimlik doğrulama zorunludur.
• Alan adı için en az p=none düzeyinde bir DMARC politikası yayımlanmalıdır.
• Gönderen alan adı ile kimlik doğrulama arasında hizalama (alignment) sağlanmalıdır.
• Tek tıkla abonelikten çıkma (one-click unsubscribe, RFC 8058) desteklenmelidir.
• Spam şikâyet oranı %0,3’ün altında tutulmalıdır (ideali %0,1’in altı).

Bu eşiğin altında kalan küçük göndericiler için bile aynı kurallar en iyi uygulamadır: kimlik doğrulaması yapılmış bir alan adı, hem daha iyi teslim edilebilirlik hem de daha güçlü marka koruması demektir.

Bu kurallara ek olarak, gönderen sunucunun geçerli bir ileri ve geri DNS (PTR) kaydına sahip olması ve iletileri TLS ile şifreli iletmesi de beklenir. Yönetilen bir sağlayıcıda bu teknik gereksinimler sizin için karşılanır; kendi sunucusunu işletenlerin ise her birini ayrıca yapılandırması gerekir.

Kayıtları test etme ve doğrulama

Kayıtları ekledikten sonra doğru yayımlandığını kontrol edin. Komut satırında dig (ya da Windows’ta nslookup) ile TXT kayıtlarını sorgulayabilirsiniz:

dig TXT sirketiniz.com

dig TXT selector._domainkey.sirketiniz.com

dig TXT _dmarc.sirketiniz.com

Komut satırına erişiminiz yoksa, aynı sorguları çevrimiçi DNS ve DMARC denetleyicileriyle de yapabilirsiniz; sonuç aynıdır: üç kaydın da yayımlandığını, söz diziminin geçerli olduğunu ve DMARC hizalamasının çalıştığını görmek. Kurulumdan sonra ilk birkaç hafta boyunca DMARC raporlarını izlemek, gözden kaçan bir gönderici olup olmadığını erkenden yakalamanızı sağlar.

Ardından kendinize (ya da farklı bir sağlayıcıdaki bir adrese) test e-postası gönderip, alıcıdaki ileti başlıklarında spf=pass, dkim=pass ve dmarc=pass satırlarını görmelisiniz. Üçü de “pass” ise kurulumunuz çalışıyordur.

DNS ve yayılma: sabırlı olun

DNS değişiklikleri anında yayılmaz. Bir kaydı eklediğinizde ya da değiştirdiğinizde, eski değerin önbelleklerden temizlenmesi TTL süresi kadar (dakikalar ile saatler arası) zaman alabilir. Bu yüzden bir kaydı test etmeden önce yayılmayı bekleyin ve değişiklik planlarken TTL değerlerini göz önünde bulundurun. Kritik geçişlerden önce TTL’i düşürmek, yayılmayı hızlandırır.

Sık yapılan hatalar

• Birden fazla SPF kaydı: Aynı alan adında iki SPF TXT kaydı bulunması doğrulamayı bozar; hepsini tek kayıtta birleştirin.
• SPF’i açık uçlu bırakmak: Kaydı +all ile bitirmek herkese izin verir; ~all veya -all kullanın.
• DKIM anahtarını hiç yenilememek: Uzun süre aynı anahtarı kullanmak riski artırır; periyodik rotasyon önerilir.
• Doğrudan reject’e geçmek: Meşru göndericileri tespit etmeden p=reject, meşru e-postaların reddine yol açar.
• Alt alan adlarını unutmak: Kök alan adını koruyup alt alan adlarını (ör. posta.sirketiniz.com) yetkilendirmemek açık kapı bırakır.
• DNS yayılımını beklememek: Kayıt değişiklikleri TTL süresi kadar zaman alır; test etmeden önce yayılmayı bekleyin.
• Üçüncü taraf araçları unutmak: CRM ya da fatura sisteminiz gibi sizin adınıza gönderen servisleri yetkilendirmezseniz, meşru e-postalarınız DMARC’a takılır.
• Raporları izlememek: p=none aşamasında raporları okumadan sıkılaştırmaya geçmek, meşru göndericileri gözden kaçırmanıza yol açar.

Özetlersek: SPF hangi sunucuların gönderebileceğini, DKIM iletinin değişmediğini ve gerçekten sizden geldiğini, DMARC ise bu iki kontrolün sonucunda ne yapılacağını ve size nasıl raporlanacağını belirler. Üçünü birlikte, kademeli ve raporları izleyerek kurun. Doğru kurulduğunda bu üçlü; hem gelen kutunuza güven hem de dışarıya gönderdiğiniz her e-postaya itibar kazandırır.

Bu üç kayıt teknik görünse de bir kez kurulur ve uzun süre çalışır. AkıllıPosta’da alan adınızı bağlarken DNS sihirbazı, size özel SPF, DKIM ve DMARC kayıtlarını üretip kopyalanmaya hazır listeler; Yandex’ten geçiş gibi taşımalarda bu kayıtları sizin yerinize planlarız. Kimlik doğrulamanın güvenlik mimarimizdeki yerini Güvenlik ve KVKK sayfamızda anlattık; kurumsal e-postayı bir bütün olarak ele aldığımız kurumsal e-posta rehberimize de göz atabilirsiniz.