Email integracija: SendGrid, Mailgun i šabloni

Email integracija spaja vašu aplikaciju sa servisom koji može isporučiti poštu u većem obimu, uz autentifikaciju, šablone i trag šta se desilo sa svakom porukom. Reset lozinke, potvrda narudžbe, faktura i obavijest o prijavi dio su proizvoda. Kad završe u spamu, stignu kasno ili uopšte ne napuste server, kupac zaključi da je firma stala.

CodeWiz postavlja transactional e-mail za web aplikacije, online prodavnice i SaaS proizvode. Spajamo SendGrid, Mailgun ili drugog provajdera, autentifikujemo domen, odvajamo poštu proizvoda od newslettera i činimo kvarove vidljivim umjesto tihim. Aplikacija čuva poslovni događaj; provajder radi isporuku.

Ovo je za timove koji šalju poštu iz plugina, sa dijeljenog hostinga ili sa jedne SMTP prijave koju niko ne želi dirati. I za prodavnice u kojima timeout na checkoutu može značiti plaćenu narudžbu bez potvrde.

Kod teme sendgrid alati otvorenog koda su prvi izbor kada odgovaraju poslu.

Email integracija sa SendGridom

SendGrid je čvrst izbor kad vam trebaju održavan API, dinamički šabloni i jasni webhookovi za bounce i žalbe. Nalog tretiramo kao produkcijsku infrastrukturu: vlastiti subuser ili API ključ po aplikaciji, nikakav ključ na frontendu i domen za slanje koji nije isti hostname na koji se kupci prijavljuju.

Šta produkcijski setup uključuje

• Autentifikaciju domena, da primaoci mogu provjeriti da je pošta koja se predstavlja kao vaša zaista poslana s vašim dopuštenjem. Koraci su u SendGridovom vodiču za autentifikaciju domena.
• Poseban API ključ samo sa dozvolom za slanje, sačuvan kao secret i rotiran kad ode osoblje koje ga je moglo vidjeti.
• Dinamičke šablone za poruke koje se često mijenjaju, sa običnim tekstom uz HTML.
• Event webhookove za isporučeno, odgođeno, bounce i prijavu spama, uperene u endpoint koji mi kontrolišemo.
• Listu potiskivanja koju aplikacija stvarno čita, da ne ponavljamo adresu koja je tvrdo odbijena.

DNS zapisi dolaze iz dashboarda, ne iz blog posta. Uobičajen oblik, sa zamjenama, izgleda ovako:

Zapise objavimo, sačekamo da ih provajder potvrdi i pošaljemo probnu poruku na Gmail i Outlook inbox prije nego ikakav kupac krene preko tog domena. SPF zapis koji već postoji se spaja. Drugi v=spf1 ne daje dvije politike; daje nijednu kojoj će primaoci vjerovati.

Mailgun email integracija i dolazne rute

Mailgun odgovara timovima kojima treba HTTP API okrenut programerima, regionalno slanje (uključujući EU) i dolazna pošta: odgovori, adrese podrške i tokovi tipa “pošalji dokument e-mailom”. Posao integracije istog je oblika kao kod SendGrida, uz rutiranje kao dodatak.

• Potvrđen domen za slanje, sa SPF-om, DKIM-om i praćenim hostnameom za klikove i otvaranja samo tamo gdje vam to stvarno treba. Slijedimo Mailgunovu provjeru domena.
• Odvojeni domeni ili poddomeni za transactional i masovnu poštu, da žalba na newsletter ne kazni reset lozinke.
• Dolazne rute koje provjere Mailgunov potpis prije nego aplikacija parsira tijelo. Otvoren inbound URL otvoren je put da se ubaci sadržaj.
• API ključevi i ključevi za potpis webhooka van repozitorija.
• Čuvanje logova onoliko koliko podršci treba da odgovori na “gdje je moj račun?”.

Mailgun ili SendGrid biramo prema dolaznoj pošti, mjestu čuvanja podataka i onome što je već na nalogu, ne prema poznatijem logotipu. Oba mogu poslati reset lozinke. Nisu zamjenjivi kad su šabloni, webhookovi i domeni u produkciji, pa prvi izbor treba biti smišljen.

Transactional e-mail za narudžbe, naloge i plaćanja

Email integracija, u praksi, jeste pošta koju je korisnik pokrenuo ili mora dobiti: dobrodošlica, potvrda adrese, reset lozinke, potvrda narudžbe, račun, status dostave, faktura, sigurnosno upozorenje. To nije newsletter kome je skinut logo. Ove poruke moraju biti brze, konkretne i nadoknadive.

Ne šaljemo ih unutar web zahtjeva koji je napravio narudžbu. Zahtjev zabilježi događaj i vrati odgovor. Worker sastavi poruku i preda je provajderu, sa ponovnim pokušajima i backoffom kad provajder vrati 429 ili 5xx. Ako worker stoji, događaj je i dalje u redu ili u bazi, nije izgubljen zato što je PHP istekao. To je isti odnos prema narudžbama kao u tekstu o e-commerceu bez izgubljenih narudžbi, i prema računima iz integracije payment gatewaya.

Poruke koje obično spajamo prve

• Nalog: potvrda e-maila, reset lozinke, obavijest o novom uređaju ili prijavi, sa kratkim vijekom svakog linka.
• Narudžbe: potvrđena, plaćena, poslata, refundirana. Svaka navodi id narudžbe, iznos i šta slijedi. Širi tok prodavnice opisan je u našem vodiču za optimizaciju e-commercea.
• Plaćanja: račun i obavijest o neuspjelom plaćanju. Obavijest kaže kupcu šta da uradi; ne sadrži cijeli broj kartice.
• Operativa: e-mail osoblju o niskoj zalihi ili palom poslu, na drugom toku od kupčeve pošte, da unutrašnja poplava ne blokira reset lozinke.

Šabloni e-mailova koje urednici mijenjaju bez deploya

Šabloni su mjesto gdje timovi ili tvrdo upišu HTML u kontroler ili marketingu predaju fajl koji se boje dirati. Fiksni raspored odvajamo od riječi i podataka. Raspored ostaje u verzionisanju. Tekst koji se mijenja sa kampanjom ili pravnom rečenicom živi u alatu provajdera ili u vašem CMS-u, uz pregled.

• Jedan raspored, mnogo poruka: zaglavlje, podnožje i blok sadržaja. Stilovi dugmadi žive na jednom mjestu.
• Varijable su imenovane i dokumentovane (order_id, customer_name, action_url). Nedostajući podatak obara render na stagingu, ne u inboxu kupca.
• HTML i običan tekst ostaju usklađeni. Neki klijenti, i neki alati za pristupačnost, pokazuju samo tekst.
• Linkovi u pošti naloga su apsolutni, HTTPS i ne prolaze kroz otvoreni redirect.
• Pregled ide na probnu listu prije nego izmjena šablona stigne u produkciju. Prethodnu verziju čuvamo da se loša izmjena vrati bez deploya.

Šablon je i odluka o isporučivosti. Jedna ogromna slika, sakriveni unsubscribe na resetu lozinke ili naslov koji liči na promociju uče filtere da ne vjeruju domenu kojim šaljete račune.

Izbor provajdera

Pravi provajder je onaj čiji način rada odgovara pošti koju šaljete. Cijena po poruci bitna je na velikom obimu; rijetko je razlog što pošta o narudžbi ne stigne.

Preporučujemo nalog koji već plaćate kad odgovara, i kažemo kad je SMTP na vlastitom serveru lažna ušteda. Kasniji prelazak znači novi DNS, nove šablone i period paralelnog slanja.

Isporučivost: SPF, DKIM, DMARC i bounceovi

Isporučivost je odluka primaoca da vam vjeruje. Autentifikacija je dio koji stvarno možete implementirati. SPF imenuje servere koji smiju slati za domen. DKIM potpisuje poruku. DMARC kaže primaocima šta da urade kad te provjere padnu i šalje vam izvještaje. Googleove smjernice za pošiljaoce praktičan su prag za svakog ko šalje ozbiljniji obim prema Gmailu: autentifikacija, poravnanje i put za žalbu koji radi.

Kako dižemo domen

• DMARC kreće na p=none i izvještaje čitamo, da zaboravljeni server (alat za newsletter, stari skener, podrška) ispliva prije nego što ga stavite u karantin.
• Na quarantine ili reject prelazimo kad su legitimni izvori poravnati. Stroga politika prvog dana blokira poštu koju ste zaboravili.
• Vidljivi From domen poravnajte sa DKIM domenom. Potpis za em.sendgrid.net sam po sebi ne autentifikuje you@yourdomain.com.
• Bounceove obrađujemo. Tvrdi bounce potiskuje adresu. Mekani bounce ponavlja ograničen broj puta. Žalba je stop, ne ponovni pokušaj.
• Probni inbox na velikim provajderima gledamo nakon izmjene DNS-a ili šablona. Plasman u spam je signal, ne ukrasna metrika.

Obim slanja držimo iskrenim. Sasvim nov domen koji odjednom izbaci desetine hiljada poruka liči na kompromitovan nalog. Zagrijavanje, za domen koji će slati puno, znači krenuti od pošte koju su ljudi tražili i odatle rasti.

Transactional pošta i marketing na odvojenim tokovima

Marketinška pošta i pošta proizvoda imaju druga pravila i druge načine da padnu. Kampanji trebaju saglasnost, lista i unsubscribe koji radi u jednom kliku. Resetu lozinke ne treba ništa od toga i ne smije kasniti zato što je kampanja u toku. Miješanje na jednom domenu, jednom API ključu i jednom folderu šablona način je da promocija pokvari plasman računa.

• Odvojeni poddomeni, na primjer mail.example.com za poštu proizvoda i news.example.com za kampanje.
• Odvojeni API ključevi i liste potiskivanja. Odjava sa newslettera ne smije blokirati obavijest o dostavi, a tvrdi bounce na adresi za reset ne smije biti zanemaren.
• Saglasnost i prepoznatljiv pošiljalac na svemu promotivnom. Transactional pošta ostaje vezana za događaj koji ju je izazvao.
• Upozorenja osoblju idu trećim putem kad su bučna, da pošta nadzora ne popuni istu kvotu kao pošta kupaca.

Uobičajene greške isporuke koje ispravljamo

Kvarovi koje nas zovu da popravimo rijetko su “provajder je pao”. To su odluke u postavci koje su na staging inboxu izgledale dovoljno dobro:

• Slanje iz web zahtjeva, pa spor provajder postane neuspio checkout i izostala potvrda.
• Dva SPF zapisa, ili zapis koji i dalje navodi server koji ste napustili prije godina.
• Nema webhooka, pa bounceovi postoje samo na dashboardu koji niko ne otvara.
• Isti domen za kupljenu listu i za reset lozinke.
• Secreti u temi, mobilnoj aplikaciji ili javnom repozitoriju.
• Linkovi u pošti naloga koji ističu, a šablon to ne kaže, ili pokazuju na staging.
• Nema običnog teksta, a raspored je jedna slika bez teksta koji bi filter pročitao.

Od čega zavisi cijena

Procjenu dajemo kad vidimo koje poruke šaljete, odakle i šta se desi kad jedna padne. Posao raste sa nekoliko činjenica:

• Koliko tipova poruka, jezika i šablona, i da li je tekst već napisan.
• Da li domen već ima čist SPF, DKIM i DMARC, ili stare pošiljaoce prvo treba pronaći.
• Dolazna pošta, više brendova i odlazak sa postojećeg provajdera, što znači paralelni rad.
• Webhookovi, potiskivanje i red u aplikaciji, naspram “pozovi API i nadaj se”.
• Stalni pogled na DMARC izvještaje i bounceove, ako to želite i poslije puštanja, a ne samo jednokratni setup.

Jedan provajder i pet transactional šablona na domenu koji kontrolišete mali je projekat. Nekoliko brendova, dolazne rute i migracija bez rupe u pošti o narudžbi veći su. Kažemo koji je koji prije nego krenemo.

Kako radimo

1. Upoznavanje: popisujemo svaku poruku koju proizvod šalje, koji sistem je šalje danas i koje kvarove kupci već primjećuju.
2. Plan: biramo provajdera, domene, podjelu između pošte proizvoda i marketinga i šta “nije uspjelo” mora uraditi za narudžbu ili reset lozinke.
3. Izrada: autentifikujemo domen, spremamo secrete, dodajemo šablone i šaljemo kroz workera sa ponovnim pokušajima i event webhookovima.
4. Test: probni inboxi, namjerni bounce, žalba, timeout provajdera i šablon kome fali podatak. Staging ne smije pisati pravim kupcima.
5. Puštanje: prebacujemo jedan tip poruke odjednom, počev od onog koji najviše boli kad padne, i pratimo plasman i stopu bounceova.
6. Podrška: kratak runbook za rotaciju ključeva, čitanje bouncea i vraćanje šablona, plus po želji nadzor DMARC-a i reda.

Zašto CodeWiz

• Aplikacija i put pošte zajedno: gradimo Laravel, Node.js, WordPress i kod prodavnice, pa poruka ide u red tamo gdje se narudžba ili prijava stvarno dese.
• Open-source na prvom mjestu, provajder tamo gdje zasluži: aplikacija ostaje prenosiva. SendGrid ili Mailgun je servis isporuke, ne mjesto gdje krijemo poslovnu logiku.
• Po mjeri, ne podrazumijevani plugin: WooCommerce shop, SaaS mailer za naplatu i inbox podrške ne dobijaju istu postavku.
• Poštene cijene: vrhunski razvoj bez vrhunskih cijena, iz Banje Luke, na daljinu sa klijentima lokalno i u inostranstvu.
• Ostatak proizvoda u istim rukama: plaćanja, performanse i prodavnica su kod istog tima. Više o studiju je na stranici o CodeWizu.

Često postavljana pitanja

Koliko traje email integracija?

Jedan provajder, potvrđen domen i nekoliko transactional šablona često su gotovi za nekoliko dana, uključujući probne poruke. Odlazak sa starog pošiljaoca, sa dolaznim rutama i nekoliko brendova, traje duže jer se DNS i paralelni rad moraju preklopiti.

Koliko košta postavljanje?

Zavisi od broja šablona, stanja DNS-a i toga da li se pošta već šalje iz web zahtjeva. Naknade provajdera su vaše i naplaćuje ih taj provajder. Implementaciju procjenjujemo nakon pregleda poruka, ne kao fiksni paket.

Hoće li pošta prestati završavati u spamu?

Autentifikacija, čista lista i odvojeni tokovi uklanjaju uobičajene razloge zbog kojih primaoci ne vjeruju domenu. Niko ne može obećati mjesto u inboxu Gmaila ili Outlooka. Možemo pokazati rezultat autentifikacije, stopu bounceova i probni inbox nakon puštanja.

Možete li nas prebaciti sa starog SMTP plugina bez gubitka pošte o narudžbama?

Da. Novi put vozimo paralelno, uporedimo uzorak poruka, pa prebacujemo jedan tip odjednom. Narudžbe ostaju zapisane u vašoj bazi i dok se jedno slanje ponavlja, što i jeste smisao vađenja slanja iz checkout zahtjeva.

Radite li i newsletter, ne samo račune?

Postavljamo razdvajanje, domen i osnovu saglasnosti da kampanja ne može pokvariti plasman transactional pošte. Kalendar kampanja i tekst su vaši. Radije ćemo ispravno spojiti unsubscribe nego poslati listu kojoj ne smijete pisati.

Spremni za poštu koja stiže?

Recite nam koje poruke kupci danas propuštaju i koji sistem ih šalje. Predložićemo postavku koja autentifikuje domen i drži poštu o narudžbama i nalozima u pokretu kad provajder zakaže. Kontaktirajte nas da prođemo detalje, ili pogledajte šta pokriva naša email integracija.