Üçünün işi necə bölünüb
| Qeyd | Nəyi yoxlayır | Zəif tərəfi |
|---|---|---|
| SPF | Məktubu gətirən serverin IP ünvanı sizin siyahınızdadırmı. | Yönləndirmədə sınır: məktub üçüncü serverdən keçəndə IP dəyişir. |
| DKIM | Məktubun özünə atılmış rəqəmsal imza domenin açarı ilə uyğun gəlirmi. | Məktubun mətni yolda dəyişdirilsə (bəzi siyahı serverləri belə edir) imza sınır. |
| DMARC | SPF və DKIM nəticəsi istifadəçinin gördüyü From ünvanı ilə uzlaşırmı. | Özü heç nə yoxlamır — yalnız o ikisinin nəticəsindən asılıdır. |
DMARC-ın rolunu ayrıca vurğulamaq lazımdır: SPF və DKIM
görünməyən sahələri yoxlayır (zərfin göndərəni və imzanın
domeni), istifadəçi isə ekranda From sətrini görür. Bu ikisi
bir-birindən fərqli ola bilər — saxta məktubların klassik üsulu məhz
budur. DMARC onları bağlayır və uzlaşmayan məktubla nə edilməli olduğunu
deyir.
SPF — kimin sizin adınıza göndərə biləcəyi
SPF adi bir TXT qeydidir:
v=spf1 ip4:203.0.113.10 -all
Tərcüməsi: «bu domendən yalnız 203.0.113.10 ünvanlı server göndərir,
qalan hamısını rədd edin». Mexanizmlər əlavə oluna bilər —
include: başqa domenin siyahısını çəkir, a və
mx isə domenin öz qeydlərini işlədir.
Bir domendə yalnız BİR SPF qeydi
Yeni göndərən əlavə edərkən ən çox edilən səhv ikinci SPF qeydi
yaratmaqdır. Standart buna icazə vermir: iki qeyd görən yoxlayıcı
permerror qaytarır və hər ikisini nəzərə
almır. Yəni səhv «yarım işləmir» — ümumiyyətlə işləmir. Düzgün yol
mexanizmləri tək sətirdə birləşdirməkdir.
10 DNS sorğusu həddi
RFC 7208 SPF-in yoxlanması zamanı 10-dan çox DNS sorğusuna icazə vermir.
Hər include, a, mx,
ptr və exists bir sorğudur, üstəlik
include-un içindəki include-lar da hesaba düşür. Hədd aşılanda nəticə
yenə permerror olur — qeyd qısa görünsə də tamamilə sınır.
Bu, üç-dörd xidmət (poçt, CRM, bülleten, faktura) əlavə edən şirkətdə
asanlıqla baş verir.
-all və ~all fərqi
Zəncirin sonundakı işarə «siyahıda olmayan göndərənlə nə edilsin» sualının cavabıdır:
-
-all— sərt rədd (hardfail). Siyahıda olmayan hər kəs rədd edilməlidir. -
~all— yumşaq rədd (softfail). «Şübhəlidir, amma buraxın» deməkdir; məktub adətən spam qovluğuna düşür.
-all daha güclüdür, amma bir şərtlə: göndərən siyahınız tam
olmalıdır. Natamam siyahı ilə ən çox zərər çəkən saytdakı əlaqə
formasıdır — o, çox vaxt hostinq serverindən göndərir və SPF-ə
yazılmır. Nəticə: sayt formu «işləyir», məktub isə heç yerə çatmır.
Siyahını tam bilməyincə ~all ilə başlamaq təhlükəsizdir.
DKIM — məktubun üstündəki imza
DKIM-də gizli açar poçt serverində qalır və hər gedən məktuba imza atır; açıq açar isə DNS-də dərc olunur. Qəbul edən tərəf imzanı açıq açarla yoxlayır. Qeyd selektor adı ilə tapılır:
mailora1._domainkey.sirket.az TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."SPF-dən əsas fərqi budur: imza məktubun özündədir, ona görə məktub yönləndiriləndə də sağ qalır. SPF isə həmin anda sınır, çünki göndərən IP artıq başqasıdır.
Ən pis hal: qeyd var, imza yoxdur
DKIM qeydinin DNS-də olması onun işlədiyini sübut etmir. Açar dərc oluna bilər, poçt serveri isə onu tapmayıb məktubu imzasız göndərə bilər. Bu vəziyyət DKIM-in ümumiyyətlə olmamasından pisdir: domen «mən imzalayıram» deyir, imzasız məktub isə şübhəli görünür. Bu, bizim öz sistemimizdə baş verib — ayrıca yazıda təfərrüatı ilə göstərilib.
DMARC — nəticəni From ünvanı ilə bağlayır
Ən sadə DMARC qeydi belədir:
_dmarc.sirket.az TXT "v=DMARC1; p=none; rua=mailto:dmarc@sirket.az"-
p=none— heç nə kəsilmir, yalnız hesabat toplanır. -
p=quarantine— uzlaşmayan məktub spam qovluğuna göndərilir. -
p=reject— uzlaşmayan məktub ümumiyyətlə qəbul edilmir. -
rua— gündəlik hesabatların gələcəyi ünvan.
Ən sürətli səhv: ilk gündən p=reject yazmaq. O an
unutduğunuz hər göndərən — faktura proqramı, sayt forması, filialın
serveri — səssizcə kəsilir və siz bunu müştəri zəng edənə qədər
bilmirsiniz. Ona görə sıra həmişə eynidir: none, sonra quarantine, sonra
reject.
Addım-addım: üçünü təhlükəsiz qurmaq
-
Göndərənlərin siyahısını çıxarın
Sizin adınıza kim məktub göndərir: poçt sistemi, saytdakı əlaqə forması, CRM, faktura və ya bülleten xidməti. Bu siyahı natamam qalarsa, sonrakı hər addım unudulmuş göndərənin məktubunu kəsəcək.
-
BİR SPF qeydi yazın
Domendə yalnız bir SPF qeydi ola bilər. Yeni göndərən əlavə edərkən ikinci qeyd yaratmayın — mövcud qeydə əlavə edin. İki qeyd olanda yoxlama permerror verir və hər ikisi nəzərə alınmır.
-
DNS sorğu sayını yoxlayın
SPF-in yoxlanması 10 DNS sorğusundan çox tələb edərsə, qeyd tamamilə sınır. Hər include, a, mx və exists mexanizmi sorğu sayılır və include-un içindəki include də hesaba düşür.
-
DKIM açarını dərc edin və imzanı yoxlayın
Açarı selektor qeydinə yazın, sonra test məktubunun başlıqlarında DKIM-Signature sətrinin həqiqətən olduğuna baxın. Açarın DNS-də olması imzanın atıldığını sübut etmir — bu iki hal bir-birindən asılı deyil.
-
DMARC-ı p=none ilə başladın
İlk qeyd belə olur: v=DMARC1; p=none; rua=mailto:dmarc@sirket.az. p=none heç bir məktubu kəsmir, yalnız hesabat toplayır. Birbaşa p=reject yazmaq öz poçtunu kəsməyin ən sürətli yoludur.
-
Hesabatları oxuyun
İki-dörd həftə ərzində gələn hesabatlarda sizin adınıza göndərən bütün mənbələr görünür. Burada unudulmuş sistemlər üzə çıxır: köhnə faktura proqramı, saytdakı forma, filialın öz serveri.
-
Siyasəti tədricən sərtləşdirin
Hesabatlarda yalnız tanıdığınız mənbələr qalanda p=quarantine, sonra p=reject-ə keçin. SPF-i də eyni məntiqlə ~all-dan -all-a keçirmək olar. Hər dəyişiklikdən sonra bir neçə gün hesabatlara baxın.
Üç domendə ölçdüklərimiz
Aşağıdakı dəyərlər 2026-08-18-də ictimai DNS sorğuları ilə alınıb. Onlar keyfiyyət hökmü deyil — hər sətri özünüz yoxlaya bilərsiniz və xidmətlər qurğularını istənilən vaxt dəyişə bilər.
| Göstərici | Zoho | Yandex | Mailora |
|---|---|---|---|
| SPF zəncirinin sonu | ~all | ~all | -all |
| SPF-in tələb etdiyi DNS sorğusu (hədd 10) | 2 | 4 | 1 |
| DKIM açar uzunluğu | 1024 bit | 1024 bit | 2048 bit |
| DKIM selektoru | zmail | hər domenə ayrı, iki ədəd |
Bu rəqəmlərin praktik mənası:
- Sorğu sayı sizə qalan yeri göstərir. Poçt sisteminiz 4 sorğu işlədirsə, öz göndərənləriniz üçün 6 yer qalır; 1 işlədirsə, 9 qalır. Hədd aşılanda SPF tamamilə sınır.
- 1024 bit sınıq deyil — Google-un tələb etdiyi minimumdur və məktublar qəbul edilir. 2048 sadəcə uzunmüddətli ehtiyatdır.
- Selektorun hər müştəridə eyni olması təhlükəsizlik problemi deyil, amma açar rotasiyasını çətinləşdirir: bir açarı dəyişmək bütün domenlərə toxunur. Mailora-da hər domenə ayrıca cüt (mailora1 və mailora2) verilir, ona görə rotasiya kəsintisiz aparılır.
Google-un göndərən tələbləri
1 fevral 2024-dən Google Gmail-ə göndərənlərdən minimum dəst tələb edir: SPF və ya DKIM, düzgün irəli və geri DNS (PTR), TLS ilə ötürmə, RFC 5322 formatına uyğun başlıqlar, ən azı 1024 bitlik DKIM açarı və spam şikayətlərinin aşağı nisbəti. Bunlar «tövsiyə» deyil — qarşılanmayanda məktub sadəcə qəbul edilmir.
Bizim vəziyyətimiz, dürüst yazılmış: sadalananların hamısını qarşılayırıq — SPF və DKIM ikisi də var, forward və reverse DNS uyğundur, Gmail-ə ötürmə TLSv1.3 ilə gedir, DKIM açarı 2048 bitdir. Şikayət nisbətini isə ölçmürük: Postmaster Tools qeydiyyatımız hələ yoxdur. Ölçmədiyimiz göstərici barədə rəqəm yazmırıq.
Tez-tez rast gəlinən səhvlər
- Domendə iki SPF qeydi — nəticə permerror, hər ikisi boşa çıxır.
- Yeni xidmət əlavə edərkən include yığmaq və 10 sorğu həddini aşmaq.
- Göndərən siyahısı natamam ikən -all yazmaq — sayt forması birinci qurban olur.
- DKIM açarını dərc edib imzanın atıldığını yoxlamamaq.
- Açarı DNS-ə yapışdırarkən sətir sonlarının kəsilməsi — qeyd görünür, yoxlama isə uğursuz olur.
- Birbaşa p=reject ilə başlamaq.
- DMARC-a rua ünvanı yazmamaq: siyasət var, amma nəyin kəsildiyini heç kim görmür.
Tez-tez verilən suallar
Üçü də mütləqdirmi, yoxsa biri kifayət edirmi?
Google-un göndərən tələbləri (1 fevral 2024-dən) SPF və ya DKIM-dən ən azı birini tələb edir. Praktikada isə ikisi də lazımdır: SPF yönləndirmədə sınır (məktub üçüncü serverdən keçəndə göndərən IP dəyişir), DKIM isə imza məktubun özündə olduğu üçün sağ qalır. DMARC olmadan isə heç kim sizə kimin adınızdan göndərdiyini bildirməyəcək.
İki SPF qeydim var, ikisi də düzgün görünür. Problem nədir?
Standart bir domendə yalnız bir SPF qeydinə icazə verir. İkisi olanda yoxlayan tərəf permerror qaytarır və nəticə heç bir qeydin lehinə olmur — yəni hər ikisi boşa çıxır. Həll: hər iki qeydin mexanizmlərini bir sətirdə birləşdirmək və ikincisini silmək.
10 sorğu həddini aşdığımı necə bilim?
Hər include, a, mx, ptr və exists mexanizmi bir sorğudur, üstəlik include-un içindəki include-lar da sayılır — ona görə qeyd qısa görünsə də hədd aşıla bilər. 2026-08-18-də ölçdüyümüzdə Yandex-in zənciri 4, Zoho-nunku 2 sorğu tələb edirdi. Yoxlama alətimiz sorğu sayını hesablayır.
-all yazsam nə risk var?
-all «siyahıda olmayan hər kəsi rədd et» deməkdir. Siyahı natamamdırsa, unudulmuş göndərənin məktubu kəsilir — ən çox rast gəlinən qurban saytdakı əlaqə formasıdır, çünki o, çox vaxt başqa serverdən göndərir. 2026-08-18-də yoxladığımızda həm Zoho, həm Yandex daha yumşaq olan ~all işlədirdi. Mailora -all işlədir, çünki göndərən siyahısı bizim nəzarətimizdədir; sizin öz siyahınızı tam bilməyincə ~all ilə başlamaq daha təhlükəsizdir.
1024 bitlik DKIM açarı pisdirmi?
Xeyr, sınıq deyil — Google-un tələb etdiyi minimumdur və məktublar qəbul edilir. 2048 bit sadəcə daha uzun müddətə hesablanmış ehtiyatdır. 2026-08-18-də ölçdüyümüzdə Zoho və Yandex 1024 bit dərc edirdi, Mailora 2048 bit işlədir. Bu, keyfiyyət hökmü deyil, ölçülmüş fərqdir.
DMARC hesabatları hara gəlir və onları oxumaq çətindirmi?
Hesabatlar rua sahəsində göstərdiyiniz ünvana XML formatında gəlir və əl ilə oxumaq rahat deyil. Ayrıca qutu yaradın — Mailora-da qutu sayı limitsiz olduğu üçün bu, əlavə xərc yaratmır. Hesabatların mahiyyəti sadədir: sizin adınıza hansı IP-lərdən göndərilib və həmin məktublar yoxlamadan keçibmi.
Üç qeydi indi yoxlayın
Alətlər qeydləri ictimai DNS-dən oxuyur, sorğu sayını hesablayır və nəticəni azərbaycanca izah edir. Qeydiyyat tələb olunmur, yoxlanılan domen saxlanılmır. Mailora müştərisi olduqda isə eyni yoxlama arxa planda daim aparılır — qeyd sonradan pozulsa, paneldən xəbər tutursunuz.