SPF, DKIM ve DMARC: E-Posta Doğrulama Rehberi

Bir saldırgan, şirketin gerçek alan adını kullanarak muhasebe departmanı adına sahte bir fatura e-postası gönderebilir. Alıcı, göndereni gerçek adres olarak görür ve genelde hiç şüphelenmeden ekli dosyayı açar. Bu senaryo her gün yaşanıyor çünkü klasik SMTP protokolü, e-postayı gönderenin gerçekten o alan adının sahibi olup olmadığını sormaz. SPF, DKIM ve DMARC, tam olarak bu boşluğu kapatmak için kullanılan üç DNS kaydıdır.

Bu üç kayıt, alıcı mail sunucusuna üç şeyi anlatır: gönderme yetkisinin kimde olduğunu, içeriğin yolda değişip değişmediğini ve doğrulama başarısız olduğunda ne yapılması gerektiğini. Aşağıda her birinin nasıl çalıştığını, nasıl kurulacağını ve üçünün birlikte nasıl yapılandırılacağını adım adım anlatıyoruz.

SPF kaydı gönderen sunucuları nasıl yetkilendirir

SPF (Sender Policy Framework), bir alan adı adına hangi sunucuların e-posta gönderebileceğini listeleyen bir DNS TXT kaydıdır. Alıcı sunucu, gelen e-postanın SMTP zarfındaki gönderen adresine bakar ve bu adresin alan adının SPF kaydında yetkili sunucular arasında olup olmadığını kontrol eder. Kayıtta yer almayan bir sunucudan gelen e-posta sahte kabul edilir; alıcı sunucu bu e-postayı reddedebilir ya da spam klasörüne yönlendirebilir.

Tipik bir SPF kaydı şöyle görünür:

sirketiniz.com. IN TXT "v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 -all"

Buradaki include ifadeleri Google Workspace veya Mailgun gibi üçüncü taraf gönderim hizmetlerini yetkilendirir; ip4 etiketi ise belirli bir sunucu IP adresini kayda ekler. Sondaki -all katı bir politika uygular: listede olmayan hiçbir kaynak bu alan adı üzerinden e-posta gönderemez. Daha kademeli bir geçiş isteyen kuruluşlar ~all (softfail) kullanabilir; bu ayar yetkisiz gönderimi işaretler ama e-postayı doğrudan reddetmez.

SPF'nin bilinen bir sınırı var: kayıt 10 DNS aramasını (lookup) aştığında geçersiz sayılır. Çok sayıda üçüncü taraf servis kullanan şirketler bu sınıra kolayca ulaşır. Her yeni pazarlama aracı veya CRM eklendiğinde SPF kaydı büyür; kullanılmayan servisleri kayıttan düzenli olarak çıkarmak bu birikimi önler.

SPF tek başına yeterli değildir çünkü e-postanın kullanıcıya görünen "Kimden" adını doğrulamaz, yalnızca teknik zarf gönderenini kontrol eder. Bir saldırgan, SPF kontrolünü geçen ama görünen adı sahte olan bir e-posta gönderebilir. Bu boşluğu DKIM ve DMARC kapatır.

Alt alan adları için ayrı SPF kayıtları gerekebilir. mail.sirketiniz.com üzerinden gönderim yapılıyorsa, bu alt alan adının kendi TXT kaydı olmalıdır; çünkü ana alan adının SPF kaydı, alt alan adlarına otomatik olarak miras kalmaz. Bu ayrım, çok sayıda alt alan adı kullanan kurumsal yapılarda sık atlanan bir detaydır.

DKIM e-posta içeriğine dijital imza ekler

DKIM (DomainKeys Identified Mail), giden her e-postaya özel bir anahtarla oluşturulmuş kriptografik bir imza ekler. Alıcı sunucu, alan adının DNS'inde yayınlanan genel anahtarla bu imzayı doğrular. İmza geçerliyse hem gönderenin kimliği hem de e-posta içeriğinin yolda değiştirilmediği kanıtlanmış olur.

DKIM kaydı, alt alan adı biçiminde bir TXT kaydı olarak yayınlanır:

selector1._domainkey.sirketiniz.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

selector1 kısmı, mail sunucunuzun ürettiği anahtar çiftini tanımlayan bir etikettir; her mail servis sağlayıcısı kendi seçici adını kullanır (Google için google, Microsoft 365 için genellikle selector1/selector2). Anahtar çiftini genelde mail sunucusu veya e-posta pazarlama aracı otomatik üretir. Sizin yapmanız gereken tek şey, verilen TXT kaydını DNS'e eksiksiz kopyalamaktır.

DKIM anahtarlarını periyodik olarak döndürmek (rotate) iyi bir güvenlik pratiğidir. Eski bir anahtar sızarsa saldırgan bu anahtarla imzalanmış sahte e-postalar üretebilir; anahtar rotasyonu bu riski sınırlar. Çoğu bulut sağlayıcı bu rotasyonu otomatik yapar; kendi mail sunucunuzu (Postfix, Exim) yönetiyorsanız OpenDKIM gibi araçlarla anahtarları elle yenilemeniz gerekir.

Birden fazla gönderim kaynağı kullanan kuruluşlarda her kaynağın kendi DKIM seçicisi olmalıdır. Örneğin kurumsal mail için google._domainkey, fatura sistemi için invoice._domainkey gibi ayrı kayıtlar kullanılır. Bu ayrım, bir kaynağın anahtarı iptal edildiğinde diğerlerini etkilemeden yönetilmesini sağlar ve büyük altyapılarda DKIM yönetimini kolaylaştırır.

DKIM imzasının hangi başlıkları kapsadığı da önemlidir. h= etiketi imzalanan alanları listeler (genelde From, Subject, Date). Bu alanlardan biri yolda değiştirilirse imza geçersiz sayılır ve doğrulama başarısız olur. Bu titizlik, mekanizmanın e-posta içeriğinin bütünlüğünü garanti altına alan kısmıdır.

DMARC, SPF ve DKIM sonuçlarına göre politika belirler

DMARC (Domain-based Message Authentication, Reporting and Conformance), SPF ve DKIM doğrulamalarının üzerine kurulur. Bu iki kontrolden biri veya ikisi başarısız olduğunda alıcı sunucuya e-postaya ne yapılacağını söyler. Ayrıca alan adınız adına gönderilen tüm e-postalar hakkında günlük veya haftalık rapor almanızı sağlar. DMARC kaydı olmadan SPF ve DKIM, tek başına parçalı bir savunma olarak kalır.

Örnek bir DMARC kaydı:

_dmarc.sirketiniz.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; adkim=s; aspf=s"

p=quarantine başarısız e-postaların spam klasörüne düşmesini sağlar. p=reject bu e-postaları doğrudan reddeder. p=none ise sadece izler, hiçbir şeyi engellemez. rua etiketi toplu raporların gönderileceği adresi belirtir. pct etiketi ise politikanın hangi yüzdelik e-postaya uygulanacağını kontrol eder.

DMARC kurulumuna her zaman p=none ile başlanması önerilir. Bu mod hiçbir e-postayı engellemez, sadece hangi sunucuların alan adınız adına e-posta gönderdiğini gösteren raporlar üretir. İki üç hafta bu raporlar incelenip tüm meşru gönderim kaynakları SPF ve DKIM'e eklendikten sonra sırasıyla quarantine ve reject politikalarına geçilir.

adkim ve aspf etiketleri hizalama (alignment) katılığını belirler. s (strict) değeri, DKIM imzasındaki veya SPF kontrolündeki alan adının görünen "Kimden" alanıyla birebir eşleşmesini şart koşar; r (relaxed) değeri alt alan adlarına da izin verir. Katı hizalama daha güvenlidir ama alt alan adlarından gönderim yapan sistemlerde dikkatli test gerektirir.

Üç protokolü birlikte kurarken izlenecek sıra

Doğru sıralama, meşru e-postaları yanlışlıkla engellemeden geçiş yapmanızı sağlar. Önce mevcut tüm gönderim kaynaklarınızı (kurumsal mail sunucusu, CRM, e-posta pazarlama aracı, fatura sistemi) listeleyin. Bunların her biri kendi SPF kaydına ve ayrı bir DKIM seçicisine ihtiyaç duyar.

1. SPF kaydını oluşturun ve tüm meşru gönderim kaynaklarını include veya ip4 etiketiyle ekleyin.
2. Her gönderim kaynağı için DKIM'i etkinleştirin ve seçiciye ait DNS kaydını girin.
3. DMARC kaydını p=none ile yayınlayın ve raporları izlemeye başlayın.
4. Raporlarda yalnızca beklenen kaynakların göründüğünü doğrulayın.
5. Politikayı kademeli olarak önce quarantine, ardından reject seviyesine yükseltin.

Bu sıra atlanıp doğrudan p=reject ile başlanırsa, unutulan bir gönderim kaynağı (örneğin bir bilet sistemi veya webinar aracı) sessizce e-posta göndermeyi bırakabilir. Kimse fark etmeden haftalarca müşteri e-postaları kaybolabilir. Bu yüzden kademeli geçiş atlanmaması gereken bir adımdır.

DMARC raporlarını okurken nelere bakılmalı

DMARC raporları XML formatında gelir ve çıplak gözle okunması zordur. Postmark, dmarcian veya Google Postmaster Tools gibi araçlar bu raporları görsel tablolara çevirir. Her rapor, alan adınız adına e-posta gönderen tüm kaynakları, kaynak IP adreslerini ve SPF/DKIM sonuçlarını listeler.

Beklenmedik bir IP adresinin yüksek hacimde e-posta gönderdiğini görürseniz, bu ya unutulmuş bir meşru servistir ya da alan adınızı taklit eden bir saldırgandır. Kaynak meşruysa SPF ve DKIM'e ekleyin; kaynak sahteyse, bu tam olarak DMARC'ın yakalamak için tasarlandığı senaryodur.

Raporları haftalık incelemek, alan adınızın nasıl kullanıldığına dair sürekli bir görünürlük sağlar. Zamanla hangi servislerin ne sıklıkla e-posta gönderdiğini öğrenir, anormal bir artışı hızlıca fark edersiniz. Bu alışkanlık, tek seferlik bir kurulumu sürekli bir güvenlik pratiğine dönüştürür.

Yaygın yapılandırma hataları

En sık görülen hata, aynı alan adına birden fazla SPF TXT kaydı eklenmesidir. DNS standardı bir alan adı için yalnızca tek bir SPF kaydına izin verir; ikinci kayıt tüm SPF doğrulamasını geçersiz kılar. Tüm gönderim kaynakları tek bir v=spf1 satırında birleştirilmelidir.

DKIM seçicisinin yanlış kopyalanması da sık karşılaşılan bir hatadır. Sağlayıcının verdiği uzun genel anahtar metni satır sonu veya fazladan boşluk içerirse DNS kaydı geçersiz olur; kayıt eklendikten sonra bir DKIM doğrulama aracıyla test etmek bu hatayı erken yakalar. DMARC'ı hiç kurmadan yalnızca SPF ve DKIM ile yetinmek de yaygın bir hatadır; bu durumda başarısız doğrulamalara ne yapılacağı alıcı sunucunun kendi takdirine kalır.

Alan adınızı yalnızca web sitesi için kullanıp hiç e-posta göndermiyorsanız bile SPF ve DMARC kaydı eklemeniz önerilir. Boş bir SPF kaydı (v=spf1 -all) ve katı bir DMARC politikası, saldırganların o alan adını sahte gönderim için kullanmasını tamamen engeller. Bu, kullanılmayan alan adlarının fark edilmeyen bir güvenlik açığı hâline gelmesini önler.

Bu üç protokolü doğru sırayla kurup DMARC raporlarını düzenli izlemek, hem e-postalarınızın gelen kutusuna ulaşma oranını yükseltir hem de alan adınızın kimlik avı saldırılarında araç olarak kullanılmasının önüne geçer.

Yazan Celil Uyanikoglu

25 yıldır bilgi işlem piyasasında farklı dallarda uzmanlaşan bir Bilgisayar Mühendisi