Je mail belandt in spam. Je wisselt van hosting, maar het probleem blijft. Ook een nieuw dedicated IP en een opnieuw opgebouwde server leveren niet de verwachte verbetering op.
Een mogelijke oorzaak ligt niet alleen bij de server: ook de reputatie van je domein kan meespelen.
Domeinreputatie bij e-mail kan aan company.com verbonden blijven wanneer je andere infrastructuur gebruikt. Er is echter geen universele, onveranderlijke score. Filters beoordelen domein, IP, inhoud, authenticatie en verzendgedrag. Een andere aanbieder wist de geschiedenis van het domein niet automatisch.
Richt je DNS, mailboxen en authenticatie nog in, lees dan de handleiding voor zakelijke e-mail voor kleine bedrijven. Dit artikel behandelt een specifiek probleem: beschadigde domeinreputatie, mogelijke oorzaken, diagnostische aanwijzingen en architectuurkeuzes om risico te beperken. Een foutcode bewijst dit probleem niet op zichzelf.
Wat is domeinreputatie bij e-mail?
Het is de beoordeling die ontvangende diensten zoals Google, Yahoo en Microsoft vormen op basis van het verzendgedrag van je domein. Spamklachten, authenticatieresultaten, interacties en volumegeschiedenis kunnen bijdragen. Domeinreputatie verschilt van IP-reputatie, al kunnen de signalen samenhangen. Een andere aanbieder zet de beoordeling niet automatisch terug, maar correct verzendgedrag kan haar in de loop van de tijd veranderen.
In 2025-2026 is domeinbeoordeling belangrijk bij grote ontvangers, mede om misbruik door steeds wisselende IP-adressen tegen te gaan. Dat betekent niet dat domeinreputatie altijd zwaarder weegt dan alle andere signalen. De criteria verschillen per aanbieder.
Een IP zonder bekende problemen, juiste PTR-records en weinig mislukte afleveringen sluiten beperkingen door domeingeschiedenis niet uit. Omgekeerd is domeinreputatie niet de enige beperkende factor. Diagnose vraagt om gegevens over de volledige verzendroute.
Hoe reputatieschade eruit kan zien: diagnostische aanwijzingen
Spamplaatsing, SMTP-weigeringen met 550 en problemen na een IP-wissel kunnen aanleiding zijn om domeinreputatie te onderzoeken. Inhoud, authenticatie en ontvangstbeleid spelen ook mee. De Gmail-categorie Promoties is geen blokkade. De tabel geeft mogelijke controles, geen definitieve diagnoses.
| Symptoom | Technische aanwijzing | Mogelijke verklaring |
|---|---|---|
| Mail komt in spam terecht | 250 OK: op die SMTP-hop geaccepteerd, later als spam ingedeeld | Mogelijk reputatie, inhoud of andere signalen. Acceptatie garandeert geen inboxplaatsing. |
| Beleidsweigering bij de gateway | 550 5.7.1 of 550 5.7.515 (Microsoft) | Controleer volledig antwoord, authenticatie-eisen en beleid; de codes bewijzen geen reputatieschade. |
| Transactionele mail in Promoties | Facturen en wachtwoordherstel verschijnen in Gmail Promoties | Mogelijk indeling door inhoud of gemengde stromen; geen bewijs van domeinblokkade. |
| Directe weigering op een nieuw IP | Nieuw dedicated IP, vanaf de eerste dag geweigerd | Onderzoek eerdere IP-reputatie, DNS, authenticatie en domein; geen sluitend bewijs. |
Die laatste rij is geen definitieve test. Een pas toegewezen IP kan al een geschiedenis hebben of nog positieve signalen missen. Een directe weigering kan ook door netwerk, PTR, authenticatie of beleid ontstaan. Andere infrastructuur lost het probleem niet automatisch op, maar bewijst evenmin dat alleen het domein de oorzaak is.
Vier operationele oorzaken van reputatieschade
Filters beoordelen gedrag en infrastructuur naast inhoud en authenticatie. Inzicht in deze factoren helpt domeinreputatie te beschermen, zonder permanente schade of automatische blokkades te veronderstellen.
1. Samenvoeging van subdomeinsignalen
Een veelgehoorde aanname: “Ik verstuur riskante campagnes vanaf promo.example.com, dan blijft example.com beschermd”.
Die scheiding is niet gegarandeerd. Ontvangers kunnen signalen van het organisatiedomein en het subdomein samen beoordelen. Veel klachten over promo.example.com kunnen ook example.com beïnvloeden, maar niet elk incident schaadt automatisch het hoofddomein. Subdomeinen helpen stromen te onderscheiden; ze vormen geen volledige afscherming.
2. De grens voor bulkverzenders en het blijvende effect
Sinds februari 2024 stellen Google en Yahoo strengere eisen aan bulkverzenders. Bij Google gaat het om ongeveer 5,000+ berichten per dag naar persoonlijke Gmail-accounts. Controleer definities, tellingen en criteria van Yahoo afzonderlijk.
Volgens het beschreven Google-beleid kan de classificatie blijven na een eenmalige overschrijding, bijvoorbeeld met Black Friday. Teruggaan naar 50 berichten per dag verwijdert die niet automatisch. Controleer de actuele eisen voor gepubliceerd DMARC, authenticatie, lijstkwaliteit en afmelden met één klik bij relevante promotionele berichten. DMARC publiceren betekent niet altijd dat quarantaine of weigering vereist is, en niet elke aanbieder hanteert dezelfde blijvende classificatie.
3. Het klachtenrisico bij 0.3%
Google en Yahoo noemen relevante grenzen voor spamklachten. Definitie en noemer verschillen per aanbieder. Overschrijding verhoogt het risico, maar veroorzaakt niet altijd een onmiddellijke blokkade.
- Referentie: 0.3% (3 klachten per 1,000 berichten in dit rekenvoorbeeld)
- Waar controleren: Google Postmaster Tools voor beschikbare Gmail-gegevens; controleer huidige interface en gegevensdekking
- Herstelschatting: 30-60 dagen correct verzendgedrag na lagere klachtenpercentages, als planningsindicatie en niet als gegarandeerde termijn
Veel beheerders merken het probleem pas als aflevering verslechtert. Richt monitoring vooraf in en houd rekening met beperkte gegevens of beschikbaarheid die van voldoende volume afhangt.
4. Andere gebruikers op een gedeeld IP
Gedeelde hosting, waaronder sommige cPanel- en webmaildiensten, kan dezelfde IP-adressen voor meerdere klanten gebruiken. Misbruik kan bijdragen aan een Spamhaus SBL-vermelding. Gevolgen voor jouw mail hangen af van de pool en de ontvanger. Herhaalde koppeling aan problematische infrastructuur kan ook domeinsignalen beïnvloeden, maar verslechtering is niet automatisch.
Preventie: een passende architectuur ontwerpen
Authenticatie, doordachte scheiding van stromen en gecontroleerde netwerkinfrastructuur vullen elkaar aan. Vooral bij hogere volumes zijn dit belangrijke controles. Ze garanderen geen goede reputatie en vervangen toestemming, passende inhoud en monitoring niet.
Laag 1: authenticatie met SPF, DKIM en DMARC
Authenticatie helpt ontvangers de technische afzenderidentiteit te controleren. Correcte instellingen zijn belangrijk, maar garanderen geen vertrouwen of inboxplaatsing.
- SPF: autoriseert IP-adressen voor het gecontroleerde domein. Het budget van 10 DNS-lookups omvat ook geneste mechanismen. Includes van Google Workspace, Mailchimp en Zendesk kunnen het budget verbruiken of overschrijden; het aantal diensten alleen bepaalt geen PermError.
- DKIM: ondertekent delen van het bericht. RSA-sleutels van 2048-bit zijn hier de aanbevolen richtlijn; controleer ondersteunde algoritmen, sleutellengtes en actuele aanbiedereisen.
- DMARC: vereist geldige SPF óf DKIM met uitlijning op de zichtbare From. Een bevoegde beheerder kan beginnen met
p=none, rua instellen en alle legitieme verzenders beoordelen voordat het beleid stapsgewijs naarp=quarantineofp=rejectgaat.
# Example DMARC record - replace with your reporting address
_dmarc.company.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@company.com; pct=100"
Dit record is een voorbeeld, geen instelling om zonder controle te publiceren. Microsoft-weigering 550 5.7.515 kan authenticatie-eisen betreffen en bewijst niet alleen het ontbreken van streng DMARC-beleid. Controleer het volledige antwoord, SPF, DKIM en uitlijning. Verifieer ook de Google- en Yahoo-eisen van 2024: een gepubliceerd beleid is niet automatisch een verzoek om weigering.
Laag 2: afzonderlijke hoofddomeinen
Overweeg aparte hoofddomeinen voor legitieme stromen met verschillende doelen. Gebruik ze niet om blokkades te omzeilen of ongewenste verzending voort te zetten. Gebruik het primaire bedrijfsdomein niet zonder afweging voor zeer grote campagnes of ongevraagde benadering.
Primair: company.com: directiecorrespondentie, facturen en klantondersteuning; gescheiden van campagnes.
Marketing: trycompany.com: verwachte en toegestane nieuwsbrieven en productupdates.
Zakelijke benadering: getcompany.com: passende, rechtmatige communicatie, niet bedoeld om bescherming te omzeilen.
Afzonderlijke domeinen kunnen sommige gedeelde signalen beperken, maar zijn niet de enige bescherming. Ze garanderen niet dat de directie na een incident altijd investeerders kan mailen. IP, inhoud en andere signalen kunnen samenhangen. De handleiding voor multidomeinmailhosting beschrijft beheer op grotere schaal voor bureaus.
Laag 3: netwerkcontroles en FCrDNS
Controleer reverse DNS van het verzend-IP: PTR moet naar een hostnaam wijzen waarvan de A- of AAAA-antwoorden dat IP weer bevatten. Dit heet Forward-Confirmed reverse DNS, FCrDNS.
# Verify FCrDNS on your sending IP
dig -x YOUR_IP_ADDRESS # Should return your hostname
dig +short YOUR_HOSTNAME # Should return the same IP
Een mismatch kan beperkingen waarschijnlijker maken, maar veroorzaakt niet altijd een directe Gmail- of Microsoft-blokkade. Herstel en test de instellingen voordat je het volume op een nieuw IP verhoogt.
Laag 4: geleidelijke opbouw en inactiviteit
Reputatie is niet statisch. Zonder recente verzending kunnen sommige signalen minder relevant worden, maar inactiviteit veroorzaakt geen universele reset.
- Nieuw domein: een voorbeeld is beginnen met 20 berichten op de eerste dag en iedere 2-3 dagen verdubbelen, zonder koude acquisitie per e-mail in de eerste 30 dagen. Stem tempo en doelgroep af op toestemming, capaciteit, reacties en actuele regels.
- Inactief domein: overweeg na meer dan 30 dagen zonder verzending een voorzichtige hervatting. Neem niet aan dat reputatie is gewist of dat je altijd volledig opnieuw moet beginnen.
De TrekMail-regels voor geleidelijke volumeopbouw beschrijven de aanpak voor beheerde SMTP. Controleer de huidige voorwaarden en toepassing op jouw account.
Eerste maatregelen bij beschadigde reputatie
Openpercentages onder 5%, meer niet-bezorgingsmeldingen of 550-weigeringen verdienen onderzoek, maar bewijzen geen reputatieprobleem. Openmetingen zijn technisch gezien beperkt betrouwbaar. Analyseer de gegevens en stem onderstaande maatregelen af op de daadwerkelijke oorzaak.
- Pauzeer problematische promotionele campagnes. Verstuur alleen noodzakelijke, verwachte transactionele mail, zoals wachtwoordherstel en betaalbewijzen, aan passende ontvangers. Stuur niet uitsluitend om interacties te creëren.
- Bekijk Google Postmaster Tools. Gebruik huidige weergaven en beschikbare gegevens naast logs. Bij negatieve signalen kan een periode van 4-8 weken als planningskader dienen, maar herstel is niet gegarandeerd binnen die termijn en er is niet altijd een zichtbare categorie “Bad”.
- Beoordeel inactieve contacten. Verwijder niet automatisch iedereen die 90 dagen niet opent. Kijk ook naar klikken, antwoorden, toestemming en bewaarplichten. Sluit ongeschikte of aantoonbaar ongeldige contacten uit van verzending, zonder kunstmatige interactie te creëren.
- Overweeg migratie pas na diagnose. Bij een vermelding op Spamhaus DBL controleer je de oorzaak, herstel je misbruik en volg je de geldende verwijderingsprocedure. Neem niet aan dat de vermelding permanent of onherstelbaar is. Een eventueel nieuw domein dient legitiem gebruik, niet het omzeilen van een beperking. De handleiding voor mail op je eigen domein beschrijft de technische inrichting.
Hoe TrekMail deze architectuur kan ondersteunen
Directiecorrespondentie en nieuwsbrieven zonder passende controles combineren kan gedeelde risico's opleveren. Goedkope infrastructuur bewijst echter geen oorzaak, en één campagne schaadt niet automatisch het hele domein.
TrekMail beschrijft hulpmiddelen om passende scheiding te ontwerpen en te beheren, binnen abonnementsgrenzen.
| Situatie om te beoordelen | Beschreven TrekMail-aanpak |
|---|---|
| Directiemail en nieuwsbrieven op dezelfde server | Zakelijke mail op beheerde IP-pools, niet zonder reputatierisico |
| Gedeelde hosting met onbekende andere gebruikers | Eigen SMTP voor bulkverzending met SES, SendGrid of Mailgun waar ondersteund |
| Hetzelfde domein voor alle mail | Multidomeinbeheer om stromen naar functie te scheiden |
| Handmatige DNS-inrichting met mogelijke fouten | SPF-, DKIM- en DMARC-wizard waar beschikbaar; echte berichten testen |
Voor het mkb beschrijft TrekMail zakelijke mail (team@company.com) op beheerde IP-adressen en hulpmiddelen voor authenticatie-inrichting. Eigen SMTP met Amazon SES, SendGrid of Mailgun hangt af van abonnement, aanbieder, inloggegevens en limieten. Gescheiden routes kunnen helpen, maar garanderen geen risicovrije infrastructuur of volledige automatische scheiding voor elk account.
Voor bureaus kan het dashboard beheer over 100+ klantdomeinen vereenvoudigen, als het abonnement dat toestaat. Zakelijke mailboxen en aparte marketingrelays vragen om instellingen en controles. Een incident kan nog gedeelde signalen of je reputatie als aanbieder raken. De handleiding voor klantmailbeheer beschrijft de organisatie over accounts.
Reputatieproblemen vragen vaak architectuurverbeteringen naast herstel van verzendgedrag. Authenticatie, scheiding en gecontroleerde infrastructuur zijn belangrijk, maar vervangen toestemming, lijstkwaliteit en monitoring niet.
In het beschreven aanbod begint het Starter-abonnement bij $3.50/maand, met beheerde SMTP, SPF-, DKIM- en DMARC-inrichting en multidomeinondersteuning. De proef van 14 dagen vereist een betaalkaart; toegang en functies hangen van de huidige voorwaarden af. Nano wordt beschreven met 10 domeinen en eigen SMTP voor $0, zonder kaart. Controleer beschikbaarheid, toelatingseisen en limieten: dit garandeert niet voor altijd gratis gebruik of volledige toegang.
Na reputatieverbetering blijven onderhoud en controles nodig. Goede inrichting beperkt sommige risico's, maar garandeert niet dat nieuwe incidenten uitblijven.