E-posta Nasıl Çalışır: Protokoller, Adımlar ve Mimariye İlişkin Eksiksiz Teknik Kılavuz

E-posta, işletmeler ve bireyler için dijital iletişimin omurgası olmaya devam etmektedir; ancak altta yatan mekanizmaları kullanıcıların büyük çoğunluğu tarafından yeterince anlaşılamamaktadır. Özünde, e-posta teslimi — iletim için SMTP, yönlendirme için DNS MX kayıtları ve alma için IMAP veya POP3 — her biri bir gönderenin istemcisinden alıcının gelen kutusuna saniyeler içinde mesaj taşımak için sırayla çalışan kesin bir protokol zinciri tarafından yönetilen çok aşamalı bir aktarma sürecidir.

Bu mimariyi anlamak yalnızca akademik bir mesele değildir. Sistem yöneticileri, geliştiriciler ve bir posta ortamını yöneten herkes, teslimat hatalarını teşhis etmek, güvenlik duruşunu güçlendirmek, sunucuları doğru yapılandırmak ve spam klasöründen kaçınmak için bu bileşenlerin nasıl etkileşime girdiğini kavramalıdır. Bu kılavuz, giriş düzeyindeki makalelerin sürekli olarak atladığı uç durumlar ve hata modları dahil olmak üzere eksiksiz teknik tabloyu kapsamaktadır.

E-posta Altyapısının Temel Bileşenleri

Tek bir e-postanın yaşam döngüsünü izlemeden önce, dahil olan ayrı sistemleri belirlemek önemlidir. Her biri vazgeçilmez bir rol oynar ve herhangi birindeki yanlış yapılandırma teslimatı sessizce bozabilir.

E-posta İstemcisi (MUA — Mail User Agent)

Mail User Agent (MUA), kullanıcının e-posta oluşturduğu, gönderdiği ve okuduğu arayüzdür. Örnekler arasında Microsoft Outlook, Apple Mail, Mozilla Thunderbird ve Gmail’in web arayüzü gibi tarayıcı tabanlı istemciler yer almaktadır. MUA, e-postayı doğrudan alıcıya iletmez. Görevi, mesajı genellikle kimlik doğrulamayla port 587’de çalışan bir Mail Submission Agent’a (MSA) teslim etmektir; bu da mesajı giden SMTP sunucusuna iletir.

Yaygın bir mimari yanlış anlama, MUA ile SMTP sunucusunu tek bir birim olarak ele almaktır. Bunlar ayrı bileşenlerdir. MUA bir istemcidir; SMTP altyapısı ise taşıma katmanıdır.

Posta Sunucusu (MTA — Mail Transfer Agent)

Mail Transfer Agent (MTA), sistemler arasında e-posta aktarımından sorumlu sunucu yazılımıdır. Postfix, Exim, Sendmail ve Microsoft Exchange en yaygın kullanılan MTA’lardır. Bir MTA, işlemin yönüne bağlı olarak hem gönderici hem de alıcı olarak işlev görebilir. DNS aramalarını gerçekleştiren, uzak sunuculara SMTP bağlantıları kuran ve teslimat başarısız olduğunda yeniden deneme için mesajları kuyruğa alan MTA’dır.

Mail Delivery Agent (MDA)

Basitleştirilmiş açıklamalarda sıklıkla göz ardı edilen Mail Delivery Agent (MDA), alıcı MTA tarafından kabul edilen bir mesajı alarak diskteki doğru kullanıcının posta kutusuna yerleştiren bileşendir. Dovecot ve Courier yaygın MDA’lardır. MDA, posta kutusu kotalarını uygular, sunucu taraflı filtreleme kurallarını (Sieve betikleri) uygular ve mesajı uygun depolama biçimine (Maildir veya mbox) yazar.

DNS ve MX Kayıtları

Domain Name System, e-postanın yönlendirme omurgasıdır. Geçerli bir MX (Mail Exchange) kaydı olmadan, hiçbir harici sunucu belirli bir alan adı için postanın nereye teslim edileceğini bulamaz. MX kayıtları bir öncelik değeri taşır — düşük sayılar daha yüksek önceliği gösterir — bu da yöneticilerin birincil ve yedek posta sunucularını yapılandırmasına olanak tanır. Gönderen MTA, MX kayıtlarını sorgular, ardından bir bağlantı başlatmadan önce elde edilen ana bilgisayar adını bir A veya AAAA kaydı aracılığıyla bir IP adresine çözer.

E-posta Teslim Süreci: Adım Adım

Adım 1: Mesaj Oluşturma ve Gönderme

Kullanıcı, MUA’sında alıcı adresini, konu satırını, gövde içeriğini ve ekleri belirterek bir mesaj yazar. Ekler ve HTML içeriği, ikili verileri metin tabanlı SMTP üzerinden iletim için güvenli bir base64 kodlu biçimde saran MIME (Multipurpose Internet Mail Extensions) kullanılarak kodlanır. Örneğin, PDF eki olan bir mesaj birden fazla MIME parçasına bölünür: biri metin gövdesi için, diğeri kodlanmış ikili dosya için.

Kullanıcı “Gönder”e tıkladığında, MUA giden posta sunucusuna — genellikle port 587 (STARTTLS) veya port 465 (SMTPS) üzerinden — kimliği doğrulanmış, şifreli bir bağlantı açar. SASL (Simple Authentication and Security Layer) aracılığıyla kimlik doğrulama, yetkisiz aktarım kötüye kullanımını önler.

Adım 2: SMTP El Sıkışması ve Mesaj Transferi

Gönderen MTA, resmi bir el sıkışmasıyla bir SMTP oturumu başlatır:

1. İstemci, kendisini ana bilgisayar adıyla tanımlayarak `EHLO` (Extended HELO) gönderir.
2. Sunucu, yetenekleriyle yanıt verir (örn. STARTTLS, AUTH, SIZE sınırları).
3. İstemci, zarf göndericiyi bildirmek için `MAIL FROM:<sender@domain.com>` komutunu verir.
4. İstemci, alıcıyı bildirmek için `RCPT TO:<recipient@domain.com>` komutunu verir.
5. İstemci, tam mesaj başlıkları ve gövdesiyle birlikte `DATA` gönderir.
6. Oturum `QUIT` ile kapanır.

Bu SMTP diyaloğu, bağlantının bir istemci ile gönderim sunucusu arasında veya internet üzerinden posta aktaran iki MTA arasında olmasından bağımsız olarak aynıdır.

Adım 3: DNS Çözümlemesi ve MX Araması

Gönderen MTA, alıcının sunucusuna bağlanmadan önce hedefi çözümlemek zorundadır. Süreç katı bir sırayı izler:

1. Alıcının alan adı için DNS’de MX kayıtları sorgulanır (örn. `example.com`).
2. Her biri bir ana bilgisayar adı ve öncelik değeri içeren bir veya daha fazla MX kaydı alınır.
3. MX ana bilgisayar adı, bir A kaydı (IPv4) veya AAAA kaydı (IPv6) aracılığıyla bir IP adresine çözümlenir.
4. Önce en yüksek öncelikli (en düşük numaralı) MX ana bilgisayarına bağlantı denenir.

Kritik uç durum: Bir alan adı için MX kaydı yoksa, RFC 5321 gönderen MTA’nın alan adının A kaydına geri dönmesi ve teslimatı doğrudan denemesi gerektiğini belirtir. Bu davranış, yanlış yapılandırılmış alan adlarında sıklıkla istismar edilir ve beklenmedik teslimat yollarına yol açabilir. Ayrıca, MX kaydı bir CNAME’e işaret ediyorsa, bu RFC 2181’i ihlal eder ve katı MTA’larda teslimat hatalarına neden olabilir.

Adım 4: Sunucudan Sunucuya SMTP Aktarımı

IP adresi çözümlendikten sonra, gönderen MTA alıcının MTA’sına port 25 üzerinden bir TCP bağlantısı kurar. Port 25, sunucudan sunucuya iletişim için ayrılmıştır ve tüketici IP aralıklarından kaynaklanan spam’i önlemek amacıyla ISP’ler tarafından konut bağlantıları için genellikle engellenir.

Kurumsal ve bulut ortamlarında, e-posta hedefe ulaşmadan önce birden fazla aktarım atlaması geçirebilir. Her aktarım, mesaja izlenebilir bir denetim izi oluşturan bir `Received:` başlığı ekler. Bu başlıkları incelemek, teslimat gecikmelerini teşhis etmek ve bir mesajın nerede bekletildiğini veya reddedildiğini belirlemek için birincil yöntemdir.

STARTTLS fırsatçı şifreleme, her iki sunucu da destekliyorsa bu aşamada müzakere edilir. Alıcı sunucu STARTTLS’i tanıtmıyorsa, çoğu MTA teslimatı başarısız kılmak yerine şifresiz iletişime geri döner — bu, MTA-STS (Mail Transfer Agent Strict Transport Security)‘nin şifreli bağlantıları zorunlu kılarak çözmeye tasarlandığı bilinen bir güvenlik açığıdır.

Adım 5: Kabul, Filtreleme ve Spam Değerlendirmesi

Alıcı MTA mesajı kabul ettiğinde, onu hemen kullanıcının gelen kutusuna yerleştirmez. Bir dizi kontrol gerçekleşir:

• SPF (Sender Policy Framework): Alıcı sunucu, yetkili gönderme IP adreslerini listeleyen bir TXT kaydı için gönderenin alan adı DNS’ini sorgular. Gönderen IP listede yoksa, SPF kontrolü başarısız olur.
• DKIM (DomainKeys Identified Mail): Gönderen sunucu, mesaj başlıklarını ve gövdesini özel bir anahtarla kriptografik olarak imzalar. Alıcı sunucu, ilgili genel anahtarı DNS’den alır ve imzayı doğrular. Geçerli bir DKIM imzası, mesajın iletim sırasında değiştirilmediğini kanıtlar.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): SPF ve DKIM’i bir araya getirir. Alan adı sahibi, kimlik doğrulamasında başarısız olan mesajlarla ne yapılacağını belirten bir DMARC politikası yayınlar — `none` (yalnızca izle), `quarantine` (spam’e gönder) veya `reject` (mesajı sil). DMARC ayrıca toplu ve adli raporlamayı etkinleştirir.

Kimlik doğrulama kontrollerinin ardından mesaj, içerik filtreleme ve spam puanlama motorlarından geçer (SpamAssassin, Rspamd veya özel sistemler). Puanlar, başlık anormalliklerine, kara liste aramalarına (RBL’ler/DNSBL’ler), içerik kalıplarına ve gönderen itibarına göre atanır. Eşiği aşan mesajlar gereksiz posta klasörüne yönlendirilir veya tamamen reddedilir.

Adım 6: Posta Kutusu Depolama ve Alma

Tüm filtrelerden geçen mesajlar MDA’ya iletilir ve MDA bunları kullanıcının posta kutusuna yazar. İki baskın depolama biçimi şunlardır:

• Maildir: Her mesaj bir dizin yapısında ayrı bir dosya olarak depolanır. Dayanıklılığı nedeniyle tercih edilir — bozuk bir mesaj diğerlerini etkilemez.
• mbox: Bir klasördeki tüm mesajlar tek bir dosyada birleştirilir. Daha basittir ancak eş zamanlı erişimde bozulma ve kilitleme sorunlarına eğilimlidir.

Alıcının e-posta istemcisi daha sonra mesajı IMAP veya POP3 kullanarak alır.

Adım 7: IMAP veya POP3 Aracılığıyla İstemci Alma

Teslimatın son aşaması, istemcinin mesajı posta kutusu sunucusundan çekmesidir. Protokol seçiminin önemli operasyonel etkileri vardır.

IMAP – POP3 – SMTP: Protokol Karşılaştırması

IMAP, neredeyse tüm modern dağıtımlar için doğru seçimdir. Mesajları sunucuda tutar, okundu/okunmadı durumunu, klasör yapısını ve bayrakları bağlı her cihazda gerçek zamanlı olarak senkronize eder. Telefonda bir mesajı silmek, masaüstü istemcisine anında yansır.

POP3, mesajları yerel cihaza indirir ve varsayılan olarak bunları sunucudan kaldırır. Bu, tek cihaz erişimi ve sınırlı sunucu depolama alanı döneminde mantıklıydı, ancak çoklu cihaz ortamlarında ciddi sorunlar yaratır ve sunucu taraflı yedeklemeyi ortadan kaldırır. POP3, yeni dağıtımlar için eski bir protokol olarak değerlendirilmelidir.

E-posta Güvenlik Mimarisi: SPF, DKIM ve DMARC Derinlemesine

Bu üç mekanizma katmanlı bir kimlik doğrulama yığını oluşturur. Yalnızca bir veya ikisini dağıtmak, istismar edilebilir boşluklar bırakır.

SPF — Zarf Düzeyinde Yetkilendirme

SPF, kullanıcılara görünen `From:` başlığını değil, SMTP diyaloğunda kullanılan zarf göndericiyi (`MAIL FROM` adresi) doğrular. Tipik bir SPF kaydı şöyle görünür:

“`

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

“`

`~all` softfail, listelenmemiş IP’lerden gelen mesajların kabul edilmesine ancak işaretlenmesine izin verir. `-all` hardfail, alıcı sunuculara bunları tamamen reddetmelerini bildirir. SPF tek başına, kullanıcıların gerçekte gördüğü görünür `From:` başlığını korumaz — bu nedenle DMARC gereklidir.

DKIM — Kriptografik Mesaj Bütünlüğü

DKIM, tanımlanmış bir başlık kümesini (genellikle `From`, `To`, `Subject`, `Date`) ve mesaj gövdesinin bir karmasını imzalar. İmza, bir `DKIM-Signature:` başlığına gömülür. Bu başlıktaki seçici ve alan adı, genel anahtarı içeren bir DNS TXT kaydına işaret eder. Mesaj imzalandıktan sonra değiştirilirse — gövdede tek bir karakter bile olsa — imza doğrulaması başarısız olur.

Önemli operasyonel not: Posta listesi yazılımı ve bazı yönlendirme yapılandırmaları mesaj içeriğini değiştirir (alt bilgi ekleme, başlıkları yeniden yazma), bu da DKIM imzalarını bozar. Bu, dikkatli yapılandırma gerektiren DKIM ile posta listesi yöneticileri arasında bilinen bir etkileşimdir.

DMARC — Politika Uygulama ve Hizalama

DMARC, tanımlayıcı hizalama kavramını tanıtır: `From:` başlığındaki alan adı, SPF tarafından doğrulanan alan adıyla veya DKIM imzalama alan adıyla hizalanmalıdır. Bu, SPF’nin tek başına açık bıraktığı boşluğu kapatır. `reject` politikası en güçlü yapılandırmadır:

“`

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s

“`

`adkim=s` ve `aspf=s`, organizasyonel alan adı eşleşmesi yerine tam alan adı eşleşmesi gerektiren katı hizalamayı zorunlu kılar.

Gelişmiş Konular: MTA-STS, DANE ve ARC

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS, bir alan adının HTTPS aracılığıyla gelen bağlantıların TLS kullanması gerektiğini ve hangi sertifikaların kabul edilebilir olduğunu belirten bir politika yayınlamasına olanak tanır. Fırsatçı olan ve ortadaki adam saldırganı tarafından kaldırılabilen STARTTLS’in aksine, MTA-STS şifrelemeyi zorunlu kılar. MTA-STS’yi destekleyen gönderen MTA’lar politikayı önbelleğe alır ve bunu karşılayamayan bir sunucuya teslim etmeyi reddeder.

DANE (DNS-Based Authentication of Named Entities)

DANE, belirli bir TLS sertifikasını veya genel anahtarı bir posta sunucusu ana bilgisayar adına bağlamak için DNSSEC imzalı TLSA kayıtlarını kullanır. Bu, sunucu kimlik doğrulaması için ticari Sertifika Yetkilisi güven modeline olan bağımlılığı ortadan kaldırır. DANE benimsenmesi Avrupa hükümeti ve finans sektörlerinde artmaktadır, ancak hem gönderen hem de alıcı alan adında DNSSEC ön koşulu nedeniyle ana akım dağıtımlarda sınırlı kalmaktadır.

ARC (Authenticated Received Chain)

ARC, DMARC’ı bozan yönlendirme sorununu çözmek için geliştirilmiştir. Bir mesaj bir aracı üzerinden yönlendirildiğinde (posta listesi veya e-posta takma adı gibi), orijinal SPF ve DKIM hizalaması bozulabilir. ARC, kimliği doğrulanmış `Received:` başlıklarının bir zincirini korur; bu, son alıcı sunucunun her atlamadaki kimlik doğrulama durumunu değerlendirmesine ve daha bilinçli bir teslimat kararı vermesine olanak tanır.

Yaygın E-posta Teslimat Hataları ve Teşhis

Mimariyi anlamak, sorun gidermeyi spekülatif olmaktan çıkarıp sistematik hale getirir.

Belirti: E-posta “550 5.7.1 Message rejected” ile geri dönüyor

• Neden: SPF hardfail, DMARC reddi veya IP kara listeye alınması.
• Teşhis: Belirli red nedeni için geri dönüş mesajını kontrol edin. SPF’yi incelemek için `dig TXT yourdomain.com` çalıştırın. Kara liste durumu için MX Toolbox veya benzerini sorgulayın.

Belirti: E-posta spam klasörüne teslim ediliyor

• Neden: SPF softfail, eksik DKIM, düşük gönderen itibarı veya içerik tetikleyicileri.
• Teşhis: Alınan mesajdaki `X-Spam-Status` başlığını inceleyin. DKIM imzalamanın etkin olduğunu doğrulayın. Gönderen IP için PTR (ters DNS) kaydının SMTP EHLO ana bilgisayar adıyla eşleştiğini kontrol edin.

Belirti: E-posta “451 Temporary failure” ile gecikiyor

• Neden: Alıcı sunucu geçici olarak kullanılamıyor veya göndereni hız sınırlamasına tabi tutuyor.
• Teşhis: Gönderen MTA, yeniden deneme zamanlamasına göre otomatik olarak kuyruğa alır ve yeniden dener. Yeniden deneme kuyruğu için MTA günlüklerini kontrol edin. Büyük sağlayıcılardan gelen kalıcı 451 hataları genellikle IP itibar sorunlarını gösterir.

Belirti: Doğru DNS kaydına rağmen DKIM imzası doğrulamada başarısız oluyor

• Neden: Mesaj iletim sırasında değiştirildi (posta listesi alt bilgisi eklendi, aktarım tarafından başlık yeniden yazıldı).
• Teşhis: Ham mesaj kaynağında bir DKIM doğrulama aracı kullanın. DKIM-Signature başlığındaki `h=` etiketinin değiştirilen başlıkları içerip içermediğini kontrol edin.

Barındırılan Ortamlar için E-posta Mimarisi

Kendi posta altyapısını dağıtan işletmeler ve geliştiriciler için barındırma ortamı, teslim edilebilirliği ve güvenliği doğrudan etkiler. Bir VPS Hosting ortamı, paylaşımlı ortamların sağlayamadığı MTA yapılandırması, PTR kayıtları ve IP itibarı üzerinde tam kontrol sağlar. Bir VPS üzerinde Postfix veya Exim çalıştırmak, hız sınırlarının, TLS politikalarının ve kimlik doğrulama mekanizmalarının hassas biçimde ayarlanmasına olanak tanır.

Yüksek hacimli işlemsel e-posta veya komşu kiracılardan tam izolasyon gerektiren kuruluşlar, gönderen IP’nin yalnızca kendilerine atandığı ve diğer müşterilerle paylaşılmadığı Dedicated Servers‘dan yararlanır. Dedicated sunucudaki IP itibarı tamamen operatörün kontrolündedir.

Kendi yönetilen MTA’sına ihtiyaç duymayan küçük işletmeler için Email Hosting, önceden yapılandırılmış SPF, DKIM ve DMARC ile tam yönetilen bir posta ortamı sağlayarak posta sunucusu yazılımını sürdürme operasyonel yükünü ortadan kaldırır.

Webmail ve posta istemcisi bağlantılarının güvenliğini sağlamak için geçerli TLS sertifikaları gereklidir. Kendinden imzalı sertifikalar istemci uyarıları oluşturur ve katı MUA yapılandırmalarında kimlik doğrulama hatalarına neden olabilir. Posta sunucusu ana bilgisayar adlarına (örn. `mail.yourdomain.com`) güvenilir SSL Certificates dağıtmak, herhangi bir üretim posta ortamı için vazgeçilmez bir temeldir.

Alan adı yapılandırması da aynı derecede temeldir. MX kayıtları, SPF TXT kayıtları, DKIM TXT kayıtları ve DMARC TXT kayıtlarının tamamı DNS’de bulunur. Güçlü bir DNS düzenleyicisine sahip bir Domain Registration sağlayıcısı aracılığıyla doğru ve güvenilir DNS yönetimi, doğru posta yönlendirme ve kimlik doğrulama kayıtlarını sürdürmek için gereklidir.

E-posta Başlığı Analizi: Denetim İzini Okuma

Her e-posta, tam yolculuğunu belgeleyen bir başlık kümesi taşır. Bunlar ters kronolojik sırayla eklenir — en üstteki `Received:` başlığı en son atlamadır. Tipik bir başlık zinciri şöyle görünür:

“`

Received: from mail.example.com (mail.example.com [203.0.113.10])

by mx.google.com with ESMTPS id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:32 -0700

Received: from [192.168.1.5] (dynamic-pool.isp.net [98.76.54.32])

by mail.example.com with ESMTPSA id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:29 -0700

“`

Teşhis için temel başlıklar:

• `Return-Path:` — Geri dönüş bildirimleri için kullanılan zarf gönderici adresi. SPF ile hizalanmalıdır.
• `Authentication-Results:` — Alıcı sunucu tarafından eklenir, SPF, DKIM ve DMARC kontrollerinin sonucunu belgeler.
• `X-Originating-IP:` — Genellikle webmail hizmetleri tarafından istemcinin IP adresini kaydetmek için eklenir.
• `Message-ID:` — Kaynak MTA tarafından atanan küresel olarak benzersiz tanımlayıcı. Sunucular arasındaki günlük girişlerini ilişkilendirmek için kullanılır.
• `MIME-Version:` ve `Content-Type:` — Mesaj gövdesinin MIME yapısını tanımlar.

Teknik Karar Matrisi ve Temel Çıkarımlar

Bir posta ortamını yapılandırırken veya denetlerken bu kontrol listesini kullanın:

DNS ve Yönlendirme

• MX kayıtları doğru öncelik değerleriyle yayınlanmış ve CNAME değil, geçerli ana bilgisayar adlarına işaret ediyor
• MX ana bilgisayar adları için A/AAAA kayıtları doğru şekilde çözümleniyor
• Gönderen IP için PTR (ters DNS) kaydı, SMTP EHLO ana bilgisayar adıyla eşleşiyor

Kimlik Doğrulama Yığını

• SPF TXT kaydı `-all` veya `~all` ile yayınlanmış ve tüm meşru gönderme kaynaklarını kapsıyor
• DKIM anahtarları minimum 2048 bit; seçici DNS’de yayınlanmış ve MTA’da imzalama etkin
• DMARC politikası en az `p=quarantine` ile yayınlanmış; toplu raporlama (`rua`) yapılandırılmış
• Yüksek güvenlikli alan adları için DMARC hizalama modu `s` (katı) olarak ayarlanmış

Taşıma Güvenliği

• STARTTLS, tüm gelen ve giden SMTP bağlantılarında etkin
• Katı TLS zorunluluğu gerekiyorsa MTA-STS politikası yayınlanmış
• Posta sunucusu ana bilgisayar adına geçerli, CA imzalı TLS sertifikası yüklenmiş

Alma Yapılandırması

• Tüm çoklu cihaz dağıtımlarında POP3 yerine IMAP kullanılıyor
• Port 993 üzerinden SSL/TLS ile IMAP zorunlu kılınmış; düz metin port 143 devre dışı veya kısıtlanmış
• Sunucu taraflı spam filtreleme (Rspamd veya SpamAssassin) güncel kural kümeleriyle yapılandırılmış

Operasyonel İzleme

• DMARC toplu raporları, yetkisiz gönderenleri tespit etmek için düzenli olarak inceleniyor
• MTA kuyruğu, teslimat sorunlarını gösteren ertelenmiş mesajlar için izleniyor
• Gönderen IP, zamanlanmış bir temelde başlıca RBL’lere (Spamhaus ZEN, Barracuda, SORBS) karşı kontrol ediliyor

SSS

SMTP port 25, 465 ve 587 arasındaki fark nedir?

Port 25, yalnızca sunucudan sunucuya MTA aktarımı için kullanılır ve son kullanıcılar için çoğu ISP tarafından engellenir. Port 587, kimliği doğrulanmış istemciden sunucuya bağlantılar için belirlenen gönderim portudur ve şifreleme müzakeresi için STARTTLS kullanır. Port 465, tüm SMTP oturumunu başından itibaren SSL/TLS ile saran eski SMTPS portudur; kısa süreliğine kullanımdan kaldırılmış ancak şimdi RFC 8314 kapsamında örtük TLS ile kimliği doğrulanmış gönderim için resmi olarak yeniden atanmıştır.

E-postam SPF’yi geçtiği halde neden DMARC’ta başarısız oluyor?

DMARC, kimliği doğrulanmış alan adı ile `From:` başlığı alan adı arasında tanımlayıcı hizalama gerektirir. SPF, zarf göndericiyi (`MAIL FROM`) doğrular; bu, görünür `From:` başlığından farklı olabilir. Bu alan adları (yapılandırılmış hizalama modunda) hizalanmıyorsa, SPF geçse bile DMARC başarısız olur. Çözüm, `From:` başlığı alan adının SPF tarafından doğrulanan alan adıyla eşleşmesini sağlamak veya DKIM hizalamasının DMARC’ı karşılaması için `From:` alan adıyla DKIM imzalamayı yapılandırmaktır.

Geçerli bir DKIM imzasının alıcı sunucuda doğrulamada başarısız olmasına ne neden olur?

En yaygın nedenler şunlardır: mesaj gövdesi veya imzalanan başlıklar iletim sırasında değiştirildi (posta listesi alt bilgileri, aktarımlar tarafından başlık yeniden yazma); DKIM seçicisi için DNS TXT kaydı imzalamadan sonra silindi veya değiştirildi; ya da DNS’deki genel anahtar, mesajı imzalamak için kullanılan özel anahtarla eşleşmiyor. Her zaman yönlendirilmiş bir kopya değil, ham mesaj kaynağını kullanarak doğrulayın.

İş ortamı için IMAP ve POP3 arasındaki pratik fark nedir?

IMAP, tam posta kutusu durumunu — okundu/okunmadı bayrakları, klasör yapısı, gönderilen öğeler, taslaklar — mesajlar sunucuda kalırken her cihazda gerçek zamanlı olarak senkronize eder. POP3, mesajları bir cihaza indirir ve varsayılan olarak bunları sunucudan kaldırır; bu da bu mesajlara ikinci bir cihazdan erişimi imkânsız kılar. E-postaya birden fazla cihazdan erişen çalışanları olan herhangi bir işletme için POP3, veri siloları oluşturur ve sunucu taraflı mesaj saklama özelliğini ortadan kaldırır. IMAP tek uygun seçimdir.

Meşru bir e-postanın neden spam klasörüne teslim edildiğini nasıl teşhis ederim?

Spam klasöründen ham mesaj kaynağını alın ve SPF, DKIM ve DMARC sonuçlarını kontrol etmek için `Authentication-Results:` başlığını inceleyin. Hangi kuralların tetiklendiğini belirlemek için alıcı sunucunun filtresi tarafından eklenen `X-Spam-Status:` veya `X-Spam-Score:` başlıklarını arayın. Gönderen IP’nin eşleşen bir PTR kaydına sahip olduğunu, herhangi bir RBL’de listelenmediğini ve gönderen alan adının eksiksiz bir kimlik doğrulama yığınına sahip olduğunu doğrulayın. Eksik veya başarısız bir DKIM imzasının nötr bir SPF sonucuyla birleşmesi, meşru postanın spam olarak puanlanmasının en sık karşılaşılan nedenidir.