Outbound e-mail audit: Outlook deferrals 2026 voorkomen

Dinsdag, 09:14. Finance vraagt: "Zijn de betalingsherinneringen van gisteren wel echt verstuurd?" De operations lead opent het verzenddashboard. 6.200 berichten verzonden, 98% afgeleverd. Ziet er prima uit. Dan belt een klant terug, boos over een tweede herinnering voor een factuur waarvan ze de eerste herinnering nooit heeft gezien. Open haar domein. Outlook. Spamfolder. Elf herinneringen liggen daar sinds vrijdagmiddag.

Dit is het telefoontje dat we tegenwoordig het vaakst krijgen. Niet "we willen AI-agents". Gewoon: onze factuur-incasso werkt niet meer en niemand kan ons vertellen waar het misgaat.

Voordat we een factuur-agent offreren voor een Nederlands MKB onder de €30M, auditen we hun outbound mailomgeving. Niet als sales gate. Als overlevingscheck. Het heeft geen zin een klant een beleefde, goed geschreven agent te geven die 800 facturen per week in Outlook-quarantaine schopt.

Dit is de audit, in de volgorde waarin wij 'm draaien.

Wat er veranderde in 2026

Microsoft rolde in 2026 strengere sender-eisen uit voor inkomende mail op Exchange Online. Kort samengevat: senders die geen DMARC alignment halen, geen serieus DMARC-beleid publiceren, of vanaf slecht geconfigureerde shared IP's versturen, krijgen vaker een deferral (4xx) of een directe rejection (5xx). Outlook.com ging als eerste om. Exchange Online-tenants volgen.

Het lijkt sterk op de Google/Yahoo bulk-sender push uit 2024, maar de failure mode is anders. Google zet je mail stilletjes in spam. Outlook defert 'm. Deferred mail blijft in een retry-queue hangen en komt uiteindelijk wel aan, uren of dagen later, meestal nadat de klant al heeft betaald (of allang niet meer heeft betaald en koud is geworden).

Die vertraging is precies het stuk dat je finance lead niet ziet. Het deliverability-dashboard staat op groen. De herinneringen zijn technisch gezien afgeleverd. Alleen kwamen ze om 03:40 op zaterdag aan, in een spamfolder, wat hetzelfde is als helemaal niet aankomen.

De DNS-basis

Open een terminal. Dit is het eerste dat we draaien.

dig TXT +short klant-domein.nl
dig TXT +short _dmarc.klant-domein.nl
dig TXT +short selector1._domainkey.klant-domein.nl
dig TXT +short selector2._domainkey.klant-domein.nl

SPF: één record, onder de 10 DNS lookups als je 'm uitvouwt, met daarin elke legitieme sender. De fout die we vaak zien: een oude include:spf.protection.outlook.com die nog rondhangt sinds een Office 365-migratie uit 2021, plus include:_spf.google.com uit een Workspace-pilot, plus een vergeten include:mailgun.org van een vendor die niemand heeft opgezegd, plus de include van de SaaS-facturatietool. Vijf includes, makkelijk 11 lookups, stille SPF PermError. Ontvangers verlagen je alignment en niemand snapt waarom.

DKIM: een 2048-bit key per verzendbron, elk op een eigen selector. Twee faalpatronen overheersen. Eén gedeelde 1024-bit key die iedereen hergebruikt (rotatie is onmogelijk zonder drie vendors tegelijk plat te leggen). Of helemaal geen DKIM op de transactionele sender, omdat iemand tijdens de onboarding "niet kon vinden waar de DNS moest". Microsoft noemt dit in z'n enforcement-notes letterlijk op. Het Exchange-team schrijft er al bijna een jaar over op de Microsoft Tech Community-blog.

DMARC: gepubliceerd, met een echt beleid en een rua=-adres dat iemand daadwerkelijk leest. p=none is prima in week één. p=quarantine; pct=100 is waar we klanten binnen 90 dagen willen hebben. p=reject is waar de audit op groen eindigt. BIMI is een vanity-laagje erbovenop, geen deliverability-hefboom, dus die auditen we als laatste.

Is één van die drie kapot, dan heeft de rest van de audit geen zin. Fix de basis eerst.

Alignment, niet alleen authenticatie

Hier stoppen de meeste interne audits en hier beginnen de meeste externe problemen. SPF slaagt is niet hetzelfde als SPF aligned. DKIM signeert is niet hetzelfde als DKIM aligned. De ontvanger checkt of het geauthenticeerde domein matcht met het domein in de From:-header. Gaan je factuur-herinneringen uit vanaf factuur@klant-domein.nl maar signeert DKIM ze met d=mg.transactional-vendor.com, dan faalt DMARC op alignment, ook al zijn beide checks technisch geslaagd.

We trekken een sample van de echte uitgaande mail van de klant (met toestemming, vanuit een verse testinbox) en lezen de Authentication-Results header met de hand uit. Ja, met de hand. Negentig seconden werk, vangt op wat de meeste automatische scanners missen.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@mg.transactional-vendor.com;
  spf=pass smtp.mailfrom=bounces.transactional-vendor.com;
  dmarc=fail (p=none dis=none) header.from=klant-domein.nl

Dat is een fail. SPF en DKIM zijn allebei geslaagd. DMARC faalt omdat het geauthenticeerde domein niet matcht met het From-domein. Onder het nieuwe Outlook-beleid wordt die mail gedeferd. Onder het beleid van Google komt 'ie in spam. Zelfde uitkomst.

De fix is óf: de vendor laten signen met een CNAME'd selector onder het eigen domein van de klant (mail._domainkey.klant-domein.nl CNAME naar de selector van de vendor), óf de From wijzigen naar een subdomein dat de vendor beheert (wat brand recognition sloopt; voor factuurflows raden we dat nooit aan).

Reputation drift over providers heen

Zodra de basis solide is, kijken we waar de mail daadwerkelijk vandaan vertrekt. De meeste Nederlandse MKB's die we auditen sturen transactionele mail via een mengelmoes: Microsoft 365 SMTP voor "echte" mail, één ESP voor transactioneel, en Amazon SES voor een herinneringsscript dat iemand in 2023 in haast in elkaar heeft gezet.

Elke provider heeft een ander reputation-profiel. Elke drift anders.

Postmark

Draait gescheiden IP's voor transactionele en broadcast-streams en houdt senders streng in de gaten. Reputation drift gaat hier langzaam en is duidelijk zichtbaar. Je krijgt waarschuwingsmails voordat er iets kapotgaat. De nadelen: prijs bij volume, en een harde lijn op alles wat naar marketing ruikt op een transactionele stream. We hebben een klant gehad die werd opgeschort omdat zijn betalingsherinneringen-template één regel cross-sell bevatte. Postmark noemde dat broadcast. Ze hadden gelijk.

Mailgun

Flexibel, en dat is meteen het probleem. Shared pools hebben luidruchtige buren. We hebben gezien hoe de factuur-herinneringen van een klant in een deferral-golf terechtkwamen op Mailgun's EU shared pool, omdat een totaal andere tenant op hetzelfde /24-blok een slechte campagne had gedraaid. Dedicated IP's helpen, maar je moet ze opwarmen, en de meeste MKB's onder de €30M hebben niet genoeg volume om een dedicated IP warm te houden zonder de planning op te rekken.

Amazon SES

De goedkoopste en de meest onverbiddelijke. Reputatie zit per account. Klachten boven de 0,1% leveren een vriendelijke waarschuwing op. Boven de 0,5% word je gepauzeerd. De appeal is een support ticket. Wij zetten geen factuur-incasso op kale SES zonder een configuration set, een SNS-gekoppelde bounce handler en een klachtendashboard dat de operations lead daadwerkelijk eens per week opent.

De val onder alle drie: de meeste klanten kunnen ons niet vertellen welke provider wat verstuurt. Het marketingplatform stuurt via de één. De boekhoudtool via de ander. Het CRM via een derde. De Microsoft 365-mailbox via een vierde. Elk heeft een eigen DKIM-selector nodig, een eigen SPF-include en een eigen reputatie-check. Voordat we ook maar iets offreren, mappen we dit op een whiteboard. Dat kost meestal twee uur en verrast iedereen in de kamer, ook de IT-lead.

De drie flows die een deferral moeten overleven

Nu de interessante vraag. Stel: Outlook begint vanaf maandagochtend 40% van je mail te deferren. Welke transactionele flows zou je finance lead diezelfde dag opmerken, en welke gaan een week lang stilletjes kapot?

Over de circa zestig mailomgevingen die we de afgelopen twee jaar hebben geauditeerd, zijn er drie flows die een plotselinge deferral moeten overleven, anders raakt het bedrijf echt schade op:

1. Password resets. Als die drie uur defer-en, staat je support-inbox in vuur en vlam. Operations heeft het snel door. Goed nieuws: de meeste providers routeren password resets via hun strengste transactionele stream. Slecht nieuws: als iemand auth-providers migreert (Auth0 naar Clerk, Cognito naar Supabase), is dit de flow die vergeten wordt en uiteindelijk via een half-geconfigureerd SES sandbox-account loopt.

2. Betaalbevestigingen. Een klant heeft net betaald. Die verwacht binnen een minuut een bevestiging. Defer-en bevestigingen twaalf uur, dan denkt de klant dat de betaling is mislukt en betaalt óf opnieuw (refund-gedoe) óf doet chargeback (erger). De receipt-flow auditen we altijd als eerste, omdat het noticing-window het kortst is.

3. Factuur-herinneringen. De flow waarvoor de klant dacht ons in te huren. Tegenintuïtief is dit juist de flow die een deferral het beste overleeft qua zichtbaarheid. Een herinnering die twaalf uur te laat de deur uitgaat, verandert niet of de klant vandaag betaalt. Het verandert of ze überhaupt betalen, maar de finance lead ziet dat signaal pas na dertig dagen, en tegen die tijd zijn er drie factuurcycli over de vervaldatum gedreven.

Loopt de reminder-flow van een klant als enige via SES met een wankele reputatie, dan zeggen we: verhuis 'm eerst en automatiseer 'm daarna. Het heeft geen zin een agent te leren weloverwogen, goed getimede duwtjes te schrijven die dinsdagavond aankomen terwijl ze maandagochtend gepland stonden.

De daadwerkelijke checklist

De audit, gedistilleerd. Dit kun je in een middag tegen je eigen omgeving aanhouden.

[ ] Eén SPF-record per verzenddomein, onder de 10 lookups
[ ] DKIM-signing op elke transactionele bron (2048-bit, eigen selector)
[ ] DMARC gepubliceerd, rua= naar een gemonitorde inbox
[ ] DMARC alignment slaagt op een gesamplede From:-domein-test
[ ] Subdomein-strategie vastgelegd (mail., billing., notify., etc.)
[ ] Eén ESP-account per business-doel, niet per developer
[ ] Bounce + complaint webhooks gekoppeld aan een dashboard dat iemand leest
[ ] Reputatie-snapshot uit Google Postmaster Tools + Microsoft SNDS
[ ] Password reset-flow end-to-end getest op een Outlook.com-inbox
[ ] Receipt-flow end-to-end getest op een Hotmail-inbox
[ ] Reminder-flow getest met een echt klantdomein in de set

Die laatste telt het zwaarst. De meeste interne "deliverability tests" sturen naar Gmail en noemen het klaar. Gmail is de makkelijke ontvanger. Outlook is de vijandige. Hotmail, Live, MSN, de rest van de Microsoft-omgeving. Daar testen of niet testen.

Wat we met de resultaten doen

Toen we dit voorjaar de factuur-agent bouwden voor een Nederlandse bouwdienstverlener, ving de audit een Mailgun pool-probleem af: hun receipt mail werd gedeferd op een shared pool omdat een totaal andere marketing-tenant op hetzelfde account de week ervoor was geflagd. We verhuisden de receipts naar Postmark, hielden de herinneringen op een opgewarmde dedicated IP, en de eerste run van de agent haalde 71% open rate. Het meeste van ons werk rond e-mailautomatisering begint hier, bij de DNS-basis, voordat er ook maar één agent is geschreven.

Wil je dit vandaag tegen je eigen omgeving draaien, pak dan de receipt-flow. Stuur er één vanuit je live systeem naar een vers Outlook.com-adres, open dan de raw headers en lees de Authentication-Results-regel. Zie je dmarc=fail of dmarc=none, dan heb je een middag werk voor de boeg. De agent komt daarna.