Relay-ի կարգավորման ուղեցույց

Ինչ անել

1. Ստեղծեք ձեր Ridgital հաշիվը։
2. Հաստատեք ձեր էլփոստի հասցեն։
3. Ընտրեք և գնեք Relay փաթեթ։
4. Համոզվեք, որ բաժանորդագրությունն ակտիվ է։
5. Նախքան ռեսուրսներ ստեղծելը՝ ուսումնասիրեք ձեր փաթեթի սահմանաչափերը։

Ինչ է վերահսկում ձեր փաթեթը

• Էլփոստային հաղորդագրությունների ամսական և օրական ծավալը։
• API-ի և SMTP-ի արագության սահմանաչափերը։
• Հաղորդագրությունների և իրադարձությունների պահպանման ժամկետները։
• Applications-ի, API Keys-ի, SMTP հավատարմագրերի և webhooks-ի քանակը։
• Կցորդների և հաղորդագրության չափի սահմանաչափերը։
• Tracking-ը, suppression-ները, համապատասխանության գործառույթները և աջակցության մակարդակը։

Ստեղծեք Application

1. Բացեք Relay → Applications բաժինը։
2. Ընտրեք Add Application։
3. Մուտքագրեք հեշտ ճանաչելի անուն։
4. Ցանկության դեպքում ավելացրեք նկարագրություն։
5. Production և Staging միջավայրերի համար ստեղծեք առանձին Applications, երբ դրանց գործունեությունն ու հավատարմագրերը պետք է միմյանցից անկախ մնան։

Ընտրեք ճիշտ scope-ը

Այն դեպքերում, երբ Relay-ը տրամադրում է scope-ի ընտրիչ, ռեսուրսը կապեք որոշակի Application-ի հետ կամ ընտրեք Account-wide, երբ ռեսուրսը պետք է հասանելի լինի ամբողջ կազմակերպությունում։

Ստեղծեք API Key

1. Բացեք Account → API Keys բաժինը։
2. Ընտրեք Create API Key։
3. Մուտքագրեք անուն, որը նույնականացնում է դրա Application-ը և միջավայրը։
4. Ցանկության դեպքում սահմանեք գործողության ավարտի ամսաթիվ։
5. Անմիջապես պատճենեք ստեղծված բանալին։

Պաշտպանեք ստեղծված բանալին

• Ամբողջական API Key-ը ցուցադրվում է միայն մեկ անգամ։
• Պահեք այն գաղտնիքների կառավարման համակարգում կամ սերվերային միջավայրի փոփոխականում։
• Երբեք մի բացահայտեք այն դիտարկիչի կոդում, բջջային հավելվածներում, կոդային շտեմարաններում կամ log-երում։
• Բանալին չեղարկելու դեպքում դրա գործողությունն անմիջապես դադարում է, և այդ գործողությունը հնարավոր չէ հետ շրջել։

Ստուգեք API հասանելիությունը

GET /relay/ping

Նախ օգտագործեք այս endpoint-ը՝ API-ի հասանելիությունը հաստատելու և API Key-ը վավերացնելու համար։

Ուղարկեք մեկ հաղորդագրություն

POST /relay/send

Հաջող պատասխանը նշանակում է, որ Relay-ն ընդունել է հաղորդագրությունը և այն ավելացրել հերթում։ Դա չի նշանակում, որ առաքումն ավարտվել է։

Ուղարկեք batch

POST /relay/send/batch

Մեկ հարցմամբ ուղարկեք մինչև 100 հաղորդագրություն։ Relay-ը յուրաքանչյուր տարրի համար վերադարձնում է առանձին արդյունք։

Ստացեք մեկ հաղորդագրության տվյալները

GET /relay/messages/{message_id}

Ստացեք ուղարկված հաղորդագրության ընթացիկ canonical կարգավիճակը և գրանցված կյանքի ցիկլը։

Ցուցադրեք ուղարկված հաղորդագրությունների ցանկը

GET /relay/emails

Ցուցադրեք և զտեք ձեր ուղարկած հաղորդագրությունները։ Արդյունքները բաժանված են էջերի։

Ասինխրոն մշակում

Առաքման փորձերը, կրկնակի փորձերը, bounce-երի մշակումը, suppression-ները, tracking իրադարձությունները և webhook ծանուցումները կատարվում են ուղարկման սկզբնական պատասխանից հետո։

Ստեղծեք հավատարմագիրը

1. Բացեք Relay → SMTP Ingress բաժինը։
2. Ընտրեք Add Credential։
3. Մուտքագրեք Application-ը նույնականացնող պիտակ։
4. Ստեղծեք հավատարմագիրը։
5. Անմիջապես պահպանեք ստեղծված օգտանունն ու գաղտնաբառը։

Կարգավորեք Application-ը

• Օգտագործեք պորտալում ցուցադրված SMTP ingress host-ը։
• Օգտագործեք 587 port-ը։
• Օգտագործեք STARTTLS։
• Նույնականացումն իրականացրեք Relay-ի ստեղծած օգտանունով և գաղտնաբառով։

Տարբերակում և կարգավիճակ

• Name: նույնականացնում է կապը Relay-ում։
• Active: որոշում է՝ արդյոք Relay-ը կարող է օգտագործել այն։
• Default: նշում է այն որպես նախատեսված հիմնական կապ։

Սերվերի միացում

• Host: ծառայություն մատուցողի SMTP hostname-ը։
• Port: ծառայություն մատուցողի SMTP port-ը։
• Encryption: տվյալ port-ի համար պահանջվող ռեժիմը։

Նույնականացում

• Username: SMTP օգտանունը։
• Password: SMTP սերվերի կողմից ընդունվող հավատարմագիրը։
• Խմբագրելիս գաղտնաբառի դաշտը թողեք դատարկ՝ ընթացիկ պահպանված գաղտնաբառը պահելու համար։

Ուղարկողի ինքնություն

• From Email: կարգավորման հետ կապված ուղարկողի հասցեն։
• From Name: ուղարկողի ցուցադրվող անունը։
• Ծառայություն մատուցողը պետք է թույլատրի ընտրված From Email-ը։

Daily Limit

Հաղորդագրությունների առավելագույն քանակը, որը Delivery SMTP-ի այս կարգավորումը կարող է ուղարկել մեկ օրվա ընթացքում։ Դաշտը թողեք դատարկ, եթե կարգավորման մակարդակում օրական սահմանաչափ չի պահանջվում։

Hourly Limit

Հաղորդագրությունների առավելագույն քանակը, որը Delivery SMTP-ի այս կարգավորումը կարող է ուղարկել մեկ ժամվա ընթացքում։ Դաշտը թողեք դատարկ, եթե կարգավորման մակարդակում ժամային սահմանաչափ չի պահանջվում։

Bounce-ի պարտադիր դաշտերը

• Bounce Email Domain։
• IMAP Host։
• IMAP Port։
• IMAP Encryption։
• IMAP Username։
• IMAP Password։

Ինչու է այս կապը կարևոր

SMTP փոխանցումից հետո հաղորդագրությունը սկզբում կարող է ստանալ delivered կարգավիճակ, իսկ հետագայում փոխվել soft_bounced-ի կամ hard_bounced-ի, երբ Relay-ն այս mailbox-ից մշակում է DSN-ը։

Գրանցեք դոմեն

1. Բացեք Relay → Sender Domains բաժինը։
2. Ընտրեք Add Domain։
3. Մուտքագրեք From հասցեի դոմենային մասը։
4. Ստուգեք՝ այն Verified է, թե Unverified։
5. Կապվեք Ridgital-ի աջակցության հետ, երբ պահանջվում է հարթակի կողմից իրականացվող հաստատում։

Դոմենի պահանջների կիրառում

Երբ ուղարկողի դոմենի պահանջների կիրառումը միացված է, չգրանցված կամ հեռացված դոմեններ օգտագործող հաղորդագրությունները կարող են մերժվել։

Relay-ում դոմեն գրանցելը չի կարգավորում SPF-ը, DKIM-ը կամ DMARC-ը։ Այս գրառումները կարգավորեք ձեր ելքային էլփոստի ծառայություն մատուցողի միջոցով։

submitted և accepted

Relay-ը ստացել և ընդունել է հաղորդագրությունը՝ ասինխրոն մշակման համար։ Առաքումը դեռ չի հաստատվել։

delivered

Կարգավորված Delivery SMTP սերվերն ընդունել է հաղորդագրությունը՝ հետագա երթուղավորման համար։ Դա չի երաշխավորում, որ հաղորդագրությունը կհայտնվի inbox-ում։

deferred և bounced

deferred-ը ներկայացնում է ժամանակավոր ուշացում։ Հետագա bounce մշակումը կարող է առաջացնել soft_bounced կամ hard_bounced կարգավիճակ։

suppressed և failed

Suppression-ը կանխել է առաքումը, կամ հաղորդագրության մշակումը ձախողվել է գրանցված մեկ այլ պատճառով։

trackOpens

Թույլ է տալիս Relay-ին tracking pixel-ի հարցման միջոցով գրանցել հաղորդագրության բացման արդյունքը։

trackClicks

Թույլ է տալիս Relay-ին tracked redirect-ների միջոցով գրանցել աջակցվող հղումների սեղմումների արդյունքները։

Ավտոմատ suppression-ի աղբյուրներ

• Hard bounce։
• Աջակցվող բողոքի հաշվետվություն։
• Մեկ սեղմումով unsubscribe։
• Համապատասխանության գործողություն։
• Հարթակի կողմից սահմանված՝ առաքելիությանը վերաբերող մեկ այլ պայման։

Նախքան suppression-ը հեռացնելը

• Ստուգեք ստացողի հասցեն։
• Ստուգեք suppression-ի պատճառը։
• Ստուգեք՝ երբ և ինչպես է այն ստեղծվել։
• Համոզվեք, որ ստացողին կրկին էլփոստ ուղարկելն օրինական է։

Վավերացրեք payload-ները

Նախքան իրադարձությանը վստահելը կամ այն մշակելը՝ վավերացրեք X-Ridgital-Signature-ում տրամադրված HMAC-SHA256 ստորագրությունը։

Փորձարկեք առաքումը

Օգտագործեք Send Test-ը, ուսումնասիրեք առաքման գրանցված փորձերը և պորտալից կրկնեք այն ձախողված առաքումները, որոնց համար կրկնակի փորձը թույլատրված է։

Փոխեք secret-ը

Rotation-ն անմիջապես անվավեր է դարձնում ստորագրման նախորդ secret-ը։ Փոփոխությունը համաձայնեցրեք ձեր ստացող Application-ի հետ։

Պաշտոնական կարգավիճակ

Webhook-ի առաքումն ասինխրոն է։ Հաղորդագրության գրանցված վիճակի պաշտոնական աղբյուր համարեք Email Logs-ը կամ Relay API-ն։

Ստացողի որոնում և արտահանում

1. Բացեք Relay → Compliance բաժինը։
2. Մուտքագրեք մեկ ստացողի էլփոստի հասցե։
3. Գտեք դրա հետ կապված Relay գրառումները։
4. Ներբեռնեք JSON-ը կամ, երբ հասանելի է, արտահանման հարցում ներկայացրեք։
5. Հարցումն ուսումնասիրեք Compliance history-ում։

Ստացողի տվյալների ջնջում

Ջնջումը վերջնականապես հեռացնում է կիրառելի հաղորդագրությունների բովանդակությունը և իրադարձությունների պատմությունը։ Հարցումը կարող է պահանջել աշխատակազմի հաստատումը և ավարտից հետո չի կարող հետ շրջվել։

Ստացողի տվյալների ջնջումը չի հեռացնում ստացողի suppression գրառումը։

Հաշիվ և հասանելիություն

• Բաժանորդագրությունն ակտիվ է։
• Օգտատերերի դերերը ճիշտ են։
• Զգայուն հաշիվներն օգտագործում են 2FA։
• Production ռեսուրսներն օգտագործում են նախատեսված Application scope-ը։

Ուղարկում

• Application-ն օգտագործում է ճիշտ API կամ SMTP ingress հավատարմագիրը։
• Secret-ները պահպանվում են անվտանգ եղանակով։
• Չօգտագործվող հավատարմագրերը չեղարկվել են։
• GET /relay/ping-ն ընդունում է production API Key-ը։

Առաքում

• Delivery SMTP-ն հաջողությամբ անցնում է Test Connection-ը։
• Ճիշտ կարգավորումն ունի Active և Default կարգավիճակները։
• From Email-ը թույլատրված է։
• Օրական և ժամային սահմանաչափերը ճիշտ են։
• Bounce mailbox-ը հասանելի է։

Մոնիթորինգ

• Իրական փորձնական հաղորդագրությունը ցուցադրվում է Email Logs-ում։
• Հաղորդագրությունը ստանում է ակնկալվող SMTP փոխանցման կարգավիճակը։
• Sender Domains-ը գրանցված են։
• Webhook ստորագրությունները վավերացված են։
• Suppression-ի գործելակերպը հասկանալի է։

TLS handshake-ի սխալ

Ընտրված port-ն ակնկալում է գաղտնագրման այլ ռեժիմ։ Ստուգեք՝ ծառայություն մատուցողը պահանջում է STARTTLS, թե անմիջական SSL/TLS։

Նույնականացման 535 սխալ

SMTP կամ IMAP սերվերը մերժել է հավատարմագրերը կամ նույնականացման եղանակը։ Ստուգեք օգտանունը, գաղտնաբառի տեսակը և ծառայություն մատուցողի հասանելիության քաղաքականությունը։

Ուղարկողը մերժվել է

Համոզվեք, որ նույնականացված Delivery SMTP հաշիվը կարող է հաղորդագրություններ ուղարկել՝ օգտագործելով կարգավորված From Email-ը և ուղարկողի դոմենը։

Առաքվել է, բայց inbox-ում չկա

Delivered կարգավիճակը հաստատում է SMTP փոխանցումը, ոչ թե inbox-ում հայտնվելը։ Ստուգեք ձեր ծառայություն մատուցողի կարգավորումները, ստացողի զտման կանոնները, ուղարկողի հեղինակությունը և bounce-ի հետագա թարմացումները։

Bounce-ը չի հայտնաբերվել

Ստուգեք Bounce Email Domain-ը, IMAP կարգավորումները, հավատարմագրերը, mailbox-ի երթուղավորումը և feedback loop-ի նպատակակետը։

Հաղորդագրությունը suppressed է

Ուսումնասիրեք suppression-ի պատճառն ու աղբյուրը։ Մի հեռացրեք այն պարզապես bounce-ը, բողոքը, unsubscribe-ը կամ համապատասխանության գործողությունը շրջանցելու համար։