1. Home
  2. Products
  3. Ստուգեք Փոստի SPF-ը

Ստուգեք Փոստի SPF-ը

SPF-ի գրառումների ստուգիչը հարցումներ է անում Ուղարկողի քաղաքականության շրջանակի համար, գրառումներ, վերլուծում է դրանք և ցուցադրում մարդկանց ընթերցվող ձևաչափով

Ինչու՞ պետք է օգտագործեք Check Mail SPF հավելվածը?

Մեր SPF գրառումների ստուգիչը կարող է վերլուծել SPF գրառումները և ցուցադրել դրանք մարդու համար ընթեռնելի ձևաչափով: Այսպիսով, դուք հեշտությամբ կարող եք հասկանալ, թե ինչպես է կազմաձևվում SPF գրառումը, որը էլեկտրոնային փոստերին, սերվերներին և IP հասցեներին թույլատրվում է նամակներ ուղարկել ձեր տիրույթի անունից:

Շատ ավելի լավ է օգտագործել մեր գործիքը կոնսոլային հավելվածների փոխարեն, ինչպիսիք են dig-ը կամ nslookup-ը: Քանի որ այդ կոնսոլային հավելվածները ձեզ ցույց կտան չմշակված SPF գրառումը, ինչպես նաև շատ անհամապատասխան TXT գրառումներ:

Դուք նույնպես պետք է փորձեք մեր DNS ստուգիչ հավելված . Այն կարող է օգտագործվել նաև SPF գրառումները ստուգելու համար: Բայց այն նաեւ ստուգում է այլ DNS գրառումներ, ինչպիսիք են A, CNAME, MX, NS, SRV, TXT, եւ ավելի. Եվ այս բոլոր գրառումները կպահանջվեն զուգահեռ, այնպես որ DNS ստուգիչը գրեթե նույնքան արագ է, որքան Check Mail SPF հավելվածը:

Միգրացիայի հեքիաթ

Մի քանի տարի առաջ կար փոքր բիզնես, առցանց խանութ: Եկեք կոչենք սեփականատիրոջը Ալիս (կեղծանուն): Ալիսը մի քանի աշխատակից ուներ, որոնք բոլորն օգտագործում էին կորպորատիվ էլփոստի հասցեներ, որոնք կապված էին իր տիրույթին։ Այս էլփոստի հասցեները կափարիչի տակ օգտագործում էին Google Mail Exchange- ը:

Ալիսի բիզնեսը շարունակում էր աճել: Նա վարձեց ավելի շատ մարդկանց, բայց մի օր հասկացավ, որ չի կարող նոր նամակներ ստեղծել նրանց համար ՝ անվճար օգտատերերի սահմանափակման պատճառով: Չցանկանալով տեղափոխվել վճարովի պլան, նա որոշել է փոխել փոստի փոխանակիչը:

Միգրացիոն գործընթացը դժվարին էր։ Նրա ՏՏ աջակցության թիմը անխոնջ աշխատել է բոլոր էլփոստի հաղորդագրությունները մեկ սերվերից մյուսը փոխանցելու համար՝ պահպանելով պատմությունը: Նրանք նաև ստեղծեցին նոր հաշիվներ և վերապատրաստեցին անձնակազմին, թե ինչպես վերաձևակերպել իրենց էլփոստի հաճախորդներին:

Միգրացիան ավարտվելուց հետո նրանք թարմացրել են DNS MX ռեկորդը իրենց տիրույթի համար, վերահղելով իրենց տիրույթին ուղարկված բոլոր նամակները նոր փոստի փոխանակիչին: Այնուամենայնիվ, նրանք անտեսեցին մեկ վճռական մանրուք ՝ SPF- ի ռեկորդը: Գուցե նրանք ենթադրում էին, որ SPF ռեկորդը կազմաձեւվել է MX ռեկորդի հիման վրա, կամ գուցե նրանք պարզապես մոռացել են SPF տեխնոլոգիայի մասին:

Հաջորդ օրը քաոսային էր։ Հաճախորդները դադարեցին նամակներ ստանալ: ՏՏ թիմը սկզբում կարծում էր, որ հարցը կապված է հնացած DNS գրառումների հետ և որոշեց սպասել, որ ռեկորդների քեշերը թարմացվեն: 24 ժամ սպասելուց հետո նրանք հասկացան, որ այլ խնդիրներ կարող են լինել։ Ալիսը սթրեսի մեջ էր ժամանակ և հաճախորդներ կորցնելու համար: Ի վերջո, թիմը սկսեց մեղադրել նոր փոստի փոխանակողին: Ոմանք նույնիսկ ցանկանում էին վերադառնալ Google- ին:

Վերջապես ՏՏ կողմնակիցներից մեկը հին ընկերոջ հետ քննարկել է խնդիրը: Այս ընկերը նրան ուղարկեց իրենց SPF գրառումը.

SPF գրառում store.alice.com տիրույթի համար

Այս SPF ռեկորդը դեռեւս ներառում էր կանոններ Google- ից, բայց ոչ մեկը նոր MX սերվերից: Ահա թե ինչու բոլորը կարող էին ստանալ նոր նամակներ `MX ռեկորդի պատճառով, բայց իրենց ուղարկած նամակների մեծ մասը չի առաքվել: Թիմը ավելացրեց “ներառել” կանոնը նոր MX սերվերի համար, եւ ամեն ինչ շտկվեց շուտով: Նրանք նաև որոշեցին ավելացնել “mx” կանոնը, ի դեպ:

Էլփոստի կոնֆիգուրացիան կարող է բարդ լինել, նույնիսկ եթե դուք ստիպված չեք պահպանել ձեր սեփական էլփոստի սերվերը: Գոյություն ունեն բազմաթիվ արձանագրություններ՝ սպամինգը, սփոֆինգը և այլ տեսակի խաբեությունները կանխելու համար: SPF- ն ընդամենը դրանցից մեկն է:

SPF գրառումները հասկանալու կարևորությունը

Ուղարկողի քաղաքականության շրջանակի (SPF) գրառումների հասկանալը վճռորոշ նշանակություն ունի ձեր տիրույթի էլփոստի անվտանգության կառավարման համար: SPF գրառումները օգտագործվում են կանխելու spammers ուղարկելու հաղորդագրություններ կեղծված 'From' հասցեներով ձեր տիրույթից. Պատշաճ կերպով կարգավորելով ձեր SPF ռեկորդը, դուք կարող եք նշել, թե որ փոստի սերվերները լիազորված են նամակ ուղարկել ձեր տիրույթի անունից:

Մեր դիմումը պարզեցնում է այս գործընթացը `պահանջելով բոլոր TXT գրառումները տվյալ տիրույթի համար և զտելով դրանք SPF գրառումը գտնելու համար, որը միշտ պետք է սկսվի 'v = spf1'- ով: Երբ մենք գտնում ենք այս ռեկորդը, մենք վերլուծում ենք այն ըստ RFC 4408 և RFC 7208 բնութագրերի:

Մեր վերլուծման գործընթացը հայտնաբերում է SPF գրառման բոլոր կանոնները և յուրաքանչյուրի համար հստակ բացատրություններ է տալիս: Սա նշանակում է, որ դուք կարող եք հեշտությամբ հասկանալ, թե ինչպես է ձեր SPF գրառումը կազմաձեւված, եւ որ նամակները, սերվերները եւ IP հասցեները լիազորված են ուղարկել նամակ անունից ձեր տիրույթի.

Մենք հավատում ենք, որ ձեր SPF գրառումը հասկանալը ձեր տիրույթի էլփոստի անվտանգության կառավարման վճռորոշ մասն է, և մենք այստեղ ենք, որպեսզի այդ գործընթացը հնարավորինս պարզ և պարզ դարձնենք:

Ինչու է SPF- ն նույնիսկ գոյություն ունի:

Տեխնիկապես, ցանկացած ոք, ով ստեղծում է SMTP սերվեր, կարող է սահմանել 'From' դաշտը ցանկացած արժեք, երբ նամակներ ուղարկելու ժամանակ: Սա հաճախ շահագործվում է սպամերների և ֆիշերների կողմից, ովքեր նամակներ են ուղարկում կեղծված 'From' հասցեներով:

Հետևաբար, դուք կարող եք ստանալ նամակ, որը կարծես ձեր բանկից է, բայց իրականում դա կարող է լինել ցանկացած մեկից: Էլեկտրոնային փոստը հորինվել է այն ժամանակ, երբ ինտերնետը կատարում էր առաջին քայլերը: Չկային խաբեբաներ և վիրուսներ: Մարդիկ մտածում էին շփվելու և իրենց գիտելիքները կիսելու նոր եղանակներ հորինելու մասին։ Անվտանգության մասին մտածելու ժամանակ չկար: Այնուամենայնիվ, քանի որ ինտերնետը շարունակում էր աճել, ի հայտ եկան օգտագործման նոր դեպքեր: Մի օր հորինվեց առաջին վիրուսը, մի օր գրվեց առաջին սպամ նամակը։ Եվ մի օր խաբեբաները հասկացան, որ նրանք կարող են օգտագործել էլփոստի հաղորդագրության From դաշտը ՝ իրենց հասցեատերերին մոլորեցնելու համար:

Կարելի է մտածել, որ լուծումն այն է, ստուգել սերվերը, որը ուղարկել է հաղորդագրությունը եւ համեմատել իր հասցեն սերվերի դոմենի անվան հետ: Բայց իրերն արդեն շատ ավելի ճկուն և կոմլիկացված դարձան։ Կարող եք մտածել, որ եթե նամակ եք ստացել Trip.com@newsletter.trip.com -ից, դա նշանակում է, որ այն ուղարկվել է SMTP սերվերից, որը գտնվում է newsletter.trip.com տիրույթում. Բայց եկեք վերլուծենք էլփոստի վերնագրերը.

Էլփոստի վերնագրերը Trip.com@newsletter.trip.com -ից էլփոստի համար

Ինչպես տեսնում եք, նամակն ուղարկվել է amazonses.com սերվերներից մեկից։ Դուք կարող եք զարմանալ, թե ինչու է դա տեղի ունենում: Դե, տեղեկագրեր ուղարկելու իրականացումը կարող է լինել բարդ խնդիր. Սովորաբար ընկերությունները նախընտրում են այն հանձնել հատուկ ծառայություններին: Այնպես որ, trip.com նախընտրում է օգտվել Amazon վեբ ծառայություններից իրականացնել այս խնդիրը. Այնուամենայնիվ, դուք այլևս չեք կարող ստուգել ուղարկողի լիազորությունը բացառապես այն սերվերի հիման վրա, որից ուղարկվել է էլփոստը: Եվ սա այն պահն է, երբ SPF ռեկորդը գալիս է օգնելու ձեզ: Եկեք նայենք newsletter.trip.com տիրույթի SPF գրառմանը.

SPF գրառում newsletter.trip.com տիրույթի համար

Ինչպես տեսնում եք, newsletter.trip.com- ը թույլ է տալիս amazonses.com սերվերներին ուղարկել նամակներ @newsletter .trip.com հասցեներից: Ավելին, եթե ավելի խորը սուզեք եւ ստուգեք amazonses.com տիրույթի SPF ռեկորդը, կարող եք կանոն գտնել ip4:54.240.0.0/18 . Այս կանոնը թույլ է տալիս բոլոր IP հասցեները 54.240.0.0- ից մինչեւ 54.240.63.255 ուղարկել նամակներ newsletter.trip.com- ից: Այնպես որ, եթե վերադառնաք վերնագրերի անալիզատորին, կարող եք տեսնել, որ էլփոստը ուղարկվել է IP 54.240.3.17- ից, որը հաստատ այս տիրույթի ներսում է

Այժմ, երբ հասկանում եք, թե ինչպես է աշխատում SPF- ը, եկեք նայենք հաջորդականությանը, որ ձեր էլփոստի սերվերը հետեւում է, երբ այն ստանում է էլփոստ.

STEP 1

Ստացեք ուղարկողի սերվերի հասցեն

Ստացողի սերվերը ստանում է ուղարկողի սերվերի հասցեն էլփոստի վերնագրերից:

STEP 2

Կարդացեք From դաշտը

Սերվերը կարդում է էլփոստի From դաշտը և ստանում դոմենի անունը

STEP 3

Ստացեք տիրույթի SPF գրառումը

Սերվերը կատարում է DNS TXT հարցումը `տիրույթի SPF գրառումը ստանալու համար եւ վերլուծում է այն:

STEP 4

Համապատասխանեցրեք ուղարկողի սերվերի հասցեն SPF գրառմանը

Սերվերը մեկ առ մեկ ստուգում է SPF բոլոր կանոնները պարզելու համար, թե արդյոք ուղարկողին թույլատրվում է նամակ ուղարկել տվյալ հասցեից:

Դուք այժմ կարող եք հետաքրքրվել, թե ինչու ենք առաջին քայլում վստահում էլփոստի վերնագրերին: Եթե ուղարկողը կարող է սահմանել From վերնագիրը ցանկացած արժեք, ինչու նրանք նույն բանը չեն անում մյուս վերնագրերին: Ահա թե ինչու միայն SPF- ը բավարար չէ ձեր մուտքի արկղը ապահովելու համար: SPF- ը միշտ պետք է համակցված լինի DKIM արձանագրության հետ: Ավելին, կա DMARC արձանագրությունը, որն արդեն պահանջում է ինչպես SPF, այնպես էլ DKIM- ը էլփոստի հաղորդագրության իսկությունը որոշելու համար: DNS ստուգիչ հավելված կարող է հարցնել ինչպես SPF, այնպես էլ DMARC գրառումները եւ ապահովում է մարդկային ընթեռնելի բացատրություններ կանոնների համար դրանցից.

Մեր ապագա ծրագրերը

Մենք մշտապես աշխատում ենք բարելավել Check Mail SPF հավելվածը տրամադրել ձեզ առավել համապարփակ եւ օգտագործողի բարեկամական SPF ռեկորդային ստուգման գործիք. Մեր առաջիկա առանձնահատկություններից մեկը ռեկուրսիվ հարցումների ավելացումն է: Սա նշանակում է, որ եթե SPF գրառումը պարունակում է որևէ 'վերահղման' կամ 'ներառում' մեխանիզմներ, ապա մեր հավելվածը ավտոմատ կերպով կկատարի համապատասխան հարցումները և այդ կանոնները ներառի արտադրանքի մեջ։

Այնուամենայնիվ, մենք հասկանում ենք այս տեղեկատվությունը հեշտ կարդալու և հասկանալու պահելու կարևորությունը։ Հետեւաբար, մենք կապահովենք, որ օգտվողները կարող են հստակ տեսնել, թե որտեղից են եկել այդ լրացուցիչ կանոնները եւ ինչպես են դրանք մեկնաբանվում: Սա կապահովի ձեր SPF ռեկորդային կոնֆիգուրացիայի ավելի ամբողջական պատկերը, մինչդեռ պահպանելով պարզությունն ու հստակությունը, որը մեր օգտվողները գնահատում են:

Մինչ մենք շարունակում ենք բարելավել եւ ընդլայնել Check Mail SPF հավելվածը, մենք նաեւ գնահատում ենք մեր օգտվողների մուտքագրումը: Մենք հավատում ենք, որ ձեր կարծիքը կարևոր է ՝ օգնելու մեզ հասկանալ, թե ինչ նոր առանձնահատկություններ կցանկանայիք տեսնել հավելվածում:

Մեր հավելվածն օգտագործելուց հետո մենք խրախուսում ենք թողնել ձեր կարծիքը `սեղմելով համապատասխան կոճակը դիմումի արդյունքի ներքեւում: Անկախ նրանից, թե դա նոր առանձնահատկությունների հարցում է, բարելավման առաջարկ կամ սխալների մասին զեկույց, մենք ցանկանում ենք լսել ձեզանից: Ձեր կարծիքը օգնում է մեզ դարձնել Check Mail SPF հավելվածը բոլորի համար ավելի լավ: