Je hebt de SPF- en DKIM-records gecontroleerd, bevestigd dat het verzendende domein er schoon uitziet en een campagne gelanceerd. Vervolgens retourneert de applicatie een authenticatiefout voordat het eerste bericht je systeem verlaat. De DNS-configuratie was niet per se onjuist. Je verzendapplicatie kan zijn mislukt bij de clientlogin die vereist is door de uitgaande SMTP-server.
Dat onderscheid beantwoordt de praktische vraag achter wat is SMTP-authenticatie. SMTP AUTH bewijst dat een client, applicatie of gebruiker gemachtigd is om via een server e-mail te verzenden. SPF, DKIM en DMARC richten zich op een ander identiteitsprobleem, namelijk of een ontvangende provider het domein dat aan het bericht is gekoppeld, moet vertrouwen. Betrouwbare afleverbaarheid hangt af van beide lagen, plus zorgvuldige lijsthygiëne vóór het verzenden.
De verborgen poortwachter van e-mailbezorging
Een marketingteam kan dagen besteden aan het beoordelen van afzenderreputatie, domeinuitlijning en berichtinhoud, om vervolgens te ontdekken dat het CRM niet kan authenticeren bij de uitgaande mailserver. De campagne bereikt de infrastructuur van de ontvanger nooit, omdat de verzendserver de verbinding al eerder weigert.
Dat is de rol van SMTP-authenticatie. Het is de poortwachter tussen een applicatie en de mailserver die uitgaande berichten accepteert. De client identificeert een authenticatiemechanisme, voltooit een uitwisseling met de server en krijgt toestemming om mail te verzenden. Zonder die toestemming doen een correct opgesteld bericht en correct gepubliceerde domeinrecords er nog niet toe.
Twee identiteitscontroles, niet één
Bij e-mailbezorging spelen twee afzonderlijke vragen:
- Kan deze client mail via deze server verzenden?
- Moet de ontvanger de afzenderidentiteit die door dit bericht wordt vertegenwoordigd vertrouwen?
SMTP AUTH beantwoordt de eerste vraag. SPF, DKIM en DMARC beantwoorden de tweede. Een CRM kan geldige inloggegevens hebben, maar verzenden vanaf een domein zonder op elkaar afgestemde authenticatierecords. Omgekeerd kan een domein sterke records publiceren, terwijl een applicatie een verlopen wachtwoord of uitgeschakelde methode gebruikt, of een server die relay voor dat account weigert.
Operationele regel: Debug het verzendpad in de juiste volgorde. Controleer eerst of de client een beveiligde, geauthenticeerde verzendsessie kan opzetten. Controleer daarna domeinniveau-authenticatie en beleid aan de kant van de ontvanger.
De standaard achter SMTP AUTH is RFC 4954, die SMTP-authenticatie formaliseerde als een service-uitbreiding op basis van SASL. Hiermee kan een server ondersteunde mechanismen bekendmaken en kan een client er één selecteren zonder de kerncommando's voor berichtoverdracht van SMTP te wijzigen. Dat ontwerp vormt nog steeds de basis voor geauthenticeerde verzending in zakelijke mailsystemen en verzendplatforms.
Waarom marketeers met deze fout te maken krijgen
De fout verschijnt vaak na een infrastructuurwijziging, niet na een wijziging in tekst of targeting. Een provider kan een verouderde authenticatiemethode uitschakelen. Een beheerder kan SMTP AUTH voor een account uitschakelen. Een beveiligingsbeleid kan versleutelde verzending vereisen. Een firewall kan server-tot-serververkeer toestaan, maar de poort blokkeren die door de marketingapplicatie wordt gebruikt.
Daarom is “het wachtwoord is correct” geen afdoende diagnose. De server kan de authenticatiemethode, de verbindingsbeveiliging, de relayrechten van het account of de configuratie van de verzendclient weigeren. Beschouw SMTP AUTH als een controle op protocolniveau, niet als een formulierveld.
De SMTP AUTH-handshake begrijpen
SMTP AUTH is een uitonderhandelde uitwisseling. De client stuurt niet zomaar een gebruikersnaam in de hoop dat de server die accepteert. De server identificeert eerst wat hij ondersteunt, waarna de client een compatibel mechanisme selecteert en de authenticatiereeks start.
De protocolvolgorde
De uitwisseling verloopt doorgaans in deze volgorde:
- De client opent een verbinding. Voor geauthenticeerde verzending maakt de applicatie meestal verbinding via een aangewezen submission-service en onderhandelt hij over transportbeveiliging voordat inloggegevens worden blootgesteld.
- De client stuurt EHLO. Deze uitgebreide begroeting vertelt de server welke SMTP-functies de client begrijpt.
- De server kondigt zijn mogelijkheden aan. De respons kan een regel
250-AUTHbevatten met de ondersteunde SASL-mechanismen. De client moet er één kiezen die de server aanbiedt. - De client stuurt AUTH. De opdracht gebruikt het geselecteerde mechanisme als eerste parameter, zoals vastgelegd in de AUTH-opdrachtspecificatie van RFC 4954.
- De partijen voltooien de uitwisseling. Afhankelijk van het mechanisme kan de server uitdagingen versturen, waarop de client reageert met de vereiste authenticatiegegevens. Base64-codering kan tijdens de uitwisseling inloggegevens weergeven, maar codering is geen encryptie. TLS moet de sessie beveiligen.
- De server accepteert of weigert de sessie. Een geslaagde authenticatie retourneert doorgaans
235. Een mislukte poging retourneert meestal535, hoewel diagnostische details per provider verschillen.
Het belangrijkste punt is dat SMTP AUTH plaatsvindt voordat de client de bericht-envelop en -inhoud indient. Na authenticatie kan de applicatie doorgaan met opdrachten zoals MAIL FROM, RCPT TO en DATA, onder voorbehoud van de relay- en beleidscontroles van de server.
Wat de responsen u vertellen
Een ontbrekende AUTH-mogelijkheid kan erop wijzen dat de client verbinding heeft gemaakt met de verkeerde service, een niet-ondersteunde poort heeft gebruikt of contact heeft opgenomen met een server die geen geauthenticeerde verzending aanbiedt. Een 535-respons kan duiden op ongeldige inloggegevens, een geblokkeerd account, een uitgeschakelde authenticatiemethode of een weigering door de provider van verouderd inloggedrag.
Applicatielogs moeten de respons codes van de server en de onderhandelde beveiligingsstatus vastleggen, zonder wachtwoorden en tokens op te slaan. Bij onderzoek naar een bericht dat is geaccepteerd maar later is gefilterd, kunnen teams ook gratis e-mailheaders analyseren om authenticatieresultaten te controleren die door ontvangende systemen zijn vastgelegd.
SMTP AUTH vervangt accountbeveiliging bovendien niet. Als een mailbox of serviceaccount multifactor-authenticatie gebruikt, controleer dan de ondersteunde flow van de provider in plaats van aan te nemen dat het normale wachtwoord werkt. De 2FA-gids van Finchum Fixes IT biedt nuttige achtergrondinformatie over waarom een tweede factor het inlogmodel verandert.
Voor teams die de ontvangergegevens opschonen die deze systemen voeden, is BillionVerify een professionele e-mailverificatieservice die is gebouwd om één probleem op te lossen: slechte e-mailgegevens kosten bedrijven geld. Dat gaat over de kwaliteit van de adressenlijst, niet over de SMTP-login zelf.
SMTP-authenticatie versus afzenderauthenticatie
De duidelijkste analogie is een werknemersbadge tegenover briefpapier van het bedrijf.
SMTP AUTH is de badge. Het vertelt je uitgaande mailserver dat deze client of dit account toestemming heeft om een bericht in te dienen. SPF, DKIM en DMARC zijn het briefpapier en de verificatiemarkeringen. Ze helpen de ontvangende provider beoordelen of het bericht het domein vertegenwoordigt dat aan de ontvanger wordt getoond.
Een geslaagde badgecontrole maakt twijfelachtig briefpapier niet betrouwbaar. Omgekeerd geven zorgvuldig ingestelde domeinrecords een applicatie geen toestemming om e-mail in de wachtrij van een server te plaatsen.
| Functie | Clientindiening (SMTP AUTH) | Domeinverificatie (SPF/DKIM/DMARC) |
|---|---|---|
| Primaire vraag | Mag deze client e-mail indienen? | Moet de ontvanger deze domeinidentiteit vertrouwen? |
| Waar het werkt | Tussen de verzendende client en de uitgaande server | Tussen het bericht, DNS-records en de ontvangende provider |
| Belangrijkste componenten | EHLO, geadverteerde AUTH-mechanismen, SASL-uitwisseling, relaymachtigingen | SPF-autorisatie, validatie van de DKIM-handtekening, DMARC-uitlijning en beleid |
| Typische fout | Afwijzing van authenticatie, uitgeschakeld account, niet-ondersteunde methode | Spoofing-fout, misuitlijning, beleidsgebaseerde filtering |
| Effect van succes | De server kan het bericht accepteren voor verdere bezorging | De ontvanger kan signalen van de domeinidentiteit gebruiken bij filterbeslissingen |
Wat elke laag bewijst
SPF autoriseert aangewezen verzendende IP-adressen voor een domein. DKIM voegt een cryptografische handtekening toe waarmee het ontvangende systeem kan controleren of de ondertekende berichtinhoud en domeinhandtekening geldig zijn. DMARC koppelt die resultaten aan het zichtbare From-domein en biedt een beleid voor het verwerken van berichten die de uitlijning niet halen. De verschillen worden duidelijk samengevat in deze vergelijking van SPF, DKIM en DMARC.
SMTP AUTH publiceert geen van die domeininstructies. Het garandeert ook niet dat een ontvanger het bericht in de inbox plaatst. Het stelt alleen vast dat de verzendservice de client als geautoriseerde indiener heeft geaccepteerd.
Publicatie is geen handhaving
Het verschil tussen records hebben en beleid handhaven is operationeel belangrijk. Een meting uit 2026 onder 5,5 miljoen domeinen vond SPF gepubliceerd bij 56,0%, DMARC bij 30,4% en DKIM bij 22,7%, volgens het e-mailauthenticatieonderzoek van DMARC Guard. In een afzonderlijke benchmark voor de top 10.000 domeinen bereikte SPF-publicatie 84,5%, DMARC-publicatie 76,6% en DMARC-handhaving met quarantaine- of reject-beleid 54,0%, afkomstig uit dezelfde bron.
De praktische les is eenvoudig. Een domein kan geconfigureerd lijken terwijl het nog steeds in een modus voor alleen monitoring werkt. Gebruik een DMARC-checkertool om beleid en uitlijning te controleren, maar los SMTP-inloggegevens afzonderlijk op. Geen van beide tools vervangt de andere.
Poorten en protocollen voor veilige verzending
Inloggegevens mogen nooit via een onbeveiligde clientverzendsessie worden verstuurd. SMTP AUTH hoort daarom bij transportversleuteling en een poort die bedoeld is voor berichtverzending, niet bij een onbeperkt relaypad.
De door standaarden gedefinieerde verzendpoort is 587, doorgaans gecombineerd met STARTTLS, zoals beschreven in dit overzicht van SMTP-authenticatiepoorten. De client brengt de SMTP-sessie tot stand, ontvangt de mogelijkheden van de server, vraagt om een TLS-upgrade en voert vervolgens de authenticatie uit binnen de beveiligde verbinding.
Het juiste eindpunt kiezen
Poort 25 wordt voornamelijk geassocieerd met relay tussen servers. Dit is niet de normale keuze voor een applicatie, CRM of marketingplatform dat e-mail met gebruikersgegevens verzendt. Veel netwerken beperken deze poort, omdat misbruik van open relays en gecompromitteerde hosts onbeperkte uitgaande SMTP tot een beveiligingsprobleem hebben gemaakt.
Poort 465 gebruikt impliciete TLS, wat betekent dat de verbinding vanaf het begin is versleuteld. Sommige providers en applicaties vereisen deze poort nog steeds, maar de configuratie moet overeenkomen met wat de server verwacht. Een client die STARTTLS verwacht op een eindpunt met impliciete TLS, of impliciete TLS verwacht terwijl de server een onversleutelde begroeting gevolgd door een upgrade verwacht, zal vóór de authenticatie mislukken.
| Verbindingstype | Typische rol | Beveiligingsverwachting |
|---|---|---|
| Poort 25 | Relay tussen servers | Niet het normale pad voor geauthenticeerde clientverzending |
| Poort 587 | Berichtverzending | STARTTLS wordt doorgaans onderhandeld vóór SMTP AUTH |
| Poort 465 | Verzending indien vereist | Impliciete TLS begint bij het tot stand brengen van de verbinding |
Configuratiecontroles die blootstelling voorkomen
Controleer voordat je inloggegevens test of het eindpunt, de poort, de versleutelingsmodus en het authenticatiemechanisme van de applicatie overeenkomen met de documentatie van de provider. Een poort kan bereikbaar zijn terwijl de TLS-onderhandeling toch mislukt. Ook kan de server AUTH aanbieden en het account toch weigeren, omdat relayrechten of het tenantbeleid verzending verbieden.
Een verificatietool voor MX-records helpt bij het identificeren van de mailservers die verantwoordelijk zijn voor het ontvangen van een domein, maar MX-gegevens zijn geen vervanging voor het verzendings-eindpunt dat je uitgaande provider verstrekt. Infrastructuur voor ontvangst en geauthenticeerde verzending kunnen afzonderlijke diensten zijn.
Beveiligingsgrens: Probeer een authenticatiefout niet te “verhelpen” door TLS uit te schakelen. Daardoor kunnen inloggegevens en berichtverkeer worden blootgesteld, terwijl het onderliggende compatibiliteits- of beleidsprobleem onopgelost blijft.
Voor systemen met hoge volumes kan een API operationeel eenvoudiger zijn dan het onderhouden van een praatgrage SMTP-sessie, maar SMTP blijft nuttig wanneer een applicatie dit al ondersteunt en de provider een stabiele verzenddienst aanbiedt. De keuze moet worden bepaald door integratiebehoeften, observability en beveiligingsmaatregelen, niet door gewoonte.
De impact van het uitfaseren van legacy-authenticatie
Een verzendworkflow kan stoppen met authenticeren, zelfs wanneer het wachtwoord niet is gewijzigd. Providers vervangen Basic Authentication, waarbij een gebruikersnaam en wachtwoord rechtstreeks worden verzonden, door OAuth en andere autorisatiestromen waarmee beheerders tokens, scopes, toestemming en intrekking kunnen beheren.
Het aangekondigde plan van Microsoft stelt dat het gedrag van Basic Authentication naar verwachting ongewijzigd blijft tot en met december 2026. Daarna wordt deze standaard uitgeschakeld voor bestaande tenants, terwijl nieuwe tenants die daarna worden aangemaakt naar verwachting OAuth als ondersteunde methode zullen gebruiken. Microsoft is van plan een definitieve verwijderingsdatum aan te kondigen in de tweede helft van 2027. Deze verwachte mijlpalen staan in de tijdlijn voor het uitfaseren van SMTP AUTH in Microsoft Exchange Online.
Waarom geldige wachtwoorden toch mislukken
De provider kan de authenticatiemethode weigeren voordat het wachtwoord wordt gecontroleerd. Een tenantbeheerder kan SMTP AUTH voor de mailbox ook hebben uitgeschakeld, of de applicatie biedt alleen LOGIN of PLAIN, terwijl de service een tokengebaseerde flow vereist. Een geslaagde inlogtest vanaf één mailbox bevestigt daarom niet dat elke verzendintegratie blijft werken.
In eerdere communicatie van Microsoft werden gefaseerde weigeringen vanaf 1 maart 2026 beschreven, met een volledige uitschakeling op 30 april 2026 voor het betreffende Basic Authentication-pad, zoals gemeld in deze migratiehandleiding voor SMTP AUTH. Planningen van providers en tenantbeleid kunnen veranderen. Controleer daarom de actuele status van elke omgeving in plaats van een oude implementatiedatum als garantie te beschouwen.
Een praktisch migratieplan
Breng elk systeem in kaart dat mail via de tenant indient, waaronder CRM-workflows, facturatieapplicaties, monitoringtools, formulieren en scripts. Leg voor elk systeem het account, endpoint, de poort, versleutelingsmodus, het authenticatiemechanisme en de eigenaar vast. Splits integraties die OAuth ondersteunen van integraties die vervanging of een goedgekeurde app-wachtwoordmethode nodig hebben.
Test de nieuwe flow in een gecontroleerde omgeving voordat je productiesequenties wijzigt. Controleer het verlopen van tokens, toestemmingsvereisten, foutafhandeling en het intrekken van toegang. Bevestig ook dat de workflow providerreacties nog steeds correct verwerkt nadat de authenticatie is geslaagd. Een connector zonder OAuth-ondersteuning kan tijdens een campagne falen, ook al is het opgeslagen wachtwoord nog geldig.
Deliverability controleren voorbij de login
Authenticatie bij je uitgaande server bewijst dat je bevoegd bent om berichten in te dienen. Het bewijst niet dat er een inbox van de ontvanger bestaat, dat het ontvangende domein e-mail voor dat adres accepteert of dat het bericht filtering zal vermijden.
Een verificatieproces vóór verzending begint met een MX-opzoeking. MX-records identificeren de mailservers die verantwoordelijk zijn voor het ontvangen van e-mail van een domein, en een domein zonder MX-records kan geen e-mail ontvangen, zoals uitgelegd in dit overzicht van hoe e-mailverificatie werkt. Een verificatieservice kan vervolgens de server van de ontvanger benaderen via een SMTP-gesprek om te beoordelen of het adres bezorgbaar lijkt.
Wat het verificatieproces daadwerkelijk controleert
De service hoeft het campagnemailtje niet te versturen om nuttige informatie te verkrijgen. De service kan de MX-host van het ontvangende domein identificeren, een SMTP-sessie openen en vragen of de server de beoogde ontvanger accepteert. Een positieve reactie kan nog steeds dubbelzinnig zijn, omdat sommige servers e-mail voor elk adres binnen het domein accepteren.
Daarom is catch-all-detectie belangrijk. Een verifier stuurt een tweede testadres naar dezelfde MX-host. Als de server ook een willekeurig adres accepteert, wordt het domein geclassificeerd als catch-all, in plaats van dat dit wordt beschouwd als bewijs dat de oorspronkelijke inbox bestaat, zoals beschreven in deze workflow voor catch-all-detectie.
Nuttig onderscheid: “Geaccepteerd door de server” en “bevestigd als een specifieke inbox” leveren niet altijd hetzelfde resultaat op.
Verificatie werkt daarom het best als een systeem voor risicoclassificatie, niet als een simplistische schakelaar tussen geldig en ongeldig. Marketingactiviteiten kunnen vermoedelijk bezorgbare adressen scheiden van onbekende, catch-all-, tijdelijke, rolgebaseerde of anderszins risicovolle records voordat een campagne harde bounces veroorzaakt.
Een BillionVerify-deliverabilitychecker kan onderdeel zijn van die controle vóór verzending, als een van de tools die een team beoordeelt voor adres- en verzendpadcontroles. Het operationele doel is breder dan alleen een geslaagde login: slechte ontvangers verminderen, de reputatie van de afzender behouden en de campagne een schoner publiek bieden.
Een veerkrachtige verzendinfrastructuur opbouwen
Een veerkrachtig verzendsysteem beschouwt authenticatie als een gelaagde controle in plaats van één enkel vinkje. De client moet zich veilig authenticeren bij de uitgaande service. Het zichtbare afzenderdomein moet geslaagde, op elkaar afgestemde identiteitscontroles doorstaan. De ontvangergegevens moeten actueel genoeg zijn, zodat de campagne geen vermijdbare bounces veroorzaakt.
Begin met een infrastructuuraudit
Breng de volledige route van applicatie tot ontvanger in kaart. Documenteer voor elke verzendworkflow de indieningsprovider, authenticatiemethode, versleutelingsvereiste, accounteigenaar en fallbackgedrag. Deze inventarisatie brengt vaak verlaten integraties aan het licht die nog steeds afhankelijk zijn van wachtwoorden of oude SMTP-instellingen.
Test vervolgens bewust de verschillende foutscenario's:
- Indieningsfout: Controleer of de client het beoogde eindpunt bereikt, TLS onderhandelt, de verwachte AUTH-mogelijkheid ziet en een geslaagde authenticatiereactie ontvangt.
- Domeinfout: Valideer SPF-autorisatie, DKIM-ondertekening en DMARC-afstemming voor het domein dat in het From-adres wordt weergegeven.
- Datafout: Verifieer nieuwe en geïmporteerde adressen voordat ze in een campagne of verkoopsequentie terechtkomen.
- Reputatiefout: Monitor bounces, klachten, blocklistsignalen en plotselinge veranderingen in acceptatiegedrag met een tool voor het controleren van IP-reputatie.
De RFC 4954-standaard biedt de protocolbasis, maar naleving van standaarden alleen garandeert geen operationele veerkracht. Providers kunnen tenantregels opleggen, mechanismen uitschakelen of authenticatievereisten wijzigen.
Maak hygiëne onderdeel van de workflow
Wacht niet tot een lijst groot is of een campagne gepland staat. Voeg verificatie toe bij registratie, import, CRM-synchronisatie en vóór belangrijke verzendingen. Een realtimecontrole kan voorkomen dat een duidelijk risicovol adres in de database terechtkomt, terwijl een bulkcontrole verouderde records kan identificeren die door verkoop- en marketingteams zijn verzameld.
De beste workflow bewaart ook het resultaat en de reden. “Onbekend vanwege catch-all” vereist een andere behandeling dan “mailbox geweigerd” of “domein heeft geen ontvangende server”. Segmentatie stelt het team in staat om te beslissen of een adres moet worden onderdrukt, gecontroleerd of voorzichtig getest, in plaats van elk onzeker record als veilig te behandelen.
Een gelaagd programma vereist ook eigenaarschap. Infrastructuurteams moeten OAuth-migraties en TLS-beleid beheren. Marketingoperations moeten de afstemming van verzenddomeinen en onderdrukkingsregels onderhouden. Datateams moeten definiëren hoe de verificatiestatus wordt verwerkt. Zonder duidelijk eigenaarschap gaat elke groep ervan uit dat een ander team het verzendtraject beschermt.
Deze video geeft een visuele uitleg van de betrokken infrastructuurconcepten:
De centrale les is praktisch: SMTP AUTH krijgt een bericht in de uitgaande wachtrij, terwijl domeinauthenticatie en ontvangerverificatie bepalen of het bredere afleveringssysteem redenen heeft om het te vertrouwen. Houd deze controles gescheiden in je monitoring, maar verbind ze in je operationele proces.
BillionVerify biedt e-mailverificatie om ontvangergegevens te controleren voordat deze campagnes, workflows en uitgaande sequenties bereiken. Gebruik het om verificatie op SMTP-niveau, MX- en catch-all-signalen en een afleverbaarheidscontrole te verbinden in je pre-sendproces en bezoek vervolgens BillionVerify om de workflow voor je team te evalueren.