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

Stel je de migratie voor waar engineers wakker van liggen. Op vrijdagmiddag zet je de schakelaar om: alle transactionele e-mail loopt voortaan via de nieuwe provider, en jij gaat naar huis. Maandagochtend stromen de supporttickets binnen: wachtwoordresets belanden in spam, facturen zijn nooit aangekomen en een flink deel van je inlogcodes is gebounced. Niemand heeft de inhoud van de e-mails veranderd. Je bent alleen van provider gewisseld, 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 dat heet de canary deploy. Je rolt de wijziging uit naar een klein deel van het verkeer, houdt de dashboards in de gaten en breidt pas uit als de cijfers standhouden. Datzelfde idee werkt uitstekend voor e-mail. Stuur een kleine fractie van je berichten via de nieuwe provider, vergelijk de afleverbaarheid met je huidige basislijn en draai de knop telkens één stap verder open. Tegen de tijd 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 ten opzichte van je oude provider en schaal in een paar weken op naar 100%. Beide providers blijven de hele tijd live, dus terugrollen kan onmiddellijk.

Waarom de big-bang-overstap zo riskant is

Drie factoren maken 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 verzenddomein en IP op hun recente geschiedenis, en een gloednieuwe opzet heeft die niet. Een plotselinge stroom mail van een onbekende bron oogt verdacht, dus zelfs volkomen legitieme berichten kunnen regelrecht in spam belanden. Afhankelijk van je volume is dit ook een warming-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 in één keer slaat die warming-up volledig over, en je mail wordt afgeknepen of gebounced totdat de reputatie is bijgetrokken. Een geleidelijke migratie is, handig genoeg, een warming-up in vermomming.

Configuratiefouten blijven verborgen tot het volume ze vindt. Een SPF-record dat nét niet klopt, een DKIM-sleutel die sommige berichten wel en andere niet ondertekent, een suppressielijst die stilletjes niet is meegekomen: 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, midden in het incident. Een gewogen verdeling houdt beide providers naast elkaar in de lucht, dus terugschakelen is een configuratiewijziging van een paar seconden, 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 die één beslissing, op basis van 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 loopt via AhaSend, terwijl de rest het oude pad volgt. Bekijk de cijfers, en zodra die van AhaSend er gezond uitzien, 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 genoeg tijd 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 op orde zijn.

Authenticeer je domein bij AhaSend, hetzelfde verzenddomein 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 tegelijkertijd via meerdere providers mail authenticeren, 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 ook maar één canary-bericht verstuurt. 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 apart kunnen bekijken, tag dan je AhaSend-verzendingen met de header ahasend-tags (bijvoorbeeld migration,canary) en filter daarop in je logs en rapporten. Sla het gerust over als je het simpel wilt houden. Het heeft geen enkel 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 zit. 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 naar AhaSend wilt sturen, opgeslagen op een plek die je zonder nieuwe deploy 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 het oude pad volgt. De knop verzetten betekent één waarde veranderen en verder niets, en juist die eigenschap maakt elke volgende 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"

Eén verfijning is het vermelden waard. Per bericht beslissen is prima voor de meeste transactionele mail, maar wil je een bepaalde gebruiker 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, zet die om naar een waarde tussen 0 en 100 en vergelijk dat met je drempelwaarde. Dezelfde gebruiker komt dan elke keer bij dezelfde provider uit, totdat jij besluit de knop te verzetten.

Alles wat hierna komt, 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 bij AhaSend aan te leveren. 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 per bericht simpelweg de SMTP-host en credentials van de gewenste provider. De SMTP-servergids behandelt credentials, verbindingslimieten, de speciale headers die je per bericht kunt meegeven 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 heeft bereikt, 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 nodig heeft voordat je opschaalt.

Het bouncepercentage, gesplitst in hard en soft, onthult problemen met lijstkwaliteit en configuratie. Hard bounces die alleen bij AhaSend-verkeer optreden wijzen meestal op een domein- of authenticatieprobleem en niet op slechte adressen, want exact dezelfde ontvangers komen bij de andere provider wél aan. Lees deze af in 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 verdergaat.

Deferrals en bezorgtijd maken het beeld compleet. Een korte piek 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.

Sluit webhooks aan voor delivered-, bounce- 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 de canary-stroom exact isoleren in je eigen dashboards.

Stap 4: opschalen, toetsen en terugrollen

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

Controleer voor elke verhoging de voorwaarde van 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. Wordt aan een voorwaarde niet voldaan, blijf dan op het huidige niveau of zet een stap terug, in plaats van door te drukken en te hopen.

Terugrollen is het makkelijke deel, en dat gemak is precies het 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 opnieuw mailt naar een adres 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 mee verhuizen. Verwijder daarna de credentials van de oude provider, schrap de legacy-tak uit 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 al helemaal geen vrijdagmiddaggok moeten zijn. Behandel het als een canary deploy: stuur een klein aandeel verkeer naar de nieuwe provider, bewaak afleverbaarheid, bounces en klachten ten opzichte van 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, kun je onmiddellijk terugrollen 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 op 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 →