Sådan sender du e-mails fra din app (og havner i indbakken)

For at sende e-mails fra din app pålideligt skal du bruge en e-mailudbyder i stedet for din egen postkasse, sende fra en adresse på dit eget domæne og tilføje de DNS-poster, udbyderen giver dig, så SPF, DKIM og DMARC alle består. Hold transaktionel mail — nulstilling af adgangskode, kvitteringer, bekræftelser — adskilt fra markedsføringsmail, send hver type kun til personer, der forventer den, og håndtér bounces og afmeldinger. Få autentificeringen rigtig først; det er den hyppigste årsag til, at app-mail havner i spam.

Transaktionel vs. markedsføringsmail

De to typer ligner hinanden i koden, men behandles meget forskelligt af indbakkeudbydere og i loven.

Hold dem adskilt. Hvis en markedsføringskampagne får spam-klager, vil du ikke have, at nulstillinger af adgangskode fra samme stream også lider under det. En almindelig tilgang er separate subdomæner — for eksempel mail.example.com til kontomail og news.example.com til nyhedsbreve — og nogle udbydere adskiller de to internt. Postmark beskriver fx sine transaktionelle og broadcast-"message streams" som kørende på adskilt afsendelsesinfrastruktur, fra september 2026.

Valg af udbyder

Din app bør ikke sende e-mail direkte fra sin egen server. Afsendelsesudbydere står for infrastrukturen, IP-omdømmet, genforsøg og bounce-håndtering. Velkendte muligheder inkluderer Postmark, Resend, SendGrid, Amazon SES og Mailgun; hver har en HTTP-API og SMTP-adgang, og priser og planer ændrer sig, så sammenlign dem på deres egne sider.

Det skal du sammenligne:

• Fokus. Nogle udbydere koncentrerer sig om transaktionel mail; andre kombinerer transaktionel og markedsføring.
• Udvikleroplevelse. En klar API, officielle biblioteker til dit sprog og nyttige logs, der viser om hver besked blev leveret, afvist eller markeret som spam.
• Webhooks for bounces, klager og leverancer, så din app kan reagere.
• Skabeloner — gemt hos udbyderen eller i din egen kode. At have dem i koden gør dem versionerede og testbare.
• Region og databehandling, hvis du har krav om, hvor data behandles.
• Pris ved dit volumen, inklusive hvad der sker, når du overskrider en gratis grænse.

Til nyhedsbreve til en liste passer et dedikeret nyheds- eller e-mail-marketingværktøj ofte bedre end at bygge kampagnefunktioner ind i din app.

Opsæt dit afsenderdomæne

Send fra dit eget domæne — hello@example.com, ikke en Gmail- eller Outlook-adresse. Mail fra en gratis postkasseadresse, sendt via en tredjepartstjeneste, fejler autentificeringstjek og bliver sandsynligvis filtreret fra.

Overvej et subdomæne kun til afsendelse. Resend anbefaler fx at sende fra subdomæner som updates.example.com for at isolere afsendelsesomdømmet (fra september 2026). Det holder også e-mail-DNS-posterne adskilt fra din hovedsides.

Udbyderen giver dig derefter DNS-poster, du skal tilføje hos der, hvor dit domæne administreres. Hvis DNS er nyt for dig, forklarer hvordan domæner og DNS virker posterne først.

SPF

SPF (Sender Policy Framework) er en TXT-post, der lister hvilke servere, der må sende e-mail for dit domæne. Modtagere tjekker, om den afsendende server står på listen.

• Et domæne bør kun have én SPF-post. Hvis du tilføjer en udbyder, skal du flette den ind i den eksisterende post i stedet for at tilføje en ekstra.
• SPF tillader højst 10 DNS-opslag, når den evalueres; lange kæder af include:-led kan overskride det og forårsage fejl.
• Mange udbydere sætter SPF på et return-path-subdomæne, som de beder dig oprette, så du måske slet ikke rører din hoved-SPF-post.

DKIM

DKIM (DomainKeys Identified Mail) tilføjer en kryptografisk signatur til hver besked. Udbyderen signerer med en privat nøgle; du publicerer den tilsvarende offentlige nøgle som en DNS-post (TXT eller CNAME, afhængigt af udbyderen). Modtagere tjekker signaturen for at bekræfte, at beskeden kom fra en autoriseret afsender, og at den ikke blev ændret undervejs.

DKIM er hovedsageligt det, udbyderens "verificér domæne"-trin handler om. Spring det ikke over.

DMARC

DMARC binder de to andre sammen. Det er en TXT-post på _dmarc.dindomæne.dk, der fortæller modtagere:

• Alignment: domænet i den synlige From-adresse skal matche det domæne, der bestod SPF eller DKIM.
• Politik: hvad der skal ske med mail, der fejler — p=none (bare rapportér), p=quarantine (behandl som mistænkelig, ofte spam) eller p=reject.
• Rapporter: hvor aggregerede rapporter skal sendes (rua=), så du kan se, hvem der sender som dit domæne.

En fornuftig vej er at starte med p=none og en rapporteringsadresse, bekræfte at din legitime mail består, og så gå til quarantine og til sidst reject. En streng politik gør det også meget sværere for andre at spoofe dit domæne.

Hvad Gmail kræver

Fra september 2026 siger Googles afsenderretningslinjer:

• Alle afsendere til personlige Gmail-konti skal have SPF eller DKIM, gyldig fremad- og bagudrettet DNS for afsendende servere, TLS, og en spam-rate i Postmaster Tools under 0,3 %.
• Masseafsendere (mere end 5.000 beskeder om dagen til Gmail) skal have SPF og DKIM, en DMARC-post (en p=none-politik er tilladt), From-domæne-alignment, og one-click afmelding plus et synligt afmeldingslink i markedsførings- og abonnementsbeskeder.

Din udbyder håndterer de serverside-dele. DNS-posterne og håndteringen af afmeldinger er dine. Selv hvis du er langt fra 5.000 om dagen, er det enkleste at opfylde masseafsender-reglerne for at være på den sikre side.

Byg afsendelsen ind i din app

Når domænet er verificeret:

1. Gem API-nøglen som en serverhemmelighed — aldrig i front-end-kode. Se hvad miljøvariabler og hemmeligheder er.
2. Send fra serveren, efter at handlingen, der udløser e-mailen, er lykkedes.
3. Lad ikke brugeren vente på e-mailen. Til alt ud over den simpleste app bør du sætte afsendelsen i kø og genforsøge ved midlertidige fejl, så et langsomt svar fra udbyderen ikke bremser tilmeldingen.
4. Log resultatet — udbyderens besked-ID og status — uden at logge nøglen eller hele beskeder med personlige data.
5. Håndtér webhooks for bounces og klager: stop med at sende til adresser, der har hard bounce eller har markeret dig som spam.

En prompt, der dækker det grundlæggende:

Send transaktionel e-mail med [PROVIDER] ved brug af server-hemmeligheden [ENV_NAME], fra "Acme hello@mail.acme.com". Send en velkomstmail efter tilmelding og en bookingbekræftelse, når en booking er gemt. Behold skabeloner i koden, med en almindelig tekstversion ved siden af HTML. Sæt afsendelser i kø og genforsøg midlertidige fejl op til tre gange. Log fejl med udbyderens fejlbesked, men aldrig API-nøglen. Tilføj et webhook-endpoint, der markerer adresser som ulevérbare ved hard bounces og klager, og spring dem over fremover.

Kontomail — bekræftelseslinks, magic links og nulstilling af adgangskode — er en del af login. Sådan tilføjer du login til din app gennemgår, hvordan disse flows hænger sammen; gør disse links engangsbrugt og kortlivede.

Vaner for leverbarhed

Autentificering får dig i betragtning. Adfærd holder dig i indbakken.

• Send kun det, folk forventer. Bekræftede tilmeldinger, klart tilvalg til markedsføring, ingen købte lister.
• Gør det nemt at afmelde alt, der ikke er rent transaktionelt, og respektér det med det samme.
• Varm nye domæner op. Et helt nyt domæne, der sender tusindvis af beskeder på dag ét, ser mistænkeligt ud. Start med din transaktionelle mail og øg volumen gradvist.
• Hold listerne rene. Fjern hard bounces straks, og overvej at fjerne personer, der ikke har åbnet noget i lang tid.
• Skriv som et menneske. En klar emnelinje, et genkendeligt From-navn, en almindelig tekstdel, få billeder og links til dit eget domæne. Undgå link-forkortere.
• Overvåg. Registrér dit domæne i Google Postmaster Tools, og læs DMARC-rapporterne nu og da.
• Brug en rigtig svar-adresse, som nogen læser. Svar er et godt signal og nyttig feedback.

Test uden at spamme nogen

• Brug din udbyders testtilstand eller sandkasse, hvor den findes, eller send til adresser, du selv ejer.
• Under udvikling skal du sende til en catch-all testindbakke i stedet for rigtige brugere; en seedet database fuld af virkeligt udseende adresser er en nem måde at sende e-mail til fremmede ved en fejl.
• Tjek hver skabelon i et par klienter — Gmail på nettet, en mailapp på telefonen, Outlook — og i mørk tilstand.
• Kig på beskedheaderne i en testmail: de viser, om SPF, DKIM og DMARC bestod.

Juridiske grundprincipper

Reglerne varierer fra land til land. Generelt kræver markedsføringsmail samtykke mange steder, skal identificere afsenderen og skal tilbyde en fungerende afmelding; transaktionel mail behandles anderledes, men må ikke bruges til stille og roligt at smugle markedsføring ind. Hvis du indsamler adresser fra en venteliste-side, skal du sige, hvad du vil sende og gemme, og hvornår og hvordan hver person tilmeldte sig. Når du er i tvivl, så tjek reglerne der, hvor dine brugere befinder sig.

Tjekliste for e-mail

• Afsendelsesudbyder valgt; API-nøglen gemt som serverhemmelighed
• Afsendelse fra eget domæne eller subdomæne, ikke en gratis postkasse
• SPF, DKIM og DMARC-poster tilføjet og består
• Transaktionel og markedsføringsmail adskilt
• Afsendelser sat i kø og genforsøgt; resultater logget
• Webhooks for bounces og klager håndteret
• Afmelding på alt ikke-transaktionelt, respekteret med det samme
• Skabeloner testet i flere klienter; testmail når aldrig rigtige brugere

Afsend e-mail fra en Mythex-app

Mythex indeholder ikke en indbygget e-mailafsendelsestjeneste til de apps, du bygger, så du medbringer en udbyder som Resend, SendGrid eller Postmark. Gem dens API-nøgle som en projekthemmelighed — agenten kan bede om den med et hemmelighedskort i chatten — og bed om de e-mails, du har brug for, med almindelige ord. Dokumentationen har en startprompt i send e-mail fra din app. Hvis du har købt dit domæne gennem Mythex på Pro, kan du tilføje udbyderens TXT- og CNAME-poster i domænets DNS-indstillinger; se custom domains.

Spørgsmål