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:
[email protected]
İ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:
[email protected]
için şu sorular sorulur:
- Format doğru mu?
example.comdomain'i var mı?- Domain'in MX kayıtları var mı?
- Mail sunucusuna bağlantı kurulabiliyor mu?
usermailbox'ı 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:
[email protected]
makul bir e-posta adresidir. Ama şunlar değildir:
burakexample.com
burak@
@example.com
burak [email protected]
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:
[email protected]
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:
[email protected]
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.comadresine gönderilecek e-postalarımail.example.comsunucusu 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:<[email protected]>
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:<[email protected]>
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:
[email protected]
[email protected]
[email protected]
[email protected]
ş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:
[email protected]
var olabilir. Ama:
[email protected]
diye bir mailbox olmayabilir. Catch-all aktif değilse sunucu muhtemelen:
550 User unknown
döndürür. Ama catch-all açıksa:
[email protected]
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:
[email protected]
olsun. Aynı domain üzerinde rastgele bir adres oluşturabiliriz:
[email protected]
SMTP sunucusu buna da:
250 OK
dönüyorsa domain'in catch-all olma ihtimali oldukça yüksektir. Akış:
[email protected]
↓
250 OK
[email protected]
↓
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:
[email protected]
görünüyor.
Ama gerçekten example.com mu gönderdi?
Yoksa birisi kendi mail sunucusundan:
From: [email protected]
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:<[email protected]>
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: [email protected]
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:[email protected];
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:
[email protected]
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:
[email protected]
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:
[email protected]
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": "[email protected]",
"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": "[email protected]",
"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ı:
[email protected]
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.