Slik sender du e-post fra appen din (og havner i innboksen)

For å sende e-post fra appen din pålitelig, bruk en e-postleverandør i stedet for din egen postkasse, send fra en adresse på ditt eget domene, og legg inn DNS-postene leverandøren gir deg, slik at SPF, DKIM og DMARC alle består. Hold transaksjonell e-post — tilbakestilling av passord, kvitteringer, bekreftelser — adskilt fra markedsføringspost, send hver type bare til folk som forventer den, og håndter bounces og avmeldinger. Få autentiseringen riktig først; det er den vanligste årsaken til at e-post fra apper havner i søppelposten.

Transaksjonell kontra markedsføringspost

Disse to typene e-post ser like ut i koden, men behandles svært ulikt av innboksleverandører og i loven.

Hold dem adskilt. Hvis en markedsføringskampanje får klager på spam, vil du ikke at tilbakestillinger av passord fra samme strøm skal lide for det. En vanlig tilnærming er egne underdomener — for eksempel mail.example.com for kontopost og news.example.com for nyhetsbrev — og noen leverandører skiller de to internt. Postmark beskriver for eksempel sine transaksjonelle og masseutsendte «meldingsstrømmer» som kjørt på separat utsendelsesinfrastruktur, fra september 2026.

Velge leverandør

Appen din bør ikke sende e-post selv fra egen server. Utsendelsesleverandører håndterer infrastrukturen, IP-omdømme, nye forsøk og behandling av bounces. Kjente alternativer inkluderer Postmark, Resend, SendGrid, Amazon SES og Mailgun; hver har et HTTP-API og SMTP-tilgang, og priser og planer endrer seg, så sammenlign dem på deres egne sider.

Dette bør du sammenligne:

• Fokus. Noen leverandører konsentrerer seg om transaksjonell e-post; andre kombinerer transaksjonell og markedsføring.
• Utvikleropplevelse. Tydelig API, offisielle biblioteker for språket ditt, nyttige logger som viser om hver melding ble levert, bounchet eller merket som spam.
• Webhooks for bounces, klager og leveranser, slik at appen din kan reagere.
• Maler — lagret hos leverandøren, eller i din egen kode. Å holde dem i koden gjør dem versjonert og testbare.
• Region og databehandling, hvis du har krav til hvor data behandles.
• Kostnad ved ditt volum, inkludert hva som skjer når du overskrider et gratisnivå.

For nyhetsbrev til en liste passer et eget nyhetsbrev- eller e-postmarkedsføringsverktøy ofte bedre enn å bygge kampanjefunksjoner inn i appen din.

Sett opp avsenderdomenet ditt

Send fra ditt eget domene — hello@example.com, ikke en Gmail- eller Outlook-adresse. Post fra en gratis postkasseadresse sendt via en tredjepartstjeneste feiler autentiseringskontrollene og filtreres sannsynligvis bort.

Vurder et underdomene kun til utsendelse. Resend anbefaler for eksempel å sende fra underdomener som updates.example.com for å isolere avsenderomdømmet (fra september 2026). Det holder også e-post-DNS-postene adskilt fra nettstedets.

Leverandøren gir deg deretter DNS-poster å legge inn der domenets DNS administreres. Hvis DNS er nytt for deg, forklarer hvordan domener og DNS fungerer postene først.

SPF

SPF (Sender Policy Framework) er en TXT-post som lister hvilke servere som får sende e-post for domenet ditt. Mottakere sjekker om avsenderserveren står på listen.

• Et domene bør bare ha én SPF-post. Hvis du legger til en leverandør, slå den sammen med eksisterende post i stedet for å legge til en ny.
• SPF tillater maksimalt 10 DNS-oppslag ved evaluering; lange kjeder med include: kan overskride det og gi feil.
• Mange leverandører setter SPF på et return-path-underdomene som de ber deg opprette, så du trenger kanskje ikke å endre hovedposten for SPF i det hele tatt.

DKIM

DKIM (DomainKeys Identified Mail) legger til en kryptografisk signatur på hver melding. Leverandøren signerer med en privat nøkkel; du publiserer den tilhørende offentlige nøkkelen som en DNS-post (TXT eller CNAME, avhengig av leverandør). Mottakere sjekker signaturen for å bekrefte at meldingen kom fra en autorisert avsender og ikke ble endret underveis.

DKIM er hovedsakelig det leverandørens «verifiser domene»-steg handler om. Ikke hopp over det.

DMARC

DMARC binder de to andre sammen. Det er en TXT-post på _dmarc.dittdomene.com som forteller mottakere:

• Samsvar (alignment): domenet i den synlige avsenderadressen må samsvare med domenet som bestod SPF eller DKIM.
• Policy: hva som skal gjøres med post som feiler — p=none (bare rapporter), p=quarantine (behandle som mistenkelig, ofte spam) eller p=reject.
• Rapporter: hvor sammenstilte rapporter skal sendes (rua=), slik at du ser hvem som sender som domenet ditt.

En fornuftig vei er å starte med p=none og en rapporteringsadresse, bekrefte at legitim post består, og deretter gå over til quarantine og til slutt reject. En streng policy gjør det også mye vanskeligere for andre å forfalske domenet ditt.

Hva Gmail krever

Fra september 2026 sier Googles retningslinjer for avsendere at:

• Alle avsendere til personlige Gmail-kontoer trenger SPF eller DKIM, gyldig fremover- og bakoverrettet DNS for avsenderserverne, TLS, og en spamrate i Postmaster Tools under 0,3 %.
• Masseavsendere (mer enn 5 000 meldinger per dag til Gmail) trenger SPF og DKIM, en DMARC-post (en p=none-policy er tillatt), domenesamsvar for avsenderdomenet, og avmelding med ett klikk pluss en synlig avmeldingslenke i markedsførings- og abonnementsmeldinger.

Leverandøren din håndterer de serverrelaterte delene. DNS-postene og håndteringen av avmelding er dine. Selv om du langt fra er oppe i 5 000 om dagen, er det enkleste sikre valget å oppfylle reglene for masseavsendere.

Bygg utsendelsen inn i appen din

Når domenet er verifisert:

1. Lagre API-nøkkelen som en hemmelighet på serversiden — aldri i kode for frontenden. Se hva miljøvariabler og hemmeligheter er.
2. Send fra serveren, etter at handlingen som utløser e-posten har lykkes.
3. La ikke brukeren vente på e-post. For alt utover den enkleste appen, legg utsendelsen i kø og prøv på nytt ved midlertidige feil, slik at et tregt svar fra leverandøren ikke bremser registreringen.
4. Logg resultatet — leverandørens meldings-ID og status — uten å logge nøkkelen eller hele meldingsinnhold med personopplysninger.
5. Håndter webhooks for bounces og klager: slutt å sende til adresser som hard-bouncer eller som merker deg som spam.

En prompt som dekker det grunnleggende:

Send transaksjonell e-post med [PROVIDER] ved hjelp av server-hemmeligheten [ENV_NAME], fra "Acme hello@mail.acme.com". Send en velkomst-e-post etter registrering og en bookingbekreftelse etter at en booking er lagret. Hold malene i koden, med en ren tekstversjon ved siden av HTML. Legg utsendelser i kø og prøv midlertidige feil på nytt opptil tre ganger. Logg feil med leverandørens feilmelding, men aldri API-nøkkelen. Legg til et webhook-endepunkt som markerer adresser som uleverbare ved hard bounces og klager, og hopp over disse adressene i fremtiden.

Kontopost — bekreftelseslenker, magiske lenker og tilbakestilling av passord — er en del av innloggingen. Slik legger du til innlogging i appen din forklarer hvordan disse flytene henger sammen; gjør disse lenkene engangsbruk og kortvarige.

Vaner som sikrer leveringsevnen

Autentisering gjør at du blir vurdert. Atferd holder deg i innboksen.

• Send bare det folk forventer. Bekreftede registreringer, tydelig samtykke for markedsføring, ingen kjøpte lister.
• Gjør avmelding enkel på alt som ikke er rent transaksjonelt, og respekter den med en gang.
• Varm opp nye domener. Et helt nytt domene som sender tusenvis av meldinger på dag én ser mistenkelig ut. Start med transaksjonell post og øk volumet gradvis.
• Hold listene rene. Fjern hard bounces umiddelbart, og vurder å fjerne personer som lenge ikke har åpnet noe.
• Skriv som et menneske. Et tydelig emne, et gjenkjennelig avsendernavn, en tekstdel, få bilder og lenker til ditt eget domene. Unngå lenkeforkortere.
• Overvåk. Registrer domenet ditt i Google Postmaster Tools og les DMARC-rapporter av og til.
• Bruk en ekte svar-adresse som noen leser. Svar er et godt signal og nyttig tilbakemelding.

Testing uten å spamme noen

• Bruk leverandørens testmodus eller sandkasse der den finnes, eller send til adresser du eier.
• I utvikling, send til en test-postkasse som fanger alt i stedet for til ekte brukere; en seeded database full av virkelig utseende adresser er en lett måte å e-poste fremmede ved en feil.
• Sjekk hver mal i noen klienter — Gmail på nettet, en mailapp på telefonen, Outlook — og i mørk modus.
• Se på meldingshodene i en testmelding: de viser om SPF, DKIM og DMARC bestod.

Juridiske grunnregler

Regler varierer fra land til land. Overordnet krever markedsføringspost samtykke mange steder, må identifisere avsenderen, og må tilby en fungerende avmelding; transaksjonell e-post behandles annerledes, men bør ikke brukes til å smugle inn markedsføring. Hvis du samler adresser fra en venteliste-side, si hva du vil sende og lagre, og når og hvordan hver person registrerte seg. Når du er i tvil, sjekk reglene der brukerne dine er.

Sjekkliste for e-post

• E-postleverandør valgt; API-nøkkel lagret som hemmelighet på serveren
• Sender fra eget domene eller underdomene, ikke en gratis postkasse
• SPF-, DKIM- og DMARC-poster lagt til og består
• Transaksjonell og markedsføringspost adskilt
• Utsendelser satt i kø og prøvd på nytt; resultater logget
• Webhooks for bounces og klager håndtert
• Avmelding på ikke-transaksjonell post, respektert umiddelbart
• Maler testet i flere klienter; testpost når aldri ekte brukere

Sende e-post fra en Mythex-app

Mythex har ingen innebygd e-postutsendelsestjeneste for appene du bygger, så du tar med en leverandør som Resend, SendGrid eller Postmark. Lagre API-nøkkelen som en prosjekthemmelighet — agenten kan be om den med et hemmelighetskort i chatten — og be om e-postene du trenger med vanlige ord. Dokumentasjonen har en startprompt i send e-post fra appen din. Hvis du kjøpte domenet ditt gjennom Mythex på Pro, kan du legge inn leverandørens TXT- og CNAME-poster i domenets DNS-innstillinger; se egendefinerte domener.

Spørsmål