Så skickar du e-post från din app (och hamnar i inkorgen)

För att skicka e-post från din app på ett tillförlitligt sätt, använd en e-postleverantör i stället för din egen brevlåda, skicka från en adress på din egen domän och lägg till de DNS-poster leverantören ger dig så att SPF, DKIM och DMARC går igenom. Håll transaktionell e-post, som lösenordsåterställningar, kvitton och bekräftelser, skild från marknadsföringsmejl, skicka varje typ bara till personer som förväntar sig den och hantera studsar och avregistreringar. Få autentiseringen rätt först, det är den vanligaste orsaken till att app-e-post hamnar i skräppostmappen.

Transaktionell kontra marknadsföringsmejl

De här två typerna av e-post ser lika ut i koden men behandlas mycket olika av inkorgsleverantörer och enligt lag.

Håll dem isär. Om en marknadsföringskampanj får klagomål om skräppost vill du inte att lösenordsåterställningar från samma flöde drabbas. Ett vanligt upplägg är separata subdomäner, till exempel mail.example.com för kontomejl och news.example.com för nyhetsbrev. Vissa leverantörer separerar de två internt. Postmark beskriver till exempel sina transaktionella och utskickade ”meddelandeströmmar” som separat infrastruktur, från september 2026.

Välja leverantör

Din app bör inte skicka e-post själv från sin egen server. Utskicksleverantörer sköter infrastrukturen, IP-ryktet, återförsök och hantering av studsar. Välkända alternativ är bland andra Postmark, Resend, SendGrid, Amazon SES och Mailgun. Varje har ett HTTP-API och SMTP-åtkomst. Priser och planer ändras, så jämför dem på deras egna webbplatser.

Saker att jämföra:

• Fokus. Vissa leverantörer koncentrerar sig på transaktionell e-post, andra kombinerar transaktionell och marknadsföring.
• Utvecklarupplevelse. Ett tydligt API, officiella bibliotek för ditt språk och användbara loggar som visar om varje meddelande levererades, studsade eller markerades som skräppost.
• Webhooks för studsar, klagomål och leveranser, så att din app kan reagera.
• Mallar, antingen lagrade hos leverantören eller i din egen kod. Att hålla mallarna i koden gör dem versionshanterade och testbara.
• Region och datahantering, om du har krav på var data behandlas.
• Kostnad vid din volym, inklusive vad som händer när du överskrider en gratisnivå.

För nyhetsbrev till en lista passar ett dedikerat nyhets- eller e-postmarknadsföringsverktyg ofta bättre än att bygga kampanjfunktioner i din app.

Konfigurera din avsändardomän

Skicka från din egen domän, till exempel hello@example.com, inte från en Gmail- eller Outlook-adress. E-post från en gratis brevlåda som skickas via en tredjepartstjänst klarar inte autentiseringskontrollerna och filtreras sannolikt bort.

Övervägg en subdomän enbart för utskick. Resend rekommenderar till exempel att man skickar från subdomäner som updates.example.com för att isolera avsändarryktet (från september 2026). Det håller också e-postens DNS-poster åtskilda från din huvudsajts.

Leverantören ger dig sedan DNS-poster att lägga till där din domäns DNS hanteras. Om DNS är nytt för dig förklarar hur domäner och DNS fungerar posterna först.

SPF

SPF (Sender Policy Framework) är en TXT-post som listar vilka servrar som får skicka e-post för din domän. Mottagare kontrollerar om den sändande servern står på listan.

• En domän bör bara ha en SPF-post. Om du lägger till en leverantör, slå ihop den med den befintliga posten i stället för att lägga till en andra.
• SPF tillåter högst 10 DNS-uppslag vid utvärdering. Långa kedjor av include:-poster kan överskrida gränsen och orsaka fel.
• Många leverantörer sätter SPF på en return-path-subdomän som de ber dig skapa, så du kanske inte behöver röra din huvudsakliga SPF-post alls.

DKIM

DKIM (DomainKeys Identified Mail) lägger till en kryptografisk signatur på varje meddelande. Leverantören signerar med en privat nyckel, och du publicerar motsvarande publika nyckel som en DNS-post (TXT eller CNAME, beroende på leverantör). Mottagare kontrollerar signaturen för att bekräfta att meddelandet kom från en godkänd avsändare och inte ändrats på vägen.

DKIM är det din leverantörs steg ”verifiera domän” till största delen handlar om. Hoppa inte över det.

DMARC

DMARC binder ihop de andra två. Det är en TXT-post på _dmarc.yourdomain.com som talar om för mottagare:

• Anpassning: domänen i den synliga avsändaradressen måste matcha domänen som klarade SPF eller DKIM.
• Policy: vad som ska göras med meddelanden som inte klarar kontrollerna: p=none (bara rapportera), p=quarantine (behandla som misstänkt, ofta skräppost) eller p=reject.
• Rapporter: vart samlade rapporter ska skickas (rua=), så att du ser vem som skickar som din domän.

Ett förnuftigt upplägg är att börja med p=none och en rapportadress, bekräfta att ditt legitima mejl går igenom och sedan gå över till quarantine och till slut reject. En strikt policy gör det dessutom mycket svårare för andra att förfalska din domän.

Vad Gmail kräver

Från september 2026 säger Googles avsändarriktlinjer:

• Alla avsändare till privata Gmail-konton behöver SPF eller DKIM, giltiga framåt- och bakåt-DNS för de sändande servrarna, TLS och en skräppostandel under 0,3 % i Postmaster Tools.
• Massavsändare (fler än 5 000 meddelanden per dag till Gmail) behöver SPF och DKIM, en DMARC-post (en p=none-policy är tillåten), anpassning av från-domänen samt avregistrering med ett klick och en synlig avregistreringslänk i marknadsföringsmejl och prenumerationsmejl.

Din leverantör sköter de serverbaserade delarna. DNS-posterna och hanteringen av avregistreringar är ditt ansvar. Även om du är långt ifrån 5 000 om dagen är det enklaste sättet att vara på säkra sidan att uppfylla reglerna för massavsändare.

Bygg in utskicket i din app

När domänen är verifierad:

1. Lagra API-nyckeln som en hemlighet på servern, aldrig i frontend-kod. Se vad miljövariabler och hemligheter är.
2. Skicka från servern, efter att åtgärden som utlöser mejlet har lyckats.
3. Låt inte användaren vänta på e-post. För allt utöver den enklaste appen, köa utskicket och gör om vid tillfälliga fel, så att ett långsamt svar från leverantören inte bromsar registreringen.
4. Logga resultatet: leverantörens meddelande-ID och status, utan att logga nyckeln eller hela meddelanden som innehåller personuppgifter.
5. Hantera webhooks för studsar och klagomål: sluta skicka till adresser som ger hårda studsar eller markerar dig som skräppost.

En prompt som täcker grunderna:

Skicka transaktionell e-post med [LEVERANTÖR] med serverhemligheten [MILJÖVARIABELNAMN], från ”Acme hello@mail.acme.com”. Skicka ett välkomstmejl efter registrering och en bokningsbekräftelse när en bokning sparats. Behåll mallarna i koden, med en textversion vid sidan av HTML. Köa utskicken och gör om tillfälliga fel upp till tre gånger. Logga fel med leverantörens felmeddelande men aldrig API-nyckeln. Lägg till en webhook-endpoint som markerar adresser som inte går att leverera vid hårda studsar och klagomål, och hoppa över dem i framtida utskick.

Kontomejl, till exempel bekräftelselänkar, magiska länkar och lösenordsåterställningar, är en del av inloggningen. Så lägger du till inloggning i din app förklarar hur de flödena hänger ihop. Gör länkarna engångsbara och kortlivade.

Vanor som ger bra leverans

Autentisering gör att du bedöms som seriös. Ditt beteende avgör om du stannar i inkorgen.

• Skicka bara det folk förväntar sig. Bekräftade registreringar, tydligt samtycke till marknadsföring och inga köpta listor.
• Gör det enkelt att avregistrera på allt som inte är strikt transaktionellt, och respektera det direkt.
• Värm upp nya domäner. En helt ny domän som skickar tusentals meddelanden första dagen ser misstänkt ut. Börja med ditt transaktionella mejl och öka volymen successivt.
• Håll listorna rena. Ta bort hårda studsar direkt och överväg att ta bort personer som inte öppnat något på länge.
• Skriv som en människa. En tydlig ämnesrad, ett igenkännbart avsändarnamn, en textdel, få bilder och länkar till din egen domän. Undvik länkförkortare.
• Övervaka. Registrera din domän i Google Postmaster Tools och läs DMARC-rapporterna då och då.
• Använd en riktig svarsadress som någon faktiskt läser. Svar är en bra signal och användbar återkoppling.

Testa utan att skicka skräppost till någon

• Använd leverantörens testläge eller sandlåda där det finns ett.
• I utveckling, skicka till en testinkorg som tar emot allt i stället för riktiga användare. En seedad databas full av verkligt utseende adresser är ett enkelt sätt att av misstag skicka mejl till främlingar.
• Kontrollera varje mall i några klienter: Gmail i webbläsaren, en mejlapp i telefonen, Outlook och i mörkt läge.
• Titta på rubrikerna i ett testmejl. De visar om SPF, DKIM och DMARC godkändes.

Juridiska grunder

Reglerna skiljer sig mellan länder. I stora drag kräver marknadsföringsmejl samtycke på många håll, måste identifiera avsändaren och ska erbjuda en fungerande avregistrering. Transaktionell e-post behandlas på ett annat sätt, men bör inte användas för att smyga in marknadsföring. Om du samlar adresser via en väntelistesida, säg vad du kommer att skicka och lagra, och när och hur varje person registrerade sig. Kontrollera reglerna där dina användare finns när du är osäker.

Checklista för e-post

• Utskicksleverantör vald; API-nyckeln lagrad som serverhemlighet
• Skickar från din egen domän eller subdomän, inte från en gratis brevlåda
• SPF-, DKIM- och DMARC-poster tillagda och godkända
• Transaktionell och marknadsföring separerade
• Utskick köade och återförsökta; resultat loggade
• Webhooks för studsar och klagomål hanterade
• Avregistrering på icke-transaktionell e-post, respekteras direkt
• Mallar testade i flera klienter; testmejl når aldrig riktiga användare

Skicka e-post från en Mythex-app

Mythex har ingen inbyggd utskicksfunktion för de appar du bygger, så du tar med en leverantör, till exempel Resend, SendGrid eller Postmark. Lagra dess API-nyckel som en projekthemlighet. Agenten kan be om den med ett hemlighetskort i chatten, och du beskriver de mejl du behöver med enkla ord. Dokumentationen har en startprompt i skicka e-post från din app. Om du köpt din domän via Mythex på Pro kan du lägga till leverantörens TXT- och CNAME-poster i domänens DNS-inställningar. Se egna domäner.

Frågor