Ինչպես ուղարկել էլ. նամակներ ձեր հավելվածից (և հասնել մուտքարկղ)

Հավելվածից էլ. նամակները հուսալի ուղարկելու համար օգտագործեք էլ. նամակների ուղարկման մատակարար, այլ ոչ թե ձեր սեփական փոստարկղը, ուղարկեք ձեր սեփական դոմենի հասցեից և ավելացրեք DNS գրառումները, որոնք տալիս է մատակարարը, որպեսզի SPF, DKIM և DMARC բոլորն անցնեն։ Պահեք գործարքային նամակները՝ գաղտնաբառի վերականգնում, կտրոններ, հաստատումներ, առանձին մարքեթինգային նամակներից, ուղարկեք յուրաքանչյուրը միայն նրանց, ովքեր դա սպասում են, և մշակեք վերադարձված նամակները և չեղարկումները։ Նախ ճիշտ կարգավորեք նույնականացումը. այն էլ.-նամակների սպամ ընկնելու ամենատարածված պատճառն է։

Գործարքային և մարքեթինգային նամակ

Այս երկու տեսակ նամակները կոդում նման են, բայց ներմուծող համակարգերը և օրենքը դրանց տարբեր են վերաբերվում։

Պահեք դրանք առանձին։ Եթե մարքեթինգային արշավը սպամի բողոքներ է ստանում, չեք ուզում, որ նույն հոսքի գաղտնաբառի վերականգնումները տուժեն։ Սովորական մոտեցումն է՝ առանձին ենթադոմեյններ, օրինակ՝ mail.example.com հաշիվների նամակների համար և news.example.com նորությունների տառերի համար։ Որոշ մատակարարներ դրանք ներքին առումով էլ են բաժանում։ Օրինակ՝ Postmark-ը նկարագրում է իր գործարքային և հեռարձակման «հաղորդագրության հոսքերը» որպես առանձին ուղարկման ենթակառուցվածքով աշխատող, 2026 թվականի սեպտեմբերի դրությամբ։

Մատակարարի ընտրություն

Ձեր հավելվածը չպետք է ինքը ուղարկի էլ. նամակ իր սերվերից։ Ուղարկող մատակարարները կառավարում են ենթակառուցվածքը, IP հեղինակությունը, նորից փորձերը և վերադարձված նամակների մշակումը։ Հայտնի տարբերակներն են Postmark, Resend, SendGrid, Amazon SES և Mailgun. յուրաքանչյուրն ունի HTTP API և SMTP մուտք, իսկ գները և պլանները փոխվում են, ուստի համեմատեք դրանք նրանց կայքերում։

Որն է համեմատելու արժեքը.

• Կենտրոնացում. Որոշ մատակարարներ կենտրոնանում են գործարքային նամակների վրա, մյուսները միավորում են գործարքայինը և մարքեթինգայինը։
• Մշակողի փորձ. Հստակ API, ձեր լեզվի պաշտոնական գրադարաններ, օգտակար մատյաններ, որոնք ցույց են տալիս, թե յուրաքանչյուր նամակ առաքվել, վերադարձվել է, թե նշվել որպես սպամ։
• Վեբհուկեր վերադարձված նամակների, բողոքների և առաքումների համար, որպեսզի ձեր հավելվածը կարողանա արձագանքել։
• Ձևանմուշներ — պահված մատակարարի մոտ կամ ձեր կոդում։ Կոդում պահելը դրանք տարբերակավորված և փորձարկելի է դարձնում։
• Տարածաշրջան և տվյալների մշակում, եթե ունեք պահանջներ այն մասին, թե որտեղ են տվյալները մշակվում։
• Արժեքը ձեր ծավալով, ներառյալ այն, թե ինչ է լինում, երբ անցնում եք անվճար սահմանը։

Ցուցակին ուղարկվող նորությունների համար հաճախ ավելի լավ է նորությունների կամ էլ. մարքեթինգի հատուկ գործիք, քան հավելվածի մեջ արշավների գործառույթներ կառուցելը։

Կարգավորեք ուղարկող դոմենը

Ուղարկեք ձեր սեփական դոմենից՝ hello@example.com, ոչ թե Gmail կամ Outlook հասցեից։ Անվճար փոստարկղի հասցեից երրորդ կողմի ծառայությամբ ուղարկված նամակը նույնականացման ստուգումները չի անցնում և հավանաբար զտվում է։

Մտածեք միայն ուղարկելու համար նախատեսված ենթադոմենի մասին։ Օրինակ՝ Resend-ը (2026 թվականի սեպտեմբերի դրությամբ) առաջարկում է ուղարկել այնպիսի ենթադոմեյններից, ինչպիսիք են updates.example.com, որպեսզի մեկուսացվի ուղարկող հեղինակությունը։ Դա նաև պահում է էլ. նամակի DNS գրառումները առանձին ձեր հիմնական կայքի գրառումներից։

Մատակարարը կտա DNS գրառումներ, որոնք պետք է ավելացնել այնտեղ, որտեղ կառավարվում է ձեր դոմենի DNS-ը։ Եթե DNS-ը նոր է ձեզ համար, ինչպես են աշխատում դոմենը և DNS-ը բացատրում է գրառումները նախ։

SPF

SPF (Sender Policy Framework) TXT գրառում է, որը թվարկում է, թե որ սերվերները կարող են նամակ ուղարկել ձեր դոմենից։ Ստացողը ստուգում է, արդյոք ուղարկող սերվերը այդ ցուցակում է։

• Դոմենը պետք է ունենա միայն մեկ SPF գրառում։ Եթե ավելացնում եք մատակարար, միացրեք այն գոյություն ունեցողի մեջ, այլ ոչ թե ավելացրեք երկրորդը։
• SPF-ը գնահատելիս թույլ է տալիս մինչև 10 DNS հարցում․ include: գրառումների երկար շղթաները կարող են գերազանցել այդ սահմանը և առաջացնել ձախողումներ։
• Շատ մատակարարներ SPF-ը դնում են այն վերադարձման ուղու (return-path) ենթադոմենի վրա, որը ձեզ խնդրում են ստեղծել, ուստի գուցե հիմնական SPF գրառմանը երբեք չդիպչեք։

DKIM

DKIM (DomainKeys Identified Mail)-ը յուրաքանչյուր նամակին ավելացնում է կրիպտոգրաֆիկ ստորագրություն։ Մատակարարը ստորագրում է իր գաղտնի բանալիով, իսկ համապատասխան հանրային բանալին դուք հրապարակում եք որպես DNS գրառում (TXT կամ CNAME՝ կախված մատակարարից)։ Ստացողները ստուգում են ստորագրությունը՝ հաստատելու համար, որ նամակը եկել է լիազորված ուղարկողից և փոխված չէ ճանապարհին։

DKIM-ն հիմնականում այն է, ինչի մասին է մատակարարի «ստուգել դոմենը» քայլը։ Մի բաց թողեք այն։

DMARC

DMARC-ը կապում է մյուս երկուսը։ Դա TXT գրառում է _dmarc.yourdomain.com հասցեում, որը ստացողներին ասում է.

• Համապատասխանեցում. Տեսանելի From հասցեի դոմենը պետք է համընկնի այն դոմենի հետ, որը անցել է SPF-ը կամ DKIM-ը։
• Քաղաքականություն. Ինչ անել ձախողված նամակների հետ՝ p=none (միայն հաշվետվել), p=quarantine (համարել կասկածելի, հաճախ սպամ) կամ p=reject.
• Հաշվետվություններ. Որտեղ ուղարկել ամփոփ հաշվետվությունները (rua=), որպեսզի տեսնեք, թե ով է ուղարկում ձեր դոմենի անունից։

Պատշաճ ճանապարհ է սկսել p=none-ով և հաշվետու հասցեով, ստուգել, որ օրինական նամակները անցնում են, և հետո անցնել quarantine, ապա՝ reject-ի։ Խիստ քաղաքականությունը նաև շատ ավելի դժվարացնում է ուրիշների կողմից ձեր դոմենը կեղծելը։

Ինչ է պահանջում Gmail-ը

2026 թվականի սեպտեմբերի դրությամբ Google-ի ուղարկողի ուղեցույցները ասում են.

• Բոլոր ուղարկողները անձնական Gmail հաշիվներին պետք է ունենան SPF կամ DKIM, ուղարկող սերվերների վավեր առաջ և հակադարձ DNS, TLS և սպամի մակարդակ Postmaster Tools-ում 0.3%-ից ցածր։
• Զանգվածային ուղարկողները (օրական ավելի քան 5000 նամակ Gmail-ին) պետք է ունենան SPF և DKIM, DMARC գրառում (թույլատրելի է p=none քաղաքականությունը), From դոմենի համապատասխանեցում և մեկ սեղմումով ապաբաժանորդագրում, ինչպես նաև տեսանելի ապաբաժանորդագրման հղում մարքեթինգային և բաժանորդագրված նամակներում։

Մատակարարը կատարում է սերվերային մասը։ DNS գրառումները և ապաբաժանորդագրման մշակումը ձերն են։ Նույնիսկ եթե օրական 5000-ից շատ չեք ուղարկում, զանգվածային ուղարկողների կանոնները պահպանելը ամենապարզ ձևն է ապահով մնալու համար։

Ներկառուցեք ուղարկումը ձեր հավելվածում

Երբ դոմենը հաստատված է.

1. Պահեք API բանալին որպես սերվերային գաղտնիք՝ երբեք առաջին մասի կոդում։ Տե՛ս ինչ են միջավայրի փոփոխականներն ու գաղտնիքները։
2. Ուղարկեք սերվերից՝ նամակը գործարկող գործողությունը հաջողվելուց հետո։
3. Մի՛ թողեք օգտատիրոջը սպասի էլ. նամակի համար։ Պարզ հավելվածից ավելի մեծ ցանկացած բանի համար հերթավորեք ուղարկումը և ժամանակավոր ձախողումների դեպքում կրկնեք, որպեսզի մատակարարի դանդաղ պատասխանը չդանդաղեցնի գրանցումը։
4. Գրանցեք արդյունքը — մատակարարի հաղորդագրության ID-ն ու կարգավիճակը, առանց բանալին կամ անձնական տվյալներ պարունակող ամբողջական հաղորդագրությունները գրանցելու։
5. Մշակեք վեբհուկերները վերադարձված նամակների և բողոքների համար։ Դադարեցրեք ուղարկումը այն հասցեներին, որոնք ուժեղ վերադարձվում են կամ նշվում որպես սպամ։

Մեկ հուշում, որը ընդգրկում է հիմունքները.

Ուղարկիր գործարքային նամակներ [PROVIDER]-ով՝ օգտագործելով սերվերի գաղտնիքը [ENV_NAME], «Acme hello@mail.acme.com» հասցեից։ Ուղարկիր ողջույնի նամակ գրանցումից հետո և ամրագրման հաստատում, երբ ամրագրումը պահպանվում է։ Պահիր ձևանմուշները կոդում, պարզ տեքստային տարբերակով՝ HTML-ի կողքին։ Հերթավորիր ուղարկումները և կրկնիր ժամանակավոր ձախողումները մինչև երեք անգամ։ Գրանցիր ձախողումները մատակարարի սխալով, բայց երբեք՝ API բանալին։ Ավելացրու վեբհուկի վերջնակետ, որը նշում է հասցեները որպես անառաքելի կոշտ վերադարձների և բողոքների դեպքում, և հետագայում բաց թողիր այդ հասցեները։

Հաշիվների նամակները՝ հաստատման հղումները, մագիկ հղումները և գաղտնաբառի վերականգնումները, մուտքի մաս են։ Ինչպես ավելացնել մուտք ձեր հավելվածին բացատրում է, թե ինչպես են այդ հոսքերը միանում. այդ հղումները դարձրեք միանգամյա և կարճատև։

Առաքելիության սովորություններ

Նույնականացումը ձեզ դիտարկելի է դարձնում։ Վարքագիծը ձեզ պահում է մուտքարկղում։

• Ուղարկեք միայն այն, ինչ մարդիկ սպասում են։ Հաստատված գրանցումներ, մարքեթինգի համար հստակ համաձայնություն, առանց գնված ցուցակների։
• Ապաբաժանորդագրումը դարձրեք հեշտ այն ամենի համար, որ խիստ գործարքային չէ, և անմիջապես կատարեք։
• Տաքացրեք նոր դոմեյնները։ Նոր դոմենը, որը առաջին օրը հազարավոր նամակ է ուղարկում, կասկածելի է թվում։ Սկսեք գործարքային նամակներից և աստիճանաբար մեծացրեք ծավալը։
• Մաքուր պահեք ցուցակները։ Անմիջապես հեռացրեք կոշտ վերադարձվածները և մտածեք հեռացնել նրանց, ովքեր երկար ժամանակ ոչինչ չեն բացել։
• Գրեք մարդու պես։ Հստակ վերնագիր, ճանաչելի ուղարկողի անուն, պարզ տեքստային մաս, քիչ նկարներ և հղումներ ձեր սեփական դոմենին։ Խուսափեք կարճ հղումներից։
• Վերահսկեք։ Գրանցեք ձեր դոմենը Google Postmaster Tools-ում և երբեմն կարդացեք DMARC հաշվետվությունները։
• Օգտագործեք իրական պատասխանի հասցե, որը ինչ-որ մեկը կարդում է։ Պատասխանները լավ ազդանշան են և օգտակար արձագանք։

Փորձարկում առանց որևէ մեկին սպամելու

• Օգտագործեք մատակարարի թեստային ռեժիմը կամ սենդբոքսը, որտեղ այն կա, կամ ուղարկեք ձեզ պատկանող հասցեներին։
• Մշակման ժամանակ ուղարկեք փորձնական մուտքարկղ (catch-all), այլ ոչ թե իրական օգտատերերին. իրական տեսք ունեցող հասցեներով լցված տվյալների բազան հեշտ ճանապարհ է պատահաբար օտարներին նամակ ուղարկելու համար։
• Ստուգեք յուրաքանչյուր ձևանմուշ մի քանի հաճախորդում՝ վեբ Gmail-ում, հեռախոսի փոստի հավելվածում, Outlook-ում և մութ ռեժիմում։
• Նայեք փորձնական նամակի վերնագրերին. դրանք ցույց են տալիս, արդյոք SPF, DKIM և DMARC անցել են։

Իրավական հիմունքներ

Կանոնները երկրից երկիր տարբերվում են։ Ընդհանրապես, մարքեթինգային նամակը շատ տեղերում պահանջում է համաձայնություն, պետք է նշի ուղարկողին և պետք է առաջարկի աշխատող ապաբաժանորդագրում. գործարքային նամակը այլ կերպ է դիտարկվում, բայց չպետք է օգտագործվի մարքեթինգը ծածկելու համար։ Եթե հասցեներ եք հավաքում սպասման ցուցակի էջից, ասեք, թե ինչ և երբ եք ուղարկելու և պահելու, և թե ինչպես է յուրաքանչյուր մարդ գրանցվել։ Եթե կասկածում եք, ստուգեք այն երկրների կանոնները, որտեղ են ձեր օգտատերերը։

Էլ. նամակի ստուգաթերթ

• Ընտրված է ուղարկող մատակարարը. API բանալին պահված է որպես սերվերային գաղտնիք
• Ուղարկում եք ձեր սեփական դոմենից կամ ենթադոմենից, ոչ թե անվճար փոստարկղից
• SPF, DKIM և DMARC գրառումները ավելացված են և անցնում են
• Գործարքային և մարքեթինգային նամակները բաժանված են
• Ուղարկումները հերթավորված և կրկնված են. արդյունքները գրանցված են
• Վերադարձի և բողոքի վեբհուկերը մշակված են
• Ապաբաժանորդագրում՝ ոչ գործարքային նամակների համար, կատարվում է անմիջապես
• Ձևանմուշները փորձարկված են մի քանի հաճախորդում. թեստային նամակը երբեք չի հասնում իրական օգտատերերին

Էլ. նամակի ուղարկում Mythex հավելվածից

Mythex-ը ձեր կառուցած հավելվածների համար ներկառուցված էլ. նամակների ուղարկման ծառայություն չունի, ուստի դուք բերում եք մատակարար, օրինակ՝ Resend, SendGrid կամ Postmark։ Պահեք նրա API բանալին որպես նախագծի գաղտնիք. գործակալը կարող է դրա համար խնդրել գաղտնիքների քարտ չաթում, և պարզ խոսքերով խնդրեք այն նամակները, որոնք ձեզ պետք են։ Սկզբնական հուշումը փաստաթղթերում կա ուղարկել էլ. նամակ ձեր հավելվածից բաժնում։ Եթե դոմենը գնել եք Mythex-ի միջոցով Pro պլանում, կարող եք ավելացնել մատակարարի TXT և CNAME գրառումները դոմենի DNS կարգավորումներում. տե՛ս առանձնահատուկ դոմեններ։

Հարցեր