DMARC Politikası Kaynaklı Mail Reddini Anlama ve Çözme

Bykomut

Mail sunucunuzu kurdunuz, SPF ve DKIM ayarlarını yaptınız, her şey yolunda gidiyor sandınız. Sonra bir gün müşteriden ya da iş arkadaşından “senin gönderdiğin mailler gelmiyor” haberi geldi. Log dosyalarına bakıyorsunuz ve karşınızda şöyle bir satır var: 550 5.7.1 Email rejected per DMARC policy. İşte tam bu noktada DMARC dünyasına dalmak zorundasınız. Bu yazıda DMARC’ın ne olduğunu, nasıl çalıştığını, neden mail reddettiğini ve bu sorunları nasıl debug edeceğinizi adım adım anlatacağım.

DMARC Nedir ve Neden Önemlidir

DMARC, Domain-based Message Authentication, Reporting and Conformance kelimelerinin kısaltmasıdır. Temel amacı, bir domain adına gönderilen e-postaların gerçekten o domain sahibi tarafından gönderilip gönderilmediğini doğrulamaktır. SPF ve DKIM’in üzerine oturur ve bu iki mekanizmayı bir arada değerlendirerek domain sahibine “bu maillerle ne yapılsın?” diyebilme yetkisi tanır.

DMARC’ın çalışma mantığını anlamak için önce şunu kafanıza yerleştirmeniz gerekiyor: SPF, mailin hangi sunuculardan gönderilebildiğini söyler. DKIM, mailin içeriğinin imzalanıp imzalanmadığını doğrular. DMARC ise bu ikisinin sonucunu alır ve üstüne bir de “alignment” kontrolü ekler. Yani sadece SPF geçti ya da DKIM geçti demek yetmez; geçen kontrol aynı zamanda mailin From: header’ındaki domain ile hizalanmış olmalıdır.

Gerçek dünyada bu şu anlama gelir: Bir saldırgan sizin domain’inizi taklit ederek mail göndermeye çalışıyorsa ve alıcı taraf DMARC uyguluyorsa, bu mailler reddedilir veya spam klasörüne düşer. Ancak yanlış yapılandırılmış sistemlerde meşru mailleriniz de aynı akıbete uğrayabilir.

DMARC DNS Kaydını Anlamak

DMARC bir DNS TXT kaydıdır ve _dmarc.yourdomain.com şeklinde tanımlanır. Bir örnek görelim:

dig TXT _dmarc.yourdomain.com +short

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

"v=DMARC1; p=reject; sp=quarantine; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s"

Bu kayıttaki parametreleri tek tek açıklayalım:

  • v=DMARC1: DMARC versiyonunu belirtir, zorunlu alan
  • p=reject: Ana politika. none, quarantine veya reject olabilir
  • sp=quarantine: Subdomain politikası. Belirtilmezse ana politika geçerli olur
  • pct=100: Politikanın uygulanacağı mail yüzdesi. Test için düşük tutulabilir
  • rua: Aggregate (toplu) raporların gönderileceği adres
  • ruf: Forensic (detaylı hata) raporlarının gönderileceği adres
  • adkim=s: DKIM alignment modu. s (strict) veya r (relaxed)
  • aspf=s: SPF alignment modu. s (strict) veya r (relaxed)

Neden Mailler Reddediliyor: Temel Sebepler

SPF ve DKIM Alignment Sorunu

En yaygın DMARC red sebebi alignment sorunudur. Diyelim ki şirketiniz sirket.com domain’ini kullanıyor. Maillerinizi bir üçüncü parti servis üzerinden gönderiyorsunuz, mesela Mailchimp veya SendGrid. Bu servisler kendi SPF kayıtlarını geçirebilir ama mailin From: alanındaki domain sizin domain’inizle hizalanmadığı sürece DMARC başarısız olur.

Bunu test etmek için:

# Mail header'larını analiz etmek için
cat /var/log/mail.log | grep "DMARC"

# Postfix log'larında DMARC red mesajlarını bulmak
grep "reject" /var/log/mail.log | grep -i "dmarc" | tail -50

Forwarding Senaryoları

Mail yönlendirme (forwarding) DMARC’ın en büyük baş ağrısıdır. Kullanıcı A, [email protected] adresine gelen mailleri [email protected] adresine yönlendiriyor. Bu durumda:

  • Orijinal mail SPF kontrolünden geçer
  • Mail yönlendirilince SPF başarısız olur (çünkü yönlendiren sunucu SPF’te yetkili değil)
  • DKIM imzası genellikle korunur ama bazı sistemler body’i değiştirir ve DKIM bozulur
  • DMARC her iki kontrolü de başarısız bulur ve politikaya göre reddeder

Bu senaryoyu debug etmek için alıcı taraftaki mail log’larına bakmanız gerekir. Kendi sunucunuzda gönderici tarafındaysanız şunları kontrol edebilirsiniz:

# SPF kontrolü için manuel test
python3 -c "
import spf
result = spf.check(i='SENDER_IP', s='[email protected]', h='mail.sirket.com')
print(result)
"

Yanlış SPF Kaydı

SPF kaydınız eksik ya da hatalıysa DMARC başarısız olur. SPF kaydını kontrol edelim:

# SPF kaydını sorgulama
dig TXT sirket.com +short | grep "v=spf"

# Daha detaylı çıktı için
dig TXT sirket.com

Eğer birden fazla SPF kaydınız varsa bu zaten bir sorun. RFC standartlarına göre bir domain için sadece bir SPF TXT kaydı olabilir. Birden fazla kayıt varsa SPF “permerror” döndürür ve DMARC başarısız olur.

Pratik Debug Adımları

Adım 1: Mail Header Analizi

Bir mail reddedildiğinde ya da spam’e düştüğünde yapmanız gereken ilk şey mail header’larını incelemektir. Gmail’de “Orijinali göster” seçeneği tam da bunun için var. Header’larda şunları arayın:

# Header örneği - bunları mail header'ında göreceksiniz
Authentication-Results: mx.google.com;
   dkim=fail [email protected] header.s=mail header.b=AbCdEfGh;
   spf=softfail (google.com: domain of sirket.com does not designate 1.2.3.4 as permitted sender) smtp.mailfrom=sirket.com;
   dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=sirket.com

Bu çıktıdaki her satır size altın değerinde bilgi verir. dmarc=fail satırında p=REJECT politikanın ne olduğunu, dis=REJECT ise ne uygulandığını gösterir.

Adım 2: Postfix Log Analizi

Kendi Postfix sunucunuzdan gönderilen maillerin reddedilip reddedilmediğini görmek için:

# Son 100 DMARC ile ilgili log satırı
tail -n 5000 /var/log/mail.log | grep -i "dmarc|authentication|reject" | tail -100

# Belirli bir domain için filtreleme
grep "sirket.com" /var/log/mail.log | grep "reject" | awk '{print $1, $2, $3, $NF}' | tail -50

# Bounce mesajlarını bulmak
grep "550 5.7" /var/log/mail.log | tail -30

Adım 3: DMARC Kaydı Doğrulama

DNS kaydınızın doğru yayıldığını ve syntax hatası olmadığını kontrol etmek için:

# DMARC kaydını sorgula
dig TXT _dmarc.sirket.com +short

# Farklı DNS sunucularından kontrol et
dig TXT _dmarc.sirket.com @8.8.8.8 +short
dig TXT _dmarc.sirket.com @1.1.1.1 +short

# DNS yayılımını kontrol et
for ns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
    echo "DNS: $ns"
    dig TXT _dmarc.sirket.com @$ns +short
    echo "---"
done

Adım 4: DKIM İmzasını Kontrol Etme

DKIM imzanızın doğru çalışıp çalışmadığını test etmek için:

# DKIM public key kaydını sorgula
# Selector'ı kendi sisteminize göre değiştirin
dig TXT mail._domainkey.sirket.com +short

# OpenSSL ile DKIM anahtarını doğrula
dig TXT mail._domainkey.sirket.com +short | tr -d '"' | 
    openssl pkey -pubin -inform PEM -noout -text 2>/dev/null || 
    echo "DKIM key formatı kontrol edilmeli"

# Postfix ile DKIM imzalama durumunu kontrol et (OpenDKIM kullanıyorsanız)
systemctl status opendkim
tail -50 /var/log/mail.log | grep -i "dkim"

Gerçek Dünya Senaryoları

Senaryo 1: E-ticaret Sitesi Transactional Mail Sorunu

Bir e-ticaret müşterisinin sipariş onay mailleri müşterilere ulaşmıyordu. Sorun şuydu: Site magaza.com domain’ini kullanıyordu, DMARC politikası p=reject olarak ayarlanmıştı. Ama mail gönderimi için kullanılan PHP uygulaması sunucunun yerel SMTP’sini kullanıyordu ve bu sunucu SPF kaydında yoktu.

Çözüm süreci:

# Önce hangi IP'den mail gönderildiğini tespit et
grep "from=<[email protected]>" /var/log/mail.log | 
    grep "client=" | awk -F'client=' '{print $2}' | 
    awk '{print $1}' | sort | uniq -c | sort -rn | head

# SPF kaydını güncelle
# Mevcut SPF kaydı
dig TXT magaza.com +short | grep spf

# Yeni IP'yi SPF'e ekle ve test et
# "v=spf1 ip4:ESKİ_IP ip4:YENİ_IP include:_spf.google.com ~all"

SPF’e yeni IP eklendikten sonra problem çözüldü. Ama burada kritik nokta şu: ~all (softfail) yerine -all (hardfail) kullanıyorsanız ve DMARC p=reject ise yetkisiz herhangi bir sunucudan gelen mail anında reddedilir.

Senaryo 2: Şirket Birleşmesi Sonrası Mail Kaos

İki şirket birleşti, eski domain eski-sirket.com, yeni domain yeni-sirket.com. Çalışanlar eski domain’den mail atmaya devam etti ama mail sunucusu artık yeni domain altında çalışıyordu. DMARC alignment hatası kaçınılmazdı.

# Postfix'te header_from ile envelope_from farkını görmek
grep "message-id" /var/log/mail.log | tail -20

# Mail queue'daki mailleri incele
mailq | head -30

# Spesifik bir mail'i kuyrukta incele
postcat -q QUEUE_ID | head -50

Bu senaryoda çözüm, eski domain için DMARC politikasını geçici olarak p=none yapıp geçiş sürecini tamamlamak ve ardından yeni domain altında doğru SPF/DKIM/DMARC yapılandırmasını oluşturmaktı.

Senaryo 3: Newsletter Sistemi Entegrasyonu

Şirketin [email protected] adresiyle Mailchimp üzerinden newsletter gönderimi yapılıyordu. DMARC p=reject olduğu için Mailchimp üzerinden giden mailler reddediliyordu çünkü Mailchimp’in sunucuları SPF’te yoktu ve DKIM imzası Mailchimp’in kendi domain’i üzerinden atılıyordu.

# Mailchimp'in SPF include'unu ekle
# SPF kaydına: include:servers.mcsv.net eklenecek

# Mevcut SPF kaydını kontrol et
dig TXT sirket.com +short | grep spf

# DKIM için Mailchimp'e custom domain DKIM ayarlaması gerekiyor
# Mailchimp panel'inden aldığınız CNAME kayıtlarını ekle:
dig CNAME k1._domainkey.sirket.com +short
# Bu kayıt Mailchimp'in DKIM sunucusuna point etmeli

DMARC Raporlarını Okumak

DMARC’ın en değerli özelliklerinden biri raporlama sistemidir. rua adresine gelen aggregate raporlar XML formatındadır ve oldukça bilgi yüklüdür.

# Gelen DMARC raporunu açıp okumak için
# Raporlar genellikle .gz veya .zip içinde gelir
gunzip dmarc_report.xml.gz

# XML'i okunabilir formata çevirmek için xmllint
xmllint --format dmarc_report.xml | head -100

# Basit bir bash ile raporu parse etmek
grep -o '<source_ip>[^<]*</source_ip>' dmarc_report.xml | 
    sed 's/<[^>]*>//g' | sort | uniq -c | sort -rn

Raporlarda dikkat etmeniz gereken alanlar:

  • source_ip: Mailin gönderildiği IP adresi
  • count: Bu IP’den gelen mail sayısı
  • disposition: Politika gereği ne yapıldı (none/quarantine/reject)
  • dkim result: DKIM kontrolünün sonucu
  • spf result: SPF kontrolünün sonucu

Eğer raporlarda tanımadığınız IP’lerden dkim=pass ve spf=pass görüyorsanız domain’iniz adına yetkisiz mail gönderimi yapılıyor olabilir. Bu durumda DMARC’ınız sizi phishing saldırılarından koruyor demektir.

DMARC Politikası Geçiş Stratejisi

Mevcut çalışan bir mail sistemini DMARC’a geçirirken kademeli ilerlemeniz şart. Direkt p=reject ile başlamak felaket olabilir.

# Aşama 1: Sadece izleme modu
# DNS kaydı: "v=DMARC1; p=none; rua=mailto:[email protected]"

# Aşama 2: Karantina modu (2-4 hafta sonra)
# DNS kaydı: "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"

# Aşama 3: pct'yi artır
# DNS kaydı: "v=DMARC1; p=quarantine; pct=75; rua=mailto:[email protected]"

# Aşama 4: Tam reject
# DNS kaydı: "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]"

# Her aşamada raporları analiz et
# Python ile basit analiz scripti
python3 << 'EOF'
import xml.etree.ElementTree as ET
import sys

tree = ET.parse('dmarc_report.xml')
root = tree.getroot()

for record in root.findall('.//record'):
    source_ip = record.find('.//source_ip').text
    count = record.find('.//count').text
    disposition = record.find('.//disposition').text
    dkim = record.find('.//dkim').text
    spf = record.find('.//spf').text
    print(f"IP: {source_ip}, Count: {count}, Disp: {disposition}, DKIM: {dkim}, SPF: {spf}")
EOF

OpenDMARC ile Kendi Sunucunuzda DMARC Uygulama

Alıcı taraftaysanız ve gelen maillere DMARC kontrolü uygulamak istiyorsanız OpenDMARC kullanabilirsiniz:

# OpenDMARC kurulumu (Debian/Ubuntu)
apt-get install opendmarc

# Yapılandırma
cat /etc/opendmarc.conf | grep -v "^#" | grep -v "^$"

# Servis durumu
systemctl status opendmarc

# Postfix ile entegrasyon için main.cf
postconf -e 'smtpd_milters = inet:127.0.0.1:8893,inet:127.0.0.1:8891'
postconf -e 'non_smtpd_milters = inet:127.0.0.1:8893,inet:127.0.0.1:8891'
postconf -e 'milter_default_action = accept'

# Log'ları takip et
tail -f /var/log/mail.log | grep -i "opendmarc|dmarc"

Sık Karşılaşılan Hatalar ve Çözümleri

“dmarc=fail (p=REJECT)”: En net red mesajıdır. SPF ve DKIM’in ikisi de başarısız ya da alignment sorunu var. Önce SPF’i, sonra DKIM’i tek tek test edin.

“550 5.7.26 This message does not have authentication information”: Google’ın verdiği bu hata, gönderici domain’de hiç SPF ya da DKIM olmadığında görülür. Mutlaka her ikisini de ayarlayın.

“dmarc=bestguesspass”: DMARC kaydı olmayan domain’ler için bazı sistemlerin verdiği sonuçtur. DMARC kaydınız varsa bu mesajı görmemelisiniz.

“permerror”: SPF’te birden fazla TXT kaydı ya da syntax hatası var. DNS kayıtlarınızı gözden geçirin.

# Hızlı sorun tespiti için tek satır komut
echo "SPF: $(dig TXT sirket.com +short | grep spf)"
echo "DKIM: $(dig TXT mail._domainkey.sirket.com +short | head -c 100)"
echo "DMARC: $(dig TXT _dmarc.sirket.com +short)"

Sonuç

DMARC sorunları çoğu zaman karmaşık görünse de sistematik yaklaşıldığında çözümü genellikle basittir. Temel kural şu: Önce SPF’i düzeltin, sonra DKIM’i, en son DMARC politikasını sıkılaştırın. p=none ile başlayın, raporları okuyun, her şeyi anladıktan sonra p=quarantine ve nihayetinde p=reject‘e geçin.

Üçüncü parti mail servisleri kullanıyorsanız her birinin SPF include’unu eklemeyi ve custom DKIM desteği sunup sunmadığını kontrol etmeyi unutmayın. Mail forwarding kullanan kullanıcılarınız varsa onları ARC (Authenticated Received Chain) destekleyen sistemlere yönlendirin.

DMARC raporlarını düzenli takip etmek, hem güvenlik açıklarını erkenden fark etmenizi hem de meşru mail akışlarınızda sorun çıkmadan önce önlem almanızı sağlar. Bu yüzden rua adresini mutlaka aktif bir posta kutusuna yönlendirin ve haftalık olarak raporları gözden geçirin. Mail güvenliği set-and-forget bir konu değil, yaşayan ve büyüyen bir sistemdir.

Benzer Konular

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir