📧
Xavfsizlik

Xatlaringiz spamga tushyapti: Gmail, Outlook va Yahoo talablari

04.11.2026
← Barcha maqolalar

Hisob-faktura yubordingiz, mijoz esa "hech narsa kelmadi" deydi: xat uning Gmail qutisida spamda yotgan yoki rad etilgan. Sababi — Gmail, Yahoo va Outlook jo'natuvchilarga qo'ygan qat'iy talablar. Endi autentifikatsiyasiz xatlar to'g'ridan-to'g'ri rad etiladi. Quyida bu talablar nimadan iboratligini, muammoni qanday aniqlashni va korporativ pochtangizni qanday tartibga keltirishni tushuntiramiz.

Muammo qanday namoyon bo'ladi

Eng ko'p uchraydigan belgi shuki, xatlar faqat ayrim qabul qiluvchilarga yetib bormaydi: korporativ manzillarga normal boradi, lekin Gmail yoki Hotmail foydalanuvchilari ularni spamda topadi. Ba'zan 550 bilan boshlanadigan kodli qaytgan xat keladi yoki Gmail xat ustida "yuboruvchi tasdiqlanmagan" degan ogohlantirish ko'rsatadi. Agar bunday holatlar birdaniga ko'paygan bo'lsa, sababi katta ehtimol bilan domeningizning autentifikatsiya sozlamalarida.

Gmail, Yahoo va Outlook nimani talab qiladi

2024-yil fevralidan boshlab Gmail va Yahoo barcha jo'natuvchilardan bir nechta asosiy shartni talab qiladi. Domeningizda SPF yoki DKIM sozlangan bo'lishi, server IP manzilining to'g'ri va teskari DNS yozuvi (PTR) mos kelishi, xatlar TLS shifrlash orqali uzatilishi kerak. Qabul qiluvchilar spam deb belgilagan xatlar ulushi 0,3% dan oshmasligi lozim, amalda esa 0,1% dan past ushlab turish tavsiya etiladi. Xat RFC 5322 standartiga mos tuzilgan bo'lishi ham shart.

Kuniga Gmail'ga 5000 dan ortiq xat yuboradigan ommaviy jo'natuvchilarga talab yanada qattiq. Ularda SPF ham, DKIM ham bo'lishi, DMARC yozuvi kamida p=none siyosati bilan e'lon qilinishi va "From" maydonidagi domen SPF yoki DKIM domeni bilan mos kelishi (alignment) kerak. Marketing xatlarida RFC 8058 bo'yicha bir bosishda obunadan chiqish (List-Unsubscribe-Post sarlavhasi) bo'lishi va obunadan chiqish so'rovi ikki kun ichida bajarilishi lozim. 2025-yil noyabridan Gmail bu talablarga javob bermaydigan trafikni faqat spamga tushirish bilan cheklanmay, uni rad eta boshladi.

Microsoft ham shu yo'ldan bordi: 2025-yil 5-maydan Outlook.com, Hotmail va Live manzillariga kuniga 5000 dan ortiq xat yuboruvchilar SPF, DKIM va mos keluvchi DMARC (kamida p=none) yozuviga ega bo'lishi kerak. Talabga javob bermagan xatlar 550 5.7.515 kodi bilan qaytariladi.

TalabBarcha jo'natuvchilarKuniga 5000+ xat
SPF yoki DKIMIkkalasidan biriIkkalasi ham
DMARCTavsiya etiladiMajburiy, kamida p=none
PTR va TLSMajburiyMajburiy
Spam darajasi0,3% dan past0,3% dan past
Bir bosishda obunadan chiqishYo'qMarketing xatlarida majburiy

Xat sarlavhalarini qanday tekshirish mumkin

Eng ishonchli diagnostika — o'z xatingizni Gmail qutisiga yuborib, uning texnik sarlavhalarini ko'rish. Xatni ochib, uch nuqta menyusidan "Show original" bandini tanlang: sahifa yuqorisida SPF, DKIM va DMARC natijalari ko'rsatiladi. Uchalasi ham pass bo'lishi kerak, biri fail, softfail yoki none bo'lsa, muammo aynan shu yerda.

Authentication-Results: mx.google.com;
  dkim=pass header.d=kompaniya.uz header.s=dkim;
  spf=pass smtp.mailfrom=info@kompaniya.uz;
  dmarc=pass (p=NONE) header.from=kompaniya.uz

DNS yozuvlari qanday ko'rinadi

Uchala mexanizm ham domeningizning DNS zonasidagi TXT yozuvlar orqali ishlaydi. SPF qaysi serverlar sizning nomingizdan xat yuborishi mumkinligini sanab beradi, DKIM har bir xatga kriptografik imzo qo'yadi va ochiq kalit DNS'da selektor nomi ostida saqlanadi. DMARC esa qabul qiluvchi serverga tekshiruv muvaffaqiyatsiz bo'lsa nima qilish kerakligini aytadi va rua manzili orqali sizga kunlik hisobotlar yuboradi.

kompaniya.uz.              TXT  "v=spf1 a mx ip4:203.0.113.10 ~all"
dkim._domainkey.kompaniya.uz.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.kompaniya.uz.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@kompaniya.uz; adkim=r; aspf=r"

Domen uchun faqat bitta SPF yozuvi bo'lishi kerak, CRM yoki tarqatma xizmatlari mavjud yozuvga include orqali qo'shiladi. sayt.uz serverlarida joylashgan pochta domenlari uchun SPF va DKIM avtomatik sozlanadi, lekin domeningiz DNS'i boshqa joyda boshqarilsa, bu yozuvlarni o'sha yerga qo'lda ko'chirish kerak bo'ladi.

DMARC'ni bosqichma-bosqich kuchaytirish

DMARC'ni darhol qattiq rejimga qo'ysangiz, siz bilmagan qonuniy manbalar (buxgalteriya dasturi, sayt formasi) ham to'silishi mumkin, shuning uchun uni bosqichma-bosqich joriy eting.

  1. p=none — hech narsa to'silmaydi, faqat hisobotlar yig'iladi. Bir necha hafta hisobotlarni o'qib, domeningizdan kim xat yuborayotganini aniqlang.
  2. p=quarantine — tekshiruvdan o'tmagan xatlar spamga tushadi. Avval pct=25 bilan qisman yoqib, keyin 100% ga yetkazish mumkin.
  3. p=reject — soxta xatlar butunlay rad etiladi. Domen firibgarlardan to'liq himoyalanadi.

Real misol: hisob-fakturalar nega spamga tushdi

Toshkentdagi bir ulgurji savdo kompaniyasi mijozlarga hisob-fakturalarni o'z saytidagi forma orqali yuborardi. Tizim xatni "From: mijoz@gmail.com" manzilidan, ya'ni mijozning o'z nomidan jo'natardi, domenda esa DKIM yo'q edi. Gmail bu xatni gmail.com nomidan yuborilgan soxta xat deb qabul qildi, chunki Google'ning DMARC siyosati begona serverlarga o'z nomidan xat yuborishni taqiqlaydi. Kompaniya formani "From: noreply@kompaniya.uz" va "Reply-To: mijoz manzili" ko'rinishiga o'tkazdi, DKIM'ni yoqdi va bir hafta ichida xatlar yana qutiga tusha boshladi.

Klassik xato: kontakt forma tashrif buyuruvchi nomidan yuboradi

Yuqoridagi misol juda keng tarqalgan. Ko'plab CMS plaginlari "From" maydoniga formani to'ldirgan odamning manzilini qo'yadi, chunki shunda javob berish qulay. Lekin bu aslida o'zgalar domeni nomidan xat yuborish demakdir va Gmail, Yahoo yoki Outlook kabi qat'iy DMARC siyosatiga ega domenlar uchun bunday xat albatta rad etiladi. To'g'ri yo'l doim bir xil: "From" maydonida o'z domeningizdagi manzil, tashrif buyuruvchining manzili esa "Reply-To" sarlavhasida bo'lishi kerak. Forma xatlarini autentifikatsiyali SMTP orqali yuborgan ma'qul.

Marketing xatlarini alohida ushlang

Agar kompaniyangiz hisob-faktura va shartnomalar bilan bir qatorda reklama tarqatmalari ham yuborsa, ularni bitta domendan yubormang. Tarqatmalarda shikoyatlar ko'proq bo'ladi va bu asosiy domen obro'sini tushirib, ish xatlarini ham spamga tushira boshlaydi. Marketing uchun news.kompaniya.uz kabi alohida subdomen yoki ixtisoslashgan tarqatma xizmatidan foydalaning.

Qora ro'yxatlar, yo'naltirilgan xatlar va Microsoft bloki

Ba'zan domen sozlamalari to'g'ri bo'lsa ham, server IP manzili Spamhaus kabi qora ro'yxatlarga tushib qolgan bo'ladi. Odatda sababi serverdagi buzilgan sayt orqali yuborilgan spam, shuning uchun IP manzilni vaqti-vaqti bilan tekshirib turing. Yo'naltirilgan (forward) xatlarda SPF buziladi, buni server tomonida SRS tuzatadi. Microsoft esa ba'zan butun server IP manzilini bloklaydi, xatlar S3140 kodi bilan qaytadi va bu server darajasida hal qilinadi.

Xato xabarini qanday o'qish kerak

Qaytgan xatda deyarli har doim aniq sabab yozilgan bo'ladi. Birinchi qator Outlook'dan, ikkinchisi Gmail'dan.

550 5.7.515 Access denied, sending domain kompaniya.uz does not meet the required authentication level.
550-5.7.26 This mail has been blocked because the sender is unauthenticated.

550 kodi xat butunlay rad etilganini bildiradi, 5.7.x esa xavfsizlik siyosati bilan bog'liq sababni ko'rsatadi. Birinchi xabar domeningiz Microsoft talab qilgan autentifikatsiya darajasiga yetmaganini, ikkinchisi esa Gmail xatni SPF yoki DKIM bilan tasdiqlay olmaganini aytadi. Yechim DNS yozuvlaridan boshlanadi.

Test qilish va yangi domenni "isitish"

Sozlamalarni o'zgartirgach, mail-tester kabi xizmatlarda xatingizni sinab ko'ring: ular SPF, DKIM, DMARC, PTR va qora ro'yxatlarni bitta hisobotda ko'rsatadi. Yangi domendan birdaniga minglab xat yubormang, hajmni bir necha hafta davomida asta-sekin oshiring. Agar xatlaringiz nega spamga tushayotganini aniqlay olmasangiz, sayt.uz texnik yordamiga murojaat qiling: mutaxassislar domen yozuvlari va qaytgan xat kodlarini tekshirib berishadi.

O'xshash maqolalar

🔐 SSL sertifikat monitoringi: tugash sanasini kuzatish va avto-renewal 🍪 Cookie xavfsizligi — SameSite, HttpOnly, Secure va Path sozlamalari 🗝️ SSH kalit xavfsizligi: public/private key, passphrase va ssh-agent 🛡️ API xavfsizligi: rate limiting, API key, autentifikatsiya va CORS
🌐 Til
🇺🇿 O'zbek ✓ 🇺🇿 Ўзбек 🇷🇺 Русский 🇬🇧 English