E-posta biçimi tahmini ve doğrulama

Kurumlar e-posta adreslerini bir kalıba göre üretir. Kalıbı bulmak, adres listesini tahmin etmeyi kolaylaştırır. Bu derste iki ayrı iş yaparsın.

Birincisi, açık kaynaklardan kalıbı çıkarmak ve bunun neden bir güvenlik bulgusu olduğunu anlamaktır. İkincisi, alan adının posta altyapısını okuyup kurumun sahte postaya karşı ne kadar korunduğunu ölçmektir. İkisi birlikte oltalamaya karşı kurumun gerçek durumunu gösterir.

Kalıbın kendisi bile bir bulgudur, çünkü tahmin edilebilir adres biçimi hedefli oltalamayı kolaylaştırır. Kurum bunu tamamen engelleyemez, adreslerin okunabilir olması gerekir. Yapılabilecek şey kalıbın etrafını güçlendirmektir.

Adres kalıpları sınırlıdır. En yaygın beşi şöyledir: ad.soyad, adsoyad, a.soyad, asoyad ve soyad.ad. Kurumun açık sayfalarında birkaç adres görürsen kalıbı çıkarırsın; üç ya da dört örnek genelde yeterlidir. Basın bülteni, destek sayfası ve yayımlanmış PDF dosyaları bu örnekleri taşır.

İki bilinen adres aynı kalıbı izliyorsa üçüncü bir çalışan için de aynı kalıbı uygularsın. Örneğin iki adres ad.soyad biçimindeyse yeni gelen çalışanın adı ve soyadı da aynı sırayla birleştirilir. Bu çıkarım basit bir örüntü eşlemesidir, ama garanti vermez; kurumun ortasında kalıp değişmiş olabilir. Örnek sayısı arttıkça kalıba olan güven de artar.

$ grep -ohE '[a-z]+\.[a-z]+@beyazvadi\.example' belgeler/*.txt | sort | uniq -c
   3 [email protected]
   2 [email protected]
   1 [email protected]

Komutu parça parça oku. grep -o yalnız eşleşen parçayı yazar, -h dosya adını gizler, -E genişletilmiş düzenli ifadeyi açar. Düzenli ifade (regex), metinde bir örüntü tanımlayan kısa bir dildir.

Buradaki desen, noktayla ayrılmış iki küçük harfli sözcüğü ve ardından kurumun alan adını arar. sort ve uniq -c aynı adresleri bir araya toplar ve sayar. Çıktıda üç adres var ve üçü de ad.soyad biçiminde.

Baştaki sayılar, adresin belgelerde kaç kez geçtiğini gösterir. Rol adresleri (info, destek, muhasebe) bu noktayı taşımaz, tek sözcüktür. Bu farkı desene çevirirsen yüzlerce satır arasından yalnız kişiye bağlı adresleri ayıklarsın.

[email protected]
[email protected]

? Deniz Aksoy -> ?

Kalıbı bulmak tahmin üretir, kanıt üretmez. Tahmin edilen adresin gerçekten var olduğunu bilmezsin. Burada acemi analist hata yapar ve listeyi doğrulanmış diye rapora koyar.

Doğru etiket 'olası adres kalıbı' olmalıdır. Türkçe harfler de bir tuzaktır. [a-z] aralığı ç, ğ, ı, ö, ş ve ü harflerini kapsamaz. Kurumların çoğu adreste bu harfleri Latin karşılığına çevirir, ama çevirmeyen kurumda desen adresleri kaçırır.

Deseni her zaman küçük bir örnek küme üstünde sınarsın. Rol adresleri ise ayrı bir başlıktır. destek@ ya da muhasebe@ gibi adresler kişiye değil göreve aittir ve raporda rahatça yer alır.

Alan adının posta altyapısını okumak meşru ve yararlıdır, çünkü bu kayıtlar zaten herkese açıktır ve okumak hedefe tek bir istek atmaz. MX kaydı postayı hangi sunucunun karşıladığını söyler. TXT kaydındaki SPF satırı hangi sunucuların o alan adı adına posta yollayabileceğini yazar. DMARC kaydı ise doğrulamayı geçemeyen postaya ne yapılacağını belirler.

Üçünü birlikte okuyunca kurumun sahte posta savunmasını tek cümlede özetleyebilirsin. Bu üç satır, kurumsal ayak izi raporunda her zaman yer alır.

$ dig MX beyazvadi.example +short
10 mail.beyazvadi.example.

$ dig TXT beyazvadi.example +short
"v=spf1 ip4:198.51.100.0/24 include:_spf.postasaglayici.example -all"

$ dig TXT _dmarc.beyazvadi.example +short
"v=DMARC1; p=reject; rua=mailto:[email protected]"

Çıktıyı satır satır oku. İlk komut MX kaydını sorar. 10 sayısı öncelik değeridir; birden çok sunucu olsaydı küçük sayı önce denenirdi.

İkinci komut TXT kayıtlarını getirir ve v=spf1 ile başlayan satır SPF politikasıdır. ip4:198.51.100.0/24 kurumun kendi posta sunucularını, include ise dış posta sağlayıcısını sayar. Sondaki -all, listede olmayan her göndericinin reddedilmesini ister.

Üçüncü komut _dmarc ön ekli adı sorar. p=reject doğrulamayı geçemeyen postanın reddedilmesini ister. rua ise toplu raporların gideceği adresi yazar.

Kayıtta sp etiketi yok. Bu durumda alt alan adları da p değerini, yani reject politikasını devralır.

SPF kaydını okumak birkaç ayrıntı ister. Kayıt mekanizmalardan kurulur. ip4 ve ip6 belirli adresleri sayar. a ve mx kaydın kendi A ve MX adreslerini kullanır.

include başka bir alan adının SPF kaydını içeri çağırır. Kaydın sonundaki niteleyici asıl kararı verir. -all listede olmayan her göndericiyi reddeder. ~all yalnız şüpheli olarak işaretler ve teslimi sürdürür. ?all ise nötr kalır.

RFC 7208 önemli bir sınır da koyar: DNS sorgusu yapan terimlerin toplamı on ile sınırlıdır. include, a, mx, ptr, exists ve redirect bu sayıya girer; ip4, ip6 ve all girmez. Sınır aşılırsa doğrulama permerror döner.

$ dig TXT _spf.postasaglayici.example +short
"v=spf1 ip4:203.0.113.0/24 include:kampanya._spf.postasaglayici.example -all"

$ dig TXT kampanya._spf.postasaglayici.example +short
"v=spf1 ip4:192.0.2.0/25 mx -all"

Zinciri sayarak oku. Kurumun kendi kaydında bir include var: birinci sorgu. Sağlayıcının kaydında bir include daha var: ikinci sorgu.

Kampanya kaydındaki mx üçüncü sorguyu açar. ip4 satırları ve -all sorgu harcamaz. Toplam üç sorgu, sınırın çok altındasın.

Şimdi kurumun bir müşteri ilişkileri servisi, bir destek masası ve bir bülten servisi için üç include daha eklediğini düşün. Her biri kendi içinde iki include taşıyorsa sayı on ikiye çıkar. On sınırı aşılır, doğrulama permerror döner ve SPF hiçbir göndericiyi doğrulayamaz.

Kayıt yerinde durur ama sessizce çalışmaz. Kurumsal raporda uzun bir include zinciri bu yüzden ayrı bir bulgudur.

DMARC standardı 2026'da yenilendi. Yıllarca bilgilendirici RFC 7489 olarak kullanılan yöntem, RFC 9989 numarasıyla standartlar yoluna taşındı. Yeni belgede kayıt okumayı doğrudan etkileyen değişiklikler var. Eski pct etiketi, yani politikanın yalnız belirli bir yüzde mesaja uygulanmasını isteyen alan, uygulamada tutarsız çalıştığı için tarihe kaldırıldı.

p etiketi ana politikayı belirler: none yalnız gözler, quarantine postayı şüpheli sayıp spam kutusuna düşürür, reject reddeder. sp etiketi var olan alt alan adlarını, np etiketi ise var olmayan alt alan adlarını ayrı yönetir. Alt alan adının kendi DMARC kaydı yoksa politika üst alan adından gelir.

$ dig TXT _dmarc.pazarlama.beyazvadi.example +short

$ dig TXT s1._domainkey.beyazvadi.example +short
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

$ dig MX kullanilmayan.beyazvadi.example +short
0 .

Kodu satır satır oku. pazarlama alt alan adı için DMARC sorgusu boş döner. Alıcı bu durumda alan adı ağacında yukarı yürür ve beyazvadi.example kaydını bulur. Kayıtta sp varsa onu, yoksa p değerini uygular.

İkinci satır DKIM kaydıdır. DKIM postayı imzalar ve kayıt bir seçici (selector) adının altında durur. Buradaki seçici s1'dir. Seçiciyi bilmeden kaydı bulamazsın, bu yüzden kaydın çıkmaması DKIM yok demek değildir.

Seçiciyi gerçek bir postanın DKIM-Signature başlığındaki s= etiketinden okursun. Son satır posta göndermeyen alan adının savunmasıdır. RFC 7505'in tanımladığı null MX, yani tek başına '0 .' satırı, alan adının hiç posta almadığını ilan eder.

Null MX tek başına yetmez. Kullanılmayan alan adına 'v=spf1 -all' ve p=reject taşıyan bir DMARC kaydı da eklersin. Üçü birlikte o adı sahte postaya kapatır. Saldırgan korunan ana alan adı yerine unutulmuş bir kampanya ya da eski marka alanını seçebilir, çünkü orada kayıt yoktur.

RFC 8461'in tanımladığı MTA-STS ise başka bir açığı kapatır. Gelen postanın şifreli kanaldan teslim edilmesini zorunlu kılar ve araya giren birinin şifrelemeyi düşürmesini engeller. Küçük eklemelerle büyük kapılar kapanır.

Kurum bu kayıtları bir kerede sertleştirmez. ABD siber güvenlik kurumu CISA, 2017'de yayımladığı BOD 18-01 direktifiyle federal kurumlara bir yol çizdi. Kurumlar doksan gün içinde geçerli SPF ve en az p=none politikalı bir DMARC kaydı yayımlayacak, raporlar için bir adres tanımlayacaktı.

Bir yıl içinde ise politikayı p=reject seviyesine çekeceklerdi. Birleşik Krallık ulusal siber güvenlik merkezinin sahte posta rehberi de aynı sırayı izler. Önce p=none ile gözler ve rua adresine gelen toplu raporları okursun.

Meşru göndericileri SPF ve DKIM'e eklersin. Sonra p=quarantine ile sahte postayı spam kutusuna düşürür, en sonunda p=reject'e geçersin. Aceleyle p=reject'e geçen kurum kendi faturalarını da kaybedebilir.

<record>
  <row>
    <source_ip>203.0.113.77</source_ip>
    <count>214</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>beyazvadi.example</header_from>
  </identifiers>
</record>

Raporun bu kaydını satır satır oku. source_ip postayı gönderen sunucunun adresidir. count, raporun kapsadığı sürede o sunucudan gelen ileti sayısıdır: 214. disposition none, çünkü kurum o dönemde p=none ile izliyordu ve alıcı postayı teslim etti.

dkim ve spf satırları fail diyor. header_from ise postanın Beyaz Vadi adıyla geldiğini gösterir. Bu kaydın iki açıklaması olabilir.

Ya kurum adına posta atan ama kayıtlara eklenmemiş meşru bir servis vardır, ya da biri kurumun adını taklit ediyordur. Ayırmak için adresin hangi ağa ait olduğunu sorgular ve ekiplere bu servisi kullanıp kullanmadıklarını sorarsın. Meşruysa kayda eklersin. Değilse bu satır p=reject için en güçlü gerekçedir.

Adres doğrulamada sınır nettir. Posta sunucusuna bağlanıp adresleri tek tek denemek, örneğin SMTP oturumunda VRFY ya da RCPT TO komutu göndermek, hedefe doğrudan istek atmaktır. Bu istek izinsizdir ve sunucunun kaydına düşer.

Üçüncü taraf doğrulama servisleri de çoğu zaman aynı denemeyi senin adına yapar, sorumluluk yine sende kalır. Gerçek kişilerin adreslerini toplayıp liste kurmak KVKK kapsamında veri işlemedir. TCK 136 da kişisel veriyi hukuka aykırı biçimde ele geçirmeyi ve başkasına vermeyi cezalandırır.

Kurum tarafında savunma bellidir. Sunucu VRFY komutunu kapatır ve var olan ile olmayan alıcıya aynı yanıtı verir. Kısa sürede çok sayıda RCPT TO deneyen istemci ise kayıtta belirgin bir desen bırakır ve sınırlanır.

Üç kaydı birlikte okuyup tek bir cümlede özetlemeyi hedefle. Beyaz Vadi için cümle şöyle kurulur: kurum SPF'i -all ile kapatmış, DMARC'ı p=reject ile uygulamış ve sp etiketi olmadığı için alt alan adları da aynı politikayı devralıyor. Bu cümle güçlü bir savunmayı anlatır.

Ters bir örnekte SPF ~all ile biter ve DMARC p=none kalır. O durumda sahte posta yalnız raporlanır ve teslim edilmeye devam eder. Rapora kalıbı ve politikanın zayıf noktasını yazarsın, tahmin ettiğin kişi adreslerini değil. Kullanılmayan alan adları için null MX, boş SPF ve reddeden DMARC önerisini de eklersin.