Hvorfor levering av transaksjons-e-post er en helt annen disiplin

Det finnes et avgjørende skille mellom markedsførings-e-poster og transaksjons-e-poster som mange utviklere overser når de først begynner å ta leveringsevne på alvor. Markedsførings-e-poster — nyhetsbrev, kampanjer, kunngjøringer — går til abonnenter som har meldt seg på. De tåler tidvise forsinkelser og til og med tidvis plassering i søppelpostmappen. Hvis et nyhetsbrev havner i søppelpost hos 2 % av listen din, er det uheldig, men virksomheten din kjører videre.

Transaksjons-e-poster er noe helt annet. Verifiseringslenker, passordtilbakestillinger, kjøpsbekreftelser, koder for tofaktorautentisering, sikkerhetsvarsler om kontoen — disse lander i kritiske øyeblikk i brukerens reise. En passordtilbakestilling som havner i søppelpost, betyr at brukeren er låst ute av kontoen sin og sannsynligvis vil opprette en supportsak eller, enda verre, aldri komme tilbake. En verifiserings-e-post som havner i søppelpost, betyr at en ny bruker ikke kan fullføre registreringen, og at anskaffelsestrakten din har en stille, usynlig lekkasje.

Og likevel blir transaksjons-e-poster ofte satt opp med mindre omhu enn markedsføringskampanjer. Mange utviklere bruker den e-postkoden rammeverket deres tilbyr, konfigurerer den med en delt SMTP-server, distribuerer den, tester den én gang med sin egen innboks — som har rause terskler for søppelpost — og går videre. Problemene dukker først opp når ekte brukere på Gmail, Outlook eller Yahoo rapporterer manglende e-poster. På det tidspunktet har feilen sviktet stille i produksjon i flere uker.

SPF: fundamentet for e-postautentisering

Sender Policy Framework (SPF) er en DNS TXT-post på avsenderdomenet ditt som forteller omverdenen hvilke e-postservere som er autorisert til å sende e-post på dine vegne. Når Gmail mottar en e-post som angivelig kommer fra [email protected], utfører den et DNS-oppslag på domenets SPF-post. Hvis IP-adressen til serveren som faktisk sendte e-posten, er oppført i SPF-posten din, består e-posten SPF-sjekken. Hvis det ikke finnes noen SPF-post i det hele tatt — eller avsenderserveren ikke er oppført — blir e-posten behandlet med mistanke allerede før selve innholdet i det hele tatt vurderes.

Det er greit å sette opp SPF når du først vet hva du gjør. Legg til en TXT-post i domenets DNS. Verdien avhenger av avsenderleverandøren din. Bruker du SendGrid: v=spf1 include:sendgrid.net ~all. Bruker du AWS SES: v=spf1 include:amazonses.com ~all. Bruker du Mailgun: v=spf1 include:mailgun.org ~all. Leverandørens dokumentasjon gir deg den nøyaktige include-verdien. Suffikset ~all er en «soft fail» — e-poster fra ikke-oppførte servere blir flagget, men ikke direkte avvist. Når du er trygg på at SPF-posten din er komplett og korrekt, kan du oppgradere til -all (hard fail), som instruerer mottakende servere om å avvise uautorisert post fullstendig.

En vanlig fallgruve: grensen på 10 DNS-oppslag. SPF-poster som kjeder sammen flere include:-direktiver, kan overskride denne grensen, noe som får SPF til å feile selv om alle serverne dine teknisk sett er oppført. Bruk MXToolbox for å sjekke SPF-posten din — det flagger problemer med antall oppslag tydelig. Hvordan SPF, DKIM og DMARC henger sammen, er godt beskrevet i SendGrids dokumentasjon om e-postautentisering.

DKIM: kryptografisk bevis for at e-posten din ikke ble tuklet med

DomainKeys Identified Mail (DKIM) legger til en kryptografisk signatur på hver e-post du sender. Signaturen genereres med en privat nøkkel som avsenderleverandøren din oppbevarer, og mottakende e-postservere verifiserer den mot en offentlig nøkkel du publiserer som en DNS TXT-post. Hvis signaturen stemmer, er to ting bevist: e-posten stammer virkelig fra avsenderinfrastrukturen din, og innholdet ble ikke endret mellom sending og mottak.

Uten DKIM konfigurert blir det betydelig enklere for ondsinnede aktører å forfalske domenet ditt — å sende e-poster som ser ut til å komme fra [email protected], men som egentlig ble sendt av en helt annen. Slik fungerer phishing-kampanjer. Søppelpostfiltre vet dette også, og det er derfor en e-post uten en gyldig DKIM-signatur fra et domene som burde ha en, blir behandlet med økt mistanke. Spamhaus og andre omdømmetjenester tar med DKIM-signeringshistorikk i domenets omdømmescore.

DKIM settes opp gjennom avsenderleverandøren din. De genererer et nøkkelpar, oppbevarer den private nøkkelen på infrastrukturen sin, og gir deg en offentlig nøkkel du legger til i DNS-en din som en TXT-post. Når den DNS-posten først er publisert og utbredt, vil hver e-post de sender på dine vegne, automatisk bære en gyldig DKIM-signatur. De fleste store leverandørene — SendGrid, Mailgun, Amazon SES, Postmark — veileder deg gjennom denne prosessen under det innledende oppsettet. Hoppet du over det, gå tilbake og konfigurer det nå.

DMARC: policylaget som binder det hele sammen

DMARC (Domain-based Message Authentication, Reporting, and Conformance) bygger videre på SPF og DKIM ved å definere hva mottakende servere skal gjøre når en e-post feiler disse sjekkene. Det introduserer også «alignment» — et krav om at domenet i e-postens Fra-header faktisk stemmer overens med domenet som besto SPF eller DKIM. Dette hindrer angripere i å bestå SPF-sjekker på ett domene mens de forfalsker et annet i den synlige Fra-adressen.

Den riktige tilnærmingen til DMARC er å starte gradvis. Begynn med en policy som kun overvåker: v=DMARC1; p=none; rua=mailto:[email protected]. p=none forteller mottakende servere at de ikke skal reagere på feil, bare sende deg rapporter. Disse aggregerte rapportene vil vise deg hvilke servere som sender e-post på dine vegne, og om de består SPF og DKIM. Gå gjennom dem i et par uker før du gjør noen policyendringer.

Når du er trygg på at alt legitimt består, gå over til p=quarantine (feilede e-poster havner i søppelpostmappen) og til slutt p=reject (feilede e-poster avvises direkte). Denne progresjonen beskytter domenets omdømme mot forfalskning samtidig som den gir deg tid til å fange opp eventuelle legitime e-postkilder du kan ha oversett. En DMARC-policy med p=reject kombinert med bestått SPF og DKIM gjør det nesten umulig for angripere å etterligne domenet ditt effektivt.

IP-omdømme: hvorfor avsenderserveren din betyr noe

Selv med perfekt SPF, DKIM og DMARC kan e-postene dine fortsatt havne i søppelpost hvis IP-adressen de sendes fra, har et dårlig omdømme. Mottakende e-postservere vedlikeholder — eller rådfører seg med tredjepartstjenester som vedlikeholder — blokkeringslister og omdømmescorer for avsender-IP-adresser. En IP med en historikk med å sende søppelpost, eller som dukker opp på blokkeringslister vedlikeholdt av tjenester som Spamhaus, vil få de utgående e-postene sine behandlet med mistanke uansett hvor godt autentiseringsoppsettet ditt er.

Bruker du en delt IP-adresse fra en delt hostingleverandør eller en billig SMTP-tjeneste, er omdømmet ditt knyttet til alle andre som bruker den samme IP-en. Én spammer i den samme delte poolen kan ødelegge leveringsevnen for alle avsendere på den IP-en. Dette er et av de sterkeste argumentene for å bruke en dedikert leverandør av transaksjons-e-post — SendGrid, Amazon SES, Postmark, Mailgun — fremfor å sende e-post direkte fra applikasjonsserveren din eller gjennom en delt SMTP-tjeneste.

På en ny avsender-IP må du også «varme opp» IP-en gradvis. Å sende en plutselig bølge av e-postvolum fra en fersk IP ser ut som spamatferd for mottakende servere. Start med lavere volum og øk gradvis over dager eller uker. De fleste dedikerte e-postleverandører håndterer IP-oppvarming automatisk hvis du er på en delt avsenderpool, eller gir deg oppvarmingsplaner hvis du bruker en dedikert IP.

Innhold og emnelinje: hva som utløser filtre

Utover autentisering og IP-omdømme blir selve innholdet i e-posten din vurdert av søppelpostfiltre. Visse mønstre utløser pålitelig spamklassifisering. Spam-utløserord i emnelinjen — «GRATIS», «GARANTERT», «HANDLE NÅ», overdrevne utropstegn, STORE BOKSTAVER — er de åpenbare som de fleste utviklere unngår. Mindre åpenbart: emnelinjer som er for vage («Viktig melding til deg»), for hastende («Kontoen din vil bli stengt») eller for salgspreget for noe som skal være en transaksjons-e-post.

Forholdet mellom tekst og bilder betyr også noe. En e-post som stort sett består av bilder med minimalt med tekst, er et klassisk spammønster — massesendere bruker bilder for å skjule nøkkelord fra tekstbaserte filtre. Transaksjons-e-poster bør primært være tekstbaserte med minimalt med bilder. Ødelagt HTML — ulukkede tagger, feilformede attributter — er enda et faresignal. Send alltid et alternativ i ren tekst sammen med HTML-versjonen din. Søppelpostfiltre ser på e-poster som bare er HTML, med økt mistanke, og bedrifters e-postsystemer fjerner ofte HTML helt.

Slik tester du e-postleveringen din — den riktige måten

Den raskeste og mest praktiske testmetoden for e-postlevering er: send en test-e-post til en fersk temp mail-innboks og sjekk både innboksmappen og søppelpostmappen. Dette gir deg umiddelbar, entydig tilbakemelding på om e-posten din når innboksen eller blir filtrert bort. I motsetning til å teste med din egen Gmail-konto — der du kanskje er hvitelistet som en hyppig avsender — har en fersk midlertidig adresse ingen tidligere historikk med domenet ditt, noe som mer nøyaktig simulerer en ny brukers førstemøte.

Du bør teste leveringen hver gang du endrer noe som kan påvirke den: bytter e-postleverandør, oppdaterer HTML-malen din vesentlig, endrer avsenderdomenet ditt, legger til et nytt avsendersubdomene, eller distribuerer til et nytt miljø (staging, produksjon). Det tar to minutter og gir deg endelig bevis. Alternativet — å vente på at brukere rapporterer problemer — betyr at leveringsproblemene dine allerede har sviktet stille i en ukjent periode.

Utover innboks/søppelpost-sjekken kan du bruke MXToolboxs e-posthelsesjekk for å kontrollere domenets samlede tilstand: SPF, DKIM, DMARC, svartelistestatus og MX-postkonfigurasjon, alt på ett sted. Gjør dette til en del av sjekklisten din før lansering for enhver ny applikasjon eller avsenderdomene. Sjekk også retningslinjene til OWASP for sikkerhetsrelaterte beste praksiser for e-post.

Returrater og spamklager: målingene som betyr noe

To målinger har en uforholdsmessig stor effekt på leveringsevnen på lang sikt: returrate og spamklagerate. En returrate over 2 % forteller mottakende servere og avsenderleverandøren din at du sender til mange ugyldige eller ikke-eksisterende adresser — et mønster som forbindes med kjøpte e-postlister og spamoperasjoner. Selv om du gjør alt annet riktig, vil en høy returrate skape leveringsproblemer. Fjern harde returer fra avsenderlisten din umiddelbart og permanent.

En spamklagerate over 0,1 % (én klage per tusen sendte e-poster) er terskelen der de fleste avsenderleverandører begynner å begrense kontoen din. Gmails Postmaster Tools rapporterer klagerater direkte hvis du har satt det opp. Overvåk disse målingene via avsenderleverandørens dashbord. Hvis klageratene stiger, undersøk hvorfor — sender du til brukere som ikke eksplisitt har samtykket? Er e-postene dine for hyppige? Er det et misforhold mellom hva brukerne forventet og hva de faktisk mottar?

Komplett sjekkliste for leveringsevne

• SPF-post: DNS TXT-post på avsenderdomenet ditt som lister opp alle autoriserte avsenderservere. Test med MXToolbox.
• DKIM: Kryptografisk signering konfigurert gjennom avsenderleverandøren din, offentlig nøkkel publisert i DNS.
• DMARC: Start med p=none-overvåking, gå videre til p=quarantine og deretter p=reject etter å ha gjennomgått aggregerte rapporter.
• Dedikert avsenderleverandør: Bruk SendGrid, SES, Postmark eller Mailgun — ikke applikasjonsserveren din eller en delt SMTP.
• Rene emnelinjer: Spesifikke, relevante, ingen utløserord, ingen overdreven tegnsetting eller store bokstaver.
• HTML + ren tekst: Ta alltid med begge. Send aldri e-poster som bare er HTML.
• Ingen URL-forkortere: Bruk fulle, direkte URL-er i e-postens brødtekst og verifiseringslenker.
• Avmeldingslenke: Ta den med der det er relevant, også i transaksjons-e-post — noen leverandører krever det.
• Fysisk adresse: Påkrevd av CAN-SPAM og lignende regler i mange jurisdiksjoner.
• Håndtering av harde returer: Fjern umiddelbart; prøv aldri en hard retur på nytt.
• Overvåking av klager: Sett opp Gmail Postmaster Tools; overvåk dashbordet for klagerate.
• Innbokstesting: Send test-e-poster til ferske midlertidige innbokser før hver distribusjon og etter enhver endring av mal eller konfigurasjon.
• MXToolbox-helsesjekk: Ta den med i sjekklisten din før lansering for hvert nytt domene og miljø.

Når du bør bruke en dedikert tjeneste for transaksjons-e-post

Hvis applikasjonen din i det hele tatt sender e-post som brukeren må motta for å kunne bruke den — verifiseringslenker, passordtilbakestillinger, kjøpsbekreftelser — bør du bruke en dedikert leverandør av transaksjons-e-post fra dag én. Kostnaden er lav (ofte gratis opp til titusenvis av e-poster i måneden), påliteligheten er dramatisk bedre enn gjør-det-selv-SMTP, og leveringsinfrastrukturen — delte IP-pooler med styrt omdømme, automatisk DKIM-signering, håndtering av returer og klager — vedlikeholdes av team hvis eneste jobb er å holde e-post i innbokser.

Den vanligste gjør-det-selv-feilen er å kjøre en e-postserver på samme IP som webapplikasjonen din, eller å bruke en billig hostingleverandørs medfølgende SMTP-tjeneste. Disse IP-ene blir rutinemessig lagt til blokkeringslister av tjenester som Spamhaus fordi hostingmiljøet deles med ondsinnede aktører. Å bytte til en dedikert transaksjonsleverandør er som regel en ettermiddags arbeid og har en umiddelbar positiv effekt på leveringsevnen. Det er en av de infrastrukturforbedringene som gir mest utbytte for et lite team. Personvernbevisste team bør også gå gjennom veiledningen fra Electronic Frontier Foundation om ansvarlig håndtering av brukerdata når e-post er involvert. I tillegg kan overvåking av adresser mot kjente databruddsdatabaser via Have I Been Pwned supplere svindelforebyggingen din når nye kontoer opprettes.