SPF, DKIM ve DMARC Nedir? Mail Kimliği Nasıl Doğrulanır?

SPF, DKIM ve DMARC, bir mailin gerçekten göründüğü alan adından gelip gelmediğini alıcı sunucuya kanıtlayan üç DNS kaydıdır. SPF alan adınız adına hangi sunucuların mail gönderebileceğini listeler. DKIM giden her maile alan adınızın dijital imzasını ekler. DMARC ise bu iki kontrolü okurun ekranda gördüğü gönderen adresine bağlar ve tutmazsa alıcı sunucunun ne yapacağını söyler. Üçü de alan adınızın DNS zone’unda birer TXT kaydı olarak durur.

Bu kayıtlar olmadan bir mailin gönderen satırı yalnızca bir yazıdır. SMTP mailin kimden geldiğini doğrulamaz ve From: satırına ne yazılırsa alıcının ekranına o düşer. Muhasebeye yöneticinin adresinden gelmiş gibi görünen bir ödeme talimatı tam olarak bu boşluktan doğar. Gmail ve Outlook.com’un çok mail gönderenlerden bu üç kaydı şart koşmasının sebebi de budur.

SMTP yazımızda postayı bir otogar üzerinden anlatmıştık. Bagaj etiketi sandığın hangi otobüse yükleneceğini belirler, biletteki isim ise yalnızca gösterilir ve kimse onu kontrol etmez. Bu yazı aynı otogarın varış kapısındaki kontrol masasını anlatıyor. Masada sırayla üç soru sorulur:

1. Sandığı getiren otobüs firmanın listesinde mi? SPF bu soruyu cevaplar.
2. Sandığın üstündeki mühür sağlam mı? DKIM bu soruyu cevaplar.
3. Biletteki firma, bu iki kontrolden geçen firmayla aynı mı? DMARC bu soruyu cevaplar ve okuru koruyan asıl soru budur.

Anlatılanların hepsini kendi alan adımız sistemkusu.com üzerinde ölçtüm. Kayıtları 10 Ekim 2026’da iki ayrı Public DNS (internetteki herkese açık DNS sunucusu) adresinden, 8.8.8.8 ve 1.1.1.1 üzerinden sorguladım ve çıktılar aşağıda olduğu gibi duruyor. Acele ediyorsanız doğrudan kendi alan adınızın kayıtlarını nasıl kontrol edeceğinize gidebilirsiniz.

Bu makale kurumsal network kurulumu hizmetimizin e-posta altyapısı koluna odaklanır ve DNS rehberimizdeki TXT kayıtları bölümünü derinleştirir.

SPF, DKIM ve DMARC Neden Var? SMTP Göndereni Doğrulamaz

Örnekteki kontrol masasının neden kurulduğu SMTP’nin kendi tasarımında yazılıdır. SMTP bir maili kimin gönderdiğini hiçbir aşamada doğrulamaz. Gönderen sunucu zarfa MAIL FROM ile bir adres, mailin içine de From: satırıyla başka bir adres yazar ve ikisini de kendisi seçer. Alıcı sunucu bunları olduğu gibi kabul eder. Zarf ile başlığın neden ayrı olduğunu SMTP yazısında ayrıntısıyla anlattık.

Bu kayıtlar olmasaydı ne olurdu? Alıcı tarafın elinde bir mailin sahte olduğunu anlamak için yalnızca içerik filtresi kalırdı. Bir saldırgan, muhasebe@sistemkusu.com adresinden geliyormuş gibi duran bir IBAN değişikliği talimatını kendi sunucusundan gönderebilir. Karşı taraftaki sunucunun bu iddiayı sınayacağı hiçbir kaydı olmaz. Talimatın düzgün Türkçesi ve tanıdık imza bloğu onu içerik filtresinden de geçirir.

Gmail ve Outlook.com Bu Üç Kaydı Şart Koşuyor

Büyük mail sağlayıcıları bu boşluğu artık kendi kurallarıyla kapatıyor. İki birinci el kaynak bugünkü şartları şöyle çiziyor:

• Gmail, 1 Şubat 2024’ten beri Gmail adreslerine mail gönderen herkesten en az SPF ya da DKIM istiyor. Günde 5.000’den fazla mail gönderenler için üçü birden şart: SPF, DKIM ve DMARC. DMARC policy’sinin p=none olması yetiyor, ama From: satırındaki alan adının SPF ya da DKIM’in doğruladığı alan adıyla hizalı olması gerekiyor.
• Outlook.com için Microsoft Nisan 2025’te duyurduğu kuralla günde 5.000’den fazla mail gönderen alan adlarından aynı üçlüyü istiyor. İlk duyuruda kuralı tutmayan mailin önce gereksiz e-posta klasörüne düşeceği yazıyordu. 29 Nisan güncellemesiyle bu cümle silindi ve 5 Mayıs 2025’ten itibaren bu mailler 550 5.7.515 koduyla doğrudan reddediliyor.

Bu kayıtların gerekmediği bir alt eşik yok. Günde on mail atan bir ofis de Gmail’in bütün gönderenler için koyduğu şarta tabidir. Hacimle değişen tek şey, üçünden hangisinin zorunlu, hangisinin tavsiye olduğudur. Hiç mail göndermeyen bir alan adının da kendine göre kayıtları vardır.

Kontrol Masası: Üç Kaydın Otogardaki Karşılığı

Otogar benzetmesinin parçaları e-postada şunlara karşılık geliyor:

Benzetme iki yerde kopar. Gerçek bir mühür taklit edilebilir ve görevli onu gözle karşılaştırır. DKIM imzası ise matematikle doğrulanır. İmzayı atan özel anahtar gönderen sunucudan hiç çıkmaz ve DNS’teki açık anahtardan geri üretilemez. İkinci kopma kontrolün sıklığındadır. Otogarda kontrol ara sıra yapılır, e-postada ise her alıcı sunucu gelen her mail için bu kayıtları DNS’ten okur. Açık anahtarla özel anahtarın nasıl bir çift oluşturduğunu şifreleme yazımızın anahtar çifti bölümünde anlattık.

SPF Nedir? Mail Gönderebilecek Sunucuların Listesi

Örnekteki masada ilk soru plaka sorusudur ve onu SPF cevaplar. SPF (Sender Policy Framework), bir alan adı adına hangi sunucuların mail gönderebileceğini listeleyen DNS kaydıdır. Alıcı sunucu, kendisine bağlanan sunucunun IP adresini bu listede arar. Bugün geçerli tanımı Nisan 2014 tarihli RFC 7208 belgesidir.

Bir ayrıntı bütün yazının anahtarıdır. SPF listesi, okurun gördüğü From: satırındaki alan adından değil, zarftaki MAIL FROM adresinin alan adından okunur. Örnekteki otogarla söylersek, SPF biletin üstündeki firmaya değil, bagaj etiketindeki firmaya bakar. From, Return-Path ve Reply-To alanlarının farkını mail başlığı yazımızda gerçek bir başlık üzerinde anlattık. Bu ayrımın neden önemli olduğu DMARC’ın hizalama kontrolünde ortaya çıkıyor.

SPF Kaydı Nasıl Okunur? sistemkusu.com Örneği

sistemkusu.com alan adının kökünde üç ayrı TXT kaydı duruyor ve yalnızca biri SPF. Diğer ikisi, başka hizmetlerin alan adı sahipliğini doğrulamak için istediği metinlerdir. SPF satırını ayıklamak için kayıtları v=spf1 ile süzmek yeter:

Resolve-DnsName sistemkusu.com -Type TXT -Server 8.8.8.8 | Where-Object Strings -like 'v=spf1*' | Select-Object Name,TTL,Strings

Name             TTL Strings                              
----             --- -------                              
sistemkusu.com  60 {v=spf1 include:_spf.google.com ~all}

Kayıt üç parçadan oluşuyor ve soldan sağa okunuyor:

1. Sürüm. v=spf1 kaydın SPF olduğunu söyler. Bu etiketle başlamayan bir TXT kaydı SPF sayılmaz.
2. Google’ın listesi. include:_spf.google.com Google’ın kendi listesini çağırır, yani Google Workspace sunucularından gelen mail bu satır sayesinde geçer.
3. Geri kalan herkes. ~all listede olmayan her sunucu için sonucu söyler. Baştaki ~ işareti “büyük ihtimalle yetkisiz” demektir ve teknik adı softfail’dir.

include satırının arkasında ne olduğu da sorgulanabilir. Google’ın listesi ölçüm günü düz bir adres listesiydi:

(Resolve-DnsName _spf.google.com -Type TXT -Server 8.8.8.8).Strings

v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56 ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all

Listede iki IPv4 ve altı IPv6 aralığı var. Maili getiren sunucunun adresi bu aralıklardan birindeyse include eşleşir ve sistemkusu.com için sonuç pass olur.

SPF kaydında kullanılabilecek terimler ve DNS sorgusu harcayıp harcamadıkları şöyle:

Her terimin önüne bir işaret konabilir ve terim eşleştiğinde sonucu o işaret belirler:

Alıcı sunucu terimleri soldan sağa dener ve ilk eşleşen terimin sonucunu alır. Bu yüzden all her zaman en sonda durur.

SPF 10 Sorgu Sınırı: Kayıt Neden Sessizce Bozulur?

SPF değerlendirmesi en fazla on DNS sorgusu harcayabilir ve sınır aşıldığında sonuç permerror olur. RFC 7208’in 4.6.4 bölümü sayılacak terimleri tek tek yazar: include, a, mx, ptr, exists ve redirect. Gerekçesi DNS’e makul olmayan bir yük bindirmemektir. Aynı bölüm, cevapsız dönen sorguların da ikiyle sınırlanmasını ister.

Kendi kaydımızı bu sınıra göre ölçtüm. include zincirini sonuna kadar izleyen küçük bir betik yazdım ve sorgu harcayan her terimi saydırdım:

sistemkusu.com  (TXT kaydi sayisi: 3)
  "v=spf1 include:_spf.google.com ~all"
  [sorgu 1] include:_spf.google.com
    _spf.google.com  (TXT kaydi sayisi: 1)
      "v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56 ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all"
      (bu kayitta 2 ip4 ve 6 ip6 araligi, sorgu harcamaz)

Toplam DNS sorgusu gerektiren terim: 1 / 10 (kalan 9)
Void lookup (NXDOMAIN ya da bos yanit): 0 / 2
Zincirdeki toplam ip4 araligi: 2, ip6 araligi: 6

On sorgu hakkının biri harcanıyor, dokuzu kalıyor. Google’ın listesi içinde başka include taşımadığı için tek sorguya mal oluyor. Bu sayı bir ölçümdür, sabit bir değer değildir. Ölçüm sırasında _netblocks.google.com adlı alt listeler hâlâ çözülüyordu, ama _spf.google.com onlara bağlanmıyordu. Google listesini istediği gün yeniden bölebilir ve include satırının bedeli o gün değişir.

Sınır şöyle aşılır. Önce kurumsal mail için bir include girer, sonra bülten servisi, sonra fatura programı, sonra müşteri yönetimi yazılımı. Her servis yalnızca kendi satırını eklemenizi ister ve hiçbiri toplamı söylemez. Çağrılan listelerin her biri kendi include satırlarını da taşıyabildiği için toplam, kayıtta görünen include sayısından hızla büyür. On birinci sorguda kayıt permerror verir ve panel hiçbir uyarı göstermez.

Bir alan adında tek bir SPF kaydı olabilir. Yeni bir mail servisi “şu TXT kaydını ekleyin” dediğinde ikinci bir v=spf1 satırı açmak ikisini birden geçersiz kılar, RFC 7208 bu durumu da permerror sayar. Doğrusu yeni servisi mevcut satıra eklemektir. Örneğin Microsoft 365’e geçiş sırasında Google Workspace ve Microsoft 365 aynı anda gönderiyorsa kayıt tek satıra iner:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Softfail mi Hard Fail mı? SPF Kaydının Sonu

Mail gönderen bir alan adında kaydı ~all ile, hiç mail göndermeyen bir alan adında -all ile bitirmek doğru seçimdir. Gerekçe DMARC’ın kendi standardında yazılıdır.

RFC 9989’un 7.1 bölümüne göre bazı alıcı sunucular SPF’i DMARC’tan önce, daha mailin gövdesi gelmeden uygular. -all ile biten bir kayıt bu sunucularda maili o anda reddettirebilir. Oysa aynı mail hizalı bir DKIM imzası taşıyor olabilir ve DMARC’tan geçebilirdi.

Böyle erken reddedilen mailler DMARC raporlarına da hiç düşmez, çünkü alıcı sunucu From: satırını görmeden konuşmayı kapatmıştır. Kayıp hem yaşanır hem görünmez kalır.

Google’ın iki alan adı da ölçümde ~all ile bitiyordu. google.com kaydını include:_spf.google.com ~all ile kapatıyor, gmail.com ise aynı listeye redirect ile devrediyor. Mail göndermeyen alan adında durum tersinedir. Orada yetkili hiçbir sunucu olmadığı için -all kimseyi yanlışlıkla dışarıda bırakmaz.

Yönlendirilen Mail SPF’i Neden Bozar?

SPF’in yapısal zayıflığı yönlendirmedir. Bir mail sunucusu gelen maili başka bir adrese olduğu gibi aktardığında, mail son alıcıya artık yönlendiren sunucunun IP adresinden ulaşır. O adres, zarftaki alan adının SPF listesinde yoktur ve SPF kontrolü kalır. Bazı yönlendiren sunucular zarf adresini kendi alan adlarıyla yeniden yazarak bunu kendi taraflarında çözer, ama bu bir zorunluluk değildir.

Örnekteki otogarda bunun karşılığı aktarmadır. Sandık aktarma merkezinde başka bir firmanın otobüsüne geçer, varıştaki görevli plakaya bakar ve plakayı gönderen firmanın listesinde bulamaz. Sandık sahte değildir. Plakaya bakmak yalnızca bu yolculuk için yanlış sorudur.

Bu zayıflık bir sonraki kaydın var olma sebebidir. Örnekteki otogarda yolculuk boyunca sandıkla birlikte taşınan bir kanıt gerekir.

DKIM Nedir? Mailin Üstündeki Dijital İmza

Örnekteki otogarda SPF’in plaka listesi aktarmada tutmuyor. DKIM bu yüzden kanıtı otobüse değil sandığın kendisine koyar. DKIM (DomainKeys Identified Mail), giden her maile alan adınıza ait bir dijital imza ekleyen ve o imzayı doğrulamaya yarayan açık anahtarı DNS’te yayımlayan yöntemdir. Tanımı Eylül 2011 tarihli RFC 6376 belgesidir.

Mühür benzetmesi anahtar çiftine birebir oturuyor. Özel anahtar firmanın kasasındaki mühürdür ve gönderen sunucudan hiç çıkmaz. Açık anahtar ise mührün kâğıda bastığı izin herkese açık örneğidir ve DNS’te durur. İzi gören herkes damgayı karşılaştırabilir, ama izden mühür yapılamaz. Anahtar çiftinin bunu nasıl sağladığını sertifika otoritesi yazımızda anlattık.

DKIM İmzası Nasıl Atılır ve Doğrulanır?

İmza dört adımda atılır ve doğrulanır:

1. Gövdenin hash’i. Gönderen sunucu mailin gövdesinden bir hash çıkarır ve onu imza başlığının bh= alanına yazar.
2. İmza. Seçtiği başlıkları ve bu hash’i özel anahtarıyla imzalar, sonucu b= alanına yazar. Standart, From: satırının imzaya girmesini zorunlu tutar.
3. Başlık. İmzayı, imzalayan alan adını taşıyan d= ve anahtarın adını taşıyan s= alanlarıyla birlikte DKIM-Signature başlığı olarak maile ekler.
4. Doğrulama. Alıcı sunucu bu iki alandan {s}._domainkey.{d} adını kurar, oradaki açık anahtarı DNS’ten alır ve imzayı doğrular.

Gövdede ya da imzalanan başlıklardan birinde tek bir karakter değişirse doğrulama başarısız olur. Örnekteki otogarda sandığı açıp içine bir şey koyan herkes mührü kırar.

DKIM maili şifrelemez. İçerik yolda okunabilir kalır. DKIM yalnızca mailin yolda değiştirilmediğini ve hangi alan adının imzaladığını kanıtlar. Yolun şifrelenmesi TLS’in işidir ve ikisi birbirinin yerine geçmez.

DKIM Selector Nedir?

Selector, aynı alan adında birden fazla DKIM anahtarı tutabilmek için kullanılan addır ve açık anahtarın DNS’teki yerini belirler. Anahtar {selector}._domainkey.{alan adı} adında durur. Google Workspace’in varsayılan selector’ı google olduğu için bizim anahtarımız google._domainkey.sistemkusu.com adındadır.

RFC 6376’nın 3.1 bölümü selector’ın varlık sebebini iki işle açıklar:

1. Anahtar değişimi. Yeni anahtar yeni bir selector altında yayımlanır ve gönderen sunucu ona geçer. Eski anahtar bir süre sonra silinir ve bu sırada hiçbir mail imzasız kalmaz.
2. Yetki devri. Sizin adınıza gönderen her servis kendi selector’ını ve kendi anahtarını alır. Bülten servisinin anahtarını iptal etmek kurumsal mailin imzasına dokunmaz.

Selector’ı bilmeden DKIM kaydını sorgulayamazsınız, çünkü DNS’te “bu alan adının bütün anahtarlarını listele” diye bir sorgu yoktur. Selector’ı ya mail sağlayıcınızın yönetim panelinde ya da gelen bir mailin DKIM-Signature başlığındaki s= alanında bulursunuz.

DKIM Kaydı Nasıl Okunur? Anahtar Neden İki Parça Döner?

Panelde tek satır olarak girilen DKIM kaydı, sorguda iki parça hâlinde döner. Kendi anahtarımızı sorguladım:

(Resolve-DnsName google._domainkey.sistemkusu.com -Type TXT -Server 8.8.8.8).Strings

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqJarfRr3ZC9dhN7t4jqXsfa//aAZ4UIqZ+RbBLEHBEmbL+YRv3HCcb+JV5KC84WJkcB90F3GrMreWrA06kawHdyhJ70hatqpAoZZahmmwPIYWKhpkOpCyykskhweujjgg6sy0wSzVyOgOeZSo6xSF5zdHSADEKp9JFCW7dOXRpbIlKbnLZdLTUPP/7Z/E06Qo
3HZbvRF8heiIzBsys0t9v4tUkSxncN9Z4HGh90GqE2bgJdiASriXtjkEFBNMM4OScCluVAAO3kD1k4Tt9bnUZedOlpJW0ixBBIKGdGBvXafYy8BdsM8wh2Q0/3W+7TCWa0cNUiZW+TOkRUVx9kngQIDAQAB

Parçaların uzunluğunu da sordum:

(Resolve-DnsName google._domainkey.sistemkusu.com -Type TXT -Server 8.8.8.8).Strings | ForEach-Object { $_.Length }

255
155

DNS’te bir TXT kaydının tek bir metin parçası en fazla 255 karakter olabilir. 2048 bitlik bir anahtarla kayıt 410 karaktere çıktığı için 255 ve 155 karakterlik iki parçaya bölünmüş. RFC 6376 parçaların arada boşluk bırakılmadan birleştirilmesini ister. Anahtarı elle kopyalayıp bir doğrulama aracına yapıştırırken araya virgül, boşluk ya da satır sonu girmemesi bu yüzden önemlidir:

(Resolve-DnsName google._domainkey.sistemkusu.com -Type TXT -Server 8.8.8.8).Strings -join ''

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqJarfRr3ZC9dhN7t4jqXsfa//aAZ4UIqZ+RbBLEHBEmbL+YRv3HCcb+JV5KC84WJkcB90F3GrMreWrA06kawHdyhJ70hatqpAoZZahmmwPIYWKhpkOpCyykskhweujjgg6sy0wSzVyOgOeZSo6xSF5zdHSADEKp9JFCW7dOXRpbIlKbnLZdLTUPP/7Z/E06Qo3HZbvRF8heiIzBsys0t9v4tUkSxncN9Z4HGh90GqE2bgJdiASriXtjkEFBNMM4OScCluVAAO3kD1k4Tt9bnUZedOlpJW0ixBBIKGdGBvXafYy8BdsM8wh2Q0/3W+7TCWa0cNUiZW+TOkRUVx9kngQIDAQAB

Kayıt üç etiket taşıyor:

1. v=DKIM1 kaydın DKIM anahtarı olduğunu söyler.
2. k=rsa anahtarın türünü söyler.
3. p= açık anahtarın kendisidir ve base64 ile yazılır. Boş bırakılan bir p= anahtarın iptal edildiği anlamına gelir.

Anahtarı çözdüğümde 2048 bitlik bir RSA anahtarı çıktı. RFC 8301 imzalayan tarafın en az 1024 bitlik anahtar kullanmasını zorunlu tutar, 2048 biti önerir ve SHA-1 ile imzalamayı tamamen yasaklar. Google Workspace de DKIM kurulum dokümanında 2048 biti önerir. 1024’ü yalnızca uzun kaydı kabul etmeyen DNS panelleri için seçenek olarak bırakır.

Selector yanlış yazılırsa ne olduğunu görmek için var olmayan bir selector’ı sorguladım:

Resolve-DnsName yok._domainkey.sistemkusu.com -Type TXT -Server 8.8.8.8

Resolve-DnsName : yok._domainkey.sistemkusu.com : DNS adı yok
...
    + FullyQualifiedErrorId : DNS_ERROR_RCODE_NAME_ERROR,Microsoft.DnsClient.Commands.ResolveDnsName

DNS adı yok, DNS’in NXDOMAIN cevabıdır ve bu adda hiçbir kaydın olmadığını söyler. Alıcı sunucu imzadaki s= değeriyle aynı cevabı alırsa imzayı doğrulayamaz. İki sorgu aynı alan adının altında yapıldı. Biri tam bir anahtar döndürdü, öteki hiçbir şey. Yani DKIM’in çalışıp çalışmadığını alan adı değil selector belirler.

Google Workspace’te kayıt DNS’e girildikten sonra yönetim panelindeki Start authentication (Türkçe arayüzde Kimlik doğrulamasını başlat) düğmesiyle imzalama ayrıca açılır. Google, DKIM’in devreye girmesinin kayıt eklendikten sonra 48 saati bulabileceğini yazıyor. İmza açıldığında panelin durum satırı bunu söyler:

DKIM Yönlendirmeye Dayanır, Ama Göndereni Kanıtlamaz

DKIM imzası mailin içinde taşındığı için yönlendirmeden sağ çıkar. Örnekteki aktarma merkezinde sandık başka otobüse geçse de mühür üstündedir. İmzanın bozulduğu yer içeriğin değiştiği yerdir. Konusuna etiket ekleyen ya da gövdenin altına not basan posta listeleri imzayı bozar.

Ama DKIM’in de bir kör noktası var. İmza yalnızca d= alanındaki alan adının bu maili imzaladığını kanıtlar. O alan adının okurun gördüğü From: satırıyla aynı olduğunu kanıtlamaz. Bir saldırgan kendi alan adıyla kusursuz bir imza atıp From: satırına sizin adresinizi yazabilir. RFC 9989 bunu açıkça söyler: geçerli bir imza herhangi bir alan adından gelebilir, kötü niyetli birinin alan adı da buna dahildir.

DMARC Nedir? Okurun Gördüğü Göndereni Korumak

SPF ve DKIM’in ikisi de bir alan adını doğruluyor, ama hangi alan adını doğrulayacaklarını maili gönderen seçiyor. DMARC bu seçimi okurun gördüğü adrese bağlar. DMARC (Domain-based Message Authentication, Reporting, and Conformance), SPF ya da DKIM’den geçen alan adının From: satırındaki alan adıyla eşleşmesini şart koşan ve eşleşmezse alıcı sunucunun ne yapacağını söyleyen DNS kaydıdır.

Kayıt _dmarc alt adında durur. Mayıs 2026’dan beri geçerli tanımı RFC 9989 belgesidir ve 2015 tarihli RFC 7489’un yerini almıştır.

Hizalama (Alignment): DMARC’ın Asıl Kontrolü

Hizalama (alignment), SPF ya da DKIM’in doğruladığı alan adının From: satırındaki alan adıyla eşleşmesidir. DMARC’tan geçmek için iki kontrolden en az birinin hem geçmesi hem de hizalı olması gerekir. Örnekteki otogarda bunun karşılığı tek bir sorudur: plaka listesi ya da mühür, biletin üstünde adı yazan firmaya mı ait?

İki maili yan yana koyunca ayrım görünür hâle geliyor. Birincisi bizim gönderdiğimiz gerçek bir mail. İkincisi, kendi alan adını kullanan bir saldırganın From: satırına bizim adresimizi yazdığı sahte bir mail:

Sahte mailin SPF ve DKIM sonuçları kusursuzdur. Onu yakalayan tek kontrol DMARC’tır. Okuru koruyan şey bu yüzden SPF ya da DKIM değil, hizalamadır.

Eşleşmenin ne kadar sıkı aranacağını hizalama kipi belirler:

• Gevşek (relaxed, r). İki alan adı aynı kurumsal alan adına (Organizational Domain) bağlıysa hizalı sayılır. bulten.sistemkusu.com ile imzalanmış bir mail, From: satırında sistemkusu.com yazsa da geçer. Varsayılan budur.
• Katı (strict, s). İki alan adının birebir aynı olması gerekir.

SPF için aspf=, DKIM için adkim= etiketi bu kipi seçer.

DMARC Policy’si: none, quarantine ve reject

p= etiketi, DMARC’tan kalan maile alıcı sunucunun ne yapmasını istediğinizi söyler ve üç değer alır:

Policy’nin yanında şu etiketler de durabilir:

• sp= alt alan adları için ayrı policy belirler. Yazılmazsa p= geçerlidir.
• np= var olmayan alt alan adları için policy belirler ve RFC 9989’la geldi.
• rua= toplu raporların gönderileceği adrestir. Alıcı sunucular bu adrese, alan adınızla kimin mail gönderdiğini ve hangisinin geçip hangisinin kaldığını düzenli özetler hâlinde yollar.
• adkim= ve aspf= hizalama kipini seçer.

Eski rehberlerde görebileceğiniz pct= etiketi RFC 9989’la standarttan çıktı. Policy’yi mailin yalnızca bir yüzdesine uygulatan bu etiketin yerini, policy’yi bir kademe aşağıdan uygulatan deneme kipi t=y aldı. Rapor aralığını ve biçimini belirleyen ri= ile rf= de kaldırıldı.

DMARC Kaydı Nasıl Okunur? sistemkusu.com ve Google Örnekleri

Kendi DMARC kaydımız şöyle:

(Resolve-DnsName _dmarc.sistemkusu.com -Type TXT -Server 8.8.8.8).Strings

v=DMARC1; p=none; rua=mailto:iletisim@sistemkusu.com; adkim=r; aspf=r

Kayıttaki etiketler şunları söylüyor:

1. v=DMARC1 kaydın DMARC olduğunu söyler ve ilk sırada durmak zorundadır.
2. p=none alan adını izleme modunda tutar. Kalan mail için karar alıcının kendi filtresine kalır.
3. rua=mailto:iletisim@sistemkusu.com toplu raporların gideceği adrestir.
4. adkim=r ve aspf=r gevşek hizalamayı seçer. İkisi de zaten varsayılan olduğu için yazılmasalar da sonuç değişmezdi.

Kayıtta sp= yok, bu yüzden alt alan adları da p=none policy’sini devralıyor.

Aynı sorguyu Google’ın iki alan adına da sordum:

Resolve-DnsName _dmarc.google.com -Type TXT -Server 8.8.8.8 | Format-List Name,Type,TTL,Strings
Resolve-DnsName _dmarc.gmail.com -Type TXT -Server 8.8.8.8 | Format-List Name,Type,TTL,Strings

Name    : _dmarc.google.com
Type    : TXT
TTL     : 300
Strings : {v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com}

Name    : _dmarc.gmail.com
Type    : TXT
TTL     : 600
Strings : {v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com}

Aynı şirket, aynı sunucu listesiyle mail gönderen iki alan adı için iki ayrı karar vermiş. google.com kalan maili reddettiriyor. gmail.com ise kendisi için yalnızca izliyor, alt alan adları için karantina istiyor. Buradan çıkan ders şu: DMARC policy’si bir kurulum ayarı değil, alan adı başına verilen bir karardır. p=none görmek kaydın yarım kaldığını göstermez.

Kendi alan adımız da şu an izleme modunda. RFC 9989’un 5.1 bölümü bu sırayı kendisi önerir: önce p=none ile başlanır, gelen raporlardan unutulmuş gönderenler bulunur ve policy ancak bütün meşru mail hizalandıktan sonra sıkılaştırılır. Standart bu sürecin aylar sürebileceğini de yazar. Raporların nasıl okunduğunu ve reject kademesine geçişi ayrı bir yazıda kendi alan adımız üzerinde anlatacağım.

SPF, DKIM ve DMARC Birlikte Nasıl Çalışır?

Üç kaydı tek tek gördük. Alıcı sunucu ise onları tek bir akışta, belli bir sırayla okur:

1. Bağlantı. Gönderen sunucu bağlanır ve zarftaki MAIL FROM adresini söyler. Alıcı, bu adresin alan adının SPF kaydını okur ve bağlanan IP adresini listede arar.
2. İmza. Mailin gövdesi geldiğinde alıcı DKIM-Signature başlıklarını bulur, her imzanın açık anahtarını DNS’ten çeker ve imzayı doğrular.
3. Hizalama. Alıcı, From: satırındaki alan adının _dmarc kaydını okur. Geçen SPF ya da DKIM sonucunun alan adı From: ile hizalıysa DMARC geçer.
4. Karar. DMARC kalırsa alıcı alan adı sahibinin policy’sini dikkate alır, sonucu toplu rapora işler ve maili kendi filtreleriyle birlikte değerlendirir.

DMARC’tan geçmek gelen kutusuna düşmeyi garanti etmez. Üç kayıt mailin kimden geldiğini kanıtlar, mailin istenip istenmediğini değil. İçerik, gönderim hacmi ve alan adının itibarı alıcının filtresinde ayrıca tartılır. Tersi de geçerlidir. p=none policy’si olan bir alan adının kalan maili, alıcının kendi filtresinin kararına kalır.

Authentication-Results: Sonuç Mailin Başlığında Görünür

Alıcı sunucu üç kontrolün sonucunu maile Authentication-Results başlığı olarak ekler. Başlığın biçimini RFC 8601 tanımlar. Gmail’de bir mailin sağ üstündeki ⋮ menüsünden Show original (Türkçe arayüzde Aslını göster) açıldığında, Gmail sonucu sayfanın üstünde SPF, DKIM ve DMARC satırları hâlinde özetler ve altında mailin bütün başlıklarını gösterir.

İş adresimizden kişisel bir Gmail adresine tek satırlık bir test maili gönderdim ve başlığını bu sayfadan okudum. Gmail’in yazdığı satır şu:

Authentication-Results: mx.google.com; dkim=pass header.i=@sercebilisim.com header.s=google header.b="hi/2edN+"; arc=pass (i=1); spf=pass (google.com: domain of ilker.pehlivan@sercebilisim.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=ilker.pehlivan@sercebilisim.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sercebilisim.com; ...

Satırda bakılacak üç parça var:

1. SPF. spf=pass ve yanındaki smtp.mailfrom= SPF’in zarftaki adresin alan adı için geçtiğini söyler. Maili getiren sunucunun adresi 209.85.220.65, yani yukarıda ölçtüğümüz Google listesindeki 209.85.128.0/17 aralığının içinde.
2. DKIM. dkim=pass ve yanındaki header.i=@sercebilisim.com header.s=google imzanın alan adımız adına, google selector’ıyla atıldığını söyler. Alıcının doğrularken kullandığı anahtar, DNS’ten okuduğumuz anahtardır.
3. DMARC. dmarc=pass ve yanındaki header.from= hizalamanın okurun gördüğü alan adına göre yapıldığını söyler. Parantezdeki p ve sp kaydımızdaki policy’yi, dis ise alıcının bu maile uyguladığı işlemi gösterir. Buradaki değer NONE, yani alıcı maile dokunmadı.

Satırın ortasındaki arc=pass ayrı bir protokolün, ARC’ın sonucudur. ARC, posta listesi ve yönlendirme gibi aracılardan geçen mailde kimlik sonucunun yol boyunca taşınması için geliştirildi ve bu yazının konusu dışında kalıyor.

Üç alan adı aynıysa ya da aynı kurumsal alan adına bağlıysa yapılandırma doğrudur. Bizim test mailimizde üçü de sistemkusu.com. dkim=pass görüp yanında mail sağlayıcınızın kendi alan adını görüyorsanız imza sizin değil sağlayıcının adına atılıyordur. Bu durumda DMARC hizalama için yalnızca SPF’e dayanır ve yönlendirilen her mailde kalır.

SPF, DKIM ve DMARC Kaydı Nasıl Kontrol Edilir?

Bir mailin başlığı tek bir mailin sonucunu gösterir. Alan adınızın kayıtlarını ise doğrudan DNS’ten okuyabilirsiniz ve bunun için bir web aracına gerek yoktur. SPF, DKIM ve DMARC kayıtlarını Windows’ta Resolve-DnsName ya da nslookup ile sorgulayabilirsiniz. Yukarıdaki bölümlerde kullandığım üç komut şunlardı:

(Resolve-DnsName sistemkusu.com -Type TXT -Server 8.8.8.8 | Where-Object Strings -like 'v=spf1*').Strings
(Resolve-DnsName google._domainkey.sistemkusu.com -Type TXT -Server 8.8.8.8).Strings -join ''
(Resolve-DnsName _dmarc.sistemkusu.com -Type TXT -Server 8.8.8.8).Strings

sistemkusu.com yerine kendi alan adınızı, google yerine kendi selector’ınızı yazmanız yeter.

nslookup her Windows’ta hazır gelir, ama TXT kayıtlarını süzmez:

nslookup -type=TXT sistemkusu.com 8.8.8.8

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

sistemkusu.com	text =

	"google-site-verification=sY-HJSlArb8BVtDfxWaqv-HiE9uMAXl5iGzMgrbzJw8"
sistemkusu.com	text =

	"v=spf1 include:_spf.google.com ~all"
sistemkusu.com	text =

	"google-site-verification=MqLYPnQX37ILd78lG-oIW7l8mccPmgC5bEYYNa5gVRA"

Ölçüm betiği aynı sorguyu hemen öncesinde aynı DNS sunucusuna Resolve-DnsName ile süzmeden de sordu ve orada SPF satırı ilk sıradaydı. nslookup onu ortada veriyor. DNS bir addaki kayıtların sırasını garanti etmez. Bu yüzden SPF kaydını sırasına göre değil, v=spf1 ile başlayan satırı arayarak bulun.

Çıktıda şunlara bakın:

1. SPF tek satır mı? v=spf1 ile başlayan tam olarak bir satır dönmeli. İki satır dönüyorsa ikisi de geçersizdir.
2. SPF neyle bitiyor? Mail gönderen alan adında ~all, göndermeyende -all beklenir. +all herkesi yetkili sayar ve kaydı anlamsız kılar.
3. DKIM anahtarı dönüyor mu? v=DKIM1 ve dolu bir p= dönmeli. DNS adı yok görüyorsanız selector yanlıştır ya da anahtar hiç yayımlanmamıştır.
4. DMARC kaydı doğru adda mı? Kayıt _dmarc adında durmalı ve v=DMARC1 ile başlamalıdır. Kök alan adına yazılmış bir DMARC kaydını alıcılar hiç okumaz.
5. Rapor adresi okunuyor mu? rua= bir kutuya gidiyorsa o kutu birinin önüne düşmelidir, yoksa izleme modu hiçbir şey izlemez.

Değişiklik gerekiyorsa kayıtlar alan adınızın DNS’ini yönettiğiniz panele girilir, yani nameserver’larınız hangi firmadaysa oraya. Bunun alan adını aldığınız firma olmak zorunda olmadığını ve panelin isim alanının nasıl doldurulduğunu DNS rehberimizde anlattık. İsim alanına SPF için kök alan adı (çoğu panelde @ ya da boş), DKIM için google._domainkey, DMARC için _dmarc yazılır. Bizim kayıtlarımızın TTL değeri 60 saniye, yani bir değişiklik bir dakika içinde önbelleklerden düşer.

Kontrol listesinden biri tutmuyorsa sebebini bir sonraki bölümdeki tabloda arayın.

SPF, DKIM ve DMARC’ta Sık Yapılan Hatalar

Belirtiden sebebe gitmek için aşağıdaki tablo, bu yazıda anlatılan mekanizmaların hata hâllerini bir araya getiriyor:

Mailleriniz karşı tarafta spam’e düşüyorsa teşhis şu sırayla daralır:

1. Kendi kişisel Gmail adresinize bir test maili gönderin ve başlığındaki Authentication-Results satırından üç sonuçtan hangisinin kaldığını bulun.
2. Kalan kontrolün kaydını yukarıdaki komutlarla sorgulayın ve tabloda karşılığını arayın.
3. Üçü de geçiyorsa sorun kimlikte değil, içerik ya da itibardadır. Bakılacak yer SMTP tarafındaki teşhis sırasıdır.

Mail Göndermeyen Alan Adını Korumak: SPF, DMARC ve Null MX

Buraya kadar anlatılan her şey mail gönderen bir alan adı içindi. Hiç mail göndermeyen bir alan adı da sahte göndericiye açıktır ve onu korumak, mail gönderen bir alan adını korumaktan kolaydır. Ortada hizalanacak meşru bir gönderen olmadığı için policy ilk günden reject olabilir. Kayıt hiç yoksa alıcı sunucunun uygulayacağı bir talimat da yoktur, çünkü RFC 9989’a göre DMARC kaydı bulunamayan alan adında DMARC hiç devreye girmez.

Birleşik Krallık hükümetinin dijital hizmet birimi GDS, mail göndermeyen alan adları için yayımladığı rehberde şu kayıtları öneriyor:

Rehberin DMARC örneği bunlara ek olarak rapor adresi ve katı hizalama da taşıyor. Rapor görmek isterseniz kayda bir rua= eklemeniz yeter.

DNS rehberimizin MX bölümünde bir alan adında hiç MX kaydı yoksa gönderen sunucunun A kaydına düştüğünü anlatmıştık. Null MX bu düşüşü kapatır. Tanımı RFC 7505 belgesidir ve bu kaydı gören gönderen sunucu maili kuyrukta bekletmeden hemen geri çevirir. GDS’nin rehberi, bazı DNS panellerinin null MX kaydını kabul etmediğini de not düşüyor.

Sonuç: Göndereni Kanıtlayan Şey Hizalamadır

Üç kaydın işi tek cümleye sığar: SPF sunucuyu, DKIM içeriği, DMARC ise okurun gördüğü göndereni doğrular.

Asıl kalması gereken ayrım üçüncüsündedir. SPF ve DKIM tek başına bir alan adını kanıtlar, ama hangi alan adını kanıtlayacaklarını gönderen seçer. Bir saldırgan kendi alan adıyla iki kontrolden de geçebilir. Okurun ekranındaki adresi koruyan tek şey, bu sonuçların From: satırıyla hizalanmasını şart koşan DMARC’tır.

Girişteki otogar benzetmesine son kez dönelim. Masa plakaya ve mühre baktı, sonra son soruyu sordu: liste ve mühür biletteki firmaya mı ait? Firma masaya bir talimat bıraktıysa görevli ne yapacağını bilir. Bırakmadıysa karar görevlinin kendi sezgisine kalır.

Bu üç kayıt DNS kayıt türlerinin bir parçasıdır ve DNS zone’unuzda durur. Mailin sunucular arasında nasıl taşındığını SMTP rehberimizde, şirket ölçeğinde e-posta güvenliğinin diğer katmanlarını siber güvenlik önlemleri rehberimizde anlattık.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn