E-mails versturen vanuit je app (en in de inbox terechtkomen)

Om e-mails vanuit je app betrouwbaar te versturen, gebruik je een e-mailverzendprovider in plaats van je eigen mailbox, verstuur je vanaf een adres op je eigen domein en voeg je de DNS-records toe die de provider aanlevert, zodat SPF, DKIM en DMARC allemaal slagen. Houd transactionele e-mail — wachtwoordresets, bonnen, bevestigingen — gescheiden van marketing-e-mail, verstuur elk alleen naar mensen die het verwachten, en verwerk bounces en uitschrijvingen. Zorg eerst dat de authenticatie klopt; dat is de meest voorkomende reden waarom app-e-mail in de spam belandt.

Transactionele versus marketing-e-mail

Deze twee soorten e-mail lijken in de code op elkaar, maar worden door inboxproviders en door de wet heel verschillend behandeld.

Hou ze uit elkaar. Als een marketingcampagne spamklachten krijgt, wil je niet dat wachtwoordresets uit dezelfde stream daar onder lijden. Een gangbare aanpak is aparte subdomeinen — bijvoorbeeld mail.example.com voor accountmail en news.example.com voor nieuwsbrieven — en sommige providers scheiden de twee intern. Postmark beschrijft bijvoorbeeld zijn transactionele en broadcast "message streams" als draaiend op aparte verzendinfrastructuur, vanaf september 2026.

Een provider kiezen

Je app moet niet zelf vanaf de eigen server e-mail verzenden. Verzendproviders regelen de infrastructuur, de IP-reputatie, nieuwe pogingen en het verwerken van bounces. Bekende opties zijn Postmark, Resend, SendGrid, Amazon SES en Mailgun; elk heeft een HTTP-API en SMTP-toegang. Prijzen en abonnementen veranderen, dus vergelijk ze op hun eigen sites.

Wat je moet vergelijken:

• Focus. Sommige providers richten zich op transactionele e-mail; andere combineren transactioneel en marketing.
• Developer-ervaring. Duidelijke API, officiële bibliotheken voor jouw taal, bruikbare logs die laten zien of elk bericht is afgeleverd, gebounced of als spam is gemarkeerd.
• Webhooks voor bounces, klachten en afleveringen, zodat je app erop kan reageren.
• Templates — opgeslagen bij de provider, of in je eigen code. Ze in code bewaren maakt ze versioneerbaar en testbaar.
• Regio en gegevensverwerking, als je eisen hebt over waar gegevens worden verwerkt.
• Kosten bij jouw volume, inclusief wat er gebeurt als je de gratis tier overschrijdt.

Voor nieuwsbrieven naar een lijst past een aparte nieuwsbrief- of e-mailmarketingtool vaak beter dan campagnefuncties in je app bouwen.

Stel je verzenddomein in

Verstuur vanaf je eigen domein — hello@example.com, niet een Gmail- of Outlook-adres. E-mail vanaf een gratis mailboxadres die via een externe dienst wordt verstuurd, faalt bij de authenticatiecontroles en wordt waarschijnlijk gefilterd.

Overweeg een subdomein alleen voor verzending. Resend adviseert bijvoorbeeld om vanaf subdomeinen zoals updates.example.com te verzenden om de verzendreputatie te isoleren (vanaf september 2026). Zo blijven de e-mail-DNS-records ook gescheiden van die van je hoofdsite.

De provider geeft je vervolgens DNS-records om toe te voegen bij de plek waar de DNS van je domein wordt beheerd. Als DNS nieuw voor je is, legt hoe domeinen en DNS werken eerst de records uit.

SPF

SPF (Sender Policy Framework) is een TXT-record met de servers die namens jouw domein e-mail mogen versturen. Ontvangers controleren of de verzendende server op de lijst staat.

• Een domein moet maar één SPF-record hebben. Als je een provider toevoegt, voeg die dan samen met het bestaande record in plaats van een tweede record toe te voegen.
• SPF staat bij de evaluatie maximaal 10 DNS-lookups toe; lange ketens van include:-verwijzingen kunnen dat overschrijden en storingen veroorzaken.
• Veel providers zetten SPF op een return-path-subdomein dat zij je laten aanmaken, dus je hoeft je hoofd-SPF-record misschien helemaal niet aan te raken.

DKIM

DKIM (DomainKeys Identified Mail) voegt een cryptografische handtekening toe aan elk bericht. De provider ondertekent met een privésleutel; jij publiceert de bijbehorende publieke sleutel als DNS-record (TXT of CNAME, afhankelijk van de provider). Ontvangers controleren de handtekening om te bevestigen dat het bericht van een geautoriseerde afzender komt en onderweg niet is veranderd.

De stap "domein verifiëren" van je provider draait vooral om DKIM. Sla die niet over.

DMARC

DMARC bindt de andere twee aan elkaar. Het is een TXT-record op _dmarc.jouwdomein.com dat ontvangers vertelt:

• Afstemming: het domein in het zichtbare Van-adres moet overeenkomen met het domein dat SPF of DKIM heeft doorstaan.
• Beleid: wat er met mail moet gebeuren die faalt — p=none (alleen rapporteren), p=quarantine (als verdacht behandelen, vaak spam) of p=reject.
• Rapporten: waar geaggregeerde rapporten naartoe moeten worden gestuurd (rua=), zodat je ziet wie namens jouw domein verstuurt.

Een verstandige route is beginnen met p=none en een rapportageadres, controleren of je legitieme mail slaagt, daarna overstappen naar quarantine en uiteindelijk reject. Een strikt beleid maakt het ook veel moeilijker voor anderen om jouw domein te spoofen.

Wat Gmail vereist

Vanaf september 2026 stellen de afzenderrichtlijnen van Google het volgende:

• Alle afzenders naar persoonlijke Gmail-accounts hebben SPF of DKIM nodig, geldige forward- en reverse-DNS voor verzendende servers, TLS, en een spamratio in Postmaster Tools onder 0,3%.
• Bulkafzenders (meer dan 5.000 berichten per dag naar Gmail) hebben SPF én DKIM nodig, een DMARC-record (een beleid p=none is toegestaan), afstemming van het From-domein, en eenklik-uitschrijving plus een zichtbare uitschrijflink in marketing- en abonnementsberichten.

De serverkant regelt je provider. De DNS-records en het afhandelen van uitschrijvingen zijn aan jou. Ook als je ver onder de 5.000 per dag zit, is voldoen aan de bulkregels de eenvoudigste manier om op de veilige kant te blijven.

Bouw het versturen in je app

Zodra het domein is geverifieerd:

1. Sla de API-sleutel op als geheim aan de serverkant — nooit in front-endcode. Zie wat omgevingsvariabelen en geheimen zijn.
2. Verstuur vanaf de server, nadat de actie die de e-mail triggert is geslaagd.
3. Laat de gebruiker niet wachten op e-mail. Voor alles wat meer is dan de simpelste app: zet het versturen in de wachtrij en probeer tijdelijke fouten opnieuw, zodat een trage reactie van de provider de aanmelding niet vertraagt.
4. Log het resultaat — het bericht-ID en de status van de provider — zonder de sleutel of volledige berichtinhoud met persoonsgegevens te loggen.
5. Verwerk webhooks voor bounces en klachten: stop met versturen naar adressen die hard bouncen of jou als spam markeren.

Een prompt die de basics dekt:

Verstuur transactionele e-mail met [PROVIDER] via het servergeheim [ENV_NAME], vanaf "Acme hello@mail.acme.com". Verstuur een welkomstmail na aanmelding en een boekingsbevestiging nadat een boeking is opgeslagen. Bewaar templates in code, met een platte-tekstversie naast de HTML. Zet verzendingen in de wachtrij en probeer tijdelijke fouten tot drie keer opnieuw. Log fouten met de foutmelding van de provider, maar nooit de API-sleutel. Voeg een webhook-endpoint toe dat adressen als onbezorgbaar markeert bij hard bounces en klachten, en sla die adressen in de toekomst over.

Account-e-mails — verificatielinks, magic links en wachtwoordresets — horen bij het inloggen. Hoe je inloggen aan je app toevoegt legt uit hoe die stromen samenhangen; maak deze links eenmalig bruikbaar en kortstondig.

Gewoontes voor deliverability

Authenticatie zorgt dat je serieus wordt genomen. Gedrag houdt je in de inbox.

• Verstuur alleen wat mensen verwachten. Bevestigde aanmeldingen, duidelijke opt-in voor marketing, geen gekochte lijsten.
• Maak uitschrijven makkelijk bij alles wat niet strikt transactioneel is, en respecteer het meteen.
• Warm nieuwe domeinen op. Een gloednieuw domein dat op de eerste dag duizenden berichten verstuurt, lijkt verdacht. Begin met je transactionele mail en laat het volume geleidelijk groeien.
• Houd lijsten schoon. Verwijder hard bounces direct en overweeg mensen te verwijderen die al lange tijd niets hebben geopend.
• Schrijf als een mens. Een duidelijk onderwerp, een herkenbare Van-naam, een platte-tekstdeel, weinig afbeeldingen en links naar je eigen domein. Vermijd linkverkorters.
• Monitor. Registreer je domein in Google Postmaster Tools en lees af en toe de DMARC-rapporten.
• Gebruik een echt antwoordadres dat iemand leest. Antwoorden zijn een goed signaal en nuttige feedback.

Testen zonder iemand te spammen

• Gebruik de testmodus of sandbox van je provider waar die bestaat, of verstuur naar adressen die van jou zijn.
• Verstuur in ontwikkeling naar een catch-all testinbox in plaats van naar echte gebruikers; een gevulde database met echt ogende adressen is een makkelijke manier om per ongeluk vreemden te mailen.
• Controleer elke template in een paar clients — Gmail in de browser, een mailapp op de telefoon, Outlook — en in de donkere modus.
• Bekijk de berichtheaders van een testmail: die laten zien of SPF, DKIM en DMARC zijn geslaagd.

Juridische basics

De regels verschillen per land. In grote lijnen heeft marketing-e-mail op veel plaatsen toestemming nodig, moet de afzender worden genoemd en moet er een werkende uitschrijving zijn; transactionele e-mail wordt anders behandeld, maar mag niet worden gebruikt om stiekem marketing in te smokkelen. Als je adressen verzamelt via een wachtlijstpagina, leg dan vast wat je zult versturen en opslaan, en wanneer en hoe elke persoon zich heeft aangemeld. Controleer bij twijfel de regels waar je gebruikers zitten.

E-mailchecklist

• Verzendprovider gekozen; API-sleutel opgeslagen als servergeheim
• Verzenden vanaf je eigen domein of subdomein, niet vanaf een gratis mailbox
• SPF-, DKIM- en DMARC-records toegevoegd en geslaagd
• Transactionele en marketingmail gescheiden
• Verzendingen in de wachtrij gezet en opnieuw geprobeerd; resultaten gelogd
• Webhooks voor bounces en klachten verwerkt
• Uitschrijving bij niet-transactionele mail, meteen gerespecteerd
• Templates getest in meerdere clients; testmail bereikt nooit echte gebruikers

E-mail versturen vanuit een Mythex-app

Mythex bevat geen ingebouwde e-mailverzendservice voor de apps die je bouwt, dus breng je zelf een provider mee, zoals Resend, SendGrid of Postmark. Sla de API-sleutel op als projectgeheim — de agent kan er via een geheimenkaart in de chat om vragen — en vraag in gewone woorden om de e-mails die je nodig hebt. De documentatie heeft een startprompt in e-mail versturen vanuit je app. Als je je domein via Mythex hebt gekocht op Pro, kun je de TXT- en CNAME-records van de provider toevoegen in de DNS-instellingen van het domein; zie eigen domeinen.

Veelgestelde vragen