De bulkverzenderregels van Google en Yahoo uitgelegd: wat bedrijven moeten doen om e-mail bezorgbaar te houden
Belangrijkste punten
- •Google en Yahoo definiëren bulkverzenders als domeinen die ongeveer 5.000 of meer berichten per dag versturen, waarbij het volume wordt geteld over alle mailstromen op het primaire domein in plaats van per server.
- •Compliance vereist SPF, DKIM, een gepubliceerd DMARC-record, overeenkomende From-header-alignment, one-click unsubscribe-headers voor marketingmail en geldige forward- en reverse-DNS.
- •Spamklachten moeten onder 0,1% blijven in Google Postmaster Tools, want bij 0,3% volgt automatische spamplaatsing ongeacht de authenticatiestatus.
- •Niet-compliante mailstromen krijgen oplopende straffen: 4xx-uitstelcodes, plaatsing in spamfolders en uiteindelijk 5xx hard bounces.
- •Microsoft zal in 2025 vergelijkbare SPF-, DKIM- en DMARC-eisen handhaven voor Outlook.com-bulkverzenders, waarmee de regels verder reiken dan Google en Yahoo.

Komen uw uitgaande e-mails terug met 550-foutcodes? Melden ontvangers dat uw berichten in de ongewenste map belanden in plaats van in hun inbox? Daar is een duidelijke reden voor. In februari 2024 stopten Google en Yahoo met het behandelen van e-mailauthenticatie als optioneel — het is nu een harde eis. Voor elk bedrijf dat afhankelijk is van e-mail, schaden deze veranderingen de bezorgbaarheid en daarmee de omzet als u ze negeert.
Kernpunten:
- Google en Yahoo vereisen dat bulkverzenders uitgaande mail authenticeren met SPF en DKIM en een DMARC-record publiceren.
- De drempel van 5.000 berichten per dag voor bulkverzenders omvat al het gecombineerde verkeer over uw primaire domein.
- Spamklachten in Google Postmaster Tools moeten onder 0,1% blijven; bij 0,3% treden automatische bezorgbaarheidsmaatregelen in bij ontvangende gateways.
- Marketing- en abonnementse-mails moeten RFC 8058 one-click unsubscribe-headers ondersteunen.
- Beginnen met p=none voldoet aan de basiscompliance, maar overstappen op p=quarantine of p=reject is belangrijk om domeinspoofing te voorkomen en langetermijndomeinreputatie op te bouwen.
Wat er is veranderd en waarom: de Gmail/Yahoo-verzenderregels
Waarom bestaan deze regels? De oorzaak ligt in hoe e-mail oorspronkelijk is ontworpen. Simple Mail Transfer Protocol (SMTP), gestandaardiseerd in 1982 via RFC 821, had geen ingebouwd mechanisme om de identiteit van de afzender te verifiëren. Elke mailserver kon een bericht versturen dat beweerde van elk willekeurig e-mailadres afkomstig te zijn, en ontvangende gateways accepteerden dit — waardoor iedereen met weinig moeite een domeinnaam in de zichtbare header kon vervalsen.
Beveiligingsengineers hebben dit structurele gebrek door de jaren heen hersteld. SPF verscheen midden jaren 2000 om verzendende IP-adressen te valideren aan de hand van een openbare DNS-lijst. DKIM volgde, met publieke-sleutelcryptografie waarmee verzenders uitgaande headers konden ondertekenen. In 2012 publiceerden grote spelers in de sector DMARC om SPF- en DKIM-controles te koppelen en domeineigenaren een manier te geven handhavingsbeleid in te stellen.
Jarenlang behandelden inboxproviders deze standaarden als optioneel. Domeinen met SPF en DKIM verdienden bonuspunten; domeinen zonder bereikten de inbox meestal nog steeds, mits het IP-adres schoon was.
Daar kwam in februari 2024 een einde aan. Zoals uiteengezet in de e-mailrichtlijnen voor verzenders van Google, verschoven inboxproviders authenticatie van een aanbeveling naar een harde toegangseis.
In plaats van niet-geauthenticeerde mail in één keer te blokkeren, voerden providers de handhaving gefaseerd in. Begin 2024 begonnen ze de verbindingssnelheid te vertragen en tijdelijke 4xx-uitstelcodes terug te sturen op niet-geauthenticeerde streams. In de daaropvolgende maanden escaleerden ze naar strenge 5xx-weigeringscodes en automatische spamplaatsing. Microsoft richtte zijn gatewayfilters snel op dezelfde standaarden af voor hoogvolumeverzenders en heeft sindsdien aangekondigd dat Outlook.com in 2025 vergelijkbare SPF-, DKIM- en DMARC-eisen gaat handhaven voor bulkverzenders — een teken dat deze regels een branchebrede norm worden in plaats van een beleid van alleen Google en Yahoo.
Wie telt als bulkverzender volgens de Gmail-richtlijnen
Google definieert een bulkverzender als elk domein dat ongeveer 5.000 of meer berichten binnen een venster van 24 uur naar persoonlijke Gmail-accounts verstuurt; Yahoo hanteert een vergelijkbare norm. Maar alleen op dat getal focussen is een veelgemaakte fout.
Ten eerste wordt het volume berekend over het hele hoofddomein, niet per IP-adres of serverhostnaam. Als een marketingplatform 3.500 nieuwsbrieven verstuurt terwijl een applicatieserver 2.000 wachtwoordresets of factuurbevestigingen onder hetzelfde domein verstuurt, is de drempel overschreden.
Ten tweede geldt de regel voor alle uitgaande mail, niet alleen marketing. Systeemmeldingen, klantontvangsten en dagelijkse zakelijke e-mails tellen allemaal mee voor de dagelijkse limiet. Elk domein dat dicht bij 3.000 berichten per dag verstuurt, dient volledige authenticatie in te richten alsof het al over de limiet heen is.
De kernvereisten voor e-mailverzenders
Om aan de bulkverzendereisen van Google en Yahoo te voldoen, moet de e-mailinfrastructuur zes technische controles doorstaan:
- Stel geldige SPF-records en DKIM-sleutelparen in voor alle uitgaande mailstromen.
- Publiceer een geldig DMARC TXT-record in de DNS van het domein.
- Zorg dat het domein in de zichtbare "From:"-header overeenkomt met het domein dat door SPF of DKIM is geauthenticeerd.
- Houd spamklachten van gebruikers onder 0,1% in Google Postmaster Tools en laat ze nooit 0,3% bereiken.
- Voeg native one-click unsubscribe-headers toe aan alle marketing- en nieuwsbriefmail.
- Zorg dat verzendende server-IP's overeenkomende A/AAAA-records en geldige reverse-DNS (PTR)-records hebben.
Wat er gebeurt als u niet voldoet
Het mislukken van authenticatiecontroles schaadt de domeinreputatie bij ontvangende mailservers, doorgaans in drie stappen:
- Ontvangende servers reageren met 4xx-uitstelcodes; de wachtrijen lopen vol en de levering wordt met uren vertraagd.
- Berichten passeren de gateway, maar worden omgeleid naar de spammap van de ontvanger in plaats van de primaire inbox.
- Mailservers verbreken de verbinding volledig en geven 5xx hard bounce-fouten terug.
Hoe u aan elke eis voldoet: stap voor stap
1. Configureer SPF en let op de limiet van 10 lookups
Voeg een DNS TXT-record toe aan de domeinroot met elk geautoriseerd IP-adres en elke externe mailleverancier. Let op de limiet van 10 DNS-lookups: de SPF RFC beperkt records tot maximaal 10 externe DNS-query's (include, a, mx, redirect). Overschrijding veroorzaakt een SPF PermError, die ontvangende servers behandelen als een authenticatiefout. Controleer het record periodiek en verwijder verouderde vendor-includes om onder de limiet te blijven.
2. Stel DKIM-ondertekening in op alle uitgaande kanalen
DKIM ondertekent uitgaande e-mailheaders met een cryptografische handtekening en moet worden ingeschakeld voor elk platform dat namens het domein mail verstuurt. Genereer een 2048-bits DKIM-sleutelpaar in uw e-mailserviceportaal en publiceer de publieke sleutel als CNAME- of TXT-record in DNS. Zodra DNS is gepropageerd, schakelt u ondertekening in de beheerconsole in en inspecteert u de ruwe headers van een teste-mail om te bevestigen dat de DKIM-Signature-header aanwezig is en slaagt.
3. Publiceer een DMARC-record
Om te voldoen aan de basis-DMARC-eis die Gmail en Yahoo afdwingen, publiceert u een DMARC TXT-record op _dmarc.uwdomein.nl. Bij een eerste installatie is het verstandig te beginnen met een monitoringbeleid (p=none) om rapportagegegevens te verzamelen zonder de e-maillevering te riskeren. Test de DNS-invoer vóór livegang met een openbare DMARC-recordchecker om syntaxisfouten op te sporen.
4. Voeg RFC 8058 one-click unsubscribe-headers toe
Een gewone HTML-afmeldlink onderaan een e-mail is niet voldoende voor marketingmail. Twee ruwe mailheaders moeten in de uitgaande stream worden geïnjecteerd:
List-Unsubscribe:
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Wanneer clients zoals Gmail of Yahoo deze headers parsen, tonen ze een opvallende "Afmelden"-knop naast de naam van de afzender in de inbox-UI. Klikken hierop verstuurt een geautomatiseerd POST-verzoek naar de server, waardoor de abonnent direct wordt verwijderd zonder een browservenster te openen.
5. Verifieer forward en reverse DNS
Ontvangende servers controleren of het verzendende IP-adres overeenkomt met het domein in DNS. Het IP moet via een PTR-record naar een geldige hostnaam verwijzen, en die hostnaam moet via een standaard DNS A-record terug naar hetzelfde IP-adres verwijzen. Beheerders van dedicated mailservers of cloudinstances kunnen de reverse-DNS-instellingen in de console van hun provider aanpassen of een supportticket openen om het IP toe te wijzen aan de fully qualified domain name (FQDN) van de mailserver.
6. Volg statistieken in Postmaster Tools en DMARC-rapporten
Maak een Google Postmaster Tools-account aan en verifieer het domeineigendom via een DNS TXT-record. Het dashboard geeft direct inzicht in domeinreputatie, spamklachten en authenticatiesuccespercentages. Houd het klachtpercentage onder 0,1%; bij 0,3% stuurt Google mail naar spamfolders, ongeacht de SPF- en DKIM-status. Om authenticatiefouten bij alle ontvangende providers te monitoren en malafide verzendende IP's op te sporen, stelt u geautomatiseerde DMARC-rapportage in.
Voorbij compliance: de regels gebruiken om de bezorgbaarheid te verbeteren
Een p=none-beleid laat een domein onbeschermd tegen spoofing — het zegt ontvangende servers authenticatiegegevens vast te leggen, maar weerhoudt aanvallers er niet van het domein na te bootsen in phishingaanvallen.
Zodra alle legitieme mailstromen door de SPF- en DKIM-alignment komen, waardeert u het DMARC-beleid op naar p=quarantine of p=reject. p=quarantine stuurt niet-geauthenticeerde mail rechtstreeks naar spam, terwijl p=reject valse berichten bij de ontvangende gateway weggooit.
Na het bereiken van DMARC-handhaving kunnen verzenders Brand Indicators for Message Identification (BIMI) publiceren, waarmee een geverifieerd merklogo naast berichten in de inbox van ontvangers wordt getoond, wat de zichtbaarheid en het vertrouwen in het merk vergroot.
Veelgestelde vragen over bulkverzendereisen
Wat is de bulkverzenderdrempel voor Google en Yahoo?
Google en Yahoo definiëren bulkverzenders als domeinen die circa 5.000 of meer berichten per dag naar persoonlijke accounts versturen. Het volume wordt over het hele primaire domein berekend, met alle verzendservices gecombineerd.
Gelden deze regels ook voor transactionele e-mail?
Ja. Transactionele e-mails zoals wachtwoordresets, orderupdates en systeemwaarschuwingen moeten door SPF-, DKIM-, DMARC- en DNS-controles komen, al vereisen ze geen one-click unsubscribe-headers.
Is een DMARC-beleid van p=none voldoende om te voldoen?
Ja, p=none voldoet aan de basiseisen van Google en Yahoo. Het monitort echter alleen verkeer zonder imitatie te blokkeren, dus overstappen op p=quarantine of p=reject wordt aanbevolen.
Wat gebeurt er met mijn e-mail als ik niet aan de eisen voldoe?
Mailproviders zullen SMTP-verbindingen beperken met 4xx-foutcodes, e-mails rechtstreeks naar spamfolders sturen of 5xx hard bounces geven die mail ronduit weigeren.
Hoe lang duurt het om te herstellen van hoge spamklachten?
Zodra de lijsthygiëne is hersteld en het klachtpercentage onder 0,1% terugkeert, duurt het doorgaans 7 tot 14 dagen van schoon verzenden voordat Google Postmaster Tools de domeinreputatie heeft herbouwd.
Hoe controleer ik of mijn SPF-record de limiet van 10 lookups overschrijdt?
Inspecteer het SPF TXT-record en tel elk mechanisme dat een DNS-lookup triggert. Als het totale aantal DNS-query's over het hoofdrecord en geneste records samen meer dan 10 bedraagt, zal het SPF-record mislukken met een PermError.
Bron: FinTechZoom