SPF-controle in Exchange: SPF-records controleren, publiceren en corrigeren in Exchange

In mei 2025 begon Microsoft e-mails te weigeren van afzenders met een hoog verzendvolume die geen geldige SPF, DKIM en DMARC hadden. Als uw domein meer dan 5.000 berichten per dag naar Outlook.com of Hotmail.com verstuurt zonder de juiste authenticatie, komen die berichten nooit in de inbox terecht.

Google en Yahoo hebben in februari 2024 soortgelijke eisen ingevoerd. in februari 2024. Die eerdere handhavingsronde zorgde ervoor dat het aantal niet-geverifieerde berichten dat Gmail-gebruikers ontvingen met ongeveer 75% afnam, aldus het e-mailbeveiligingsteam van Google.

Volgens het FBI IC3 Internet Crime Report, 2023. 

Het probleem in Exchange-omgevingen is dat SPF-fouten onopgemerkt blijven. Exchange Online waarschuwt je niet wanneer je record niet meer klopt. Er is geen ingebouwd dashboard waarop de slagingspercentages worden weergegeven. De meeste teams komen er pas weken later achter, wanneer gebruikers klagen dat e-mails worden teruggestuurd, of wanneer de marketingafdeling meldt dat de open rates zijn ingestort.

In deze handleiding wordt uitgelegd hoe u uw Exchange SPF-record op vier verschillende manieren kunt controleren, hoe u het juiste record publiceert voor Exchange Online, on-premise en hybride omgevingen, en hoe u de meest voorkomende SPF-fouten (inclusief de limiet van 10 lookups die SPF in de meeste middelgrote organisaties onbruikbaar maakt), hoe Exchange Online SPF achter de schermen daadwerkelijk evalueert, en hoe u SPF continu kunt monitoren in plaats van het één keer te controleren en vervolgens te vergeten.

Hoe controleer je het SPF-record van je e-mailprovider (stap voor stap)

Er zijn vier betrouwbare manieren om je SPF-record, van de snelste tot de meest uitgebreide. Gebruik methode 1 voor een snelle controle, methode 4 voor doorlopend operationeel inzicht.

Methode 1: Gebruik een SPF-zoekfunctie (snelst)

1. Open een willekeurige SPF-checker (de PowerDMARC SPF-checker is gratis en vereist geen aanmelding)
2. Voer je domeinnaam in (bijv. joudomein.com, zonder het voorvoegsel http://) en 
3. Bekijk de uitvoer

De zoekopdracht levert verschillende SPF-validatieresultaten op. Hieronder wordt uitgelegd wat elk uitvoerveld betekent en waar u op moet letten bij het bekijken ervan: 

Een record kan correct worden geparseerd en het aantal overeenkomsten kan zes zijn, maar toch kan er een legitieme afzender ontbreken. De SPF-checker controleert de gegevens in het DNS, maar weet niet welke IP-adressen geautoriseerd moeten zijn.

Methode 2: Controleer via het Microsoft 365-beheercentrum

Meld u aan bij het Microsoft 365-beheercentrum. Ga naar Instellingen → Domeinen → selecteer uw domein → DNS-records. Controleer onder het gedeelte Microsoft Exchange of de status van het TXT-record ‘OK’ is.

Als de status 'Ongeldige invoer' aangeeft, ontbreekt uw SPF-record of bevat het niet de vereiste vermelding `include:spf.protection.outlook.com`. Dit is de snelste manier om SPF te controleren zonder het beheerdersportaal te verlaten.

Methode 3: Controleren via de opdrachtregel (nslookup / dig)

Voor het oplossen van problemen aan de serverzijde of in situaties waarin u geen toegang hebt via de browser, kunt u het SPF TXT-record van uw domein rechtstreeks vanaf de opdrachtregel opvragen.

Voer een van de volgende opdrachten uit: 

# Windows

nslookup -type=txt uwdomein.com

# Linux 

/ macOSdig txt uwdomein.com +short

De uitvoer bevat het onbewerkte TXT-record. Zoek naar de regel die begint met v=spf1. Als je twee van zulke regels ziet, heb je meerdere SPF-records, wat direct een PermError oplevert. Los dit op voordat je verdergaat.

Methode 4: Controleer via DMARC-geaggregeerde rapporten (de gouden standaard)

Geaggregeerde rapporten van e-mailproviders, zoals Gmail, Yahoo, Microsoft, Mail.ru en regionale internetproviders, geven de SPF-slaag- en faalpercentages weer voor alle e-mails die uw domein heeft verzonden, en niet slechts voor één testbericht. Dit is de enige manier om een continu en volledig beeld te krijgen van de gezondheid van uw SPF.

Als je DMARC publiceert met een rua=-tag, verzamel je deze rapporten al. De meeste organisaties beschikken hierover, maar slechts weinigen bekijken ze, omdat de onbewerkte XML onleesbaar is zonder een platform om deze te parseren.

PowerDMARC verwerkt deze rapporten dagelijks en presenteert SPF-specifieke analyses in een speciaal dashboard, met slagings- en mislukkingspercentages per afzender, het bijhouden van DNS-lookups en waarschuwingen wanneer er een nieuwe, niet-geautoriseerde afzender opduikt.

Methode 5: Controleer via de kopteksten van Exchange-berichten (praktijkcontrole)

Om te controleren hoe SPF door een daadwerkelijke ontvanger wordt beoordeeld:

• Stuur een testbericht vanaf je domein naar een extern adres (een persoonlijk Gmail-account is voldoende).
• Open het bericht en haal de volledige headers op. In Outlook: Bestand → Eigenschappen → Internetheaders. In OWA of Gmail: Bron weergeven / Origineel weergeven.
• Zoek de header „Authentication-Results“ en zoek het veld „spf=“.

Hieronder zie je de betreffende header met aantekeningen:

Verificatieresultaten: 

spf=goedgekeurd (IP-adres van afzender is 40.107.22.83)  

smtp.mailfrom=uwdomein.com;  

dkim=pass (handtekening is geverifieerd)  

header.d=uwdomein.com;  

dmarc=goedgekeurd actie=geen  

header.from=uwdomein.com;  

compauth=pass reden=100

spf=pass geeft aan dat het verzendende IP-adres is geautoriseerd door uw SPF-record. Als u spf=fail, spf=softfail of spf=permerror ziet, geeft het specifieke resultaat aan wat er misgaat:

• spf=fail: Het verzendende IP-adres komt helemaal niet voor in uw SPF-record.
• spf=softfail: Het IP-adres is niet geautoriseerd, maar in je record wordt ~all gebruikt in plaats van -all.
• spf=permerror: Uw SPF-record vertoont een structureel probleem (>10 lookups, meerdere records, syntaxfout).

Hoe een geldig Exchange SPF-record eruitziet

Een SPF-record publiceren voor Exchange Online (M365)

Het publiceren van een SPF-record voor Exchange Online is eenvoudig. De meeste teams struikelen echter over het correct invullen van de gegevens.

Stap 1: Breng al uw geautoriseerde verzendbronnen in kaart

Voordat u aan de DNS gaat sleutelen, moet u elk systeem controleren dat namens uw domein e-mail verstuurt. De meeste organisaties schatten deze lijst 30 tot 50 procent te laag in.

• Microsoft 365 / Exchange Online → opnemen:spf.protection.outlook.com
• Marketingautomatisering (HubSpot, Mailchimp, Marketo, Pardot) → elk heeft zijn eigen integratie
• CRM (Salesforce, Microsoft Dynamics) → raadpleeg de SPF-documentatie van de leverancier
• Transactiemails (SendGrid, Amazon SES, Postmark, Mailgun) → leveranciersspecifieke inclusies
• Helpdesk / ticketbeheer (Zendesk, Freshdesk, ServiceNow) → leveranciersspecifieke integraties
• HR / salarisadministratie (BambooHR, Gusto, Workday) → controleer of ze meldingen versturen vanuit uw domein
• Oude lokale servers → IPv4: met openbare IP-adressen

De meest betrouwbare manier om afzenders te ontdekken die je nog niet kende, is DMARC-geaggregeerde rapporten. Elke legitieme (en onrechtmatige) bron die namens uw domein verstuurt, verschijnt daar.

Stap 2: Maak het SPF-record aan

Begin met de versietag, voeg geautoriseerde bronnen toe en sluit af met de kwalificatie.

Eenvoudig voorbeeld van M365:

v=spf1 

voeg toe:spf.protection.outlook.com -all

Een typisch middelgroot bedrijf dat gebruikmaakt van HubSpot en SendGrid:

v=spf1 

bijvoorbeeld: spf.protection.outlook.com 

onder andere:_spf.hubspot.com 

inclusief:sendgrid.net -all

Houd tijdens het bouwen het aantal DNS-zoekopdrachten bij. Elk `include:`-, `a:`-, `mx:`-, `ptr:`- en `exists:`-mechanisme leidt tot één zoekopdracht. `ip4:`- en `ip6:`-mechanismen tellen niet mee. Geneste `include:`-opdrachten tellen ook mee, omdat `include:spf.protection.outlook.com` zelf intern 2 tot 4 extra zoekopdrachten vereist terwijl het door de infrastructuur van Microsoft wordt doorgestuurd.

Stap 3: Publiceer het record in DNS

Het publicatieproces verschilt enigszins per DNS-provider, maar verloopt in grote lijnen hetzelfde:

Instellingen die je altijd moet gebruiken:

• Type record: TXT
• Host / Naam: @ (of leeg, afhankelijk van de provider)
• TTL: 3600 (1 uur) tijdens het testen, daarna 86400 (24 uur) zodra het systeem stabiel is

Belangrijk: Slechts één SPF-record per domein. Een tweede v=spf1 TXT-record is een PermError die erop wacht om ontdekt te worden. Als het provisioningproces van uw DNS-provider automatisch een record aanmaakt wanneer u een dienst toevoegt, controleer dan onmiddellijk op duplicaten.

Stap 4: Controleer het gepubliceerde record

• Wacht 5 tot 60 minuten totdat de DNS-wijzigingen zijn doorgevoerd (afhankelijk van de TTL en de provider).
• Voer de SPF-opzoeking uit methode 1 opnieuw uit om te controleren of het record correct wordt omgezet.
• Controleer het M365-beheercentrum (methode 2). De TXT-status zou nu ‘OK’ moeten zijn.
• Stuur een testbericht naar een extern adres en controleer of in de headers 'spf=pass' staat.
• Controleer of het aantal DNS-zoekopdrachten lager is dan 10.

Als u het record liever niet handmatig wilt samenstellen, dan is de PowerDMARC SPF Generator een correct opgemaakt record genereren zodra u uw verzendbronnen opgeeft.

SPF voor hybride Exchange-omgevingen: on-premise + cloud

Hybride Exchange-omgevingen maken SPF aanzienlijk complexer, omdat e-mail tegelijkertijd zowel vanuit Microsoft 365 als vanuit de lokale infrastructuur kan worden verzonden. Vooral tijdens migraties lopen de e-mailroutes vaak zo in elkaar over dat er onopgemerkte SPF-fouten ontstaan, tenzij met elke uitgaande route correct rekening wordt gehouden.

De hybride uitdaging: twee e-mailroutes, één SPF-record

In een hybride omgeving kan uitgaande e-mail via drie verschillende routes worden verzonden:

• Rechtstreeks via Exchange Online: voor mailboxen die in M365 worden gehost
• Exchange- of Edge Transport-servers op locatie: voor mailboxen die nog op locatie staan
• Slimme hosts of relays van derden: wanneer e-mail extern wordt doorgestuurd voordat deze het openbare internet bereikt

Elk traject geeft de ontvangende server een ander bron-IP-adres weer. Voor SPF maakt het niet uit welk traject de bedoeling was, omdat het alleen controleert of het daadwerkelijk waargenomen IP-adres geautoriseerd is. Beide trajecten moeten in één enkel SPF-record worden opgenomen, omdat er slechts één SPF-record per domein is toegestaan.

Hoe stel je een SPF-record in voor Hybrid Exchange?

Neem beide autorisatiepaden op:

v=spf1 include:spf.protection.outlook.com ipv4:203.0.113.10 ipv4:203.0.113.11 -all

De on-prem IP-adressen zijn de openbare adressen die uw mailserver gebruikt bij het verzenden naar het internet, niet de interne RFC 1918-adressen. Controleer de verzendconnectoren van uw Edge Transport-server en eventuele NAT- of firewallregels die het openbare IP-adres bepalen. Als u geografische redundantie of meerdere uitgaande paden hebt, moet elk openbaar IP-adres dat mogelijk e-mail verzendt, in het record zijn opgenomen.

SPF tijdens migratie (overgangsfase)

Bij een gefaseerde of cutover-migratie ontstaat er een periode waarin mailboxen op beide locaties aanwezig zijn en e-mail via beide routes kan worden verzonden. SPF moet gedurende de gehele periode beide routes dekken.

• Voordat de migratie begint: Zorg ervoor dat uw SPF-record zowel de on-prem ip4:-vermeldingen omvat als include:spf.protection.outlook.com.
• Tijdens de migratie: Laat beide autorisaties actief. Houd de SPF-slaagpercentages in de gaten via de geaggregeerde DMARC-rapporten. Als routeringswijzigingen ervoor zorgen dat e-mail via onverwachte routes wordt geleid, laten de rapporten dit zien voordat gebruikers het merken.
• Nadat de migratie is voltooid: Verwijder de on-prem ip4:-vermeldingen. Het achterlaten van verouderde IP-adressen in SPF vormt een veiligheidsrisico. Als die oude IP-adressen door uw internetprovider of cloudprovider opnieuw worden toegewezen, kan de nieuwe gebruiker geauthenticeerde e-mail versturen onder uw domeinnaam.

Het is een veelgemaakte fout om tijdens de migratie IP-adressen op locatie te verwijderen omdat de overgang „bijna voltooid“ is. Er is maar één mailbox nodig die nog via het oude pad wordt gerouteerd om de authenticatie voor de e-mail van die gebruiker te verstoren.

Subdomeinen in Exchange: SPF wordt niet overgenomen

Een cruciaal punt waar veel hybride organisaties tegenaan lopen: subdomeinen nemen het SPF-record van het bovenliggende domein niet over. Als marketing.jouwdomein.com e-mail verstuurt via een aparte e-mailprovider, heeft het een eigen SPF TXT-record nodig. SPF-records met jokertekens worden niet ondersteund door het protocol. Elk subdomein dat e-mail verstuurt, moet een eigen v=spf1-record hebben dat in de DNS-root is gepubliceerd.

Dit betekent ook dat het gebruik van subdomeinen een effectieve strategie is om de SPF-belasting te spreiden. Leid marketingmail via marketing.uwdomein.com en transactionele mail via mail.uwdomein.com, zodat elk subdomein zijn eigen budget van 10 lookups krijgt. Dit voldoet aan de RFC-normen, wordt goed ondersteund door e-maildienstverleners en wordt op grote schaal toegepast in bedrijfsomgevingen.

Controleert Exchange Online de SPF bij e-mailverkeer binnen dezelfde tenant?

Nee. Exchange Online behandelt berichten binnen dezelfde tenant als interne e-mail en voert geen SPF-controle uit. Berichten tussen verschillende tenants, zelfs als het om vertrouwde partnerorganisaties gaat, worden wel aan een SPF-controle onderworpen, omdat die e-mail via het openbare e-postrouteverloop wordt verzonden.

Voor organisaties met meerdere domeinen binnen één M365-tenant geldt dat elk domein een eigen SPF-record nodig heeft. Het delen van een record tussen domeinen via een CNAME-record is geen gangbare praktijk en werkt niet betrouwbaar.

Veelvoorkomende SPF-fouten bij Exchange en hoe je deze kunt oplossen

Elk van de onderstaande probleemoplossingsscenario’s volgt dezelfde diagnostische structuur: symptoom → oorzaak → oplossing.

PermError: te veel DNS-opzoekingen

• • Symptoom: SPF retourneert PermError. Ontvangers kunnen uw e-mail als ongewenst markeren of weigeren. DMARC-afstemming mislukt.
  • Oorzaak: Meer dan 10 DNS-lookups in uw SPF-record, inclusief geneste includes. Dit is de meest voorkomende SPF-fout bij organisaties die gebruikmaken van meerdere SaaS-diensten.

• Oplossing (5-stappenplan):

• • Stap 1: Controleer je huidige aantal lookups met behulp van een SPF-checker die geneste includes recursief telt.
  • Stap 2: Verwijder verouderde includes voor services die u niet meer gebruikt.
  • Stap 3: Vervang include: door ip4: mechanismen wanneer de IP-adressen van de leverancier stabiel en gedocumenteerd zijn.
  • Stap 4: Verplaats verzenders met een hoog volume die niet tot het bedrijf behoren (marketing, transacties) naar subdomeinen met hun eigen SPF-records.
  • Stap 5: Als je nog steeds boven de 10 zit, implementeer dan SPF-flattening of macro's met behulp van een tool zoals PowerSPF om includes automatisch om te zetten in IPv4-vermeldingen en houd het record bijgewerkt wanneer leveranciers van IP-adres veranderen.

Voor-en-na-voorbeeld:

Voorheen (14 zoekopdrachten: PermError):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com include:zendesk.com include:spf.freshdesk.com a mx -all

Na (7 zoekopdrachten: onder de limiet):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net ip4:198.2.128.0/24 ip4:192.254.113.0/24 -all# Salesforce en Zendesk verplaatst naar mail.uwdomein.com# Freshdesk vervangen door afgevlakte ip4-vermeldingen# a- en mx-mechanismen verwijderd (overbodig door expliciete includes)

Er zijn meerdere SPF-records gevonden

• Symptoom: De SPF-checker geeft een foutmelding 'multiple SPF records' weer. Alle SPF-evaluaties mislukken.
• Oorzaak: Er bestaan twee of meer TXT-records die beginnen met v=spf1 voor hetzelfde domein. Dit gebeurt vaak wanneer het provisioningproces van een SaaS-leverancier een tweede record aanmaakt zonder dat de beheerder dit opmerkt.
• Oplossing: Voeg samen tot één record. U kunt meerdere include: en ip4: mechanismen in één record hebben, maar slechts één v=spf1 TXT-record per domein. Verwijder de overbodige vermelding.

SPF werkt niet meer na het toevoegen van een nieuwe SaaS-tool

• Symptoom: E-mails van de nieuw toegevoegde tool slagen niet voor de SPF-controle. Andere afzenders kunnen ook problemen ondervinden als het nieuwe include het totale aantal lookups boven de 10 brengt.
• Oorzaak: De nieuwe service is niet toegevoegd aan SPF, of het toevoegen ervan heeft de opzoeklimiet overschreden.
• Oplossing: Voeg de include toe en controleer vervolgens opnieuw het totale aantal lookups. Als je nu boven de 10 zit, is het aantal lookups het probleem, niet de include zelf. Pas de bovenstaande 5-stappenworkflow toe.

SPF-fout bij hybride uitwisseling (lokale IP ontbreekt)

• Symptoom: E-mails die vanuit de lokale Exchange-omgeving worden verzonden, slagen niet voor de SPF-controle, terwijl e-mails afkomstig van M365 wel worden geaccepteerd.
• Oorzaak: Het openbare IP-adres van de on-premises server staat niet in het SPF-record. Dit komt vooral vaak voor na een gedeeltelijke migratie waarbij de beheerder de SPF voor Exchange Online heeft bijgewerkt, maar is vergeten dat het on-premises pad nog steeds e-mail doorstuurt.
• Oplossing: Voeg ip4:x.x.x.x toe voor elk uitgaand IP-adres op locatie. Als e-mail via een Edge Transport-server, smart host of een relay van een derde partij wordt gerouteerd, moet het openbare IP-adres van die relay ook worden opgenomen.

SPF werkt niet meer na migratie naar Exchange Online

• Symptoom: E-mails na de migratie slagen over de hele linie niet voor de SPF-controle.
• Oorzaak: DNS verwijst nog steeds naar oude on-prem IP-adressen, bijvoorbeeld: spf.protection.outlook.com is niet toegevoegd, of e-mail wordt tijdens de overgang via onverwachte routes gerouteerd.
• Oplossing: Controleer of het SPF-record tijdens de migratieperiode zowel de oude (on-prem) als de nieuwe (Exchange Online) autorisatiepaden bevat. Verwijder oude vermeldingen pas nadat is bevestigd dat 100% van de mailboxen is gemigreerd. Houd gedurende het hele proces de geaggregeerde DMARC-rapporten in de gaten. Deze laten precies zien welke paden uw e-mail volgt vanuit het perspectief van de ontvangers.

SPF is goedgekeurd, maar de e-mail komt in de spamfolder terecht

• Symptoom: De headers geven spf=pass weer, maar het bericht komt terecht in de spamfolder van de ontvanger.
• Oorzaak: SPF is slechts één van de vele signalen. De reputatie van de afzender, de inhoud, DKIM of DMARC kunnen mogelijk niet in orde zijn. Elk van deze factoren kan een geldige SPF-uitslag tenietdoen.
• Oplossing: Controleer de DKIM-afstemming, het DMARC-beleid, de reputatie van de afzender (status op de zwarte lijst, leeftijd van het domein, recente volumeveranderingen) en de reputatie van de inhoud/links. De Domain Analyzer van PowerDMARC geeft in één scan een score voor al deze aspecten.

SPF-fout bij doorgestuurde e-mails

• Symptoom: Automatisch doorgestuurde berichten, e-mails van mailinglijsten of berichten die via transportregels worden gerouteerd, slagen niet voor de SPF-controle.
• Oorzaak: Het IP-adres van de doorstuurserver staat niet in het SPF-record van de oorspronkelijke afzender. Dit is een architectonische beperking van SPF en geen configuratiefout.
• Oplossing: Behandel het mislukken van SPF bij doorgestuurde e-mail als verwacht gedrag. Zorg ervoor dat DKIM correct is geconfigureerd voor uw domein. DKIM-handtekeningen blijven behouden bij het doorsturen, waardoor DMARC via DKIM-afstemming kan slagen, zelfs wanneer SPF mislukt. ARC (Authenticated Received Chain) in Exchange Online behoudt bovendien authenticatieresultaten in vertrouwde doorstuurketens.

Hoe Exchange Online SPF-resultaten daadwerkelijk verwerkt (uitleg over de ‘black box’)

De meeste Exchange-beheerders lopen tegen dezelfde verwarring aan: hoe gaat Exchange Online Protection (EOP) nu eigenlijk om met SPF-fouten? Sommige bronnen beweren dat een ‘hard fail’ automatisch tot afwijzing leidt. Anderen suggereren dat SPF slechts een ondergeschikt spamsignaal is. Hier volgt hoe het in werkelijkheid werkt.

De multisignaalpijplijn (SPF is slechts één invoer)

Exchange Online Protection neemt geen beslissingen over de aflevering op basis van SPF alleen. SPF is slechts één van de factoren in een uitgebreide authenticatiebeoordeling die het volgende omvat:

• SPF-resultaat: geslaagd, mislukt, gedeeltelijk mislukt, neutraal, PermError of TempError
• DKIM-resultaat: geslaagd, mislukt of geen
• DMARC-resultaat: afgeleid van de afstemming van SPF of DKIM met het From-domein in de header
• Reputatie van de afzender: IP-reputatie, domeinreputatie, historische verzendpatronen
• Spam Confidence Level (SCL)-score: de interne score van Microsoft, variërend van -1 (veilige afzender) tot 9 (spam met hoge betrouwbaarheid)
• Inhoudsfiltering: trefwoorden, URL-reputatie, analyse van bijlagen

EOP baseert zich op het samengestelde authenticatieresultaat – en niet op één specifiek protocol – om te bepalen wat er uiteindelijk met het bericht gebeurt.

Hoe EOP omgaat met elke SPF-uitkomst

PermError is een ernstige fout die EOP vrijwel op dezelfde manier behandelt als een regelrechte SPF-fout, en die doorwerkt in DMARC, waardoor de authenticatie volledig wordt verstoord. Daarom vormt de limiet van 10 lookups een structureel zwak punt.

Waar kunt u de SPF-resultaten in Exchange bekijken?

Drie plaatsen, in oplopende volgorde van volledigheid:

• Berichtkoppen (Authentication-Results): Elk bericht dat door EOP wordt verwerkt, wordt voorzien van de stempel spf=pass/fail/softfail/permerror/temperror, samen met het geëvalueerde verzendende domein en IP-adres.
• Trace van Exchange-berichten: Toont de bezorgstatus, bron-IP, ontvanger en uiteindelijke bestemming, maar geeft de SPF-evaluatie niet duidelijk weer. Als u alleen op berichttracering vertrouwt voor SPF-zichtbaarheid, vaart u op goed geluk.
• DMARC-geaggregeerde rapporten (RUA): De enige gegevensbron die laat zien hoe ontvangers wereldwijd uw SPF beoordelen. RUA-rapporten tonen de slagings- en faalpercentages per IP en per bron voor elke ontvangende server die uw e-mail verwerkt.

SPF-hard-fail-handhaving configureren in EOP

Standaard neemt Exchange Online SPF-resultaten mee in de samengestelde score, maar weigert het geen berichten uitsluitend op basis van SPF. Om EOP expliciet zo in te stellen dat SPF-hard-fail als spam te markeren:

Ga in het Exchange Online-beheercentrum naar Beveiliging → Spamfilter → Geavanceerde opties en zet de schakelaar ‘SPF-record: hard fail’ op Aan. Je kunt ook de volgende PowerShell-cmdlet uitvoeren:

Get-HostedContentFilterPolicy | Where-Object {$_.IsDefault -eq $true} | Set-HostedContentFilterPolicy -MarkAsSpamSpfRecordHardFail On

SPF-aanbevelingen voor Exchange-omgevingen in 2026

• Gebruik -all (hard fail) als standaardinstelling. In combinatie met DMARC is -all de norm. De enige uitzondering is de eerste implementatiefase, voordat DMARC volledig is geïmplementeerd.
• Gebruik nooit +all. Hiermee geef je het hele internet toestemming om namens jouw domein te verzenden. Als je +all in je record aantreft, beschouw dit dan als een actueel beveiligingsincident.
• Vermeld altijd spf.protection.outlook.com voor M365, zelfs als uitgaande e-mail via een gateway van een derde partij wordt gerouteerd. Exchange Online genereert agenda-uitnodigingen, automatische antwoorden, NDR’s en leesbevestigingen die rechtstreeks vanuit de infrastructuur van Microsoft worden verzonden.
• Controleer je SPF-record minimaal elk kwartaal. SaaS-leveranciers wijzigen hun IP-reeksen. Marketingteams gaan nieuwe tools gebruiken zonder de IT-afdeling hiervan op de hoogte te stellen. Door elk kwartaal een controle uit te voeren, kun je afwijkingen opsporen voordat deze tot een PermError leiden. Door continue monitoring via DMARC-rapporten worden afwijkingen in realtime opgemerkt.
• Implementeer SPF in combinatie met DKIM en DMARC. SPF alleen voorkomt geen vervalsing van het ‘From’-veld in de header. DKIM alleen controleert niet of de afzender in de envelop klopt. Alleen door DMARC af te dwingen – waarbij wordt gecontroleerd of SPF of DKIM overeenkomt met het ‘From’-domein in de header – is uitgebreide bescherming gewaarborgd.
• Voldoe aan de afzendervereisten van alle grote ontvangers. In 2026 eisen Google, Yahoo, Microsoft en Apple allemaal SPF + DKIM + DMARC voor bulkverzenders. PCI DSS v4.0, dat sinds maart 2025 verplicht is, schrijft deze drie maatregelen expliciet voor als anti-phishingmaatregelen.

Hoe u de SPF continu kunt controleren 

Het grootste verschil tussen organisaties die „SPF hebben ingesteld“ en organisaties die daadwerkelijk door SPF worden beschermd, is de monitoring. Eenmalige configuratie is het makkelijke deel, maar het opsporen van onopgemerkte storingen in de maanden daarna is wat het verschil maakt tussen werkende e-mailverificatie en theoretische e-mailverificatie.

Waarom eenmalige SPF-controles een vals gevoel van veiligheid geven

SPF-records veranderen voortdurend omdat leveranciers hun geautoriseerde IP-reeksen aanpassen, uw include-ketens naar andere IP-adressen verwijzen en een daarvan ervoor kan zorgen dat u de opzoeklimiet overschrijdt. Teams voegen nieuwe SaaS-tools toe zonder de SPF bij te werken. Bij migraties verandert de routering van uitgaande e-mail op manieren die niet in uw DNS tot uiting komen. Oude vermeldingen blijven bestaan voor diensten die de organisatie al jaren niet meer gebruikt.

Hoe continue SPF-monitoring eruitziet

Vier onderdelen, die elk een specifieke storingsvorm aanpakken:

• DMARC-geaggregeerde rapporten worden dagelijks verzameld van ontvangers over de hele wereld. Deze rapporten tonen de SPF-resultaten per IP-adres en per bron voor elke ontvangende server die uw e-mail heeft verwerkt. PowerDMARC verzamelt deze gegevens automatisch en presenteert ze in een speciaal SPF-analysedashboard met slagings- en faalpercentages per bron, het aantal DNS-lookups en historische trendlijnen.
• Geautomatiseerde meldingen zodra SPF-fouten een drempel overschrijden, wanneer er een nieuwe, niet-geautoriseerde afzender verschijnt of wanneer een DNS-wijziging invloed heeft op uw record. PowerAlerts van PowerDMARC sturen deze via e-mail, Slack of Discord, zodat het juiste team het probleem tijdens kantooruren ziet.
• Geautomatiseerde SPF-afvlakking die wordt bijgewerkt wanneer externe providers hun IP-adressen wijzigen. PowerSPF vertaalt include: chains naar ip4:-vermeldingen en houdt uw record permanent onder de 10 lookups zonder handmatige DNS-wijzigingen.
• Monitoring van zwarte lijsten en reputatie. Als uw verzend-IP's op een blokkeerlijst terechtkomen, kan SPF weliswaar slagen, maar verslechtert de afleverbaarheid toch. Geïntegreerde reputatiemonitoring detecteert de foutmodus die SPF alleen niet ziet.

Speciaal voor MSP’s: wanneer de provider van een klant zijn IP-bereik wijzigt, weet u dat al voordat de e-mail van de klant niet meer werkt. 

Het MSP-dashboard van PowerDMARC biedt gecentraliseerde SPF-monitoring voor alle klantdomeinen vanaf één scherm, met de mogelijkheid om per klant details te bekijken. Hierdoor verandert SPF-beheer van reactief brandjes blussen in een volwaardige dienst.

Start een gratis proefperiode van 15 dagen om het zelf uit te proberen. 

Veelgestelde Vragen

Hoe controleer ik SPF-records in Exchange Online?

Gebruik een SPF-controletool zoals de PowerDMARC SPF Checker, voer je domein in en controleer het record, de syntaxis en het aantal lookups. Je kunt dit ook controleren in het Microsoft 365-beheercentrum onder Instellingen → Domeinen → DNS-records. Voor verificatie aan de kant van de ontvanger controleer je de header Authentication-Results in een extern verzonden testbericht.

Welk SPF-record heb ik nodig voor Microsoft 365?

Minimaal: v=spf1 include:spf.protection.outlook.com -all. Als je nog andere verzendservices gebruikt (HubSpot, SendGrid, Salesforce, Zendesk), voeg dan hun includes toe vóór -all. Zorg ervoor dat het totale aantal DNS-lookups onder de 10 blijft, inclusief geneste lookups binnen elke include:.

Waarom werkt SPF niet, ook al ziet mijn record er correct uit?

Veelvoorkomende oorzaken: het overschrijden van de limiet van 10 DNS-lookups (PermError), meerdere SPF-records op hetzelfde domein, doorgestuurde e-mails (SPF werkt bij het doorsturen per definitie niet) of een leverancier die zijn geautoriseerde IP-bereiken wijzigt zonder u hiervan op de hoogte te stellen. Controleer de header `Authentication-Results` voor het specifieke `spf=`-resultaat.

Wat is het verschil tussen -all en ~all?

-all (hard fail) geeft ontvangers de opdracht om berichten van niet-geautoriseerde IP-adressen te weigeren of af te wijzen. ~all (soft fail) is soepeler. In 2026, wanneer DMARC is geïmplementeerd, bepaalt het DMARC-beleid de handhaving, ongeacht de kwalificatie. Als u nog geen DMARC hebt, biedt -all aanzienlijk betere bescherming.

Hoeveel DNS-lookups voert include:spf.protection.outlook.com uit?

De Microsoft-include telt als één opzoekactie, maar leidt tot geneste includes die ongeveer 2 tot 4 extra opzoekacties vereisen. Het exacte aantal varieert naarmate Microsoft zijn infrastructuur bijwerkt. Controleer dit altijd met een tool die geneste opzoekacties recursief telt.

Is SPF voldoende om e-mailspoofing te voorkomen?

Nee. SPF alleen voorkomt geen vervalsing van het zichtbare ‘Van:’-adres (header ‘From’). Het controleert alleen de afzender van de envelop (Return-Path). Voor volledige bescherming is DKIM nodig voor ondertekening op berichtniveau, plus DMARC om naleving af te dwingen. De combinatie van deze drie protocollen, die continu worden gecontroleerd, is de norm in 2026.