La oss forestille deg at du utvikler en ny funksjon eller et program. Enden er i sikte. Alle kompliserte infrastrukturer, databaser, APIer, tester ser bra ut. Da er du klar over at det er sentrale punkter i systemet der du må sende "transaksjonelle" e-postmeldinger; passord reset, velkomst e-post, kvitteringer, fakturaer.

Du vet at det er tjenester og APIer du kan bruke til å håndtere dette for deg, men når du begynner å se på å sende epost innser du at det kommer til å bli vanskeligere enn du trodde. Spesielt hvis du vil bruke designene som designer, produktleder eller markedsføringsjef hadde i tankene.

Dette er et vanlig scenario. Som utviklere tenker vi sjelden på transaksjonelle e-postmeldinger til etter å ha bygget ut produktet. Men det er ok da det er en mengde løsninger der ute som har ryggen din. Det har vært lang tid siden du måtte stole på å sette opp din egen e-postinfrastruktur for å håndtere sending, mottak, studs, avmeldinger osv..

Når det er sagt, er det noen få viktige ting du trenger å vite om å bygge HTML-e-post, sende e-post og opprettholde en god avsenderomtale. Denne sjekklisten vil hjelpe deg med å forberede deg til ditt neste prosjekt som har transaksjonelle e-poster. Vi skal dekke:

1. Hva er transaksjonelle e-poster?
2. Velg din e-postleverandør (ESP)
3. En guide til levering og omdømme
   
4. Koding Responsive HTML Email
   
5. E-postressurser for utviklere
   

Merk: denne opplæringen er en del av en hel ukes verdi av e-postinnhold på Tuts + Web Design-sjekk ut læringsguiden for Mastering HTML Email for mer!

Hva er transaksjonelle e-poster?

Du kan kategorisere e-postmeldinger som bedrifter og apper sender inn:

• Transaksjonelle e-poster
• Markedsføring e-post

Du kan bryte disse ned lenger i underkategorier, men for det vi snakker om her, la oss holde fast i disse to.

Markedsføring e-post er vanligvis salgsfremmende i naturen og håndteres av markedsføringsteam. De inkluderer månedlige nyhetsbrev, sesongbaserte kampanjer, selskaps- og produktoppdateringer, nye utgivelser etc. Det er en innholds- og livssyklusstrategi bak når og hvor ofte å sende dem.

Transaksjonelle e-poster er de som utløses av brukeradferd og vanligvis implementeres av utviklere eller produktgrupper. Brukeren gjør noe i appen din, noe som fører til at en e-post sendes. Disse inkluderer:

• Velkommen e-post
• Bekreftelses e-post
• Passord tilbakestilles
• Nye fakturaer / kvitteringer
• etc.

De fleste av disse e-postene vil du sannsynligvis sende deg selv, men du kan også sende disse via tredjepartstjenester, for eksempel Stripe for kvitteringer, Shopify for e-handel.

Reglene for transaksjons- og markedsføringsemail varierer litt. GDPR trådte i kraft 25. mai 2018, slik at alle som sender markedsføring e-post kreves for å samle eksplisitt tillatelse fra abonnenter og opprettholde en oversikt over denne tillatelsen. Som det står, trenger du ikke eksplisitt tillatelse til å sende transaksjonelle e-postmeldinger, f.eks. kvittering til noen som nettopp har kjøpt noe fra butikken din. Men det er fordeler med å holde seg i tråd med GDPR-forskriftene, uansett hvilke typer e-poster du sender.

Velg din e-postleverandør (ESP)

Det er ganske mulig å konfigurere din egen e-postserver og administrere sending av e-post selv. Hvis du er hos et stort firma som Google eller Facebook, kan du til og med ha ditt eget e-postinfrastrukturteam dedikert til å støtte transaksjonspost.

For de fleste av oss anbefaler jeg ikke å sette opp og vedlikeholde din egen e-postserver. Det er mye overhead involvert i støtte og vedlikehold. I stedet bruker du en av ESPene der ute. De har gode APIer for utviklere og er rimelige, vanligvis med sjenerøse gratis nivåer.

SendGridMailgunpoststempelMailjetSparkPost

Hver av disse ESPene er utstyrt med alt du trenger for å administrere transaksjonspost:

• Sende e-post via API eller SMTP.
• Motta og analysere innkommende e-post.
• Metrics for sendt, mottatt, hoppet, åpnet, klikket e-post.
• Oppheve abonnement og undertrykkelseslistehåndtering.
• Omdømme overvåking.
• Tilbakemelding loop management.
• GDPR-samsvar og mer.

Når du har plukket din ESP, er det på tide å sette opp ting.

En guide til levering og omdømme

Postboksleverandører (som Gmail og Outlook) ser på en liten ting som heter rykte. Du vil ha et godt omdømme for å sikre at e-posten din kommer inn i mottakerens innboks. Hvis du har dårlig rykte, vil e-posten din enten gå til spam eller e-postleverandøren kan avvise det, og det vil sprette.

Ifølge Talos var gjennomsnittlig daglig mengde spam sendt globalt i juli 2018 305,95 milliarder kroner. Du vil ikke at posten din skal falle inn i denne bøtte.

Gjennomsnittlig daglig spamvolum

Ting som kan bidra til dårlig rykte:

• Mottakere flagger e-posten din som spam.
• Mottakere åpner ikke eller engasjerer seg med e-posten din.
• Du sender for mange e-poster.
• Du sender e-post fra en IP-adresse som har dårlig score.
• Du har ikke oppsett DKIM, SPF og DMARC.
• Innholdet du sender ser ut som spam.

De tre hovedautentiseringsmetodene du må vurdere, er SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) og DMARC (Domain-based Message Authentication, Reporting and Conformance).

SPF er en måte for postboksleverandører å godkjenne at e-posten faktisk kom fra domenet ditt. Det er en TXT DNS-post som du må legge til via DNS-administrasjonen.

domain.com. TXT "v = spf1 inkluderer: domain ~ all"

DKIM bruker offentlige / private nøkkelpar til å signere hver melding med en unik kryptografisk signatur, utformet for å oppdage e-spoofing. Når du klikker send, vil ESP legge til en privat signatur, og på DNS ​​sitter din offentlige signatur, som mottakerens postkasse leverandør vil ringe for å sikre at alt ser bra ut.

_domainkey.domain.com. TXT "v = DKIM1; k = rsa; p = PUBLIC_KEY"

DMARC er ikke en godkjenningsprotokoll, men lar deg sette inn en policy for hva du skal gjøre med meldinger som ikke overgår SPF eller DKIM, enten det blir avvist eller karantene.

_dmarc.domain.com. TXT "v = DMARC1; p = avvise; pct = 100; [email protected]"

Her er et eksempel på hvordan e-postautentisering alle kommer sammen. Dette er forenklet, men gir deg en ide om hvordan det fungerer.

E-postautentisering (src: htmlemail.io)

Omdømme er knyttet til både ditt sende-domene og IP-adressen du bruker, så du vil at dette skal være statisk. Kontrollerer din IP-adresse er den mest grunnleggende metoden som en postboksleverandør (Gmail, Outlook, Hotmail, Yahoo, AOL etc.) har når du sjekker omdømmet ditt. Når du sender over 50 000 e-poster per uke, bør du vurdere å bruke en dedikert IP, slik at du ikke deler den med andre, noe som gir deg litt mer isolasjon. Og husk at du må "varme opp" IP-er. Du bør ikke bare begynne å sende millioner av e-poster fra en ny, dedikert IP med en gang. De fleste ESP tilbyr denne funksjonen.

En annen ting å vurdere, er å bruke separate IPer og underdomener for transaksjons- og markedsførings-e-post. Jeg setter vanligvis opp noe som send.mydomain.com for markedsføring og notifications.mydomain.com for transaksjonelle e-poster.

Ikke send fra en "no-reply @" e-postadresse. Først av alt ser det dårlig ut til mottakerne dine, da det ser ut som om du ikke bryr deg og ikke vil høre fra dem. For det andre er det a flott ting når mottakerne svarer og engasjerer seg. Dette er hva postboksleverandører liker å se.

Bruk verktøy som SenderScore og SenderBase for å overvåke ditt omdømme.

Koding Responsive HTML Email

MIME Multipart

Når du sender en e-post, er det laget av overskrifter og forskjellige deler. Dette er kjent som Multipurpose Internet Mail Extensions (MIME). Dette kombinerer ren tekst, HTML og / eller andre deler og overlater den til mottakerklienten for å bestemme hva og hvordan å vise den.

• Overskrifter inneholder nøkkelverdipar som hvem den opprinnelige avsenderen var, emnet, svaradressen og en rekke andre interessante data. Innenfor kroppen din har du forskjellige "deler".
• tekst / vanlig er den enkleste formen for å sende en e-post med kun tekst og ingen formatering.
• tekst / html muliggjør HTML. Dette er hvor HTML-e-posten din går.
• tekst / watch-html er for klokker, som Apple Watch, og har begrenset HTML-støtte.
• tekst / x-amp-html er en ny del som bringer interaktivt innhold til Gmail med AMP for Email.

For de fleste e-postmeldinger sender du en ren tekstdel og en HTML-del. Postkasse leverandører liker å se begge. Den gode nyheten er at ESPer håndterer alt dette for deg. Det er nok ikke noe du trenger å tenke på med mindre du prøver å gjøre noe mer avansert med e-post.

Hvis du er nysgjerrig på hvordan alt ser ut, klikk i Gmail Se original (eller Vis originalen) og det vil vise deg hvordan pølsen er laget. Piecing disse sammen er ganske komplisert, noe som er en annen god grunn til å bruke en ESP som gjør alt dette for deg.

Tabeller og Inline CSS

Når du koder HTML-e-post, anbefales det (fortsatt) at vi bruker tabeller (

), tabellrader () og tabellceller (

). Mange e-postklienter blir bedre med å støtte moderne HTML og CSS, men du risikerer at de faller fra hverandre i bestemte e-postklienter. Det er mange e-postklienter der ute. Litmus, et testverktøy for e-post, støtter for øyeblikket over 90 klienter over skrivebord, web og mobil. Disse e-postklienter bruker alle forskjellige gjengivelsesmotorer. Noen bruker Webkit, noen Internet Explorer, noen Microsoft Word. Og alle legger til litt av sin egen smak av stiler og klasser på toppen av det du gir. Med dette i betraktning anbefales det at du spiller det trygt og holder deg til noen regler når du koder for e-post. Bruk i stedet for Bruk full heksadesimale farger # ff6600 i stedet for stenografi # f60 Bruk padding i stedet for margin Bruk bakgrunnsfarge i stedet for bakgrunn Bruk innebygd CSS i stedet for innebygd CSS Hold deg til system- og websikker fonter Legg til role = "presentasjon" til hver tabell slik at det er klart for skjermleserne at bordet blir brukt til oppsett Bruk semantiske HTML-koder, for eksempel og , hvor det er aktuelt For eksempel, her er hvordan jeg vanligvis kode knapper for HTML-e-post, ved hjelp av et ytre bord for justering, og et indre bord for knappformen. Det er en ganske kuletett løsning: Skrive CSS inline kan være monotont, for ikke å nevne vanskelig å vedlikeholde, og uskalelig, spesielt for store lag. Dette er hvor du vil bruke en CSS inliner eller noen verktøy for automatisering for å hjelpe deg med å bygge og legge inn malene dine. Rammer som MJML og Inky gir utviklere et mer vennlig templerende språk å jobbe med. InkyMJML Merk: du kan bruk medieforespørsler og betingede uttalelser for å målrette mot bestemte klienter - med dem kan du ha spesielle layouter for Outlook eller bruke webfonter i Webkit-klienter. Ta en titt på denne enkle, åpen kildekode-responsive e-postmalen for å komme i gang eller lese mer om disse teknikkene for koding av mer avanserte HTML-e-postmaler. Trenger jeg virkelig å bruke tabeller og Inline CSS i 2018? Det kommer an på. Hvis du vil spille det trygt og sørg for at e-postene dine er bulletproof, så ja. Hvis du har god innsikt i mottakerne dine og du vet at de bruker e-postklienter som har støtte for innebygd CSS og boksmodellen, så kanskje ikke. Du kan definitivt ta risikoen, og det kan ikke være et problem. Jeg holder personlig med gamle vaner og bruker tabeller og inline CSS, men mange andre begynner å eksperimentere med alternativet "nei inline". Bilder, GIF, Video og Media Noen klienter (spesielt Outlook) vil blokkere bildegengivelse som standard, og tvinge mottakere til å logge inn for å se bildene dine. Med det i tankene gi alltid bildene dine meningsfull ALT-tekst. Du vil ønske å gi bilder av høy kvalitet til netthinnen skjermbilder (for eksempel iPhone) derfor bildene dine bør være minst 2x dimensjonene du vil vise dem på. Med det for øye, gi alltid bildet ditt a bredde attributt for å stoppe det overfylte på noen kunder. Animerte GIF-er støttes hos de fleste klienter. Video støttes på iOS, Apple Mail og Outlook.com. Du kan også eksperimentere med emojis i emnelinjene for å få mottakerens oppmerksomhet 🤯 Komprimer medieaktivitetene dine og last dem opp til et innholdsleveringsnettverk (CDN), for eksempel Amazon Web Services, Cloudinary eller imgix. Mange ESPer vil takle dette for deg. tl; dr Og vi er ferdige! La oss ta opp: Det er mer å sende e-post enn møter øyet. Bruk en utvikler vennlig API-tjeneste for å administrere e-post for deg. Sett opp SPF, DKIM og DMARC for ditt sende domene. Hvis du sender mye epostbetaling for en dedikert IP i stedet for å bruke en delt IP. Send vanlig tekst og HTML-e-post. Bruk tabeller og lag din CSS slik at de ikke faller fra hverandre på e-postklienter. Husk å teste e-postene dine på e-postklienter og på tvers av enheter. E-postressurser for utviklere E-postdesign Inspirasjon av virkelig gode e-poster E-postmaler for oppstart og utviklere Stiftelsen for e-postmaler MJML Templating Framework CSS i e-poststøtte av kampanjeovervåker Email Design System for Sketch DMARC-skjerm med poststempel Slik sender du Transaksjonell Email med Ruby on Rails Slik sender du transaksjonell e-post med PHP Slik sender du transaksjonell e-post med Node.js Webdesign Alt du kanskje vil vite om importerklæringer * Alt annet enn kameraet Mer Essential Night Photography Gear ×