SPF-record instellen: voorbeelden en veelvoorkomende fouten

Wie in 2026 e-mailinfrastructuur inricht, moet het SPF-record zorgvuldig controleren. Fouten kunnen, afhankelijk van de ontvangende dienst en andere authenticatie, tot spamplaatsing of volledige weigering leiden. Een geldig record alleen garandeert geen inboxplaatsing.

Sinds februari 2024 gelden bij Google en Yahoo strengere authenticatie-eisen voor bepaalde afzenders. Ontbrekende of onjuiste SPF kan relevant zijn, maar veroorzaakt niet bij iedere ontvanger automatisch SMTP 550. Controleer de toepasselijke regels en de volledige foutmelding.

Voor een oprichter met één domein kan een fout betekenen dat een investeerder de presentatie niet ontvangt. Voor een MSP met 500 klantdomeinen kan de maandag beginnen met vragen over onbereikbaar Gmail. Zorgvuldige configuratie en monitoring verkleinen dit risico, zonder alle problemen uit te sluiten.

Deze gids legt uit wat SPF doet, hoe je een record opbouwt, welke valkuilen de bezorgbaarheid kunnen beïnvloeden en hoe je configuraties overzichtelijk beheert bij meerdere klanten.

Wat SPF wel en niet doet

Sender Policy Framework (SPF) is een DNS-gebaseerd autorisatieprotocol, beschreven in RFC 7208. Het record bepaalt welke systemen voor de gecontroleerde envelopidentiteit mogen verzenden. Het is geen algemene beveiligingslaag en authenticeert niet zelfstandig het zichtbare afzenderadres.

Hoe de controle werkt

Bij een bericht van alice@yourcompany.com kijkt Gmail voor SPF niet uitsluitend naar het zichtbare From-adres. Relevant is de envelopafzender in MAIL FROM, die na aflevering doorgaans in Return-Path staat en voor bounces wordt gebruikt. Bij een lege envelopafzender kan HELO worden gecontroleerd. De ontvanger zoekt het toepasselijke domeinrecord op en evalueert de verzendende IP.

Een passend mechanisme kan pass opleveren. Niet-geautoriseerde verzending kan bijvoorbeeld softfail bij ~all of fail bij -all krijgen; neutral en fouten zijn eveneens mogelijk. Het resultaat schrijft geen automatische afleverbeslissing voor.

Het verschil tussen From en Return-Path

Dit wordt soms voorgesteld als de fout van 90% van beginners, maar dat is geen onderbouwde statistiek. De technische kern: SPF controleert niet het From-adres dat Outlook of Apple Mail toont, maar de relevante envelopidentiteit.

De valkuil: Mailchimp kan voor nieuwsbrieven een eigen bounceadres gebruiken, zoals bounce-mc.us1.mailchimp.com. De ontvanger controleert dan SPF van Mailchimp, niet jouw domein. Jouw eigen record kan geldig zijn zonder bij die verzending te worden geraadpleegd; de daadwerkelijke providerconfiguratie is bepalend.

Daarom is SPF alleen onvoldoende voor authenticatie van het zichtbare domein. Lees over de samenwerking met DKIM en DMARC in de instelvolgorde voor SPF, DKIM en DMARC.

Waarom SPF belangrijk blijft

Ook met DKIM en DMARC blijft SPF belangrijk voor de toepasselijke afzendereisen. Een melding zoals 550 5.7.515 Access Denied moet binnen Microsofts specifieke regels worden onderzocht; zij bewijst niet dat iedere ontbrekende SPF-record bij iedere ontvanger direct tot deze fout leidt.

Basispatroon: één verzendprovider

Een klein bedrijf met één hoofdprovider, zoals TrekMail, Google Workspace of Microsoft 365, en eventueel één marketingdienst heeft een overzichtelijke configuratie nodig. Voeg autorisaties samen waar ze werkelijk voor hetzelfde envelopdomein gelden.

De basisregel: publiceer precies één SPF-record per gecontroleerde DNS-naam.

Een nieuwe dienst als tweede SPF TXT-record toevoegen in plaats van samenvoegen veroorzaakt PermError bij SPF-evaluatie. Het probleem is meerdere geselecteerde SPF-records, niet meerdere TXT-records in het algemeen. De ontvanger bepaalt vervolgens het beleid.

Onderdelen van een SPF-record

De SPF-instelgids biedt verdere voorbeelden. Controleer alle sjablonen aan de hand van actuele providerwaarden, syntaxis en verzendroutes voordat je ze publiceert.

TrekMail voor kleine bedrijven vergelijken

De bron vergelijkt Google Workspace op $6-$18 per gebruiker per maand. Voor tien gebruikers is dat $720-$2,160 per jaar. TrekMail Starter wordt beschreven als $3.50 per maand met maximaal 100 gebruikers. Dit zijn historische vergelijkingsvoorbeelden; verifieer actuele prijzen, voorwaarden en inbegrepen diensten. include:spf.trekmail.net kan passen bij ondersteunde verzending, maar vervangt geen volledige DNS- en authenticatiecontrole.

Meerdere afzenders: beheer voor bureaus

MSP's en bureaus beheren vaak meerdere verzenddiensten: HubSpot voor verkoop, Zendesk voor ondersteuning, Klaviyo voor marketing en TrekMail voor zakelijke mail. Niet iedere dienst vraagt automatisch een include in het hoofddomein; stel vast welk envelopdomein elke dienst werkelijk gebruikt.

Waar autorisaties voor hetzelfde domein gelden, moeten ze in één SPF-record passen. Houd daarbij rekening met de limiet van 10 relevante DNS-opzoekende termen.

De limiet van 10 DNS-termen beheren

RFC 7208 §4.6.4 begrenst relevante DNS-opzoekende mechanismen en modifiers tijdens evaluatie tot 10, inclusief geneste termen. Dit is geen telling van alle DNS-pakketten. De beperking helpt misbruik van de DNS-infrastructuur voorkomen en vraagt ook bij legitieme configuraties aandacht.

Deze termen tellen wanneer ze worden geëvalueerd: include:, a, mx, exists, redirect. Exists gebruikt een A-query; redirect draagt de evaluatie over als de voorafgaande mechanismen niet matchen. De verouderde ptr-term telt eveneens mee.

Deze mechanismen verbruiken dat budget niet: ip4:, ip6:, all

De valkuil van geneste includes

Je voegt include:bluehost.com toe: dat lijkt 1 term. Een illustratief genest record kan vervolgens spf.protection.outlook.com en mail.bluehost.com bevatten, zodat die ene include drie relevante termen laat evalueren. spf.protection.outlook.com kan weer verder verwijzen. Dit is geen bevestiging van huidige Bluehost-records; inspecteer de actuele keten en het gevolgde pad.

Overschrijdt de geëvalueerde keten 10 relevante termen, dan hoort de ontvanger PermError terug te geven. Dat is niet hetzelfde als SPF fail en leidt niet noodzakelijk tot stille verdwijning. Raadpleeg logs en andere authenticatie om de gevolgen vast te stellen.

Je verbruik controleren

Gebruik een CLI of een betrouwbare visualisatietool. Op Mac of Linux kun je beginnen met:

dig +short txt yourdomain.com

Onderzoek daarna ieder include:-domein recursief, en neem andere relevante mechanismen en modifiers mee. De TXT-query alleen telt het budget niet. De gids over SPF-opzoeklimieten helpt de keten en overschrijdingen onderzoeken.

Flattening of segmentatie met subdomeinen

Wanneer je de limiet van 10 relevante termen dreigt te overschrijden, zijn er twee mogelijke aanpakken. Niet ieder bureau bereikt die limiet en het bereiken ervan is nog geen overschrijding.

Optie 1: SPF-flattening, met onderhoudsrisico

Flattening vervangt geselecteerde include:-ketens door actuele IP-adressen, bijvoorbeeld als ip4:-mechanismen. ip4: verbruikt geen DNS-termenbudget, maar honderden IP-adressen kunnen nog andere limieten en beheerproblemen opleveren. Neem ook relevante adresfamilies zorgvuldig mee.

Het risico: Diensten zoals HubSpot en Klaviyo kunnen verzend-IP's wijzigen. Een statische lijst kan bijvoorbeeld na enkele maanden verouderen, nieuwe legitieme IP's missen of oude IP's onterecht blijven autoriseren. Dit is geen vaste termijn, maar vereist actief onderhoud.

Kies flattening alleen met betrouwbare broncontrole, wijzigingsbeheer, validatie en een herstelplan. Automatische updates kunnen helpen, maar garanderen niet dat iedere wijziging correct en tijdig wordt verwerkt.

Optie 2: segmentatie met subdomeinen

Je kunt verzendstromen verdelen over envelopdomeinen in plaats van alles in het hoofddomein onder te brengen. SPF wordt voor de daadwerkelijke MAIL FROM-identiteit geëvalueerd; daarvoor kan een subdomein worden ingericht.

Moet marketing zichtbaar vanaf team@company.com verzenden, of past news@marketing.company.com? Alleen het zichtbare adres aanpassen wijzigt het SPF-domein niet.

Hoofddomein (company.com): houd de toepasselijke autorisaties overzichtelijk, bijvoorbeeld voor zakelijke en kritieke mail. Onderstaande records zijn illustratief; controleer providerwaarden vóór publicatie.

v=spf1 include:spf.trekmail.net -all

Marketingsubdomein (marketing.company.com): configureer de betrokken diensten om dit werkelijk als envelopdomein te gebruiken.

v=spf1 include:servers.mcsv.net include:hubspot.com -all

Een apart daadwerkelijk gebruikt SPF-domein heeft zijn eigen budget van 10 relevante termen. Controleer daarnaast relaxed of strict DMARC-uitlijning. Een slechte reputatie van marketing.company.com blijft niet gegarandeerd daar beperkt: ontvangers kunnen het organisatiedomein en gedeelde IP's meewegen. Dit is beheerssegmentatie, geen bescherming van het directieadres tegen alle reputatierisico's.

Meer voorbeelden staan in de SPF-configuratiesjablonen. Lees ook over configuratie voor meerdere verzenddiensten en controleer steeds de toepasselijke providerinstellingen.

Controle na DNS-publicatie

Opslaan in het DNS-paneel rondt de inrichting niet af. Controleer publicatie, syntaxis en echte verzending met de volgende stappen.

1. DNS-publicatie en caches controleren

Veranderingen kunnen minuten of uren zichtbaar blijven verschillen door TTL en caching. Controleer naast de autoritatieve servers een openbare resolver, niet alleen je lokale cache:

nslookup -type=txt yourdomain.com 8.8.8.8

8.8.8.8 richt de query op Googles openbare resolver in plaats van de resolver van je ISP. Ook die kan cachen. Een goed antwoord daar bewijst niet dat iedere resolver wereldwijd de wijziging al ziet.

2. Syntaxis controleren

Let op syntaxis en evaluatiegedrag. Veelvoorkomende aandachtspunten zijn:

• Witruimte vóór v=spf1 kan herkenning als SPF-record verhinderen
• ip4: 192.1.1.1: de spatie na de dubbele punt is ongeldig
• Meerdere all-mechanismen: all matcht altijd, waardoor latere mechanismen niet worden bereikt
• Dubbele include:-termen kunnen bij evaluatie onnodig budget verbruiken; het gevolg hangt af van het pad en eventuele fouten

Gebruik een syntaxischecker en bevestig zelf de uitkomst. TrekMails DNS-wizard kan afhankelijk van de huidige functies waarschuwingen geven, maar vervangt geen volledige validatie.

3. De limiet voor lege DNS-antwoorden

RFC 7208 beveelt aan het aantal void lookups te begrenzen tot 2 opzoekingen zonder resultaat, bijvoorbeeld NXDOMAIN of een antwoord zonder relevante gegevens. Dit staat los van het algemene termenbudget.

Een typefout zoals include:spf.trekmaill.net, met een extra l, kan een leeg antwoord veroorzaken: 1 void lookup. Twee lege antwoorden overschrijden de aanbevolen limiet nog niet; overschrijding kan PermError geven. Een include waarvan het doel geen bruikbaar SPF-record heeft, kan echter al zelfstandig een fout veroorzaken.

Controleer daarom niet alleen syntaxis maar ook actuele DNS-antwoorden. Een syntaxischecker alleen hoeft ontbrekende of lege doelen niet te ontdekken.

4. Headers van echte berichten onderzoeken

Stuur een test naar een eigen Gmail-account. Open via het menu met drie puntjes "Origineel weergeven" en zoek Authentication-Results. Vertrouw alleen de resultaten die de ontvangende dienst zelf heeft toegevoegd, niet willekeurige meegestuurde headers. Een illustratief resultaat is:

spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)

spf=neutral of spf=softfail vraagt om onderzoek van beleid, envelopdomein en verzend-IP, maar bewijst niet automatisch een configuratiefout. Controleer ook DKIM en DMARC-uitlijning. Zie DNS-status controleren voor aanvullende technische controles.

Veelvoorkomende fouten

De volgende patronen komen geregeld voor bij SPF-vragen. Door ze vooraf te begrijpen kun je gericht controleren wanneer een probleem ontstaat.

1. SPF bij doorsturen

SPF evalueert de verzendende IP voor een envelopidentiteit. Dat maakt klassiek doorsturen een aandachtspunt.

Alice mailt Bob, die alles naar Charlie doorstuurt. Als de envelopafzender ongewijzigd blijft, ziet Charlie de IP van Bobs server terwijl SPF voor het oorspronkelijke domein wordt geëvalueerd. De controle kan daardoor falen, ook bij een legitiem bericht; het werkelijke resultaat hangt van de configuratie af.

SPF alleen lost dit niet algemeen op. DKIM kan doorsturen overleven als de relevante ondertekende headers en body geldig blijven. Voor DMARC is bovendien uitlijning nodig. SRS kan de envelopafzender herschrijven voor SPF van de doorstuurdienst, maar herstelt niet automatisch de oorspronkelijke From-uitlijning.

Lees meer over deze verschillen in domeinmail doorsturen en bezorgbaarheid. Ook forwarding is geen garantie op inboxplaatsing.

2. Het ptr-mechanisme

Begin jaren 2000 kwam ptr, dat reverse DNS gebruikt, vaker voor:

v=spf1 ptr -all

De RFC raadt ptr af vanwege betrouwbaarheid en belasting, maar schrapt het niet uit de syntaxis. Stel niet zonder bewijs dat Gmail elk dergelijk record negeert of bestraft. Vervang geërfde ptr-autorisaties zorgvuldig door passende mechanismen. Dit staat los van het belang van PTR-records voor mailservers.

3. Het risico van +all

Ook deze onveilige illustratieve configuratie komt voor; neem providerwaarden niet ongecontroleerd over:

v=spf1 include:spf.google.com +all

De qualifiers betekenen:

• -all = fail voor iedere nog niet gematchte IP; geen automatisch bevel tot weigering
• ~all = softfail voor iedere nog niet gematchte IP; geen garantie op acceptatie of markering
• +all = pass voor iedere IP die dit mechanisme bereikt

+all kan willekeurige IP's autoriseren voor de gecontroleerde envelopidentiteit. Een record met +all kan misbruik vergemakkelijken, maar schakelt andere ontvangerscontroles niet uit en maakt phishing niet automatisch veilig. Staat je record op +all, inventariseer dan de legitieme verzendroutes en kies een passende afsluiting, bijvoorbeeld -all, met tests en een terugvalplan.

4. Return-Path van externe verzenddiensten

Een marketingdienst kan zonder aangepaste bounceconfiguratie zijn eigen Return-Path-domein gebruiken. SPF controleert dan dat domein, niet het jouwe. Een aangepast trackingdomein is niet hetzelfde als een aangepast envelop- of bouncedomein. DMARC kan alsnog slagen via geldige uitgelijnde DKIM; SPF-uitlijning volgt relaxed of strict domeinvergelijking.

Onderzoek of je ESP een aangepast Return-Path-subdomein ondersteunt, zoals bounce.yourcompany.com, en configureer de daarvoor vereiste DNS-records. Zie DMARC-uitlijning en domeinreputatie.

Generators: bruikbaar, maar niet zonder controle

SPF-generators verschillen in kwaliteit en mogelijkheden. Sommige helpen bij overzicht en controle; geen enkele uitkomst moet zonder beoordeling worden gepubliceerd.

Bruikbare hulpmiddelen

Visualisatietools brengen de geneste include:-keten in beeld. Controleer of ze ook andere relevante termen en evaluatiepaden meenemen. Sommige hulpmiddelen voor e-mailbezorgbaarheid bieden deze functie.

Syntaxischeckers kunnen ontbrekende dubbele punten en ongeldige tekens vinden. Lege DNS-antwoorden vereisen ook DNS-evaluatie; controleer wat de tool werkelijk ondersteunt na iedere wijziging.

Waar extra controle nodig is

Wizards met één klik kunnen verschillende afsluitingen voorstellen; ga niet uit van een universele standaard. ?all geeft neutral voor niet eerder gematchte IP's. Kies bewust je beleid na een afzenderinventarisatie; -all of ~all hebben andere resultaten, maar geen ervan garandeert bezorging.

Generators voor gesplitste tekenreeksen: Een DNS TXT-tekenreeks heeft maximaal 255 octetten, niet noodzakelijk hetzelfde aantal Unicode-tekens. Een lang SPF-record kan bestaan uit meerdere geciteerde tekenreeksen in één TXT-record, niet twee afzonderlijke SPF-records:

• Juiste structuur: "v=spf1 include:a..." "include:b... -all" (twee tekenreeksen, één record; schematisch voorbeeld waarin bij werkelijk gebruik de benodigde grensspatie moet worden toegevoegd)
• Onjuist: Twee afzonderlijke SPF TXT-records veroorzaken PermError bij selectie

Tekenreeksen worden zonder automatisch ingevoegde spatie samengevoegd. Controleer de uiteindelijke waarde, grensspaties en syntaxis. Niet iedere generator splitst correct; valideer de uitkomst vóór publicatie en bevestig daarna de DNS-antwoorden.

Meer over hulpmiddelen en hun beoordeling staat in onze gids voor SPF-generators en instellingen.

TrekMail: configuraties samenbrengen

Grote suites zijn niet per definitie slechte producten. Ze bundelen diensten en rekenen vaak per gebruiker. Of die bundel nuttig is, hangt af van de behoeften van je klanten en de actuele contracten.

Voor domeinen die via de betreffende beheerde TrekMail-route verzenden, kan het volgende illustratieve SPF-record van toepassing zijn. Verifieer actuele waarden en alle overige verzenddiensten:

v=spf1 include:spf.trekmail.net -all

Die ene regel is niet automatisch compleet voor ieder gehost domein, vooral niet bij eigen SMTP of extra diensten. IP-beheer, rDNS en feedbackloops hangen af van de daadwerkelijke verzendroute en dienstverlening. Ook bij beheerde SMTP blijven toestemming, doelgroep, passende volumegroei en klachtenafhandeling belangrijk; autorisatie garandeert geen aflevering.

Een MSP met 50 klantdomeinen kan in een uniforme configuratie 50 vergelijkbare SPF-records beheren. Die standaardisatie kan werk verminderen, maar verschillen tussen klanten en verzenddiensten blijven relevant. Ook als je dezelfde regel al honderd keer hebt gebruikt, controleer je ieder nieuw domein en de geldende abonnementsvoorwaarden.

Bij migratie helpen het IMAP-migratieoverzicht en de gids voor vereiste DNS-records om mailboxgegevens en MX, SPF, DKIM en DMARC afzonderlijk te plannen en testen. IMAP verplaatst geen DNS of appconfiguratie; MX gaat vooral over inkomende routing. Controleer de actuele dashboardmogelijkheden voor meerdere klanten in domeinen in bulk importeren.

Een zorgvuldige SPF-aanpak

Authenticatie-eisen zijn sinds 2024 aangescherpt voor bepaalde afzenders. Een onjuist SPF-record verdient aandacht, maar de gevolgen verschillen per ontvanger, authenticatieroute en beleid. Onderhoud de configuratie in plaats van op een algemene respijtperiode te vertrouwen.

De belangrijkste controles op een rij:

1. Inventariseer de records. Voer dig +short txt yourdomain.com uit en tel alleen de geselecteerde SPF-records, niet alle TXT-records. Meer dan één SPF-record op dezelfde naam veroorzaakt PermError.
2. Combineer toepasselijke autorisaties. Gebruik één SPF TXT-record voor de verzenddiensten die werkelijk hetzelfde envelopdomein gebruiken.
3. Evalueer het DNS-budget. Overschrijdt het relevante pad 10 termen, onderzoek dan vereenvoudiging of echte envelopsubdomeinen. Flattening vraagt aantoonbaar onderhoud.
4. Kies bewust -all. Overweeg de stap vanaf ~all na inventarisatie en tests. Beoordeel +all met prioriteit en wijzig het zorgvuldig; ontvangersbeleid blijft bepalend.
5. Controleer Return-Path-uitlijning. Onderzoek bij Mailchimp en HubSpot een eigen bouncedomein waar ondersteund. Controleer daarnaast geldige uitgelijnde DKIM voor DMARC.
6. Stop niet bij SPF. Doorsturen kan SPF laten falen en ook DKIM kan door wijzigingen ongeldig worden. Richt alle drie in: SPF, DKIM en DMARC, en test de relevante routes.

Een SPF-record van 50 bytes is een illustratie, geen vaste omvang. Goede inrichting helpt risico's voor klantenrelaties beperken. Controleer bij iedere verzendwijziging en regelmatig daarna; alleen jaarlijks controleren kan te weinig zijn.

Maak DNS-beheer overzichtelijker. Bekijk TrekMails gratis aanbod en controleer actuele platformprijzen, voorwaarden en ondersteuning voor SPF, DKIM en DMARC.