SPF, DKIM en DMARC zijn ingesteld, maar mail belandt nog in spam

E-mailauthenticatie: waarom ingestelde SPF, DKIM en DMARC niet genoeg zijn

Je hebt er werk van gemaakt. Urenlang heb je in DNS cryptische tekenreeksen van je e-mailproviders gekopieerd. Je hebt controles uitgevoerd en overal groene vinkjes gekregen. Waarom dalen de openingspercentages dan toch? Waarom belanden transactionele berichten, zoals wachtwoordherstel, facturen en meldingen, in de spammap of verdwijnen ze helemaal?

Dit is de harde waarheid over e-mailauthenticatie met SPF, DKIM en DMARC: een geldige configuratie staat niet gelijk aan een goede reputatie. Een geldig identiteitsbewijs garandeert ook niet dat iemand een club binnenkomt. Sinds februari 2024 hebben providers als Google en Yahoo hun eisen voor grote afzenders aangescherpt, terwijl Microsoft eigen signalen en beleidsregels hanteert. Zie je groene lampjes in je dashboard maar rode cijfers in je omzet, dan loop je waarschijnlijk tegen een van de minder zichtbare controles naast deze basisprotocollen aan.

De valkuil voor bulkafzenders: de grens ligt lager dan je denkt

Een gevaarlijke misvatting luidt: "Ik verstuur minder dan 5,000 berichten per dag, dus de regels voor bulkmail gelden niet voor mij."

Dat klopt om twee redenen niet, en zelfs een correcte SPF-, DKIM- en DMARC-configuratie beschermt je niet tegen deze valkuil. Ten eerste telt Google het volume op het niveau van het hoofddomein. Verstuur je 2,000 marketingberichten via news.example.com, 2,000 transactionele berichten via app.example.com en 1,500 interne meldingen via corp.example.com, dan val je onder de regels voor bulkafzenders. Subdomeinen worden bij het hoofddomein opgeteld.

Ten tweede geldt de hoogste bereikte grens. Overschrijdt je hoofddomein eenmaal de drempel van 5,000 berichten, bijvoorbeeld door een Black Friday-campagne of een eenmalige database-update, dan blijft Google het als bulkafzender behandelen. De strengere vereisten blijven dus gelden, ook wanneer het volume later daalt naar 50 berichten per dag.

Microsoft beoordeelt afzenders met een eigen combinatie van signalen. Je SPF-, DKIM- en DMARC-records kunnen foutloos zijn, maar ook de leeftijd en reputatie van een IP-adres kunnen meewegen. Verstuur je vanaf een nieuw domein en IP-adres meteen 2,000 berichten, dan kun je 4xx-beperkingen krijgen, ongeacht een geslaagde SPF-controle. Een nieuwe afzender heeft nog geen opgebouwde reputatie.

Waar SPF, DKIM en DMARC misgaan: de ijzeren driehoek

Veel beheerders stellen SPF, DKIM en DMARC in, controleren de syntaxis en kijken er vervolgens niet meer naar om. Maar geldige syntaxis garandeert nog geen goede werking. Op deze punten gaat het vaak fout.

SPF: het zwarte gat van doorsturen

SPF is in feite een lijst met toegestane IP-adressen. Het record zegt bijvoorbeeld: "IP 1.2.3.4 mag voor example.com verzenden." Dat werkt goed totdat iemand automatisch doorsturen instelt.

Je stuurt een factuur naar client@smallbiz.com. Die klant laat alle post doorsturen naar client@gmail.com. Gmail ziet dan de verbinding vanaf het IP-adres van smallbiz.com en niet vanaf dat van jou. Bij de controle van jouw SPF-record staat smallbiz.com niet vermeld, waardoor SPF kan mislukken. Als je alleen op SPF vertrouwt, kan doorgestuurde mail in spam belanden of worden geweigerd. Je hebt een geldige, uitgelijnde DKIM-handtekening nodig om het bericht de doorstuurstap te laten doorstaan. Lees voor de volledige configuratie onze handleiding voor SPF-records.

DKIM: het probleem met domeinuitlijning

DMARC controleert twee zaken: of SPF of DKIM volgens RFC 6376 slaagt en of de domeinen op elkaar aansluiten. Uitlijning betekent dat het domein in de From-header overeenkomt met de relevante technische domeinen, namelijk Return-Path voor SPF en d= voor DKIM.

Een herkenbaar helpdeskscenario: je gebruikt een CRM zoals Zendesk of HubSpot om te verzenden als support@yourcompany.com. Het CRM verwerkt bounces, waardoor Return-Path bounces.zendesk.com is en SPF niet uitlijnt. Zonder aangepaste CNAME ondertekent DKIM met d=zendesk.com, zodat ook DKIM niet uitlijnt. Het bericht is technisch door Zendesk geauthenticeerd, maar DMARC ziet geen geslaagd mechanisme dat bij jouw domein aansluit. Met beleid p=reject kan het bericht daarom worden geweigerd.

De limiet van 10 DNS-opzoekingen

SPF heeft volgens RFC 7208 een harde bovengrens van 10 DNS-opzoekingen per evaluatie. Bureaus met klanten die veel SaaS-diensten gebruiken, lopen hier snel tegenaan. Google Workspace kan alleen al 4 opzoekingen gebruiken. Voeg Mailchimp, HubSpot, een ticketsysteem en een HR-tool toe:

Elk include:-mechanisme veroorzaakt een DNS-opzoeking, en een opgenomen record kan zelf weer andere records opnemen. Komt de evaluatie boven 10 uit, dan retourneert de ontvangende server PermError. In de praktijk biedt SPF dan niet de verwachte geldige uitkomst. Door alles zorgvuldig toe te voegen kun je de configuratie dus juist ongeldig maken.

Verborgen controles naast SPF, DKIM en DMARC

Naast de drie bekende protocollen bestaan technische vereisten zonder opvallende marketingnaam die de bezorging eveneens kunnen tegenhouden.

FCrDNS (Forward-Confirmed Reverse DNS)

Een verzendend IP-adres hoort een PTR-record te hebben dat naar een hostnaam verwijst, terwijl het A-record van die hostnaam terugwijst naar het oorspronkelijke IP-adres. Deze controle helpt de infrastructuur consistent te identificeren. Zet je een virtuele machine in de cloud op, installeer je Postfix en verstuur je zonder PTR-record, dan kan Gmail het verkeer als verdacht behandelen en bijvoorbeeld 550 5.7.1 retourneren.

RFC 8058: met één klik afmelden

Sinds juni 2024 is voor marketingmail van bepaalde bulkafzenders een link in de voettekst alleen niet genoeg. De relevante berichten moeten twee specifieke headers bevatten:

Het HTTPS-eindpunt moet een POST-verzoek accepteren en niet afhankelijk zijn van GET. Antispambots controleren berichten soms door links te volgen. Als afmelden via GET meteen effect heeft, kunnen bots echte gebruikers onbedoeld uitschrijven. Kunnen gebruikers zich niet eenvoudig afmelden, dan kiezen ze eerder voor "Spam melden", waardoor het klachtenpercentage richting 0.3% kan gaan.

De grens van 0.3%: de economie van reputatie

Perfecte SPF-, DKIM- en DMARC-controles, correcte FCrDNS en geldige headers helpen niet genoeg als ontvangers je berichten ongewenst vinden.

Een belangrijke maatstaf is het percentage spamklachten. Google adviseert dit onder 0.3% te houden, oftewel minder dan 3 klachten per 1,000 bezorgde berichten, en bij voorkeur aanzienlijk lager. Een herhaaldelijk te hoog percentage kan tot beperkingen of blokkades leiden.

De noemervalkuil in Yahoo-rapportage

Het weergegeven klachtenpercentage kan afhangen van welke bezorgde berichten een provider in de noemer opneemt. Stel dat je 1,000 berichten verstuurt. Je domeinreputatie is al zwak, 900 berichten komen in spam terecht en 100 in de inbox. Eén ontvanger klaagt. Binnen die illustratieve inboxgroep is de berekening 1/100 = 1.0%, oftewel 3x de handhavingsgrens. Controleer daarom de definities in het dashboard van de provider en kijk niet alleen naar het totale verzendvolume.

Het probleem van de luidruchtige buur

Zelfs met correct ingestelde SPF, DKIM en DMARC kan je mail bij standaard gedeelde hosting of een goedkoop "onbeperkt" platform vanaf hetzelfde IP-adres vertrekken als die van duizenden andere klanten. Als een van hen misbruik pleegt en het IP-adres op een blokkeerlijst belandt, kan ook jouw bezorging verslechteren. Je hebt niets verkeerd gedaan, maar deelt wel de reputatie van de infrastructuur. Hoe groot dit risico is, hangt af van het toezicht en de isolatie van de provider.

De vrijdagchecklist voor SPF, DKIM en DMARC

1. Controleer de headers: stuur een bericht naar een persoonlijk Gmail-adres. Open het bericht, klik op de drie puntjes en kies "Origineel weergeven". Zoek Authentication-Results. Slaagt SPF? Slaagt DKIM? Komt het domein bij dkim= overeen met header.from? Zo niet, dan is er waarschijnlijk een uitlijningsprobleem.

2. Controleer FCrDNS: voer dig -x <your-sending-ip> uit. Geeft dit een hostnaam terug? Voer daarna dig <that-hostname> uit. Verwijst die weer naar het IP-adres? Herstel het DNS als de kring niet sluit voordat je het verzendvolume verhoogt.

3. Scheid verkeersstromen: verstuur marketing bij voorkeur niet via je primaire bedrijfsdomein. Gebruik team@company.com voor persoonlijke zakelijke mail en newsletter@marketing.company.com voor campagnes. Als marketing de grens van 0.3% bereikt, helpt de scheiding de reputatie van het hoofddomein te beschermen, al vormt ze geen absolute garantie.

4. Lees verder: bekijk voor praktisch reputatieherstel onze handleiding voor afzenderreputatie en onze uitgebreide uitleg over domeinreputatie voor e-mail.

TrekMail-abonnementen

De beschreven betaalde abonnementen hebben een proefperiode van 14 dagen waarvoor een kaart nodig is. Voor Free is geen kaart vereist. Controleer altijd de actuele prijzen en voorwaarden.

Conclusie

E-mailauthenticatie met SPF, DKIM en DMARC is geen eenmalige instelling, maar doorlopend beheer. Geslaagde controles zijn slechts de basis. Voor een goede kans op bezorging in de inbox zijn correcte domeinuitlijning, verzorgd netwerkbeheer met FCrDNS, headers voor afmelden met één klik en actief reputatiebeheer nodig. Geen enkele afzonderlijke maatregel garandeert plaatsing in de inbox. Controleer de resultaten en houd grip op je infrastructuur.

Groene vinkjes voor SPF, DKIM en DMARC zijn het toegangsbewijs, niet de eindstreep. Probeer TrekMail gratis en beheer je e-mailauthenticatie doelgericht.