SMTP oturumu ba\u015flarken g\u00f6nderen sunucu kendini al\u0131c\u0131 sunucuya tan\u0131t\u0131r. Bu tan\u0131t\u0131m komutu klasik olarak HELO<\/strong>, modern SMTP uzant\u0131lar\u0131n\u0131 bildirebilen s\u00fcr\u00fcm olarak da EHLO<\/strong> \u015feklindedir. Bu komutun i\u00e7inde g\u00f6nderici sunucu bir isim (genellikle bir alan ad\u0131) g\u00f6nderir. Pek \u00e7ok ki\u015fi bunu \u201cdetay\u201d gibi g\u00f6rse de, al\u0131c\u0131 sistemler bu de\u011feri spam risk analizi, hatal\u0131 yap\u0131land\u0131rma tespiti ve bazen de kaba do\u011frulama kontrolleri i\u00e7in kullan\u0131r.<\/p>\n HELO\/EHLO de\u011feri tek ba\u015f\u0131na bir kimlik do\u011frulama mekanizmas\u0131 de\u011fildir; SPF\/DKIM\/DMARC gibi kontrollerle kar\u0131\u015ft\u0131r\u0131lmamal\u0131d\u0131r. Ancak k\u00f6t\u00fc ayarlanm\u0131\u015f bir HELO\/EHLO, \u00f6zellikle yeni kurulumlarda veya IP itibar\u0131 zay\u0131f a\u011flarda, teslim edilebilirli\u011fi olumsuz etkileyebilir ve baz\u0131 al\u0131c\u0131lar taraf\u0131ndan \u201c\u015f\u00fcpheli\u201d sinyal olarak de\u011ferlendirilir.<\/p>\n Basitle\u015ftirilmi\u015f bir SMTP ak\u0131\u015f\u0131nda \u00f6nce TCP ba\u011flant\u0131s\u0131 kurulur, sonra al\u0131c\u0131 sunucu bir kar\u015f\u0131lama banner\u2019\u0131 d\u00f6ner, ard\u0131ndan g\u00f6nderen EHLO<\/strong> (ya da HELO) ile kendini tan\u0131t\u0131r. Bu a\u015famadan sonra STARTTLS, AUTH, MAIL FROM, RCPT TO ve DATA gibi ad\u0131mlar gelir. Yani HELO\/EHLO, g\u00f6nderenin \u201cben buyum\u201d dedi\u011fi ilk and\u0131r.<\/p>\n Bu y\u00fczden HELO\/EHLO de\u011ferinin, g\u00f6nderim yapan MTA\u2019n\u0131n ger\u00e7ek a\u011f kimli\u011fiyle ve DNS kay\u0131tlar\u0131yla tutarl\u0131 olmas\u0131, hata ay\u0131klama ve itibar y\u00f6netimi a\u00e7\u0131s\u0131ndan da \u00f6nemlidir. Loglarda \u201chelo=…\u201d \u015feklinde g\u00f6r\u00fcnen de\u011fer, bir sorunun kayna\u011f\u0131n\u0131 bulurken kritik ipu\u00e7lar\u0131 verir.<\/p>\n \u0130deal yakla\u015f\u0131m, HELO\/EHLO i\u00e7inde tam nitelikli alan ad\u0131 (FQDN)<\/strong> kullanmakt\u0131r. \u00d6rnek: mail.example.com, mx1.example.com gibi. \u201clocalhost\u201d, \u201cserver\u201d, \u201cmail\u201d, \u201cexample\u201d gibi tek par\u00e7al\u0131 veya anlam\u0131 belirsiz de\u011ferler, al\u0131c\u0131 taraf i\u00e7in g\u00fcven vermez.<\/p>\n PTR (rDNS) kayd\u0131, bir IP adresinin hangi host ad\u0131na i\u015faret etti\u011fini s\u00f6yler. Pek \u00e7ok al\u0131c\u0131 sistem, g\u00f6nderen IP\u2019nin PTR kayd\u0131n\u0131 kontrol eder ve daha sonra bu PTR\u2019nin ileri DNS\u2019te tekrar ayn\u0131 IP\u2019ye d\u00f6n\u00fcp d\u00f6nmedi\u011fine bakar. Bu yakla\u015f\u0131m genellikle forward-confirmed reverse DNS (fcrDNS)<\/strong> olarak an\u0131l\u0131r.<\/p>\n Buradaki hedef \u201ckripto d\u00fczeyinde do\u011frulama\u201d de\u011fildir; daha \u00e7ok altyap\u0131n\u0131n d\u00fczg\u00fcn y\u00f6netilip y\u00f6netilmedi\u011fine dair bir kalite sinyalidir. PTR kayd\u0131 olmayan veya anlams\u0131z bir PTR\u2019ye sahip IP\u2019ler, \u00f6zellikle kurumsal al\u0131c\u0131lar ve baz\u0131 antispam katmanlar\u0131 taraf\u0131ndan daha riskli g\u00f6r\u00fclebilir.<\/p>\n Bu \u00fc\u00e7l\u00fc tutarl\u0131l\u0131k; destek s\u00fcre\u00e7lerinde, teslimat sorunlar\u0131nda ve baz\u0131 otomatik kontrollerde belirgin avantaj sa\u011flar.<\/p>\n fcrDNS<\/strong>, basit\u00e7e \u201cIP\u2019nin PTR kayd\u0131ndaki hostname\u2019in A\/AAAA kayd\u0131 ayn\u0131 IP\u2019ye d\u00f6n\u00fcyor mu?\u201d sorusudur. Baz\u0131 sistemler bunun tersini de kontrol eder: \u201cEHLO\u2019da verilen isim \u00e7\u00f6z\u00fcmleniyor mu ve g\u00f6nderen IP ile mant\u0131kl\u0131 bir ili\u015fki var m\u0131?\u201d<\/p>\n \u00d6nemli nokta: fcrDNS ba\u015far\u0131s\u0131zl\u0131\u011f\u0131 her zaman e-postan\u0131n reddedilece\u011fi anlam\u0131na gelmez. Ancak teslim edilebilirlik, spam puan\u0131 ve ge\u00e7i\u015f d\u00f6nemlerindeki \u015f\u00fcpheli trafik s\u0131n\u0131fland\u0131rmalar\u0131 \u00fczerinde etkisi olabilir. Ayr\u0131ca baz\u0131 kurumlar, \u00f6zellikle B2B g\u00fcvenlik katmanlar\u0131, rDNS\u2019siz veya tutars\u0131z rDNS\u2019li g\u00f6nderenlere daha kat\u0131 davranabilir.<\/p>\n EHLO 203.0.113.10 gibi bir kullan\u0131m baz\u0131 eski sistemlerde g\u00f6r\u00fcl\u00fcr. Bu durum \u00e7o\u011fu al\u0131c\u0131 i\u00e7in \u201cotomasyon\/zararl\u0131 yaz\u0131l\u0131m\u201d \u00e7a\u011fr\u0131\u015f\u0131m\u0131 yapabilir ve itibar sinyali olarak olumsuz yaz\u0131labilir.<\/p>\n EHLO mail01.local veya EHLO exchange01 gibi de\u011ferler d\u0131\u015f d\u00fcnyada \u00e7\u00f6z\u00fcmlenmez. Bu, altyap\u0131 olgunlu\u011fu d\u00fc\u015f\u00fck izlenimi yarat\u0131r ve loglarda problem tespitini zorla\u015ft\u0131r\u0131r.<\/p>\n Baz\u0131 IP bloklar\u0131nda PTR default olarak \u201cstatic-203-0-113-10.isp.example\u201d gibi olabilir. Bu her zaman felaket de\u011fildir; ancak kurumsal g\u00f6nderimler i\u00e7in \u00e7o\u011fu ekip bunu kendi alan ad\u0131 alt\u0131nda anlaml\u0131 bir host ad\u0131na ta\u015f\u0131may\u0131 tercih eder.<\/p>\n DNS standard\u0131 pratikte bir IP\u2019ye bir PTR ismi atamay\u0131 kolayla\u015ft\u0131r\u0131r. Birden fazla PTR teknik olarak m\u00fcmk\u00fcn olsa bile, tutarl\u0131l\u0131k ve beklenti y\u00f6netimi a\u00e7\u0131s\u0131ndan genellikle \u00f6nerilmez. En iyi yakla\u015f\u0131m tek bir PTR ve o host ad\u0131na do\u011fru A\/AAAA kayd\u0131d\u0131r.<\/p>\n Birden fazla \u00e7\u0131k\u0131\u015f IP\u2019si olan yap\u0131larda, her IP i\u00e7in ayr\u0131 hostname belirlemek i\u015fleri sadele\u015ftirir. \u00d6rnek yakla\u015f\u0131m:<\/p>\n E\u011fer ayn\u0131 MTA birden \u00e7ok IP\u2019den g\u00f6nderim yap\u0131yorsa, baz\u0131 sistemler HELO\u2019yu sabit tutar. Bu da \u00e7al\u0131\u015fabilir; ancak sorun giderirken \u201changi IP hangi kimlikle konu\u015ftu?\u201d sorusunu zorla\u015ft\u0131rabilir. M\u00fcmk\u00fcnse IP kimli\u011fiyle e\u015fle\u015fen bir hostname tercih edilir.<\/p>\n Bu konuda kritik nokta \u015fudur: PTR kayd\u0131 \u00e7o\u011fu zaman DNS sa\u011flay\u0131c\u0131n\u0131zdan de\u011fil, IP\u2019yi tahsis eden kurumdan y\u00f6netilir<\/strong>. Yani VPS sa\u011flay\u0131c\u0131n\u0131z, veri merkeziniz veya ISP\u2019niz \u00fczerinde ayarlan\u0131r. \u0130leri DNS (A\/AAAA) ise genellikle sizin alan ad\u0131n\u0131z\u0131n DNS b\u00f6lgesinde y\u00f6netilir.<\/p>\n TTL planlamas\u0131, DNS de\u011fi\u015fikliklerinin daha \u00f6ng\u00f6r\u00fclebilir yay\u0131lmas\u0131 a\u00e7\u0131s\u0131ndan yard\u0131mc\u0131 olabilir; ancak PTR taraf\u0131nda TTL her zaman sizin kontrol\u00fcn\u00fczde olmayabilir.<\/p>\n HELO\/EHLO, SPF\/DKIM\/DMARC yerine ge\u00e7mez. SPF, MAIL FROM (envelope-from) alan\u0131 ve g\u00f6nderen IP \u00fczerinden; DKIM i\u00e7erik imzas\u0131 \u00fczerinden; DMARC ise g\u00f6r\u00fcn\u00fcr From alan\u0131 ve hizalama \u00fczerinden \u00e7al\u0131\u015f\u0131r. Yine de al\u0131c\u0131lar \u00e7o\u011fu zaman \u201ctoplam sinyal\u201d yakla\u015f\u0131m\u0131yla de\u011ferlendirme yapar: SPF\/DKIM d\u00fczg\u00fcn olsa bile bariz k\u00f6t\u00fc HELO ve rDNS tutars\u0131zl\u0131\u011f\u0131 teslimata zarar verebilir veya en az\u0131ndan daha fazla incelemeye yol a\u00e7abilir.<\/p>\n Bu nedenle, HELO\/EHLO ve DNS tutarl\u0131l\u0131\u011f\u0131n\u0131 \u201ctemel hijyen\u201d gibi d\u00fc\u015f\u00fcnmek do\u011fru olur: tek ba\u015f\u0131na yeterli de\u011fil, ama eksikli\u011fi gereksiz risk yarat\u0131r.<\/p>\n SMTP HELO\/EHLO, e-posta altyap\u0131s\u0131n\u0131n en erken temas noktalar\u0131ndan biridir ve do\u011fru tasarland\u0131\u011f\u0131nda teslim edilebilirlikte \u201cgereksiz eksi puanlar\u0131\u201d \u00f6nlemeye yard\u0131mc\u0131 olur. FQDN se\u00e7imi, PTR ve ileri DNS uyumu ile fcrDNS tutarl\u0131l\u0131\u011f\u0131; hem teknik ekiplerin sorun giderme s\u00fcresini k\u0131salt\u0131r hem de al\u0131c\u0131 sistemlerin g\u00fcven sinyallerini g\u00fc\u00e7lendirir.<\/p>\n MX1Mail \u00fczerinde alan ad\u0131n\u0131z\u0131 ta\u015f\u0131rken veya mevcut e-posta altyap\u0131n\u0131z\u0131 d\u00fczenlerken, DNS ve kimlik do\u011frulama \u00e7al\u0131\u015fmalar\u0131na ek olarak HELO\/EHLO ve rDNS tutarl\u0131l\u0131\u011f\u0131n\u0131 da kontrol listenize eklemek, uzun vadede daha stabil bir e-posta ak\u0131\u015f\u0131 i\u00e7in iyi bir ad\u0131md\u0131r.<\/p>\n","protected":false},"excerpt":{"rendered":" SMTP HELO\/EHLO kimli\u011finin do\u011fru FQDN ile ayarlanmas\u0131, PTR\/forward DNS uyumu ve fcrDNS kontrol\u00fc sayesinde teslim edilebilirlik sorunlar\u0131n\u0131 azaltmaya y\u00f6nelik pratik rehber.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[291],"tags":[281,94,226],"class_list":["post-169","post","type-post","status-publish","format-standard","hentry","category-e-posta-teslim-edilebilirligi","tag-deliverability","tag-dns","tag-smtp"],"_links":{"self":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts\/169","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/comments?post=169"}],"version-history":[{"count":0,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts\/169\/revisions"}],"wp:attachment":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/media?parent=169"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/categories?post=169"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/tags?post=169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}SMTP oturumunda HELO\/EHLO nereye oturur?<\/h2>\n
En iyi uygulama: HELO\/EHLO i\u00e7in do\u011fru FQDN se\u00e7imi<\/h2>\n
FQDN se\u00e7erken dikkat edilmesi gerekenler<\/h3>\n
\n
PTR (Reverse DNS) ve HELO\/EHLO aras\u0131ndaki ili\u015fki<\/h2>\n
Pratik uyum modeli<\/h3>\n
\n
fcrDNS (Forward-Confirmed rDNS) nedir ve nas\u0131l d\u00fc\u015f\u00fcn\u00fclmelidir?<\/h2>\n
S\u0131k yap\u0131lan hatalar ve sonu\u00e7lar\u0131<\/h2>\n
1) HELO\/EHLO olarak IP adresi kullanmak<\/h3>\n
2) HELO\/EHLO olarak internal hostname kullanmak<\/h3>\n
3) PTR kayd\u0131n\u0131n ISP taraf\u0131ndan jenerik b\u0131rak\u0131lmas\u0131<\/h3>\n
4) Bir IP i\u00e7in birden fazla PTR beklentisi<\/h3>\n
\u00c7oklu MTA, \u00e7oklu IP ve hibrit senaryolarda isimlendirme<\/h2>\n
\n
DNS taraf\u0131nda gereken kay\u0131tlar: A\/AAAA, PTR ve planlama<\/h2>\n
De\u011fi\u015fiklik plan\u0131<\/h3>\n
\n
HELO\/EHLO ve kimlik do\u011frulama (SPF\/DKIM\/DMARC) ili\u015fkisi<\/h2>\n
Kontrol listesi: Canl\u0131ya almadan \u00f6nce h\u0131zl\u0131 do\u011frulama<\/h2>\n
\n
Sonu\u00e7: Daha temiz sinyaller, daha az s\u00fcrpriz<\/h2>\n