MTA Nedir? Mail Transfer Agent ve E-postanın Yolu

MTA nedir?

MTA (Mail Transfer Agent), e-postayı bir sunucudan diğerine taşıyan yazılımdır. Gönderenin e-postasını alır, alıcının alan adının MX kaydına bakıp doğru sunucuyu bulur ve SMTP protokolüyle iletir. Posta kutusuna son teslimi MTA değil MDA yapar. Postfix, Exim ve Sendmail bilinen MTA örnekleridir.

Bu yazı, web sitesi ya da e-ticaret sitesi sahiplerine ve kendi hosting hesabını yöneten yazılımcılara yöneliktir. Önce e-postanın yolunu ve bu yoldaki dört rolü anlatıyoruz. Ardından port 25 ile 587 farkını, kuyruğu, relay kavramını ve açık relay riskini ele alıyoruz.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu nedenle anlatım RFC belgelerine ve Google'ın resmi e-posta gönderen yönergelerine dayanır. Kurulum anlatmıyoruz; amacımız, e-posta altyapısıyla ilgili kararları doğru anlamanız ve sağlayıcınıza doğru soruları sormanızdır.

MTA nedir sorusu, e-posta sorunu yaşayan herkesin eninde sonunda karşısına çıkar. Çünkü form bildirimi gelmediğinde, bülten spama düştüğünde ya da geri dönen mesaj aldığınızda, sorunun bir MTA ile ilgili olması çok muhtemeldir. Bu yazı, o noktada neye bakacağınızı gösterir. MTA nedir ve ne yapmaz sorusunu netleştirdiğinizde, teşhis süresi belirgin biçimde kısalır.

Ayrıca küçük bir not düşelim: RFC 5598 kısaltmayı "Message Transfer Agent" olarak açar, günlük kullanımda ise "Mail Transfer Agent" demek yaygındır. İkisi de aynı bileşeni anlatır.

MTA nedir sorusunun yanında MUA, MSA ve MDA ne iş yapar?

E-posta tek bir programın işi değildir; zincirde dört rol vardır. RFC 5598 (İnternet e-posta mimarisi) bu rolleri ayrı ayrı tanımlar. Küçük kurulumlarda tek yazılım birkaç rolü birden üstlenebilir. Yine de rolleri ayırmak, bir sorunun nerede çıktığını bulmanızı kolaylaştırır. Örneğin giriş yapamıyorsanız sorun MSA tarafındadır; mesaj gidiyor ama alıcıya ulaşmıyorsa MTA ve DNS kayıtlarına bakmanız gerekir.

RFC 5598 MTA'yı, bir paket anahtarına ya da IP yönlendiricisine benzetir. Yani MTA'nın işi yönlendirme kararı verip e-postayı alıcıya bir adım yaklaştırmaktır. Kullanıcı arayüzü ya da posta kutusu yönetimi MTA'nın görevi değildir. MTA nedir diye bakarken bu sınırı akılda tutmak, sorumluluğu doğru yere yüklemenizi sağlar.

Bir e-posta gönderenden alıcıya hangi yolu izler?

Yolu adım adım izlemek, MTA'nın yerini netleştirir. Aşağıdaki sıra, tipik bir gönderimi sadeleştirerek gösterir. Gerçek kurulumlarda araya ek sunucular, güvenlik tarayıcıları ve yönlendirmeler girebilir.

1. Gönderen, MUA'da iletiyi yazar ve gönder düğmesine basar.
2. MUA, iletiyi MSA'ya teslim eder; MSA kimliği doğrular ve iletiyi giden MTA'ya aktarır.
3. Giden MTA, alıcının alan adı için DNS'te MX kaydını sorgular.
4. MTA, MX kaydındaki sunucuya SMTP ile bağlanır ve iletiyi teslim eder.
5. Alıcı tarafın MTA'sı iletiyi kabul eder ve MDA'ya devreder.
6. MDA, iletiyi alıcının posta kutusuna yazar.
7. Alıcı, kendi MUA'sıyla posta kutusunu açıp iletiyi okur.

Bu zincirde iletiyi sunucudan sunucuya taşıyan adım dördüncü adımdır ve MTA'nın asıl işi budur. Kalan adımlar ya iletiyi hazırlar ya da son teslimi tamamlar.

Sorun giderirken bu sırayı bir harita gibi kullanın. İleti 2. adımda takılıyorsa kimlik doğrulama sorunu vardır. 3. adımda takılıyorsa DNS kaydı eksik ya da hatalıdır. 4. adımda takılıyorsa alıcı sunucu iletiyi reddediyor ya da geçici hata veriyordur. 5. ve 6. adımlarda takılırsa sorun alıcının kendi sisteminde, örneğin dolu bir posta kutusunda olabilir.

MTA ile MX kaydı arasındaki ilişki nedir?

MX kaydı, bir alan adına gelen e-postayı hangi sunucunun kabul edeceğini söyleyen DNS kaydıdır. Giden MTA, alıcının alan adı için MX kaydını sorgular ve dönen sunucuya bağlanır. RFC 5321 bölüm 3.6.2'ye göre bir relay sunucu çoğu zaman son teslim sistemi değil, MX kaydının gösterdiği sunucudur.

Birden fazla MX kaydı varsa her kaydın bir öncelik değeri bulunur. MTA önce en düşük değerli, yani en öncelikli sunucuyu dener. O sunucu cevap vermezse sıradaki kayda geçer. Alan adında hiç MX kaydı yoksa, RFC 5321 bölüm 5.1 uyarınca A ya da AAAA kaydına başvurulabilir.

Dolayısıyla MX kaydını yanlış girmek, e-postaların yanlış sunucuya gitmesine ya da hiç ulaşmamasına neden olur. Kayıtlarınızı DNS sorgulama aracımızla kontrol edebilirsiniz. Özellikle e-posta sağlayıcısı değiştirdikten sonra MX kayıtlarına bakmanız gerekir. Kayıt değişikliğinin her yere yayılması zaman alabilir; bu süre boyunca bazı iletiler eski, bazıları yeni sunucuya gidebilir.

SMTP nedir ve MTA'lar birbiriyle nasıl konuşur?

SMTP (Simple Mail Transfer Protocol), MTA'ların e-posta aktarırken kullandığı protokoldür; RFC 5321'de tanımlanır. Protokol metin tabanlıdır: istemci komut gönderir, sunucu üç haneli kodla yanıtlar. Aşağıdaki kısaltılmış oturum, örnek alan adlarıyla akışı gösterir.

S: 220 mx.example.net ESMTP hazir
C: EHLO mail.example.com
S: 250-mx.example.net
S: 250 STARTTLS
C: MAIL FROM:<gonderen@example.com>
S: 250 OK
C: RCPT TO:<alici@example.net>
S: 250 OK
C: DATA
S: 354 Mesaji gonderin, nokta ile bitirin
C: (baslik ve mesaj govdesi)
C: .
S: 250 Kuyruga alindi
C: QUIT

Satırların başındaki S sunucuyu, C istemciyi gösterir. Önce taraflar tanışır (EHLO), sonra zarf bilgisi verilir (MAIL FROM ve RCPT TO), en sonda mesajın kendisi gelir (DATA). Sunucu "Kuyruğa alındı" dediğinde sorumluluğu devralmış olur; bu nokta, kuyruk bölümünde önem kazanır. Dolayısıyla bir iletinin "gönderildi" görünmesi, alıcıya ulaştığı anlamına gelmez; yalnızca ilk MTA'nın iletiyi kabul ettiğini gösterir.

Port 25, 587 ve 465 arasındaki fark nedir?

Port 25, sunucular arası aktarım içindir; port 587 ise istemcinin e-postayı ilk teslim ettiği submission portudur. RFC 6409'a göre 587 portunda MSA, varsayılan olarak kimlik doğrulaması yapılmamış oturumun MAIL komutunu reddeder. Port 465 ise RFC 6409'da geçmez; bazı sağlayıcılar onu örtük TLS ile sunar.

Pratikte bir mail istemcisini ya da WordPress eklentisini ayarlarken, port ve şifreleme türünü sağlayıcınızın verdiği değerlerle girin. Rastgele bir port denemek yerine sağlayıcının yardım sayfasını esas alın.

Postfix, Exim ve Sendmail gibi örneklerde MTA nedir, nasıl ayrışırlar?

Postfix, Exim ve Sendmail aynı işi yapan farklı yazılımlardır. Hepsi SMTP konuşur, kuyruk tutar ve e-postayı yönlendirir. Fark; yapılandırma biçiminde, varsayılan davranışta ve hangi dağıtım ya da panelle geldiğinde ortaya çıkar. Aşağıdaki tablo yalnızca genel bir çerçeve verir.

Hangisinin kurulu olduğu çoğu zaman sizin seçiminiz değildir. Paylaşımlı hostingde sağlayıcı bu seçimi yapar. Bu yüzden "hangi MTA daha iyi" sorusundan önce, "sağlayıcım e-posta teslimatını nasıl yönetiyor" sorusunu sormanız daha verimlidir.

MTA kuyruğu nedir ve e-postalar neden bekler?

Kuyruk, MTA'nın henüz teslim edemediği iletileri geçici olarak sakladığı alandır. Alıcı sunucu meşgulse, geçici hata veriyorsa ya da ulaşılamıyorsa MTA iletiyi silmez; belirli aralıklarla yeniden dener. RFC 5321 bölüm 4.5.4, yeniden deneme sürecinin birkaç gün boyunca sürmesini öngörür.

Postfix örneğinde kuyruğun birkaç bölümü vardır: yeni gelenler için incoming, teslime hazırlananlar için active, ertelenenler için deferred ve elle durdurulanlar için hold. Bu adlar Postfix'in QSHAPE belgesinde geçer. Kuyruktaki iletileri görmek için aşağıdaki komut kullanılır.

postqueue -p
mailq

İkinci komut, ilkinin eşdeğeridir. Çıktıda her iletinin kuyruk kimliği, boyutu, gönderen ve alıcı adresi görünür. Kuyrukta binlerce ileti birikmişse sorun genellikle alıcı tarafında ya da sizin sunucunuzdan çıkan istenmeyen e-postadadır. Bu durumda kendi başınıza kuyruğu silmeyin, sağlayıcınıza haber verin.

SMTP hata kodları ne anlama gelir: 4xx ile 5xx farkı nedir?

SMTP yanıt kodunun ilk hanesi, durumun geçici mi kalıcı mı olduğunu söyler. 4 ile başlayan kodlar geçici hatadır; MTA iletiyi kuyrukta tutup yeniden dener. 5 ile başlayan kodlar kalıcı hatadır; MTA denemeyi bırakır ve gönderene bir geri dönüş mesajı üretir.

Örneğin alıcı adresi yoksa 5xx alırsınız ve adresi düzeltmeniz gerekir. Alıcı sunucu o an yoğunsa 4xx alırsınız ve MTA kendiliğinden tekrar dener. Geri dönen mesajın metnini mutlaka okuyun; çünkü sebep çoğu zaman o metnin içinde yazar.

Geri dönen e-posta (bounce) mesajı neden boş göndericiyle gelir?

Bounce mesajı, teslim edilemeyen e-postanın göndericiye bildirilmesidir. RFC 5321 bölüm 4.5.5, bu bildirimlerde boş geri dönüş adresi kullanılmasını ister: MAIL FROM:<>. Amaç, bounce mesajının da teslim edilemediği durumda sonsuz bir döngü oluşmasını engellemektir.

Bu bilgi, sorun gidermede işinize yarar. Bir bounce mesajının gönderen alanı boş ya da sistem adresi gibi görünüyorsa bunu normal sayın. Önemli olan, mesajın içinde yer alan teknik açıklamadır. Orada alıcı sunucunun adını, hata kodunu ve kısa bir gerekçeyi görürsünüz.

• Hata kodunun 4xx mi 5xx mi olduğuna bakın.
• Gerekçe metnini bir arama motorunda tırnak içinde aratın.
• Alıcı sunucunun adından, sorunun hangi tarafta olduğunu anlayın.
• Gerekirse mesajın tamamını sağlayıcınıza iletin.

Hosted e-posta servisleri kullanıyorsanız MTA nedir, kimde kalır?

Google Workspace ya da Microsoft 365 gibi bulut e-posta servisleri kullanıyorsanız MTA'yı sizin yerinize servis sağlayıcı işletir. Siz yalnızca DNS'te MX kayıtlarını o servisin verdiği değerlere çevirirsiniz. Böylece kuyruk, TLS, relay kısıtı ve güvenlik güncellemeleri sizin sorumluluğunuzdan çıkar.

Ancak sorumluluğun tamamı devredilmiş olmaz. Alan adınızın SPF, DKIM ve DMARC kayıtlarını hâlâ siz yönetirsiniz. Ayrıca sitenizin kendi gönderdiği e-postaları (sipariş bildirimi, form yanıtı) bu servisten geçirmeyi de siz ayarlarsınız. Bu yüzden yeni bir servise geçerken iki şeyi kontrol edin: MX kayıtlarını ve sitenin e-posta gönderme yöntemini.

Sağlayıcı seçimi ayrı bir konudur ve burada karşılaştırma yapmıyoruz. Seçenekleri ve alan adlı e-postanın artılarını kurumsal e-posta altyapısı yazımızda bulabilirsiniz.

Smarthost ve e-posta yönlendirme MTA'da ne anlama gelir?

Smarthost, bir MTA'nın giden e-postayı kendisi teslim etmek yerine başka bir sunucuya devretmesidir. Örneğin sunucunuzdaki yerel MTA, iletileri doğrudan alıcıya göndermez; kimlik doğrulamalı bir e-posta servisine aktarır. Böylece teslimat itibarı, o servisin altyapısına dayanır.

E-posta yönlendirme ise başka bir olaydır: bir adrese gelen iletiyi otomatik olarak başka bir adrese iletirsiniz. Yönlendirme sırasında iletinin gönderen sunucusu değişmez ama iletiyi gönderen MTA artık yönlendiren sunucudur. Bu nedenle bazı alıcı sunucular, SPF kontrolünde yönlendirilmiş iletileri başarısız sayabilir.

• Smarthost, giden iletinin hangi sunucudan çıkacağını belirler.
• Yönlendirme, gelen iletiyi başka bir adrese taşır.
• İkisinde de kimlik doğrulama ve kayıt uyumuna dikkat edin.
• Ayar değerlerini sağlayıcınızın yardım sayfasından alın.

Relay nedir ve açık relay neden tehlikelidir?

Relay, bir MTA'nın kendisine ait olmayan bir alan adı için gelen e-postayı başka bir sunucuya aktarmasıdır. Meşru relay, kimliği doğrulanmış kullanıcılar ya da tanımlı ağlar için çalışır. Açık relay ise herkesten gelen iletiyi herhangi bir adrese aktaran, yanlış yapılandırılmış sunucudur.

Tehlike şudur: Saldırgan, açık relay üzerinden sizin sunucunuzun adıyla milyonlarca istenmeyen e-posta gönderebilir. Sonuçta IP adresiniz kara listelere girer, meşru e-postalarınız spam klasörüne düşer ve sağlayıcınız hesabınızı askıya alabilir. Üstelik bunu çoğu zaman haftalarca fark etmezsiniz.

RFC 5321 bölüm 3.6.2, bir sunucunun politika gereği belirli bir adrese relay yapmayı reddedebileceğini ve bu durumda 550 yanıtı vermesi gerektiğini söyler. Günümüzde modern MTA yazılımları varsayılan olarak açık relay'e izin vermez. Risk, çoğunlukla elle yapılan geniş izin ayarlarından doğar.

Sunucunuzun açık relay olmadığından nasıl emin olursunuz?

Önce sunucuyu kimin yönettiğine bakın. Paylaşımlı hosting ya da yönetilen VPS kullanıyorsanız relay ayarı sağlayıcınızın sorumluluğundadır; bu durumda sağlayıcıdan yazılı bir güvence isteyin. Kendi VPS'inizi yönetiyorsanız MTA'nın relay kısıtlama ayarlarını resmi dokümandan okuyup doğrulamanız gerekir.

Postfix kullanıyorsanız ilgili ayarlar smtpd_relay_restrictions ve mynetworks parametreleridir. Ayarların tam anlamını ve güvenli değerlerini Postfix'in resmi belgelerinden okuyun; bu yazıda değer önermiyoruz. Çünkü yanlış bir mynetworks girdisi, sunucunuzu tüm ağa açabilir.

• Sunucudan beklenmedik sayıda giden e-posta olup olmadığına bakın.
• Kuyruğun alışılmadık biçimde büyüyüp büyümediğini izleyin.
• Çok sayıda geri dönen mesaj geliyorsa şüphelenin.
• IP adresinizin kara listede olup olmadığını sağlayıcınızla birlikte kontrol edin.

Üçüncü kişilerin sunucularına test mesajı yağdırmayın. Test, yalnızca kendi kontrolünüzdeki adreslerle ve sağlayıcınızın bilgisi dahilinde yapılmalıdır.

MTA'yı kendiniz mi kurmalısınız, yoksa hosting sağlayıcınıza mı bırakmalısınız?

Çoğu web sitesi sahibi için cevap açıktır: e-posta altyapısını sağlayıcıya ya da yönetilen bir e-posta servisine bırakın. Kendi MTA'nızı işletmek; DNS kayıtlarını, TLS'i, kuyruğu, kara liste takibini ve güvenlik güncellemelerini sürekli yönetmek demektir. Bir hata, bütün alan adınızın itibarını düşürür.

Şu durumlarda kendi MTA'nızla uğraşmamalısınız:

• Teslimat sorunlarını teşhis edecek deneyiminiz yoksa.
• Siteniz müşteri e-postaları, sipariş bildirimleri gibi kritik iletiler gönderiyorsa.
• Güvenlik güncellemelerini düzenli izleyecek zamanınız yoksa.
• Sunucunuz paylaşımlı hostingdeyse; bu durumda zaten yetkiniz olmaz.

Kendi VPS'inizi yönetiyor ve MTA kurmak istiyorsanız önce hosting seçimi rehberimizi okuyun. Sunucuyu korumak için Fail2ban ve CSF güvenlik duvarı yazılarımız da işinize yarar.

SPF, DKIM ve DMARC MTA ile nasıl ilişkilidir?

SPF, DKIM ve DMARC, alıcı MTA'nın gelen iletinin gerçekten sizden geldiğini doğrulamak için baktığı DNS tabanlı kayıtlardır. Google'ın gönderen yönergelerine göre tüm göndericilerin SPF ya da DKIM kurması gerekir. Günde 5.000'den fazla ileti gönderenler ise SPF, DKIM ve DMARC'ın üçünü birden kurmalıdır.

• SPF, alan adınız adına hangi sunucuların e-posta gönderebileceğini listeler.
• DKIM, ileti başlığına dijital imza ekleyerek içeriğin değişmediğini gösterir.
• DMARC, doğrulama başarısız olursa alıcının ne yapacağını belirtir.

Yani MTA nedir sorusunun cevabı taşımaktır; bu üç kayıt ise taşınan iletinin güvenilirliğini kanıtlar. Kayıtlarınızı SPF, DKIM ve DMARC kontrol aracımızla test edebilirsiniz. Kayıtları kendi başınıza değiştirmeden önce, e-postayı kullanan tüm servisleri (site, CRM, bülten aracı) listeleyin; çünkü eksik bir kayıt, o servisin e-postalarını spama düşürür.

PTR kaydı ve TLS neden teslimat için önemlidir?

Alıcı MTA'lar, bağlanan sunucunun kimliğine de bakar. Google'ın gönderen yönergelerine göre gönderen IP adresi, PTR kaydındaki ana makine adının IP adresiyle eşleşmelidir. Ayrıca ileri DNS kaydı (A ya da AAAA) aynı IP adresine çözülmelidir. Bu eşleşme olmazsa ileti reddedilebilir ya da spama düşebilir.

Aynı yönergeler, e-posta iletimi için TLS bağlantısı kullanmanızı da ister. TLS, iletinin sunucular arasındaki yolda okunmasını zorlaştırır. Sonuç olarak PTR ve TLS, sunucunuzun "düzgün işletilen bir MTA" izlenimi vermesine yardım eder.

PTR kaydını genellikle IP adresinin sahibi, yani hosting ya da bulut sağlayıcınız ayarlar. Siz kendi DNS panelinizden PTR kaydı oluşturamazsınız. Dolayısıyla bu konuda sağlayıcınıza başvurmanız gerekir. Sağlayıcıya yazarken "sunucu IP adresim için PTR kaydı hangi ana makine adını gösteriyor" diye sorun; bu soru, destek ekibinin işini hızlandırır. Örnek bir IP için 203.0.113.10 gibi bir adres düşünün: bu adresin ters kaydını yalnızca adresi size tahsis eden taraf değiştirebilir.

WordPress ve web siteleri e-postayı MTA üzerinden mi gönderir?

Evet, ama iki farklı yolla. WordPress varsayılan olarak PHP'nin mail işlevini kullanır; bu işlev sunucudaki yerel MTA'ya devreder. Alternatif yol, SMTP eklentisiyle bir dış e-posta servisine kimlik doğrulamalı bağlanmaktır. WP Mail SMTP gibi eklentiler bu ikinci yolu kolaylaştırır.

Burada da MTA nedir sorusunun pratik yüzü ortaya çıkar: web sitenizin e-postası, sunucudaki bir MTA'dan ya da dış bir servisten çıkar ve alıcı bu kaynağa göre karar verir.

Site formunuzdan gelen bildirimlerin spama düşmesi, çoğunlukla ilk yöntemin sonucudur. Gönderen alan adı ile gönderen sunucu uyuşmadığı için SPF ve DKIM doğrulaması başarısız olur. Kurumsal e-posta tarafını ayrıntılı ele aldığımız kurumsal e-posta altyapısı rehberimize göz atın. Eklenti kurulumunu burada anlatmıyoruz; sağlayıcınızın verdiği SMTP değerlerini kullanın.

E-posta teslim edilmiyorsa hangi sırayla teşhis edersiniz?

Teşhiste önce kimin sorumlu olduğunu ayırın: gönderen mi, alıcı mı, aradaki sunucu mu? Aşağıdaki sıra, en ucuz kontrolden başlayıp pahalıya doğru gider. Böylece gereksiz yere sağlayıcıyı meşgul etmezsiniz, ama gerektiğinde de vakit kaybetmezsiniz.

1. Geri dönen mesajı okuyun ve hata kodunun 4xx ya da 5xx olduğunu not edin.
2. Alıcı adresini doğru yazdığınızdan emin olun.
3. Alan adının MX kayıtlarını DNS sorgulama ile kontrol edin.
4. SPF, DKIM ve DMARC kayıtlarını test edin.
5. Sunucunuzun IP adresini ve ters DNS kaydını kontrol edin.
6. Kuyrukta bekleyen ileti olup olmadığını sağlayıcınıza sorun.
7. Sorun sürerse, geri dönen mesajın tamamıyla birlikte destek talebi açın.

IP adresinin kime ait olduğunu görmek için IP sorgulama aracını da kullanabilirsiniz. Bu adım, sorunun sizin sunucunuzda mı yoksa üçüncü bir tarafta mı olduğunu anlamanıza yardım eder.

E-posta pazarlaması yapıyorsanız MTA seçimi neyi değiştirir?

Bülten ve kampanya e-postalarında MTA'nın kendisinden çok gönderici itibarı belirleyicidir. Aynı IP adresinden gönderen tüm kullanıcıların davranışı, o adresin itibarını etkiler. Üstelik toplu gönderimde alıcı sunucular, hız sınırı uygulayarak iletileri geçici hatayla (4xx) geri çevirebilir.

Bu nedenle kampanya e-postalarını, normal posta kutunuzla aynı yoldan göndermek iyi bir fikir değildir. İşlem e-postaları (sipariş, şifre sıfırlama) ile pazarlama e-postalarını ayırmak, birinin sorunu diğerini etkilemesin diye mantıklıdır. Bu ayrımı nasıl yapacağınıza e-posta servisi sağlayıcınızın belgeleri yön verir.

Google'ın yönergeleri, bildirilen spam oranının Postmaster Tools'ta yüzde 0,3'ün altında tutulmasını ister. Dolayısıyla liste temizliği ve kolay abonelikten çıkış, teknik ayar kadar önemlidir. E-posta pazarlamasında yapay zekâ kullanımını ele aldığımız e-posta pazarlamasında yapay zekâ yazımıza da bakabilirsiniz.

MTA hakkında yaygın yanlış anlamalar nelerdir?

MTA konusunda sık duyduğumuz birkaç yanlış anlama var. Bunları bilmek, hem sağlayıcınızla konuşurken hem de sorun ararken zaman kazandırır. Aşağıda her birinin doğrusunu kısaca veriyoruz.

• "MTA, posta kutusudur." Hayır; posta kutusuna yazan bileşen MDA'dır.
• "Port 25 ile 587 aynıdır." Hayır; biri sunucular arası aktarım, diğeri istemci teslimi içindir.
• "MX kaydı olmadan e-posta gelmez." Her zaman değil; RFC 5321 A ya da AAAA kaydına geri dönüşe izin verir.
• "Kuyruktaki iletiler kaybolmuştur." Çoğu zaman kaybolmamıştır; MTA yeniden dener.
• "SPF kurdum, iş bitti." Yetmez; DKIM ve DMARC de gerekir.

Yanlış anlamaların çoğu, MTA nedir sorusunu tek bir yazılıma indirgemekten doğar. Oysa e-posta; DNS, kimlik doğrulama, itibar ve birden fazla yazılımın birlikte çalıştığı bir zincirdir. Bu listedeki maddeler, tek tek kontrol edilebilir. Hangisinin sizin durumunuza uyduğunu bulmak için önceki bölümlerdeki teşhis sırasını izleyin. Emin olamadığınız her noktada hosting sağlayıcınızın destek ekibine başvurmak, en güvenli yoldur; çünkü sunucu tarafındaki ayarlara erişimi ve sorumluluğu onlar taşır.

MTA konusunda nereden başlamalısınız?

Özetle MTA, e-postayı sunucudan sunucuya taşıyan yazılımdır; MUA, MSA ve MDA ile birlikte bir zincir oluşturur. MX kaydı yolu gösterir, SMTP dili sağlar, kuyruk dayanıklılık getirir. Açık relay ise bu düzenin en pahalı hatasıdır. Karar vermek için önce kendi durumunuzu netleştirin.

1. E-postanızı kimin taşıdığını belirleyin: hosting, e-posta servisi ya da kendi sunucunuz.
2. MX, SPF, DKIM ve DMARC kayıtlarınızı kontrol edin.
3. Siteniz e-postayı PHP işleviyle mi, SMTP ile mi gönderiyor, öğrenin.
4. Sağlayıcınıza relay ve PTR ayarlarını sorun.
5. Kritik e-postaları pazarlama e-postalarından ayırın.
6. Değişikliklerden önce mevcut DNS kayıtlarınızın bir kopyasını saklayın.

Web sitenizin e-posta, hız ve güvenlik altyapısını birlikte değerlendirmek isterseniz web tasarım hizmetimize göz atabilirsiniz. Ayrıca SSL sertifikası rehberimiz güvenlik tarafını tamamlar. Bu yazı hukuki ya da teknik garanti vermez; ayrıntılar için RFC 5321, RFC 5598, RFC 6409 ve Google'ın e-posta gönderen yönergelerini okuyun.