--- title: E-posta Doğrulaması Nasıl Yapılır? SPF, DKIM ve DMARC Akışı description: Bir e-posta adresinin gerçekten kullanılabilir olup olmadığını anlamak, yalnızca adresin içinde @ işareti bulunup bulunmadığını kontrol etmekten çok daha fazlasını gerektiriyor. DNS ve MX kayıtlarından SMTP seviyesindeki kontrole kadar uzanan email verification süreci ile SPF, DKIM ve DMARC gibi email authentication mekanizmaları çoğu zaman birbirine karıştırılıyor. Bu yazıda ikisinin farkını netleştirip, bir e-posta adresi doğrulanırken ve bir e-posta alıcı sunucuya ulaştığında arka planda neler olduğunu adım adım inceleyeceğim. Sonunda SPF, DKIM ve DMARC'ın neden birlikte kullanıldığını da daha rahat görebileceğiz. author: Burak Kaşıkcı date: 2026-09-30 updated: 2026-09-30 tags: - email - spf - dkim - dmarc - smtp - dns - güvenlik - backend canonical: https://burakkasikci.com/blog/e-posta-dogrulamasi-nasil-yapilir-spf-dkim-ve-dmarc-akisi slug: e-posta-dogrulamasi-nasil-yapilir-spf-dkim-ve-dmarc-akisi --- # E-posta Doğrulaması Nasıl Yapılır? SPF, DKIM ve DMARC Akışı Bir süredir e-posta doğrulama tarafıyla daha yakından uğraşıyorum. Konunun içine girdikçe fark ettiğim şey şu oldu: dışarıdan bakınca oldukça basit görünen bir işlem, birkaç farklı katmandan oluşuyor. Elimizde şöyle bir adres olduğunu düşünelim: ``` burak@example.com ``` İlk bakışta sorumuz basit: > Bu e-posta adresi gerçekten var mı? Ama teknik olarak bunun tek bir cevabı yok. Önce adresin formatı doğru mu diye bakıyoruz. Sonra domain gerçekten var mı? Mail alabiliyor mu? MX kaydı var mı? SMTP sunucusuna ulaşabiliyor muyuz? Sunucu bize bu mailbox'ın varlığıyla ilgili bir ipucu veriyor mu? Bir de işin başka bir tarafı var: > Bu adresten gelen e-postayı gönderen sunucu gerçekten bu domain adına mail göndermeye yetkili mi? İşte SPF, DKIM ve DMARC burada devreye giriyor. Yani önce önemli bir ayrımı yapalım. ## Email Verification ile Email Authentication Aynı Şey Değil Bu iki kavram sık sık birbirine karışıyor. **Email Verification**, bir e-posta adresinin kullanılabilir olup olmadığını anlamaya çalışır. Örneğin: ``` user@example.com ``` için şu sorular sorulur: * Format doğru mu? * `example.com` domain'i var mı? * Domain'in MX kayıtları var mı? * Mail sunucusuna bağlantı kurulabiliyor mu? * `user` mailbox'ı gerçekten var mı? * Domain catch-all mı? * Adres geçici/disposable bir servis mi? **Email Authentication** ise gelen bir e-postanın gerçekten iddia ettiği domain tarafından gönderilip gönderilmediğini anlamaya çalışır. Burada da devreye: ``` SPF DKIM DMARC ``` giriyor. İkisi aynı problemin farklı tarafları. Şimdi önce bir e-posta adresinin doğrulanma sürecine bakalım. *** # 1\. Adım: Syntax Kontrolü İlk kontrol en basit olanı. E-posta adresi teknik olarak geçerli bir formatta mı? Örneğin: ``` burak@example.com ``` makul bir e-posta adresidir. Ama şunlar değildir: ``` burakexample.com burak@ @example.com burak example@example.com ``` Burada çoğu projede Regex kullanıldığını görüyorum. Mesela: ``` var emailRegex = new Regex( @"^[^@\s]+@[^@\s]+\.[^@\s]+$", RegexOptions.Compiled | RegexOptions.IgnoreCase); ``` Ama burada küçük bir uyarı var. RFC'lere tam anlamıyla uyumlu bir e-posta Regex'i yazmaya çalışmak genellikle gereksiz derecede karmaşık hale geliyor. Ben pratikte syntax kontrolünü ilk filtre olarak görüyorum. Çünkü: ``` syntax valid ``` olması şu anlama gelmez: ``` email exists ``` Sadece adresin yapısal olarak mantıklı olduğunu gösterir. *** # 2\. Adım: Domain Gerçekten Var mı? Adresimiz: ``` burak@example.com ``` olsun. Buradaki domain: ``` example.com ``` İkinci aşamada DNS üzerinden domain'in gerçekten var olup olmadığını kontrol edebiliriz. Örneğin: ``` nslookup example.com ``` veya: ``` dig example.com ``` ile DNS sorgusu yapılabilir. Domain hiç çözümlenemiyorsa zaten doğrulamaya devam etmenin çok anlamı yoktur. Örneğin: ``` burak@bu-domain-kesinlikle-yok-123456.com ``` adresinin syntax'ı tamamen doğru olabilir. Ama domain yoksa email de çalışmayacaktır. *** # 3\. Adım: MX Kaydı Kontrolü Şimdi biraz daha kritik bir noktaya geldik. Bir domain'in var olması, o domain'in e-posta aldığı anlamına gelmez. Mail sunucularının nerede olduğunu DNS üzerindeki **MX kayıtları** söyler. MX: ``` Mail Exchange ``` anlamına gelir. Örneğin: ``` dig MX gmail.com ``` gibi bir sorgu yaptığımızda Gmail'in mail sunucularını görebiliriz. Basitleştirirsek şöyle bir kayıt düşünelim: ``` example.com MX 10 mail.example.com ``` Bu şu anlama gelir: > `example.com` adresine gönderilecek e-postaları `mail.example.com` sunucusu kabul ediyor. Birden fazla MX kaydı da olabilir. ``` MX 10 mail1.example.com MX 20 mail2.example.com ``` Buradaki sayı priority değeridir. Daha düşük değer genellikle daha yüksek önceliğe sahiptir. Yani önce: ``` mail1.example.com ``` denenir. Ulaşılamazsa: ``` mail2.example.com ``` kullanılabilir. *** # 4\. Adım: SMTP Sunucusuna Bağlanmak MX kaydını bulduk. Şimdi işin eğlenceli kısmı başlıyor. SMTP sunucusuna bağlanabiliriz. SMTP'nin açılımı: ``` Simple Mail Transfer Protocol ``` Sunucular arasında e-posta taşınmasını sağlayan temel protokoldür. Genellikle SMTP bağlantısı için port: ``` 25 ``` kullanılır. Örneğin teorik olarak: ``` telnet mail.example.com 25 ``` ile bağlantı kurulabilir. Sunucu bize şöyle bir cevap verebilir: ``` 220 mail.example.com ESMTP ``` Bu aslında: > Buradayım, konuşabiliriz. demektir. SMTP iletişimi oldukça ilginçtir çünkü aslında komut-cevap mantığında ilerler. *** # 5\. Adım: SMTP Handshake SMTP sunucusuna bağlandıktan sonra genellikle ilk komutlardan biri: ``` EHLO smtpseer.com ``` olur. Sunucu cevap verir: ``` 250-mail.example.com 250-SIZE 52428800 250-STARTTLS 250 SMTPUTF8 ``` Buradaki `250`, kabaca: ``` OK ``` anlamına gelir. Artık SMTP sunucusuyla iletişim kurabiliyoruz. *** # 6\. Adım: MAIL FROM Sonra kendimizi gönderen olarak tanıtırız. Örneğin: ``` MAIL FROM: ``` Sunucu: ``` 250 OK ``` diyebilir. Burada henüz gerçekten e-posta göndermiyoruz. Sadece SMTP transaction başlatıyoruz. *** # 7\. Adım: RCPT TO Asıl kritik nokta burası. Kontrol etmek istediğimiz adresi gönderiyoruz: ``` RCPT TO: ``` Mail sunucusu farklı cevaplar verebilir. Örneğin: ``` 250 OK ``` Bu oldukça olumlu bir sinyaldir. Sunucu kabaca şunu söylüyor: > Bu recipient için mail kabul edebilirim. Ama buradaki önemli detay şu: Bu cevap yine de yüzde 100: ``` Mailbox kesin vardır. ``` anlamına gelmez. Çünkü bazı mail sunucuları güvenlik nedeniyle olmayan adreslere bile `250` dönebilir. *** # SMTP Response Kodları Ne Anlama Geliyor? Örneğin: ``` 250 2.1.5 OK ``` genellikle adresin kabul edildiğini gösterir. Ama: ``` 550 5.1.1 User unknown ``` çok daha nettir. Bu genellikle: ``` Mailbox bulunamadı. ``` anlamına gelir. Başka bir örnek: ``` 450 4.2.0 Mailbox temporarily unavailable ``` Bu ise geçici bir problem olabilir. Burada çok önemli bir ayrım var. SMTP response kodlarında genel olarak: ``` 2xx → başarılı 4xx → geçici hata 5xx → kalıcı hata ``` mantığını görebiliriz. Dolayısıyla email verification sisteminde: ``` 450 ``` ile: ``` 550 ``` aynı şekilde değerlendirilmemelidir. *** # 8\. Adım: DATA Göndermeden Bağlantıyı Kapatmak Email verification yapıyorsak gerçekten email göndermek istemeyiz. Dolayısıyla: ``` RCPT TO ``` sonrasında işlemi bitirebiliriz. Örneğin: ``` RSET QUIT ``` kullanılır. Akış kabaca şöyle olur: ``` CONNECT ↓ EHLO ↓ MAIL FROM ↓ RCPT TO ↓ Result ↓ QUIT ``` Burada: ``` DATA ``` komutuna geçmeyiz. Çünkü `DATA` sonrasında artık gerçekten mail içeriği gönderme aşamasına geçmiş oluruz. *** # Peki Gmail Gibi Servislerde Bu Çalışıyor mu? İşte pratikte email verification sistemlerinin zorlandığı nokta burada başlıyor. Büyük e-posta sağlayıcıları mailbox enumeration yapılmasını istemez. Yani kötü niyetli bir sistemin: ``` ahmet@gmail.com mehmet@gmail.com ali@gmail.com ayse@gmail.com ``` şeklinde milyonlarca adresi deneyip: > Hangileri gerçekten var? diye öğrenmesini engellemeye çalışırlar. Bu nedenle bazı sistemler SMTP seviyesinde gerçek mailbox bilgisini doğrudan paylaşmaz. Sonuç olarak profesyonel bir email verification servisi tek bir kontrolden karar vermez. Birden fazla sinyali birlikte değerlendirir. *** # Catch-All Domain Nedir? Email verification tarafında en kafa karıştırıcı konulardan biri de catch-all sistemidir. Bir domain düşünelim: ``` example.com ``` Normalde: ``` burak@example.com ``` var olabilir. Ama: ``` asdfgh123456@example.com ``` diye bir mailbox olmayabilir. Catch-all aktif değilse sunucu muhtemelen: ``` 550 User unknown ``` döndürür. Ama catch-all açıksa: ``` asdfgh123456@example.com ``` için bile: ``` 250 OK ``` dönebilir. Çünkü domain şunu söylüyordur: > Bana gelen bütün adresleri kabul et. Bu durumda email verification servisi kullanıcının gerçekten var olduğunu kesin olarak anlayamaz. Sonuç genellikle şöyle sınıflandırılır: ``` Catch-All ``` veya: ``` Accept-All ``` *** # Catch-All Nasıl Tespit Edilir? Basit ama etkili yöntemlerden biri random mailbox testidir. Örneğin doğruladığımız adres: ``` burak@example.com ``` olsun. Aynı domain üzerinde rastgele bir adres oluşturabiliriz: ``` this-user-probably-does-not-exist-928371@example.com ``` SMTP sunucusu buna da: ``` 250 OK ``` dönüyorsa domain'in catch-all olma ihtimali oldukça yüksektir. Akış: ``` burak@example.com ↓ 250 OK random-928371@example.com ↓ 250 OK ↓ Possible Catch-All ``` Tabii burada da tek bir test üzerinden yüzde yüz kesin hüküm vermemek gerekir. *** # Disposable Email Kontrolü Bir diğer kontrol de temporary veya disposable email adresleridir. Örneğin bazı servisler birkaç dakika kullanılabilen geçici mailbox'lar oluşturur. Bunlar teknik olarak tamamen geçerli olabilir. ``` MX var SMTP çalışıyor Mailbox var ``` Ama bir SaaS uygulaması açısından değerleri düşük olabilir. Özellikle: * ücretsiz trial * kampanya * üyelik * kupon * finansal servisler gibi sistemlerde disposable email kontrolü faydalı olabilir. Burada genellikle bilinen disposable domain listeleri tutulur. Örneğin: ``` example-tempmail.com another-temp-mail.net ``` gibi. *** # Email Verification İçin Tam Akış Bütün parçaları bir araya getirirsek mantıklı bir email validation pipeline şu şekilde olabilir: ``` Email ↓ Syntax Check ↓ Domain Check ↓ MX Lookup ↓ Disposable Domain Check ↓ SMTP Connection ↓ EHLO ↓ MAIL FROM ↓ RCPT TO ↓ Catch-All Test ↓ Risk Analysis ↓ Result ``` Sonuçları da sadece: ``` Valid Invalid ``` olarak tutmak bana çok sınırlayıcı geliyor. Daha mantıklı sınıflandırma: ``` Valid Invalid Risky Catch-All Disposable Unknown TemporaryFailure ``` şeklinde olabilir. Çünkü email verification dünyasında her zaman kesin bir cevap alamıyoruz. *** # Şimdi Gelelim SPF, DKIM ve DMARC'a Buraya kadar anlattığımız şey: ``` Email Verification ``` idi. Şimdi başka bir probleme geçiyoruz. Bir mail geldi. Gönderen: ``` billing@example.com ``` görünüyor. Ama gerçekten `example.com` mu gönderdi? Yoksa birisi kendi mail sunucusundan: ``` From: billing@example.com ``` yazarak bize sahte mail mi gönderdi? İşte burada email authentication devreye giriyor. *** # SPF Nedir? SPF: ``` Sender Policy Framework ``` anlamına gelir. Temel olarak domain sahibinin DNS üzerinden şunu söylemesini sağlar: > Benim adıma hangi sunucular mail gönderebilir? Örneğin: ``` example.com ``` Google Workspace kullanıyor olsun. DNS'e şöyle bir SPF kaydı eklenebilir: ``` v=spf1 include:_spf.google.com ~all ``` Bu bir TXT kaydıdır. Örneğin: ``` example.com TXT "v=spf1 include:_spf.google.com ~all" ``` Burada: ``` v=spf1 ``` SPF versiyonudur. ``` include:_spf.google.com ``` Google'ın tanımladığı mail sunucularına izin verir. ``` ~all ``` ise diğer kaynakların SPF açısından yetkili kabul edilmediğini belirtir. *** # SPF Nasıl Kontrol Edilir? Bir mail sunucusu bize bağlandığında gönderen IP'nin: ``` 203.0.113.10 ``` olduğunu düşünelim. Mail şunu söylüyor: ``` MAIL FROM: ``` Alıcı sunucu DNS'e sorar: ``` example.com SPF kaydı nedir? ``` DNS: ``` v=spf1 ip4:203.0.113.10 -all ``` döndürüyorsa gönderen IP izinlidir. Sonuç: ``` SPF PASS ``` Ama mail: ``` 198.51.100.20 ``` adresinden geldiyse: ``` SPF FAIL ``` olabilir. Akış: ``` Incoming Mail ↓ Sender IP ↓ MAIL FROM Domain ↓ DNS SPF Lookup ↓ IP allowed? / \ Yes No ↓ ↓ PASS FAIL ``` *** # SPF Kaydındaki all Değerleri SPF tarafında sık gördüğümüz birkaç ifade vardır. ``` -all ``` Fail. Yani: > Bunların dışında gönderene izin vermiyorum. ``` ~all ``` SoftFail. Kabaca: > Bunların dışındaki kaynaklardan gelen mail şüpheli. ``` ?all ``` Neutral. ``` +all ``` herkese izin verir. Pratikte: ``` +all ``` neredeyse SPF kullanmamak gibi düşünülebilir ve çoğu senaryoda tercih edilmez. *** # SPF ile İlgili Önemli Bir Detay SPF, kullanıcının mail uygulamasında gördüğü: ``` From: ``` adresini doğrudan doğrulamaz. Kontrol genellikle SMTP envelope sender, yani: ``` MAIL FROM ``` domain'i üzerinden yapılır. Bu fark DMARC tarafında tekrar karşımıza çıkacak. *** # DKIM Nedir? DKIM: ``` DomainKeys Identified Mail ``` anlamına gelir. SPF: > Bu IP benim adıma mail gönderebilir. derken DKIM farklı bir şey söyler: > Bu mail gerçekten ilgili domain'in özel anahtarıyla imzalanmış. Yani burada public/private key mantığı vardır. Mail gönderilirken mail sunucusu mesajı private key ile imzalar. Public key ise DNS'te yayınlanır. *** # DKIM Nasıl Çalışır? Örneğin domain: ``` example.com ``` olsun. DKIM selector: ``` selector1 ``` olsun. DNS kaydı genellikle şu adreste bulunur: ``` selector1._domainkey.example.com ``` TXT kaydı şöyle görünebilir: ``` v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA... ``` Buradaki: ``` p= ``` bölümünde public key vardır. Gönderilen mail'in header'ında ise şöyle bir alan görebiliriz: ``` DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=abc123...; b=xyz456... ``` Buradaki önemli alanlardan ikisi: ``` d=example.com ``` ve: ``` s=selector1 ``` alanlarıdır. Alıcı mail sunucusu buradan DNS adresini oluşturur: ``` selector1._domainkey.example.com ``` Sonra public key'i alır. Mail üzerindeki imzayı doğrular. İmza geçerliyse: ``` DKIM PASS ``` sonucu çıkar. *** # DKIM Neyi Sağlıyor? DKIM'in iki önemli faydası var. Birincisi: Gönderen domain'in mesajı imzaladığını doğrular. İkincisi: Mesajın imzalanan bölümlerinin yolda değiştirilip değiştirilmediğini anlamaya yardımcı olur. Örneğin mail: ``` Ödemeniz 100 TL'dir. ``` şeklinde gönderildiyse ve yolda bir sistem bunu: ``` Ödemeniz 100.000 TL'dir. ``` şeklinde değiştirirse DKIM doğrulaması bozulabilir. Elbette hangi header ve body bölümlerinin imzalandığı DKIM yapılandırmasına bağlıdır. *** # SPF ve DKIM Arasındaki Temel Fark Bence en kolay şöyle akılda kalıyor: ``` SPF "Bu sunucu bu domain adına mail gönderebilir mi?" ``` DKIM: ``` "Bu mesaj domain tarafından kriptografik olarak imzalanmış mı?" ``` Birisi kaynak sunucuya bakar. Diğeri mesaja. *** # DMARC Nedir? Şimdi puzzle'ın son önemli parçasına geldik. DMARC: ``` Domain-based Message Authentication, Reporting and Conformance ``` SPF ve DKIM sonuçlarını kullanır ama üzerine çok önemli bir kavram ekler: ``` Alignment ``` Yani mail'in kullanıcının gördüğü `From` domain'i ile SPF veya DKIM tarafından doğrulanan domain'in uyumlu olması beklenir. *** # Neden DMARC'a İhtiyaç Var? Şöyle bir mail düşünelim. Kullanıcı mail uygulamasında şunu görüyor: ``` From: banka.com ``` Ama SMTP envelope sender: ``` attacker-server.com ``` olsun. SPF şu domain için başarılı olabilir: ``` attacker-server.com ``` Ama kullanıcının gördüğü domain: ``` banka.com ``` Bu durumda SPF teknik olarak PASS olsa bile bizim açımızdan ciddi bir problem var. DMARC tam burada devreye giriyor. *** # DMARC Alignment Nedir? DMARC şuna bakar: Mail'in görünen adresi: ``` From: billing@example.com ``` olsun. SPF tarafından doğrulanan domain: ``` example.com ``` ise SPF alignment başarılı olabilir. DKIM imzasındaki domain: ``` d=example.com ``` ise DKIM alignment da başarılı olabilir. DMARC için genel mantık: ``` SPF Pass + SPF Alignment ``` veya: ``` DKIM Pass + DKIM Alignment ``` şartlarından en az birinin sağlanmasıdır. Basitleştirirsek: ``` DMARC PASS = Aligned SPF PASS OR Aligned DKIM PASS ``` İkisinin birden başarılı olması şart değildir. *** # DMARC DNS Kaydı Nasıl Görünür? DMARC kaydı: ``` _dmarc.example.com ``` adresinde bulunur. Örneğin: ``` v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ``` Buradaki: ``` v=DMARC1 ``` DMARC versiyonudur. ``` p=reject ``` DMARC başarısız olan mailler için uygulanacak policy'dir. ``` rua= ``` ise aggregate raporların gönderileceği adresi belirtir. *** # DMARC Policy Değerleri En çok kullanılan üç policy vardır. ## p=none ``` v=DMARC1; p=none; ``` Maili engelleme. Sadece gözlemle. Genellikle DMARC kurulumu yapılırken ilk aşamada kullanılır. *** ## p=quarantine ``` v=DMARC1; p=quarantine; ``` Şüpheli maillerin spam veya junk klasörüne gönderilmesini önerir. *** ## p=reject ``` v=DMARC1; p=reject; ``` DMARC kontrolünü geçemeyen mail'in reddedilmesini ister. Bu genellikle en sıkı politikadır. *** # DMARC'ı Doğrudan reject ile Açmak Mantıklı mı? Her zaman değil. Örneğin şirketinizde: * Google Workspace * Mailchimp * SendGrid * CRM * fatura sistemi * ticket sistemi * monitoring sistemi aynı domain adına mail gönderiyor olabilir. SPF ve DKIM yapılandırmalarının tamamı doğru değilse doğrudan: ``` p=reject ``` kullanmak geçerli e-postaların da reddedilmesine neden olabilir. Bu yüzden çoğu durumda geçiş şöyle yapılır: ``` p=none ``` önce raporlar gözlemlenir. Sonra: ``` p=quarantine ``` ardından: ``` p=reject ``` değerlendirilebilir. *** # SPF + DKIM + DMARC Birlikte Nasıl Çalışıyor? Şimdi tamamını tek bir mail üzerinden düşünelim. Diyelim ki: ``` billing@example.com ``` adresinden bize mail geldi. SMTP bağlantısını yapan IP: ``` 203.0.113.10 ``` olsun. *** ## SPF Kontrolü Alıcı sunucu DNS'e bakar: ``` example.com TXT ``` SPF: ``` v=spf1 ip4:203.0.113.10 -all ``` Gönderen IP listede. Sonuç: ``` SPF PASS ``` *** ## DKIM Kontrolü Mail header'ında: ``` d=example.com s=selector1 ``` bulunuyor. DNS sorgusu: ``` selector1._domainkey.example.com ``` Public key bulunuyor. Signature doğrulanıyor. Sonuç: ``` DKIM PASS ``` *** ## DMARC Kontrolü From: ``` billing@example.com ``` SPF domain: ``` example.com ``` DKIM domain: ``` example.com ``` Alignment başarılı. Sonuç: ``` DMARC PASS ``` Mail authentication açısından her şey güzel görünüyor. *** # Authentication-Results Header Bir mail'in header'ına baktığınızda bazen şöyle satırlar görebilirsiniz: ``` Authentication-Results: spf=pass dkim=pass dmarc=pass ``` Bir hata varsa: ``` spf=fail dkim=fail dmarc=fail ``` gibi sonuçlarla karşılaşabilirsiniz. E-posta problemlerini debug ederken ilk baktığım alanlardan biri burası olur. Çünkü tek tek DNS kayıtlarına bakmadan önce bize oldukça iyi bir ipucu verir. *** # Peki Bunlar Email Verification Sisteminde Kullanılır mı? Evet, ama farklı bir amaçla. Bir email verification platformu aşağıdakileri kontrol edebilir: ``` MX SPF DKIM DMARC ``` Ama burada dikkat etmek gerekiyor. SPF, DKIM veya DMARC'ın olmaması: ``` email adresi yoktur ``` anlamına gelmez. Örneğin: ``` user@example.com ``` gerçekten var olabilir. Domain'in MX kaydı vardır. SMTP server mailbox'ı kabul eder. Ama domain sahibi DMARC tanımlamamış olabilir. Dolayısıyla sonuç: ``` Email Valid ``` olabilir. Ama: ``` Domain Security: Weak ``` gibi ayrı bir değerlendirme yapılabilir. Bence verification platformlarında bu iki sonucu birbirinden ayırmak önemli. *** # Örnek Bir Verification Sonucu Mesela bir API şöyle bir sonuç dönebilir: ``` { "email": "user@example.com", "status": "valid", "syntaxValid": true, "domainExists": true, "mxFound": true, "smtpReachable": true, "mailboxExists": true, "catchAll": false, "disposable": false, "spf": true, "dkim": true, "dmarc": true } ``` Ama ben biraz daha detaylı bir model tercih ederdim. Örneğin: ``` { "email": "user@example.com", "verification": { "status": "valid", "confidence": 96 }, "mailbox": { "syntax": "valid", "domain": "valid", "mx": "valid", "smtp": "valid", "catchAll": false, "disposable": false }, "authentication": { "spf": "configured", "dkim": "configured", "dmarc": "configured" } } ``` Çünkü mailbox doğrulaması ile domain security aynı şey değil. *** # Email Verification Neden Hiçbir Zaman Yüzde 100 Değil? Burada önemli bir gerçek var. Dışarıdan yapılan SMTP doğrulaması her zaman kesin sonuç üretmez. Mail sunucuları: * recipient doğrulamasını kapatabilir, * catch-all kullanabilir, * greylisting uygulayabilir, * IP reputation kontrolü yapabilir, * rate limit uygulayabilir, * SMTP bağlantısını geçici olarak reddedebilir, * bot veya verification servislerini engelleyebilir. Örneğin: ``` 421 Try again later ``` cevabı aldığınızda mailbox'ın var olmadığı sonucuna varamazsınız. Bu nedenle iyi bir verification sistemi: ``` true / false ``` yerine risk bazlı yaklaşmalıdır. Örneğin: ``` Valid Invalid Unknown Risky Catch-All Temporary Failure ``` çok daha sağlıklı bir modeldir. *** # SPF, DKIM ve DMARC Email'in Spam'e Düşmesini Engeller mi? Tek başlarına hayır. Bu da sık yapılan bir yanlış anlaşılma. SPF: ``` pass ``` DKIM: ``` pass ``` DMARC: ``` pass ``` olduğu halde mail yine spam'e düşebilir. Çünkü mail provider'ları başka birçok sinyale bakar. Örneğin: * IP reputation * domain reputation * bounce rate * spam complaint oranı * kullanıcı etkileşimi * gönderim hacmi * gönderim düzeni * içerik * URL reputation * unsubscribe davranışı gibi. Yani SPF, DKIM ve DMARC: ``` deliverability ``` için önemli altyapı parçalarıdır ama tek başlarına garanti değildir. *** # Baştan Sona Email Akışı Son olarak bütün sistemi tek akışta düşünelim. Bir kullanıcı: ``` user@example.com ``` adresine mail gönderiyor. ## Gönderim tarafı Gönderen mail server mesajı oluşturur. DKIM private key ile mesajı imzalar. ``` DKIM-Signature ``` header'a eklenir. Sonra DNS üzerinden MX kaydı bulunur. ``` example.com ↓ DNS ↓ MX ↓ mail.example.com ``` Gönderen SMTP server alıcı SMTP server'a bağlanır. *** ## Alıcı tarafı Alıcı sunucu bağlantıyı yapan IP'yi görür. İlk olarak SPF kontrolü yapılabilir. ``` Sender IP ↓ SPF DNS ↓ PASS / FAIL ``` Sonra DKIM kontrol edilir. ``` DKIM Signature ↓ Selector ↓ DNS Public Key ↓ Signature Validation ↓ PASS / FAIL ``` Sonra DMARC devreye girer. ``` From Domain ↓ SPF Alignment + DKIM Alignment ↓ DMARC Policy ``` Sonuçta mail: ``` Inbox Spam Quarantine Reject ``` gibi farklı sonuçlarla karşılaşabilir. *** # Kısaca Akılda Kalması İçin Ben bu üçlüyü şöyle düşünüyorum: ``` SPF Bu IP benim adıma mail gönderebilir mi? ``` ``` DKIM Bu mail gerçekten benim anahtarımla imzalanmış mı? ``` ``` DMARC Kullanıcının gördüğü gönderen domain'i ile doğrulanan domain gerçekten uyumlu mu ve başarısız olursa ne yapmalıyız? ``` Email verification ise başka bir soru soruyor: ``` Bu mailbox gerçekten kullanılabilir mi? ``` Bu ayrımı yaptıktan sonra konu bence çok daha anlaşılır hale geliyor. *** # Sonuç E-posta doğrulaması ilk bakışta basit bir `Regex` kontrolü gibi görünse de arka planda DNS, MX ve SMTP gibi birden fazla katman bulunuyor. Üstelik catch-all, greylisting ve provider güvenlik politikaları nedeniyle her adres için kesin bir `valid/invalid` sonucu üretmek mümkün olmayabiliyor. SPF, DKIM ve DMARC ise email verification'ın değil, email authentication tarafının parçaları. SPF gönderen sunucuyu, DKIM mesajın kriptografik imzasını, DMARC ise görünen gönderen domain'i ile bu doğrulamaların uyumunu kontrol ediyor. Sağlıklı bir e-posta altyapısında bence bu iki tarafı ayrı değerlendirmek gerekiyor: önce mailbox'ın gerçekten kullanılabilir olup olmadığını anlamaya çalışmak, ardından domain'in e-posta güvenlik yapılandırmasını analiz etmek. İkisini bir araya getirdiğimizde ise elimizde yalnızca “bu e-posta geçerli mi?” sorusuna cevap veren bir sistem değil; aynı zamanda domain'in mail altyapısının ne kadar sağlıklı olduğunu da gösterebilen çok daha kapsamlı bir doğrulama mekanizması oluşuyor.