E-posta nasıl çalışır
E-postanız alıcıya doğrudan gitmez: önce sizin posta sunucunuza teslim edilir, o sunucu alıcı alan adının posta sunucusunun yerini DNS'e sorar ve mesajı oraya teslim eder. Alıcı sunucu aynı anda üç karardan birini verir, kabul ya da spam ya da ret; ve bu kararda en çok ağırlığı SPF, DKIM ve DMARC kayıtları taşır.
- Ders 9 / 12
- Orta
- Ücretsiz, kayıt yok
Gönder tuşuyla gelen kutusu arasındaki beş durak
Bu yolun hiçbir yerinde cihazınız alıcının cihazına doğrudan bağlanmaz.
-
1
Yazarsınız ve gönder'e basarsınız
Web postası ya da telefon uygulaması, fark etmez
-
2
Kendi posta sunucunuza teslim
SMTP ile. Buradan sonrası sizin elinizde değil.
-
3
DNS'e sorma: alıcının posta sunucusu nerede
MX kaydı. Posta kabul etmeyen bir alan adı bunu tam burada bildirir.
-
4
O sunucuya bağlanma ve mesajı teslim etme
Yanıt vermezse mesaj kuyruğa girer ve sonra yeniden denenir
-
5
Alıcı sunucu karar verir
Gelen kutusu, spam klasörü ya da anında ret
Bu yol, iki bağımsız alan adı arasındaki bir mesaj içindir. Gönderen ve alıcı aynı hizmetteyse ikinci, üçüncü ve dördüncü duraklar o hizmetin içinde gerçekleşir ve mesaj internete hiç çıkmaz.
Son kontrol: Bu dersteki bilgiler ve araç adları bu tarihte kaynaklarıyla yeniden doğrulanır.
Gönder tuşuna bastığınızda mesaj nerelerden geçer?
Beş durak ve hiçbiri sizinle alıcı arasında doğrudan bir bağlantı değil. Önce yazdığınız program, ister web postası ister telefondaki bir uygulama olsun, mesajı kendi posta sunucunuza teslim eder. Bu teslim SMTP adlı bir protokolle olur ve aynı protokol sonra sunucular arasında da kullanılır; postayı okumak ise başka bir iştir ve IMAP ya da POP ile yapılır, çoğu kişi bu ikisini karıştırır.
İkinci durak en ilgincidir. Gönderen sunucu example.ir postalarının nereye teslim edileceğini bilmez, bu yüzden DNS'e sorar ve MX adlı bir kaydı okur. O kayıt alan adının posta sunucusunu adlandırır. Bizimki şunu taşıyor: 10 mail.rgb.ir, yani rgb.ir postası bu addaki bir makineye teslim edilir.
Hiç posta kabul etmeyen bir alan adı ise bunu açıkça söyler. example.com boş bir MX kaydı yayımlıyor, RFC 7505'in null MX adını verdiği şey, ve anlamı denemeyin demektir. Kendi sunucu kaydımız tam olarak bunu gösteriyor: o alan adındaki bir adrese giden bir mesaj, hiçbir bağlantı denenmeden anında geri döndü, gerekçe Domain example.com does not accept mail (nullMX).
Üçüncü ve dördüncü duraklar o sunucuya bağlanmak ve mesajı teslim etmektir. Beşincisi alıcı sunucunun kararıdır ve bu dersin geri kalanı o tek karar üzerinedir.
Spama düşmekle hiç ulaşmamak arasındaki fark nedir?
Bu ikisi tek bir olay değil ve tek bir çaresi de yok. Spama düşen bir mesaj kabul edilmiştir; alıcı sunucu onu almış, sonra nereye koyacağına karar vermiştir. Reddedilen bir mesaj ise hiç kabul edilmemiştir ve size nedenini söyleyen bir geri dönüş gelir. Çoğu kişinin bilmediği üçüncü bir durum daha var: mesaj bir kuyrukta bekler ve gönderen sunucu birkaç dakikada bir yeniden dener.
Kendi sunucu kaydımız dört durumun hepsini birkaç saat içinde gösteriyor. Kabul şöyle görünür: status=sent (250 2.0.0 OK). Kuyruk şöyle: status=deferred ve şu mesaj 452-4.2.2 The recipient's inbox is out of storage space; bu, bizim bir mesajımız için iki günden biraz fazla tekrarlandı. Ret şöyle: status=bounced. Hiç yola çıkmamak ise önceki bölümdeki null MX durumudur.
Şimdi en önemli satır. Gmail bu sunucunun bir mesajını şu yanıtla reddetti: 550-5.7.26 Your email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Sonra sonucu yazdı: DKIM = did not pass ve SPF [] with ip: [65.109.218.65] = did not pass.
Aynı birkaç dakika içinde, aynı sunucudan ve aynı IP'den sıradan mesajlar 250 2.0.0 OK ile kabul edildi. Yani ne sunucu ne de IP sorundu. O tek mesaj bir geri dönüş bildirimiydi ve zarf göndericisi boştu, kayıtta görünen from=<>; zarf bir ad taşımadığında SPF'in denetleyecek bir şeyi kalmaz ve DKIM imzası da yoksa mesaj Gmail açısından kimliksizdir. Kimlik doğrulama meselesi tam da burada başlar.
SPF, DKIM ve DMARC tam olarak ne yapar?
Üçü de alan adınızın DNS'indeki metin kayıtlarıdır ve üçü de tek bir soruyu üç açıdan yanıtlar: bu mesaj gerçekten bu alan adından mı?
SPF, alan adınız adına göndermesine izin verilen sunucuların listesidir. Bizimki şöyle: v=spf1 +mx +a ~all, yani alan adının posta sunucusu ile sitenin kendi sunucusu izinlidir, geri kalan her şey şüphelidir. Sondaki ~all kesin ret değil orta ayardır; daha katısı -all'dur ve onu bilerek seçmedik, çünkü gönderen bir hizmeti unutmak gerçek postanın reddedilmesi için yeter.
DKIM, gönderen sunucunun mesajın kendisine koyduğu bir imzadır. Özel anahtar sunucuda kalır, açık anahtar ise seçici denen bir adın altında DNS'te yayımlanır. Bizimki default._domainkey.rgb.ir altında duruyor ve özel anahtarı bu makinede; yayımlanan anahtarın diskteki anahtarla bire bir aynı olduğunu az önce doğruladık. Bir sınırı açıkça söyleyelim: anahtarımız 1024 bit ve RFC 8301 bunu taban sayıp 2048'i öneriyor. Yani daha iyisini yapacak yer var.
DMARC kendi başına hiçbir şeyi denetlemez. Diğer ikisi başarısız olduğunda alıcı sunucunun ne yapacağını ve raporları nereye göndereceğini söyler. Bizimki v=DMARC1;p=quarantine;rua=mailto:admin@rgb.ir, yani şüpheli mesajı karantinaya al ve raporu gönder.
Genelde söylenmeyen incelik: SPF zarfın üzerindeki adrese, DKIM ise mektubun üzerindeki imzaya bakar ve bu ikisi farklı olabilir. DMARC'ın eklediği şey, bunlardan birinin kullanıcının gördüğü gönderen adıyla aynı aileden olmasını istemesidir. Kendi alan adından gönderirken sizin adınızı gösteren bülten hizmetleri, doğru ayarlanmadıkları sürece DMARC altında bu yüzden reddedilir.
Alıcı sunucunun kararını biçimlendiren üç kayıt
Üçüncü sütun hiçbir şeyi denetlemez; yalnızca ilk ikisi başarısız olunca ne yapılacağını söyler.
-
SPF
Bu alan adı adına hangi sunucular gönderebilir. Zarfın üzerindeki adresi denetler.
-
DKIM
Mesajın kendisi üzerinde bir imza; DNS'te yayımlanan açık anahtarla doğrulanır.
-
DMARC
Yukarıdaki ikisi başarısız olunca ne yapılacağı ve raporun nereye gönderileceği. Bizimki karantinaya ayarlı.
Üçü birden bile gelen kutusunun garantisi değildir. Gönderen IP'nin itibarı ve mesajın metni de etkilidir ve hiçbir DNS kaydı bunları düzeltmez.
Bu üçünden hangisi sizde var? Nasıl kontrol edilir
Üç DNS sorgusu ilk ikisini yanıtlar, üçüncüsü başka bir şey gerektirir. SPF için alan adının kendi metin kayıtlarını, DMARC için _dmarc alt alan adının metin kaydını okuyun:
dig +short example.ir TXT
dig +short _dmarc.example.ir TXTDKIM ise körlemesine sorulamaz, çünkü seçici adını bilmeniz gerekir ve her posta hizmetinin kendi seçicisi vardır. Onu posta hizmetinizin panelinden alın ve sonra dig +short SELECTOR._domainkey.example.ir TXT çalıştırın. Komutlarla uğraşmak istemiyorsanız ücretsiz DNS kaydı ve e-posta sağlığı aracımız bu üçünü tek yerde gösterir ve seçiciyi bilmeden DKIM'i denetlemediğini dürüstçe söyler.
Ama bunların hiçbiri postanızın pratikte kabul edildiğini kanıtlamaz. Tek gerçek kanıt alıcının hükmüdür. Erişebildiğiniz bir adrese bir mesaj gönderin ve o hizmette ham başlıkları gösteren seçeneği arayın; Gmail'de adı Show original. Authentication-Results adlı satırı bulun ve üçünün yanında ne yazdığını okuyun.
Burada yaygın bir hatayı da yakalayalım: sonucu aynı alan adındaki bir adrese göndererek test etmeyin. Bir sunucu kendisinden gelen mesaja yabancı muamelesi yapmaz ve sonuç sizi yanıltır.
Neden "gönderildi" durumu hiçbir şeyi kanıtlamaz?
Bir iletişim formu ya da bir eklenti e-posta gönderildi dediğinde, mesajı yerel posta sunucusuna teslim ettiğini kastediyordur. Bu yolun başıdır, sonu değil. WordPress'te wp_mail() fonksiyonunun true döndürmesi tam olarak bunu söyler, fazlasını değil; bunu kendi sitelerimizde yeterince gördük ve posta sunucusu kaydını okumadan teslimat hakkında bir şey söylememek burada sabit bir kural oldu.
Gerçek yanıtın yazıldığı yer posta sunucusunun kaydıdır ve orada her mesajın status= ile biten bir satırı vardır; alıcı sunucunun yanıtını kelimesi kelimesine aktarır. İki bakış arasındaki fark bu sunucunun kendi sayılarında görünüyor: mevcut kaydın kapsadığı aralıkta 44 mesaj status=sent, 24 mesaj status=bounced aldı. O 24'ün bir kısmı için mesajı gönderen program postanın gönderildiğini söylemişti.
E-posta sizin için önemliyse tek bir alışkanlık yeter: posta ayarlarınızda herhangi bir değişiklikten sonra gerçek bir mesaj gönderin ve kayda bakın. Sunucu kaydına erişiminiz yoksa barındırıcınızdan o mesaja ait satırı göndermesini isteyin. Bir kayıt satırı, on saatlik tahminden değerlidir.
Bir "gönderildi" iletisinin altında ne var
Çizginin üstünde programın size gösterdiği şey var. Altında ise gerçekten mümkün olan dört akıbet.
Gönderildi
Mesajın yerel posta sunucusuna teslim edildiği anlamına gelir. Alıcı hakkında hiçbir şey söylemez.
-
Kabul edildi
Alıcı sunucu 250 yanıtı verdi. Kayıtta: status=sent
-
Kuyrukta kaldı
Geçici bir yanıt. Yeniden denenir; mesajlarımızdan biri iki gün kuyrukta kaldı.
-
Anında reddedildi
Kalıcı bir yanıt ve bir geri dönüş. Kayıtta: status=bounced
-
Hiç gönderilmedi
Alıcı alan adı posta kabul etmediğini bildirmiş. Hiçbir bağlantı kurulmaz.
İlk durum bile mesajın hangi klasöre düştüğünü söylemez. Kabul edildi demek, alıcı sunucunun onu aldığı demektir; alıcının gördüğü değil.
Yapay zekayla hızlı yol
Spama düşen postayla başa çıkmanın alışılmış yolu, hazır bir SPF kaydı arayıp birini kopyalamaktır. Hızlı yol ise önce kanıtı toplamak, sonra dil modelini yalnızca o kanıtı kendi mevcut kayıtlarınızla karşılaştırmaya zorlamaktır. Fark şu: ikincisi üç denetimden hangisinin başarısız olduğunu söyler ve alan adınıza yarının sorunu olacak ikinci bir kayıt eklemezsiniz.
- Kanıtı alın. Ya geri dönüş mesajının tam metnini ya da kendi alan adınızın dışındaki bir adrese gönderdiğiniz mesajdaki <code>Authentication-Results</code> satırını. Bu ikisinden biri olmadan gerisi tahmindir.
- Kendi mevcut kayıtlarınızı alın: <code>dig +short DOMAIN TXT</code> ve <code>dig +short _dmarc.DOMAIN TXT</code> komutlarının ham çıktısı. DKIM seçicinizi biliyorsanız onu da alın.
- İkisini birlikte üst sınıf bir modele verin, toplu iş için değil yargı için kullandığınız sınıfa, ve yalnızca teşhis etmesini isteyin, kayıt yazmasını değil.
- Her seferinde tek bir kaydı değiştirin ve yeniden gerçek bir mesaj gönderin. DNS önbelleğe alır ve iki şeyi birden değiştirirseniz hangisinin işe yaradığını asla bilemezsiniz.
Kopyalamaya hazır şablon
Rolün bir e-posta teslim edilebilirlik uzmanı. Yalnızca aşağıdaki verilere göre karar ver ve bellekten hiçbir kayıt ekleme.
Alan adım: {alan adı}
Posta gönderdiğim hizmet: {örneğin barındırma sunucusu ya da bir hizmet adı}
dig +short {alan adı} TXT ham çıktısı:
{ham çıktı}
dig +short _dmarc.{alan adı} TXT ham çıktısı:
{ham çıktı}
Alıcı tarafından kanıt (geri dönüş metni ya da Authentication-Results satırı):
{ham metin}
Dört şey yaz:
1. Üç denetimden hangisi başarısız oldu: SPF, DKIM ya da DMARC hizalaması. Yalnızca yukarıdaki kanıta dayanarak ve metnin hangi kısmının bunu gösterdiğini söyle.
2. Olası neden, tek cümlede.
3. Tam olarak hangi kaydın değişmesi gerektiği ve onda neyin değişeceği. Nihai kayıt metnini yazma; yalnızca neyin eksik ya da fazla olduğunu söyle.
4. Veriler teşhis için yetmiyorsa başka neyin gerektiğini yaz.
Kurallar: Verilerde bir DKIM seçicisi görmüyorsan DKIM'im yok deme; denetlenemez diye yaz. SPF kaydının içindeki DNS sorgularını say ve onu geçiyorsa bunu söyle. Hazır hiçbir kayıt önerme.Çıktıya güvenmeden önce: İki şey yapıştırılmamalı: ham mesajın tamamı ve modelin kendi yazdığı herhangi bir kayıt. Ham mesaj alıcı adreslerini ve bazen tek kullanımlık parola sıfırlama bağlantılarını taşır; yalnızca <code>Authentication-Results</code> satırını ve geri dönüş metnini alın. Uydurma kayda gelince: bir SPF kusursuz görünüp yine de çalışmayabilir, çünkü RFC 7208 tek bir kaydın değerlendirilmesi için on DNS sorgusu tavanı koyar ve bunun ötesinde sonuç kalıcı başarısızlıktır. Bu hata kayıt metninde iz bırakmaz; yalnızca bir SPF doğrulayıcıyla ya da elle sayarak görünür.
Bu işte yapay zeka
E-posta, bir dil modelinin size gerçekten zaman kazandırdığı az sayıdaki konudan biri, çünkü asıl iş ham metin ve sayısal kodları okumak ve model bunda iyi. Ama sınır net: teşhisi ona bırakın, kaydın yazılmasını değil. DNS'teki yanlış bir kayıt, bir sohbetteki yanlış yanıtın aksine, alan adınızda saatlerce durur ve size gerçek posta kaybettirir.
Gerçekten işe yarayan araçlar
- Claude Ham bir geri dönüşü ve başlık satırlarını okumak için bu listedeki en iyi seçim, çünkü uzun ve yapısız metni dikkatle takip eder. İran, Anthropic'in desteklenen ülkeler listesinde değil; resmî bir kayıt ya da ödeme yolu yok.
- Gemini Teslim edilebilirlik jargonunu Farsçaya çevirmek ve sayısal bir kodu açıklamak için iyidir. Google'ın kendi sayfası Gemini uygulamasının 230'dan fazla ülke ve bölgede çalıştığını yazıyor; İran o listede yok.
- Gemini Notebook Buradaki tam kullanımı: kendi barındırıcınızın e-posta belgelerini yükleyin ve DKIM seçicisini ve ayarın tam adını modelin belleğinden değil, o belgenin içinden sorun. Bir Google hesabıyla çalışır ve İran erişilebilir bölgeler arasında değil.
Nerede geri teper
Bu konudaki asıl riskin belirgin bir biçimi var ve nadiren söylenir: model, tümüyle doğru görünen ve çalışmayan bir kayıt yazar. Bir SPF metni kusursuz olup yine de başarısız olabilir, çünkü RFC 7208 bir kaydın değerlendirilmesi için on DNS sorgusu tavanı koyar ve bu tavanı aşmak sonucu kalıcı bir başarısızlığa çevirir; göz bunu göremez. İkinci risk DMARC: raporları izleyip neyin başarısız olduğunu görmeden en baştan p=reject koymayı öneren bir model, yarın gerçek postanızı kesebilir. Anthropic bu kendinden emin uydurmayı kendi belgelerinde halüsinasyon diye adlandırıp azaltmayı yazıyor, yani üretici de bunu gerçek bir zayıflık sayıyor. Veriye gelince: Google'ın Gemini yardım sayfası gizli bilgi girmemeyi açıkça söylüyor ve ham bir mesaj tam olarak budur. Bu araçların İran'dan ödemesinin nasıl göründüğü için satın alma rehberine bakın.
Kaynaklar: RFC 7208: Sender Policy Framework, the DNS lookup limit Anthropic: reduce hallucinations Anthropic: supported countries Google: Gemini Apps privacy and data Google: where Gemini Apps are available
Bu tavsiyenin sınırı
Bu ders, kendi alan adınızdan kendi sunucunuz ya da barındırıcınız üzerinden çıkan posta üzerinedir. Postanız Google Workspace ya da Microsoft 365 gibi kurumsal bir hizmetteyse aynı üç kayıt gereklidir ama o hizmetin paneli çoğunu kendisi kurar ve DKIM seçicisi onlarındır, dolayısıyla pratik yol farklıdır. Daha önemlisi, kimlik doğrulama giriş biletidir, gelen kutusunun garantisi değil: bu üçünden sonra gönderen IP'nin itibarı ve mesajın metni karar verir ve hiçbir DNS kaydı bunları düzeltmez. İki şey bilerek dışarıda bırakıldı, çünkü başlamak için gerekli değiller ve kendi derslerini hak ediyorlar: BIMI ve ARC.
Kendi işimizden
Bu dersteki her sayı ve kayıt satırı, 7 Eylül 2026'da kendi posta sunucumuzdan alındı. Bedelini ödeyerek öğrendiğimiz üç şey. Birincisi: aynı birkaç dakika içinde, tek bir sunucudan ve tek bir IP'den, sıradan mesajlar 250 2.0.0 OK ile kabul edilirken bir geri dönüş bildirimi 550-5.7.26 ... the sender is unauthenticated ile reddedildi; tek fark, geri dönüş bildiriminin zarfının boş olması ve SPF'in denetleyecek bir şeyinin bulunmamasıydı. İkincisi: posta hizmetimiz bilerek yalnızca IPv4'e ayarlı (inet_protocols = ipv4), çünkü bu makinenin ters kaydı olmayan genel bir IPv6 adresi var ve birçok alıcı böyle bir adresten gelen postayı kabul etmiyor. Şimdi yeniden baktık: bu sunucunun IPv6 adresinin hâlâ hiçbir ters kaydı yok. Üçüncüsü: default._domainkey.rgb.ir adresinde yayımlanan DKIM anahtarını diskteki özel anahtarla karşılaştırdık ve bayt bayt aynıydılar; aynı karşılaştırma anahtarın 1024 bit olduğunu, yani RFC 8301'in tabanında olup önerdiği değerde olmadığını gösterdi.
Gerçek devam soruları
Sitemin e-postaları spama düşüyor. Önce ne yapmalıyım?
Farklı bir hizmette sahip olduğunuz bir adrese mesaj gönderin ve Authentication-Results satırını okuyun. SPF ya da DKIM orada başarısızsa iş oradadır, başka yerde değil. İkisi de geçtiği hâlde hâlâ spam işaretleniyorsa mesele gönderen itibarı ya da mesajın metnidir ve çözümün DNS ile ilgisi yoktur.
Mesajım neden birine ulaşıyor da diğerine ulaşmıyor?
Çünkü karar alıcı sunucuya aittir ve her hizmet kendi katılığını belirler. Gmail, Outlook ve küçük bir şirket sunucusu üç farklı politikaya sahiptir; birinin kabul ettiği mesajı diğeri karantinaya alır. Bu yüzden tek bir adrese karşı test etmek asla yetmez; en az iki farklı hizmeti deneyin.
Bir alan adının iki SPF kaydı olabilir mi?
Hayır ve bu gördüğümüz en sık hata. Bir alan adının tam olarak bir SPF kaydı olur; iki tane yayımlamak sonucu hataya çevirir ki bu hiç kaydı olmamakla aynıdır. Yeni bir gönderim hizmeti eklerken onu mevcut tek kaydın içine koyun, yeni bir kayda değil.