{"id":157,"date":"2026-10-16T09:01:28","date_gmt":"2026-10-16T06:01:28","guid":{"rendered":"https:\/\/mx1mail.com\/blog\/e-posta-akisi-sorun-giderme-queue-smtp-loglari-teslimat-gecikmesi\/"},"modified":"2026-10-16T09:01:28","modified_gmt":"2026-10-16T06:01:28","slug":"e-posta-akisi-sorun-giderme-queue-smtp-loglari-teslimat-gecikmesi","status":"publish","type":"post","link":"https:\/\/mx1mail.com\/blog\/tr\/e-posta-akisi-sorun-giderme-queue-smtp-loglari-teslimat-gecikmesi\/","title":{"rendered":"E-Posta Ak\u0131\u015f\u0131 Sorun Giderme: Queue (Kuyruk), SMTP Loglar\u0131 ve Teslimat Gecikmelerini Sistematik Te\u015fhis Etme"},"content":{"rendered":"<h2>E-posta ak\u0131\u015f\u0131 sorunlar\u0131nda neden \u201csistematik te\u015fhis\u201d gerekir?<\/h2>\n<p>Kurumsal e-posta sorunlar\u0131 \u00e7o\u011fu zaman \u201cmail gitmedi\u201d, \u201cge\u00e7 gitti\u201d, \u201cspam\u2019e d\u00fc\u015ft\u00fc\u201d gibi tek bir c\u00fcmleyle raporlan\u0131r. Ancak ayn\u0131 \u015fikayetin arkas\u0131nda bamba\u015fka teknik nedenler olabilir: g\u00f6nderen taraf kuyrukta bekletiyor olabilir, al\u0131c\u0131 taraf ge\u00e7ici hata d\u00f6nd\u00fcr\u00fcyor olabilir, DNS \u00e7\u00f6z\u00fcmlemesi gecikiyor olabilir ya da yanl\u0131\u015f bir y\u00f6nlendirme mesaj\u0131 dola\u015f\u0131ma sokuyor olabilir. Bu y\u00fczden iyi bir e-posta y\u00f6neticisi, rastgele ayar de\u011fi\u015ftirmek yerine mesaj\u0131n sistemler aras\u0131ndaki yolculu\u011funu kan\u0131ta dayal\u0131 bi\u00e7imde takip eder.<\/p>\n<p>Bu yaz\u0131da ama\u00e7, e-postan\u0131n \u201cg\u00f6nderildi\u201d an\u0131ndan \u201cal\u0131c\u0131 kutusuna\u201d kadar olan ak\u0131\u015f\u0131n\u0131 izlerken hangi verilere bak\u0131laca\u011f\u0131n\u0131 ve bu verileri nas\u0131l yorumlayarak k\u00f6k nedeni bulaca\u011f\u0131n\u0131z\u0131 anlatmakt\u0131r. Anlat\u0131m, belirli bir yaz\u0131l\u0131ma ba\u011fl\u0131 olmadan; kuyruk (queue), SMTP oturum kay\u0131tlar\u0131 (loglar), mesaj kimlikleri ve zaman \u00e7izelgesi mant\u0131\u011f\u0131 \u00fczerinden ilerler.<\/p>\n<h2>Mail ak\u0131\u015f\u0131n\u0131n temel bile\u015fenleri: MUA, MSA, MTA, al\u0131c\u0131 MTA<\/h2>\n<p>Te\u015fhise ba\u015flamadan \u00f6nce ak\u0131\u015f\u0131n par\u00e7alar\u0131n\u0131 netle\u015ftirmek i\u015fleri h\u0131zland\u0131r\u0131r. Tipik bir kurumsal g\u00f6nderimde zincir \u015fu \u015fekildedir:<\/p>\n<ul>\n<li><strong>MUA (Mail User Agent)<\/strong>: Kullan\u0131c\u0131n\u0131n Outlook, mobil istemci veya webmail gibi e-posta uygulamas\u0131.<\/li>\n<li><strong>MSA (Mail Submission Agent)<\/strong>: \u0130stemcinin kimlik do\u011frulay\u0131p mesaj\u0131 \u201cg\u00f6nderime kabul eden\u201d sunucu. Genelde 587\/465 \u00fczerinden \u00e7al\u0131\u015f\u0131r.<\/li>\n<li><strong>MTA (Mail Transfer Agent)<\/strong>: Mesaj\u0131 di\u011fer sunuculara aktaran bile\u015fen. Al\u0131c\u0131 domaine g\u00f6re MX bakar, ba\u011flant\u0131 kurar, iletim dener.<\/li>\n<li><strong>Al\u0131c\u0131 MTA<\/strong>: Kar\u015f\u0131 taraf\u0131n mesaj\u0131 kabul eden SMTP sunucusu. Kabul ederse mesaj teslim zinciri al\u0131c\u0131 taraf\u0131nda devam eder.<\/li>\n<\/ul>\n<p>Hata, gecikme veya kay\u0131p iddias\u0131nda ilk soru \u015fudur: Mesaj zincirin neresinde durdu? Bunu anlaman\u0131n en iyi yolu \u201czaman damgas\u0131 + mesaj kimli\u011fi + SMTP sonucu\u201d \u00fc\u00e7l\u00fcs\u00fcn\u00fc bulmakt\u0131r.<\/p>\n<h2>\u0130lk triage: Sorunu s\u0131n\u0131fland\u0131r\u0131n<\/h2>\n<p>Olay\u0131 h\u0131zl\u0131 s\u0131n\u0131fland\u0131rmak, yanl\u0131\u015f y\u00f6nde saatler harcamay\u0131 engeller. Kullan\u0131c\u0131dan veya talep kayd\u0131ndan \u015fu bilgileri toplay\u0131n:<\/p>\n<ul>\n<li>G\u00f6nderen adresi, al\u0131c\u0131 adresi, tarih-saat (zaman dilimi dahil).<\/li>\n<li>Konu sat\u0131r\u0131 ve m\u00fcmk\u00fcnse mesaj\u0131n Message-ID de\u011feri.<\/li>\n<li>Hata mesaj\u0131 var m\u0131? Bounce geldiyse tam metni istenmeli.<\/li>\n<li>Sorun tek al\u0131c\u0131da m\u0131, tek domaine mi, herkeste mi?<\/li>\n<li>\u0130stemci \u201cg\u00f6nderildi\u201d mi diyor, yoksa \u201cg\u00f6nderilemedi\u201d mi?<\/li>\n<\/ul>\n<p>Bu bilgilerle sorunu genellikle \u015fu s\u0131n\u0131flardan birine yerle\u015ftirebilirsiniz: g\u00f6nderim kabul edilmedi (submission), mesaj kuyrukta bekliyor (queue), kar\u015f\u0131 taraf ge\u00e7ici reddediyor (4xx), kal\u0131c\u0131 reddediyor (5xx), teslim edildi ama kullan\u0131c\u0131 g\u00f6rm\u00fcyor (al\u0131c\u0131 taraf kural\/karantina), ya da mesaj yanl\u0131\u015f adrese y\u00f6nleniyor.<\/p>\n<h2>Mail queue (kuyruk) okumak: Gecikmenin haritas\u0131<\/h2>\n<p>Kuyruk, MTA\u2019n\u0131n teslim edemedi\u011fi mesajlar\u0131 yeniden denemek \u00fczere tuttu\u011fu yerdir. Bir gecikme \u015fikayetinde kuyruk kontrol\u00fc, \u201cproblem \u015fu an devam ediyor mu?\u201d sorusuna en h\u0131zl\u0131 cevab\u0131 verir.<\/p>\n<h3>Kuyrukta bak\u0131lacak temel alanlar<\/h3>\n<ul>\n<li><strong>Queue ID<\/strong>: MTA\u2019n\u0131n mesaj\u0131 takip etmek i\u00e7in verdi\u011fi kimlik. Loglarda ana anahtard\u0131r.<\/li>\n<li><strong>Al\u0131c\u0131 domain\/host<\/strong>: Mesaj\u0131n gitmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131 hedef.<\/li>\n<li><strong>Ya\u015f (age)<\/strong>: Mesaj\u0131n kuyrukta ne kadar s\u00fcredir bekledi\u011fi.<\/li>\n<li><strong>Son deneme sonucu<\/strong>: Hangi SMTP hata kodu\/mesaj\u0131 ile ertelendi\u011fi.<\/li>\n<li><strong>Sonraki deneme zaman\u0131<\/strong>: MTA\u2019n\u0131n backoff politikas\u0131na g\u00f6re.<\/li>\n<\/ul>\n<h3>Gecikme t\u00fcrlerine g\u00f6re kuyruk i\u015faretleri<\/h3>\n<ul>\n<li><strong>Hedef host\u2019a ba\u011flanamama<\/strong>: DNS\/rota\/firewall\/TCP 25 engeli gibi a\u011f konular\u0131 s\u0131k g\u00f6r\u00fcl\u00fcr.<\/li>\n<li><strong>4xx ile ertelenme<\/strong>: Kar\u015f\u0131 taraf \u201c\u015fu an de\u011fil, sonra dene\u201d diyor olabilir; ge\u00e7ici rate limit, greylisting, yo\u011funluk veya policy olabilir.<\/li>\n<li><strong>Local hatalar<\/strong>: Disk dolu, s\u00fcre\u00e7 durmu\u015f, TLS k\u00fct\u00fcphanesi sorunu, DNS resolver problemi gibi yerel altyap\u0131 sorunlar\u0131 kuyrukta birikir.<\/li>\n<\/ul>\n<p>Kuyruk analizinin kritik taraf\u0131 \u015fudur: Tek bir al\u0131c\u0131 domaine giden mesajlar m\u0131 birikiyor, yoksa t\u00fcm d\u0131\u015f d\u00fcnyaya m\u0131? E\u011fer t\u00fcm d\u0131\u015f d\u00fcnyaya birikiyorsa sorun genellikle yerel a\u011f\/DNS\/\u00e7\u0131k\u0131\u015f kural\u0131 veya g\u00f6nderim servisi taraf\u0131ndad\u0131r. Tek domaine birikiyorsa kar\u015f\u0131 taraf davran\u0131\u015f\u0131, hedefin rate limit uygulamas\u0131 veya hedefe \u00f6zel itibar\/policy konular\u0131 daha olas\u0131d\u0131r.<\/p>\n<h2>SMTP loglar\u0131n\u0131 okumak: \u201cNe oldu?\u201d sorusunun kan\u0131t\u0131<\/h2>\n<p>SMTP loglar\u0131, iki sunucu aras\u0131ndaki konu\u015fman\u0131n \u00f6zetidir. \u00c7o\u011fu log format\u0131 farkl\u0131 olsa da mant\u0131k ayn\u0131d\u0131r: ba\u011flant\u0131 kuruldu mu, EHLO\/HELO nas\u0131l, TLS oldu mu, MAIL FROM\/RCPT TO kabul edildi mi, DATA a\u015famas\u0131nda ne yan\u0131t d\u00f6nd\u00fc?<\/p>\n<h3>Loglarda arayaca\u011f\u0131n\u0131z ana olaylar<\/h3>\n<ul>\n<li><strong>Connect<\/strong>: Hedef IP\u2019ye TCP ba\u011flant\u0131s\u0131 kurulmu\u015f mu?<\/li>\n<li><strong>STARTTLS\/TLS<\/strong>: \u015eifreli oturum pazarl\u0131\u011f\u0131 olmu\u015f mu, ba\u015far\u0131s\u0131z m\u0131?<\/li>\n<li><strong>MAIL FROM<\/strong>: Zarf g\u00f6nderen (envelope-from) kabul edilmi\u015f mi?<\/li>\n<li><strong>RCPT TO<\/strong>: Al\u0131c\u0131 kabul edilmi\u015f mi? Reddedildiyse kod ve gerek\u00e7e burada g\u00f6r\u00fcn\u00fcr.<\/li>\n<li><strong>DATA \/ 250 queued<\/strong>: Mesaj i\u00e7eri\u011fi g\u00f6nderildikten sonra kar\u015f\u0131 taraf \u201ckabul ettim\u201d dedi mi? \u201c250 queued\u201d benzeri bir yan\u0131t, kar\u015f\u0131 taraf\u0131n art\u0131k sorumlulu\u011fu ald\u0131\u011f\u0131n\u0131 g\u00f6sterir.<\/li>\n<\/ul>\n<p>\u00d6nemli bir n\u00fcans: Baz\u0131 reddetmeler RCPT a\u015famas\u0131nda olurken baz\u0131lar\u0131 DATA a\u015famas\u0131nda olur. DATA\u2019da gelen reddetme genellikle i\u00e7erik\/kimlik do\u011frulama\/policy de\u011ferlendirmesinin mesaj\u0131 g\u00f6rd\u00fckten sonra yap\u0131ld\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnd\u00fcr\u00fcr. Bu ayr\u0131m, yanl\u0131\u015f te\u015fhisi \u00f6nler.<\/p>\n<h2>4xx ve 5xx sonu\u00e7lar\u0131n\u0131 do\u011fru yorumlay\u0131n<\/h2>\n<p>SMTP hata kodlar\u0131 kabaca ikiye ayr\u0131l\u0131r: ge\u00e7ici (4xx) ve kal\u0131c\u0131 (5xx). Ancak tek ba\u015f\u0131na \u201c4xx ge\u00e7icidir\u201d demek yeterli de\u011fildir; tekrar deneme stratejisi ve operasyon aksiyonu gerekir.<\/p>\n<h3>4xx (ge\u00e7ici) oldu\u011funda<\/h3>\n<ul>\n<li>Mesaj genellikle kuyrukta bekler ve yeniden denenir.<\/li>\n<li>Kar\u015f\u0131 taraf\u0131n rate limit, ge\u00e7ici blok, yo\u011funluk veya greylisting benzeri bir politika uygulamas\u0131 s\u00f6z konusu olabilir.<\/li>\n<li>Yerel tarafta DNS zaman a\u015f\u0131m\u0131 veya hedefe eri\u015fim problemi de 4xx gibi g\u00f6r\u00fcnebilir (uygulama mesaj\u0131na g\u00f6re).<\/li>\n<\/ul>\n<p>Operasyonel yakla\u015f\u0131m: Ayn\u0131 domaine giden t\u00fcm mesajlarda m\u0131 4xx var? IP veya domain bazl\u0131 bir limit mi? Kuyruk ya\u015flan\u0131yor mu? Gecikme i\u015f etkiliyor mu? Bu sorulara g\u00f6re ya beklenir, ya da hedefle ileti\u015fime ge\u00e7ilir, ya da g\u00f6nderim davran\u0131\u015f\u0131 (hacim\/s\u0131kl\u0131k) g\u00f6zden ge\u00e7irilir.<\/p>\n<h3>5xx (kal\u0131c\u0131) oldu\u011funda<\/h3>\n<ul>\n<li>Mesaj hemen bounce olabilir veya teslim zinciri durur.<\/li>\n<li>Yanl\u0131\u015f al\u0131c\u0131 adresi, policy reddi, kimlik do\u011frulama uyumsuzlu\u011fu, i\u00e7erik engeli gibi nedenler olabilir.<\/li>\n<\/ul>\n<p>Operasyonel yakla\u015f\u0131m: 5xx\u2019te \u201ctekrar deneyeyim belki olur\u201d genelde do\u011fru strateji de\u011fildir. Logtaki gerek\u00e7eyi okuyup k\u00f6k nedeni d\u00fczeltmek gerekir. E\u011fer \u201cuser unknown\u201d ise adres do\u011frulan\u0131r. E\u011fer policy ise g\u00f6nderim kimli\u011fi ve teknik yap\u0131 g\u00f6zden ge\u00e7irilir.<\/p>\n<h2>Mesaj izi olu\u015fturma: Message-ID, Queue ID ve zaman \u00e7izelgesi<\/h2>\n<p>Birden fazla sistemin devreye girdi\u011fi yap\u0131larda ayn\u0131 mesaja ait farkl\u0131 kimlikler olabilir. \u0130yi bir pratik, olay\u0131 tek bir zaman \u00e7izelgesine oturtmakt\u0131r:<\/p>\n<ol>\n<li>Kullan\u0131c\u0131 istemcisinde g\u00f6nderim zaman\u0131 (yerel saat).<\/li>\n<li>MSA\u2019nin mesaj\u0131 kabul etti\u011fi zaman ve verdi\u011fi ilk iz (log kayd\u0131).<\/li>\n<li>MTA\u2019n\u0131n kuyruk kimli\u011fi ve ilk teslim denemesi.<\/li>\n<li>Kar\u015f\u0131 taraf\u0131n 250 kabul\u00fc veya 4xx\/5xx reddi.<\/li>\n<li>Varsa bounce mesaj\u0131n\u0131n geldi\u011fi zaman.<\/li>\n<\/ol>\n<p>Message-ID \u00e7o\u011fu zaman istemci veya sunucu taraf\u0131ndan \u00fcretilir ve ba\u015fl\u0131klarda ta\u015f\u0131n\u0131r. Queue ID ise MTA\u2019ya \u00f6zg\u00fcd\u00fcr. \u0130kisini ili\u015fkilendirebildi\u011finizde, \u201cmail \u00e7\u0131kt\u0131 m\u0131?\u201d tart\u0131\u015fmas\u0131 biter; kan\u0131t \u00fczerinden konu\u015fulur.<\/p>\n<h2>DNS ve a\u011f kaynakl\u0131 gecikmeleri ay\u0131rt etme<\/h2>\n<p>SMTP sorunlar\u0131n\u0131n \u00f6nemli k\u0131sm\u0131 asl\u0131nda SMTP\u2019den \u00f6nce ba\u015flar: MX sorgusu, hedef IP\u2019ye rota, TCP ba\u011flant\u0131s\u0131, TLS el s\u0131k\u0131\u015fmas\u0131. Bu katmanlardaki problemler genellikle \u201ctimeout\u201d ve uzun kuyruk beklemeleri olarak g\u00f6r\u00fcn\u00fcr.<\/p>\n<h3>Tipik belirtiler<\/h3>\n<ul>\n<li><strong>DNS gecikmesi<\/strong>: MX\/AAAA\/A sorgular\u0131 yava\u015fsa teslim denemeleri uzar, kuyruk ya\u015flan\u0131r.<\/li>\n<li><strong>TCP 25 k\u0131s\u0131t\u0131<\/strong>: Baz\u0131 a\u011flarda \u00e7\u0131k\u0131\u015f 25 kapal\u0131d\u0131r; bu durumda MTA hedefe ba\u011flanamaz.<\/li>\n<li><strong>TLS sorunlar\u0131<\/strong>: Sertifika\/uyumluluk sorunlar\u0131 baz\u0131 hedeflerde ba\u015far\u0131s\u0131z el s\u0131k\u0131\u015fmaya yol a\u00e7abilir.<\/li>\n<\/ul>\n<p>Bu t\u00fcr problemlerde loglar genellikle \u201cconnect timed out\u201d, \u201cno route\u201d, \u201cTLS handshake failed\u201d gibi a\u00e7\u0131k ifadeler ta\u015f\u0131r. \u00c7\u00f6z\u00fcm, uygulama ayar\u0131 de\u011fi\u015ftirmekten ziyade a\u011f\/DNS altyap\u0131s\u0131n\u0131 d\u00fczeltmektir.<\/p>\n<h2>\u201cTeslim edildi ama g\u00f6r\u00fcnm\u00fcyor\u201d senaryosu<\/h2>\n<p>Bazen g\u00f6nderen MTA loglar\u0131nda 250 kabul g\u00f6r\u00fcn\u00fcr, yani kar\u015f\u0131 taraf mesaj\u0131 alm\u0131\u015ft\u0131r. Buna ra\u011fmen al\u0131c\u0131 \u201cmail gelmedi\u201d diyebilir. Bu noktada sorun art\u0131k \u00e7o\u011fu zaman al\u0131c\u0131 taraf\u0131n i\u00e7 ak\u0131\u015f\u0131ndad\u0131r: karantina, spam klas\u00f6r\u00fc, kurallar, alias\/forward kar\u0131\u015f\u0131kl\u0131\u011f\u0131, yanl\u0131\u015f hedef posta kutusu, ya da al\u0131c\u0131 taraf ar\u015fivleme\/filtreleme.<\/p>\n<p>G\u00f6nderen taraf i\u00e7in yap\u0131lacak en do\u011fru \u015fey, ilgili SMTP oturum kayd\u0131n\u0131 ve al\u0131c\u0131 taraf\u0131n verdi\u011fi kabul yan\u0131t\u0131n\u0131 payla\u015fmakt\u0131r. Bu, kar\u015f\u0131 taraf\u0131n kendi loglar\u0131nda arama yapmas\u0131n\u0131 kolayla\u015ft\u0131r\u0131r.<\/p>\n<h2>Standart bir operasyon kontrol listesi<\/h2>\n<p>A\u015fa\u011f\u0131daki liste, olay y\u00f6netiminde tekrar tekrar i\u015finize yarar:<\/p>\n<ol>\n<li>Olay kapsam\u0131n\u0131 belirleyin: tek kullan\u0131c\u0131 m\u0131, tek domain mi, genel mi?<\/li>\n<li>Mesaj\u0131n kimli\u011fini \u00e7\u0131kar\u0131n: Message-ID veya konu+tarih+saat.<\/li>\n<li>Kuyru\u011fu kontrol edin: birikme var m\u0131, hangi hedeflerde?<\/li>\n<li>SMTP loglar\u0131n\u0131 inceleyin: connect, TLS, MAIL FROM, RCPT TO, DATA sonu\u00e7lar\u0131.<\/li>\n<li>Hata kodunu s\u0131n\u0131fland\u0131r\u0131n: 4xx mi 5xx mi, a\u015famas\u0131 neresi?<\/li>\n<li>Zaman \u00e7izelgesi olu\u015fturun: nerede durdu\u011funu kan\u0131tla g\u00f6sterin.<\/li>\n<li>Gerekli aksiyonu se\u00e7in: bekle\/yeniden dene, yap\u0131land\u0131rmay\u0131 d\u00fczelt, a\u011f\/DNS\u2019i d\u00fczelt, hedefle ileti\u015fime ge\u00e7.<\/li>\n<\/ol>\n<h2>Sonu\u00e7: Kal\u0131c\u0131 \u00e7\u00f6z\u00fcm i\u00e7in \u00f6l\u00e7\u00fclebilirlik ve do\u011fru platform se\u00e7imi<\/h2>\n<p>E-posta sorunlar\u0131 \u00e7o\u011fu zaman \u201ctek seferlik\u201d gibi g\u00f6r\u00fcnse de, tekrar eden gecikme ve teslimat problemleri \u015firket i\u00e7i i\u015f s\u00fcre\u00e7lerini do\u011frudan etkiler. Bu y\u00fczden kuyruk ve log \u00fczerinden kan\u0131ta dayal\u0131 te\u015fhis, sadece teknik bir beceri de\u011fil, operasyonel bir gerekliliktir.<\/p>\n<p>E\u011fer kurumunuzda e-posta ak\u0131\u015f\u0131n\u0131 daha y\u00f6netilebilir hale getirmek istiyorsan\u0131z, mail sunucusu taraf\u0131nda izlenebilirlik (log tutma, hata ayr\u0131\u015ft\u0131rma), do\u011fru DNS yap\u0131land\u0131rmas\u0131 ve d\u00fczenli bak\u0131m s\u00fcre\u00e7leri kritik rol oynar. MX1Mail gibi kurumsal e-posta hizmetlerine ge\u00e7i\u015f veya mevcut yap\u0131y\u0131 iyile\u015ftirme plan\u0131 yaparken de, bu yaz\u0131daki yakla\u015f\u0131m\u0131 kullanarak \u201csorun nerede olu\u015fuyor?\u201d sorusunu h\u0131zl\u0131ca yan\u0131tlayabilir ve aksiyonlar\u0131 \u00f6nceliklendirebilirsiniz.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Teslimat gecikmesi, bounce ve kay\u0131p e-posta \u015fikayetlerinde kuyruk, SMTP loglar\u0131 ve mesaj izi \u00fczerinden k\u00f6k neden analizi i\u00e7in pratik bir y\u00f6ntem.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[188],"tags":[396,394,277],"class_list":["post-157","post","type-post","status-publish","format-standard","hentry","category-e-posta-yonetimi","tag-mail-queue","tag-smtp-loglari","tag-teslim-edilebilirlik"],"_links":{"self":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts\/157","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=157"}],"version-history":[{"count":0,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts\/157\/revisions"}],"wp:attachment":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/media?parent=157"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/categories?post=157"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/tags?post=157"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}