Hoe je van e-mailprovider wisselt zonder je deliverability te riskeren

Stel je de migratie voor waar engineers wakker van liggen. Je zet vrijdagmiddag de knop om, richt alle transactionele e-mail op de glimmende nieuwe provider en gaat naar huis. Maandag staat de support in brand: wachtwoordresets belanden in spam, facturen kwamen nooit aan en een flink deel van je inlogcodes is gebounced. Niemand veranderde de inhoud van de e-mails. Je verhuisde alleen van provider, in één keer, en je gebruikers betaalden de rekening.

Zo hoeft het niet te gaan. Je team heeft al een draaiboek om risicovolle wijzigingen veilig uit te rollen, en het heet de canary deploy. Je rolt de wijziging uit naar een sliver van het verkeer, bekijkt de dashboards en breidt pas uit als de cijfers standhouden. Datzelfde idee werkt prachtig voor e-mail. Stuur een minuscule fractie van je berichten via de nieuwe provider, meet de afleverbaarheid tegen je huidige basislijn en draai de knop telkens één stap verder open. Op het moment dat je 100% bereikt, is de overstap een non-event, en dat is het grootste compliment dat je een migratie kunt geven.

Deze gids loopt die aanpak van begin tot eind door, met AhaSend als bestemming, en behandelt zowel de HTTP API als SMTP.

TL;DR: Doe je e-mailmigratie niet in één big bang. Zet een gewogen router voor je providers, aangestuurd door één getal. Begin met 5% naar AhaSend, bewaak afleverbaarheid, bounces en klachten tegen je oude provider en schaal in een paar weken op naar 100%. Beide providers blijven de hele tijd live, dus terugrollen is onmiddellijk.

Waarom de big-bang overstap zo riskant is

Drie krachten maken samen een overstap van de ene op de andere dag gevaarlijk, en alle drie zijn ze onzichtbaar tot er echt verkeer binnenkomt.

Reputatie verhuist niet mee. Mailboxproviders zoals Gmail en Outlook beoordelen een verzendend domein en IP op hun recente geschiedenis, en een gloednieuwe opzet heeft die niet. Een plotselinge vloed aan mail van een onbekende bron oogt verdacht, dus zelfs volkomen legitieme berichten kunnen regelrecht in spam glijden. Afhankelijk van je volume is dit ook een warm-upprobleem. Verzenders met veel volume introduceren een nieuw IP of domein normaal gesproken geleidelijk over dagen of weken, zodat de reputatie meegroeit met het volume. Een overstap van de ene op de andere dag slaat die warm-up volledig over, en je mail wordt afgeknepen of bounced totdat de reputatie is bijgetrokken. Een geleidelijke migratie is, handig genoeg, een warm-up in vermomming.

Configuratiefouten blijven verborgen tot het volume ze vindt. Een SPF-record dat bijna klopt, een DKIM-sleutel die sommige berichten wel en andere niet ondertekent, een suppressielijst die stilletjes niet meekwam: niets daarvan komt naar boven als je jezelf een testmail stuurt, en alles komt naar boven op schaal. AhaSend neemt een hele categorie van deze pijn weg. Je kunt niet versturen via een domein waarvan de DNS niet correct is geconfigureerd, want wij controleren dat continu, de hele dag door. Een kapot domein faalt snel en luid in plaats van een week lang stilletjes je inboxplaatsing te ondermijnen.

Je raakt je vangnet kwijt. Met één provider en één overstap is je rollback-plan opnieuw een spoeddeploy, onder druk, terwijl het incident loopt. Gewogen verdeling houdt beide providers naast elkaar draaiende, dus terugtrekken is een configuratiewijziging die je in seconden maakt en geen brandoefening.

Het kernidee: een canary deploy voor e-mail

Zet een kleine router tussen je applicatie en je e-mailproviders. Voor elk bericht neemt hij één beslissing tegen een percentage dat jij beheert: gaat dit bericht naar AhaSend, of blijft het bij je huidige provider? Zet de knop op 5% en ongeveer één op de twintig berichten stroomt via AhaSend terwijl de rest het oude pad volgt. Bekijk de cijfers, en zodra die van AhaSend gezond ogen, draai je de knop verder open.

Een verstandig opschaalpad ziet er zo uit:

De exacte percentages zijn minder belangrijk dan de discipline erachter: verander één ding tegelijk, geef elke fase lang genoeg om problemen bloot te leggen en ga pas door als de data schoon is.

Voordat je begint

De canary vertelt je alleen de waarheid als het fundament klopt, dus zorg dat deze drie dingen eerst staan.

Authenticeer je domein bij AhaSend, hetzelfde verzendende domein dat je nu gebruikt. Voeg de SPF-, DKIM- en DMARC-records toe die AhaSend levert en verifieer daarna het domein in het dashboard. Eén domein kan tegelijk mail authenticeren via meerdere providers, en die overlap is precies wat een geleidelijke migratie mogelijk maakt. De gids voor domeininstellingen bevat de records.

Maak je verzendcredentials aan. Voor de HTTP API genereer je een API v2-sleutel zoals beschreven in de gids voor API-sleutels. Voor SMTP maak je SMTP-credentials aan volgens de gids voor SMTP-credentials.

Bepaal hoe je succes meet voordat je één canary-bericht stuurt. Je wilt afleverbaarheid, bouncepercentage en klachtenpercentage per provider naast elkaar zien. AhaSend biedt afleverbaarheidsrapporten, bouncerapporten en realtime webhooks voor delivery-, bounce- en klachtgebeurtenissen. Haal dezelfde cijfers op bij je huidige provider, zodat je altijd appels met appels vergelijkt.

Eén optionele toevoeging, en optioneel is het echt: wil je je migratieverkeer later uit de rest kunnen lichten, tag dan je AhaSend-verzendingen met de header ahasend-tags (zoiets als migration,canary) en filter daarop in je logs en rapporten. Sla het zonder aarzelen over als je het liever strak houdt. Het heeft nul effect op de afleverbaarheid, het is puur gemak voor je eigen rapportage.

Stap 1: bepaal hoe verkeer wordt verdeeld

De kern van deze aanpak is een klein stukje routeringslogica dat tussen je applicatie en je e-mailproviders leeft. Telkens als je app een bericht verstuurt, maakt deze logica precies één keuze: AhaSend, of de huidige provider?

Die keuze wordt aangestuurd door één getal, het aandeel verkeer dat je op AhaSend wilt, opgeslagen op een plek die je zonder code uit te rollen kunt aanpassen, zoals een omgevingsvariabele of een feature flag. Voor elk bericht vergelijkt de logica dat getal met een willekeurige trekking. Zet het aandeel op 5 en ongeveer één op de twintig berichten gaat naar AhaSend terwijl de rest blijft staan. De knop verzetten betekent één waarde veranderen en verder niets, en juist die eigenschap maakt elke latere stap veilig en omkeerbaar.

In code is de hele beslissing maar een paar regels:

import os
import random

# Aandeel verkeer naar AhaSend, 0 tot 100. Pas aan zonder deploy.
AHASEND_WEIGHT = float(os.environ["AHASEND_WEIGHT"])

def pick_provider():
    return "ahasend" if random.uniform(0, 100) < AHASEND_WEIGHT else "legacy"

Er is één verfijning die het waard is om te kennen. Per bericht beslissen is prima voor de meeste transactionele mail, maar wil je een bepaalde gebruiker liever de hele migratie bij dezelfde provider houden (handig voor schone vergelijkingen per gebruiker), baseer de beslissing dan op een stabiele sleutel zoals het gebruikers-ID in plaats van een nieuwe willekeurige trekking. Hash de sleutel, map die naar een waarde tussen 0 en 100 en vergelijk dat met je drempelwaarde. Dezelfde gebruiker komt dan elke keer bij dezelfde provider terecht tot je besluit de knop te verzetten.

Alles daarna, de cijfers die je bewaakt en het opschaalpad dat je volgt, hangt af van niets meer dan dat dit ene getal eenvoudig aan te passen blijft.

Stap 2: verstuur via AhaSend

Er zijn twee manieren om een bericht aan AhaSend te overhandigen. De meeste teams kiezen er één op basis van wat hun stack al spreekt, en de router uit stap 1 roept simpelweg het bijbehorende pad aan wanneer hij AhaSend kiest.

Optie A: de HTTP API

De API v2 van AhaSend biedt één create-message-endpoint:

POST https://api.ahasend.com/v2/accounts/{account_id}/messages
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

De gids Send emails using the API loopt de volledige JSON-body, de responsevorm en de opties door die er tijdens een migratie het meest toe doen, waaronder idempotency-sleutels voor veilige retries, batchen tot 100 ontvangers per request en retentiecontrole per bericht, allemaal met voorbeelden om te kopiëren.

Optie B: SMTP

Spreekt je applicatie al SMTP, dan kun je naar AhaSend routeren door alleen de host en credentials te wisselen, zonder iets te veranderen aan hoe je het bericht zelf opbouwt. De SMTP-relay van AhaSend gebruikt deze instellingen:

Host: send.ahasend.com
Poorten: 25, 587 of 2525
Encryptie: STARTTLS (verplicht)
Authenticatie: PLAIN

Je routeringslogica kiest gewoon de SMTP-host en credentials van welke provider voor elk bericht. De SMTP-servergids behandelt credentials, verbindingslimieten, de speciale headers die je per bericht kunt zetten en kant-en-klare voorbeelden voor elke grote programmeertaal.

Stap 3: bewaak de juiste cijfers

Een canary is zo goed als de meters die je afleest. Vergelijk in elke fase deze cijfers tussen AhaSend en je huidige provider over hetzelfde tijdvak.

Afleverbaarheid is het belangrijkste cijfer. Het is het aandeel geaccepteerde berichten dat de mailboxprovider daadwerkelijk bereikte, en bij een gezonde migratie zit AhaSend binnen één of twee punten van je huidige provider. Een hardnekkig verschil betekent dat er iets in je opzet aandacht wil voordat je opschaalt.

Het bouncepercentage, gesplitst in hard en soft, onthult problemen met lijstkwaliteit en configuratie. Hard bounces die alleen op AhaSend-verkeer verschijnen wijzen meestal op een domein- of authenticatieprobleem en niet op slechte adressen, want exact dezelfde ontvangers slagen bij de andere provider. Lees deze uit het bouncerapport.

Het klachtenpercentage is je harde stop. Markeren ontvangers AhaSend-mail vaker als spam dan je basislijn, pauzeer dan het opschalen en duik in inhoud, authenticatie en lijsthygiëne voordat je een stap verdergaat.

Deferrals en bezorgtijd maken het beeld compleet. Een korte stijging in deferrals tijdens een nieuwe opschaling kan normaal zijn terwijl de reputatie wordt opgebouwd, maar een aanhoudende stijging is een waarschuwingssignaal. De statistieken over bezorgtijd van AhaSend laten zien hoe snel mail daadwerkelijk aankomt.

Koppel webhooks aan voor delivered-, bounced- en klachtgebeurtenissen, zodat problemen je binnen minuten bereiken in plaats van pas aan het eind van de dag. En heb je je migratieverkeer getagd met ahasend-tags, dan kun je precies de canary-schijf isoleren in je eigen dashboards.

Stap 4: opschalen, toetsen en terugrollen

Doorschakelen is niet meer dan de aandeelwaarde aanpassen en de configuratie opnieuw uitrollen, of een feature flag omzetten als je die hebt aangelegd. Houd één regel heilig: verander nooit het percentage, een berichtsjabloon én je domeinrecords in dezelfde zet. Eén variabele tegelijk houdt oorzaak en gevolg leesbaar terwijl je de cijfers afleest.

Bevestig voor elke verhoging de voorwaarde voor de huidige fase. Afleverbaarheid in lijn met de oude provider, bounces in hun normale bereik, klachten laag en deferrals stabiel over een representatief tijdvak dat ook je piekmomenten bevat. Faalt een voorwaarde, houd dan vast of zet een stap terug in plaats van door te drukken en te hopen.

Terugrollen is het makkelijke deel, en dat gemak is het hele punt van deze aanpak. Zet het aandeel op 0 en elk bericht stroomt weer naar je huidige provider, zonder spoeddeploy en zonder paniek om 2 uur 's nachts. Onderzoek rustig, los het probleem op en hervat het opschalen wanneer je er klaar voor bent.

Stap 5: maak het af

Heb je eenmaal een rustige week op 100% gedraaid, rond het dan netjes af. Zorg dat de suppressie-afhandeling volledig bij AhaSend ligt, zodat je nooit een adres opnieuw mailt dat is gebounced of heeft geklaagd. AhaSend beheert suppressies automatisch, en je kunt bekende slechte adressen importeren uit je oude provider zodat die zwaarbevochten reputatielessen meeverhuizen. Verwijder daarna de credentials van de oude provider, schrap de legacy-tak van je router en laat de gewogen router staan. De volgende keer dat je een configuratiewijziging wilt testen, ligt de knop al klaar.

De conclusie

Migreren van transactionele e-mail hoeft geen sprong in het diepe te zijn, en het zou zeker geen vrijdagmiddaggok moeten zijn. Behandel het als een canary deploy: stuur een klein aandeel verkeer naar de nieuwe provider, bewaak afleverbaarheid, bounces en klachten tegen je huidige basislijn en verhoog het aandeel pas als de data het verdient. Met een gewogen router die door één configuratiewaarde wordt aangestuurd blijven beide providers de hele tijd live, is terugrollen onmiddellijk en is de uiteindelijke overstap de rustigste deploy die je dit kwartaal uitrolt.

AhaSend is gebouwd voor precies dit soort zorgvuldige, door developers geleide migraties: een schone API v2 en SMTP-relay, continue DNS-verificatie zodat een verkeerd geconfigureerd domein je nooit stilletjes kan schaden, optionele tagging en retentiecontrole per bericht, realtime webhooks en de afleverbaarheids- en bouncerapporten om je canary aan af te lezen. Met de free tier krijg je 1.000 e-mails per maand om je eerste 5% doorheen te sturen. Begin gratis met AhaSend →