Merhaba,

Bir kurumun e-posta güvenliği, aslında birkaç DNS kaydında saklıdır. SPF, DKIM ve DMARC doğru yapılandırılmamışsa; alan adınız adına sahte e-posta gönderilmesi teknik olarak son derece kolaydır. Buna DNSSEC, MTA-STS, TLS-RPT ve CAA kayıtlarını da eklediğinizde, tek bir domain için kontrol edilmesi gereken yedi sekiz farklı kayıt ortaya çıkıyor.

Bunları web tabanlı araçlarla tek tek kontrol etmek mümkün, ancak 40-50 domainli bir kurumsal envanterde bu iş hızla katlanılmaz hale geliyor. İşte tam bu noktada Martien van Dijk tarafından geliştirilen DomainHealthChecker PowerShell modülü devreye giriyor.

Bu yazıda modülü tanıtacak, her bir cmdlet’i örnekleriyle göstereceğim. Sonunda da toplu tarama yapıp HTML + CSV rapor üreten kendi wrapper script’imi paylaşacağım.

Neden Bu Kayıtlar Önemli?

Kayıtlara girmeden önce kısa bir hatırlatma yapalım. Aşağıdaki tabloda her kaydın ne işe yaradığını özetledim:

Kayıt	Açılımı	Ne Yapar	Yoksa Ne Olur?
SPF	Sender Policy Framework	Domain adına e-posta göndermeye yetkili sunucuları listeler	Herkes sizin adınıza mail gönderebilir
DKIM	DomainKeys Identified Mail	Giden mesajlara kriptografik imza ekler	Mesaj içeriğinin değiştirilmediği doğrulanamaz
DMARC	Domain-based Message Authentication, Reporting and Conformance	SPF/DKIM’den geçemeyen mesajlara ne yapılacağını söyler	SPF ve DKIM pratikte yaptırımsız kalır
DNSSEC	Domain Name System Security Extensions	DNS cevaplarını kriptografik olarak imzalar	DNS cache poisoning riski
MTA-STS	Mail Transfer Agent Strict Transport Security	Sunucular arası TLS bağlantısını zorunlu kılar	TLS downgrade ve MITM saldırıları
TLS-RPT	TLS Reporting	TLS teslimat hatalarını rapor eder	Şifreleme hataları görünmez kalır
BIMI	Brand Indicators for Message Identification	Kurum logosunun posta kutusunda görünmesini sağlar	Marka görünürlüğü ve güven kaybı
CAA	Certification Authority Authorization	Domain için sertifika kesebilecek CA’ları sınırlar	Yetkisiz CA’dan sertifika alınabilir

Buradaki kritik nokta şu: bu kayıtlar birbirinden bağımsız değil. DMARC olmadan SPF ve DKIM birer tavsiye niteliğinde kalır. BIMI ise p=quarantine veya p=reject seviyesinde çalışan bir DMARC politikası olmadan zaten devreye girmez. Dolayısıyla hepsini birlikte görmek gerekir.

Modül Hakkında

Yazı tarihi itibarıyla modülün güncel sürümü 2.2.0. Bilmeniz gereken teknik detaylar:

• Minimum PowerShell sürümü: PowerShell 5.1
• Platform desteği: Windows, Linux ve macOS (PowerShell Core ile)
• Bağımlılık: Yok, harici modül gerektirmiyor
• Lisans ve depo: https://github.com/bakicubuk/Domain_SpfDkimDmarc_Checker

Adım 0: PowerShell Sürümünüzü Öğrenin

Hangi PowerShell sürümünde olduğunuzu kontrol etmek için:

$PSVersionTable.PSVersion

Çıktı bu şekildeyse Windows PowerShell 5.1 üzerindesiniz demektir:

Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      26100  33158

Bu bilgiyi aklınızda tutun; birazdan Install-PSResource bölümünde neden hata alacağınızı bu belirleyecek.

Yöntem 1: PowerShell Gallery (Önerilen)

Hem PowerShell 5.1 hem PowerShell 7.x üzerinde çalışan, en pratik yol. PowerShell’i Run as administrator (Yönetici olarak çalıştır) ile açıp:

Install-Module -Name DomainHealthChecker -Scope CurrentUser

Temiz bir sistemde ilk kurulumda PowerShell önce NuGet provider’ının kurulması için onay isteyecek. PowerShellGet modülü, NuGet tabanlı depolarla konuşabilmek için en az 2.8.5.201 sürümüne ihtiyaç duyuyor. Y diyerek devam ediyoruz:

Ardından ikinci bir onay ekranı geliyor: PSGallery varsayılan olarak untrusted repository (güvenilmeyen depo) olarak işaretlidir. Bu, modüle özgü bir güvenlik uyarısı değil, PSGallery’nin genel varsayılanıdır. Yine Y ile onaylıyoruz:

Kurulum sessizce tamamlanıyor ve prompt geri dönüyor:

Bu onay ekranlarını her seferinde görmek istemiyorsanız, PSGallery’yi güvenilir olarak işaretleyebilirsiniz. Ancak bunu bilinçli bir tercih olarak yapın; ondan sonra bu depodan kuracağınız her modül uyarısız kurulacaktır:

Set-PSRepository -Name PSGallery -InstallationPolicy Trusted

Kurulum tamamlandıysa doğrudan “Kurulumu Doğrulama” bölümüne geçebilirsiniz. Aşağıdaki iki yöntem alternatiftir, zorunlu değildir.

Yöntem 2: PSResourceGet ile Kurulum

Modülün dokümantasyonunda Install-PSResource ile kurulum da öneriliyor. Ancak bu komutu Windows PowerShell 5.1 üzerinde çalıştırırsanız hata alırsınız:

Install-PSResource -Name DomainHealthChecker/code>

Hatanın nedeni basit: Install-PSResource, Microsoft.PowerShell.PSResourceGet modülüyle gelir ve bu modül Windows PowerShell 7.4 ve sonrasında kutudan çıkar. PowerShell 5.1’de varsayılan olarak bulunmaz. Adım 0’da 5.1 gördüyseniz bu hata beklenen davranıştır.

İki seçeneğiniz var. Ya klasik Install-Module ile devam edersiniz (5.1’de sorunsuz çalışır), ya da PSResourceGet’i ayrıca kurarsınız:

Install-Module -Name Microsoft.PowerShell.PSResourceGet -Scope CurrentUser -Force

Kurulum çıktı üretmeden tamamlanır ve prompt geri döner:

Artık Install-PSResource komutu kullanılabilir:

Install-PSResource -Name DomainHealthChecker

İsteğe Bağlı: PowerShell 7 Kurulumu

Modül 5.1’de sorunsuz çalışıyor, dolayısıyla sırf bu modül için PowerShell 7 kurmak zorunda değilsiniz. Ancak Install-PSResource gibi modern komutları kullanmak ya da modülü Linux/macOS tarafında da çalıştırmak istiyorsanız PowerShell 7’ye geçmek mantıklı.

En pratik kurulum yolu winget:

winget install --id Microsoft.PowerShell --source winget

winget paketi bulur, installer hash’ini doğrular ve kurulumu tamamlar. Bu yazının hazırlandığı sırada gelen sürüm 7.6.4 idi:

Burada dikkat çeken nokta şu: kurulum bittiğinde mevcut PowerShell pencereniz kendiliğinden 7’ye dönüşmez. Yeni bir terminal açıp pwsh komutuyla başlatmanız gerekiyor. Windows Terminal kullanıyorsanız yeni sekme menüsünde “Windows PowerShell” (5.1) ve “PowerShell 7” ayrı ayrı listelenir.

Doğrulama:

pwsh -NoLogo -Command '$PSVersionTable.PSVersion'

Çıktıda Major 7 / Minor 6 / Patch 4 görünüyor. Windows PowerShell’in Major/Minor/Build/Revision şemasından farklı olarak PowerShell 7 semantik sürümleme kullanır; bu da hangi sürümde olduğunuzu bir bakışta ayırt etmenizi sağlar.

İki sürüm yan yana çalışır, PowerShell 7 kurulumu 5.1’i kaldırmaz. Ancak modül dizinleri ayrıdır:

Sürüm	Modül Dizini
Windows PowerShell 5.1	Documents\WindowsPowerShell\Modules
PowerShell 7.x	Documents\PowerShell\Modules

Bu ayrım önemli: 5.1’de kurduğunuz DomainHealthChecker modülü PowerShell 7’de otomatik olarak görünmez. pwsh içinde Install-Module -Name DomainHealthChecker -Scope CurrentUser komutunu bir kez daha çalıştırmanız gerekir.

Yani 5.1’de kurduğunuz DomainHealthChecker modülü PowerShell 7’de otomatik olarak görünmez; pwsh içinde bir kez daha Install-Module çalıştırmanız gerekir.

Yöntem 3: GitHub’dan Manuel Kurulum

PowerShell Gallery’ye erişimin kısıtlı olduğu ortamlarda modülü GitHub üzerinden klonlayıp elle import edebilirsiniz.

Önkoşul: Git

Temiz bir Windows sunucusunda Git varsayılan olarak gelmez. Kurulu değilse git clone komutu şu hatayı verir:

git : The term 'git' is not recognized as the name of a cmdlet, function, script file, or operable program.

Burada dikkat çeken nokta şu: bu hatayı gördükten sonra ardından çalıştıracağınız cd ve Import-Module komutları da hata verir. Bu ikisi ayrı sorunlar değildir; klasör hiç oluşmadığı için zincirleme oluşan sonuçlardır. Yani düzeltilmesi gereken tek bir sorun var: Git eksik.

Git’i winget ile kurun:

winget install --id Git.Git --source winget

Kurulumdan sonra terminali kapatıp yeniden açın. PATH değişikliği mevcut oturuma yansımaz; aynı pencerede devam ederseniz git komutu hala tanınmaz.

Yeni terminalde doğrulayın:

git --version

Sürüm numarası göründüyse klonlamaya hazırsınız.

Klonlama ve Import-buradakaldım. 

Depoyu nereye indireceğinizi kontrol etmek için önce hedef dizine geçin, sonra klonlayın. Bu yazıdaki wrapper script’i de içeren kendi depomu kullanmak isterseniz:

git clone https://github.com/bakicubuk/Domain_SpfDkimDmarc_Checker.git
cd .\Domain_SpfDkimDmarc_Checker\
Import-Module .\DomainHealthChecker.psd1

Yalnızca modülün orijinalini istiyorsanız:

Get-ChildItem -Filter *.psd1 -Recurse | Select-Object FullName

Komutları web sayfasından kopyalıyorsanız, satır sonlarına görünmez kontrol karakterlerinin (^D gibi) bulaşabildiğini unutmayın. PowerShell bunları komutun parçası sayar ve anlaşılmaz hatalar üretir. Şüpheli bir durumda komutu elle yazmak en hızlı çözümdür.

Import etmeden önce manifest’i doğrulamak iyi bir alışkanlıktır. Özellikle kendi fork’unuzu ya da başkasının deposunu kullanıyorsanız, çalıştırdığınız kodun ne olduğunu bilerek import edin:

Test-ModuleManifest .\DomainHealthChecker.psd1
Import-Module .\DomainHealthChecker.psd1 -Force -Verbose
Get-Command -Module DomainHealthChecker

Kurulum sonrası modülün dışa aktardığı komutları listeleyelim:

Get-Command -Module DomainHealthChecker

Git Kurmadan: ZIP ile İndirme

Sunucuya Git kurmak istemiyorsanız ya da kurulum izniniz yoksa, depoyu ZIP olarak indirip açabilirsiniz:

$Zip = "$env:TEMP\dhc.zip"
Invoke-WebRequest -Uri "https://github.com/bakicubuk/Domain_SpfDkimDmarc_Checker/archive/refs/heads/main.zip" -OutFile $Zip
Expand-Archive -Path $Zip -DestinationPath $env:USERPROFILE\Documents -Force
Remove-Item $Zip

ZIP ile indirdiğinizde klasör adının sonuna dal adı eklenir (Domain_SpfDkimDmarc_Checker-main gibi), cd komutunda buna dikkat edin.

 

Modüldeki Cmdlet’ler ve Alias’lar

Modül 10 fonksiyon export ediyor ve her biri için kısa bir alias tanımlı:

Cmdlet	Alias	Ne İşe Yarar
Invoke-SpfDkimDmarc	isdd	Tüm kontrolleri tek seferde çalıştırır
Get-SPFRecord	gspf	SPF kaydı, uzunluğu ve DNS lookup sayısı
Get-DKIMRecord	gdkim	DKIM kaydı ve selector tespiti
Get-DMARCRecord	gdmarc	DMARC politikası
Get-DNSSEC	gdnssec	DNSSEC durumu
Invoke-MtaSts	gmts	MTA-STS yapılandırması
Get-BimiRecord	gbimi	BIMI kaydı
Get-TlsRpt	gtlstps	TLS-RPT kaydı
Get-CAARecord	gcaa	CAA kaydı
Update-ModuleDomainHealthChecker	—	Modülü günceller

Invoke-SpfDkimDmarc için ayrıca Show-SpfDkimDmarc alias’ı da tanımlı.