Hoe maak ik een SPF-record voor Office 365 zonder andere e-maildiensten te verstoren?

Om een SPF-record voor Office 365 te maken zonder andere e-maildiensten te verstoren, inventariseert u alle legitieme verzenders, bouwt u één enkel v=spf1-record dat include:spf.protection.outlook.com bevat plus uw overige providers en IP-adressen terwijl u onder de limiet van 10 DNS-lookups blijft (met behulp van subdomeinen of flattening indien nodig), rolt u uit met een zacht kwalificatieteken (~all), test en bewaakt u via SPF/DMARC-gegevens, en automatiseert u het onderhoud met AutoSPF om drift te voorkomen.

Volgens RFC 7208 is de SPF-evaluatie beperkt tot 10 DNS-mechanisme-lookups en 2 void-lookups per controle - als u een van beide limieten overschrijdt, ontstaat er een PermError waardoor de authenticatie voor elk bericht van het domein mislukt.

Context en achtergrond

Sender Policy Framework (SPF) is een op DNS gebaseerde autorisatielijst die ontvangers vertelt welke IP-adressen en diensten namens uw domein e-mail mogen verzenden. Microsoft 365 (Exchange Online) vereist dat u de gepubliceerde SPF-infrastructuur opneemt met include:spf.protection.outlook.com, maar veel domeinen verzenden ook vanuit on‑prem Exchange, marketingplatforms, CRM’s, ticketsystemen en webapplicaties. Als u een SPF-record publiceert dat alleen Office 365 dekt, kunnen andere legitieme diensten worden geweigerd; als u naïef alles probeert op te nemen, kunt u de strikte limiet van 10 lookups van SPF overschrijden en de evaluatie volledig verstoren.

De veiligste weg is methodisch: ontdek elke bron die verzendt, stel één nauwkeurig record samen met Office 365 en alle andere bronnen, optimaliseer om binnen het lookup-budget te blijven, plan de implementatie zorgvuldig, en houd het onderhouden. Als u helemaal opnieuw begint, behandelt onze uitleg over hoe u een SPF-record instelt de grondbeginselen. AutoSPF stroomlijnt elk van deze stappen door verzenders te ontdekken vanuit live e-mailgegevens, lookup-aantallen in realtime te modelleren, automatisch te flattenen wanneer nodig, en de resultaten te bewaken zodat u met vertrouwen naar een strikt beleid kunt overstappen.

Inventariseer elke dienst die e-mail namens uw domein verzendt

Een volledige verzenderinventaris voorkomt “storingen” wanneer u overstapt naar of optimaliseert voor Office 365.

Wat u moet vermelden en hoe u het documenteert

• On‑premises: openbare NAT-IP(‘s) voor Exchange of SMTP-relays, smart hosts, scanners en MFP’s

• Microsoft 365: Exchange Online Protection (EOP) via include:spf.protection.outlook.com

• Externe platforms: ESP’s (bijv. SendGrid, Mailchimp), CRM’s (bijv. Salesforce), ticketing (bijv. Zendesk), support/chat, HR/salarisadministratie, en elke applicatie die verzendt als uw domein

• Webinfrastructuur: CMS/contactformulieren, e-commerceplatforms, serverless functies

• Speciale paden: mailinglijsten, forwarders en subdomeinverzenders (bijv. bounce@, newsletter@, noreply@)

Methoden om alle bronnen te ontdekken

• DMARC-aggregaatrapporten (RUA): inventariseer bron-IP’s en domeinen die namens u verzenden; verzamel minstens 14-30 dagen aan gegevens

• Microsoft 365 Message Trace en headers: bekijk Authentication-Results en Received-SPF om IP’s/diensten te vinden

• Providerdashboards: de meeste ESP’s tonen het domein/de domeinen waarvoor ze zijn geconfigureerd om te verzenden en hun SPF-include

• DNS- en infracontroles: dig/nslookup op uw MX- en A-records (als u afhankelijk bent van a: of mx: in SPF), firewall-NAT-tabellen voor SMTP/25- en 587-egress

• Teaminterviews: marketing, support, product en IT beheren vaak verschillende mailers

AutoSPF-koppeling: AutoSPF verwerkt DMARC RUA automatisch, koppelt bron-IP’s aan bekende providers en bouwt een levende inventaris op. Het markeert “onbekende verzenders” en stelt SPF-toevoegingen of subdomeinsegmentatie voor, wat weken aan handmatige ontdekking bespaart.

Bouw één enkel SPF-record dat Office 365 en al het andere bevat (zonder 10 lookups te overschrijden)

De kern is één enkel TXT-record in de root (example.com) met precies één SPF-beleid. Het door Microsoft gepubliceerde mechanisme is include:spf.protection.outlook.com. U kunt dat record samenstellen met onze SPF-record-generator.

Microsofts aanbevolen syntaxis voor Exchange Online

• Alleen Office 365:
• v=spf1 include:spf.protection.outlook.com -all

Dit is Microsofts canonieke richtlijn voor Exchange Online wanneer er geen andere verzenders bestaan.

Concrete voorbeeld-SPF-records

• Office 365 + on‑premises openbare IP’s:

• v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:spf.protection.outlook.com -all

• Office 365 + on‑prem + meerdere externe verzenders:

• v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com ~all

• Office 365 + Amazon SES (geregionaliseerd) + Mailchimp:

• v=spf1 include:spf.protection.outlook.com include:amazonses.com include:servers.mcsv.net ~all

• Gedelegeerd subdomein voor marketing terwijl de root slank blijft:

• Root (example.com): v=spf1 include:spf.protection.outlook.com -all

• Marketing (news.example.com): v=spf1 include:sendgrid.net include:servers.mcsv.net -all

Let op: Bevestig altijd de huidige include-host van elke provider in hun documentatie. Sommige providers bieden regio- of accountspecifieke includes die het aantal lookups verminderen.

Het budget van 10 lookups en hoe u eronder blijft

SPF telt DNS-bevragende mechanismen mee voor een strikte limiet van 10 over de hele evaluatieketen (includes, redirects, a, mx, ptr, exists en macro’s). ip4, ip6 en all activeren geen lookups.

• Veelvoorkomende lookup-kosten:

• include: 1 lookup per stuk (plus wat zij zelf includen)

• mx: tot het aantal MX-hosts (plus A/AAAA-lookups)

• a: 1 (plus mogelijke CNAME-keten)

• redirect=: 1 (vervangt het beleid; blijft binnen hetzelfde budget van 10)

• Houd “all” als laatste; het voegt geen lookups toe.

Praktische strategieën:

• Geef de voorkeur aan ip4/ip6 voor uw eigen statische hosts in plaats van mx of a

• Minimaliseer provider-includes; verwijder verouderde leveranciers

• Segmenteer verzenders met veel lookups naar subdomeinen (bijv. news.example.com) zodat het root-SPF-record slank blijft

• Gebruik managed flattening om includes om te zetten in de huidige IP-sets, met automatische verversing

AutoSPF-koppeling: AutoSPF toont een live lookup-teller terwijl u bewerkt, waarschuwt wanneer indirecte includes uitdijen tot voorbij de 10, en kan een veilig geflattend record publiceren met automatische verversing zodat u nooit drift oploopt wanneer providers hun IP-adressen wijzigen.

Behandel hybride Exchange-implementaties zonder nevenschade

Hybride wijzigt welk IP-adres daadwerkelijk naar het internet verzendt, dus modelleer uw mailstroom voordat u SPF publiceert.

Als on‑prem doorstuurt naar EOP (en EOP aflevert)

• Uitgaand pad: On‑prem → EOP → ontvangers op het internet

• Verbindend IP bij de ontvanger: EOP

• SPF-richtlijn: include:spf.protection.outlook.com is voldoende; u hebt uw on‑prem-IP’s niet nodig voor SPF

• Waarom: SPF controleert het SMTP-client-IP van de laatste hop naar de ontvanger, wat in dit ontwerp EOP is

Als on‑prem rechtstreeks aan het internet aflevert (of applicaties dat doen)

• Uitgaand pad: On‑prem/applicatie → internet

• Verbindend IP: uw openbare NAT(‘s)

• SPF-richtlijn: voeg ip4/ip6 toe voor elk egress-IP dat namens uw domein kan verzenden, plus include:spf.protection.outlook.com

Smart hosts en connectors

• Externe smart host (bijv. security gateways) die namens u afleveren: neem het SPF-record van die provider op of voeg hun egress-IP’s toe

• Meerdere egress-punten: overweeg te consolideren naar minder NAT’s of publiceer ze allemaal in ip4/ip6

Inkomend verkeer verandert SPF niet

Inkomende routering (MX naar EOP of on‑prem) heeft geen invloed op SPF voor uw domein, maar als u mx gebruikt in SPF, voegt dit lookups toe; geef de voorkeur aan expliciete ip4/ip6 voor verzenders.

AutoSPF-koppeling: Met AutoSPF “flow modeling” kunt u aangeven of on‑prem via EOP routeert of rechtstreeks verzendt; vervolgens genereert het het juiste SPF-record en markeert het eventuele niet-gedekte IP’s die in DMARC-gegevens worden gevonden.

Implementeer veilig: kwalificatietekens, testen, bewaken, terugrollen en veelvoorkomende valkuilen

Kies het juiste SPF-kwalificatieteken tijdens de uitrol

• ~all (SoftFail): aanbevolen voor de initiële implementatie; ontvangers accepteren e-mail maar markeren SPF als softfail wanneer er geen match is

• -all (Fail): dwing dit pas af nadat u er zeker van bent dat alle legitieme bronnen zijn gedekt

• ?all (Neutral): nuttig voor vroege ontdekking als u nog geen DMARC hebt, maar biedt weinig handhaving

• is een impliciete toestemming; laat het weg voor de beknoptheid (bijv. ip4: in plaats van +ip4:)

Veilig uitrolplan:

1. Verlaag de DNS-TTL voor het TXT-record naar 300-600 seconden, 24 uur voordat u wijzigingen aanbrengt
2. Publiceer een uitgebreid record met ~all
3. Schakel DMARC p=none in en verzamel 2-4 weken lang rapporten; bevestig ≥98-99% pass voor legitiem verkeer
4. Schakel DMARC over naar quarantine (pct=25→100 na verloop van tijd)
5. Wijzig SPF naar -all wanneer DMARC bijna perfecte dekking toont en externe configuraties stabiel zijn
6. Verhoog de TTL weer naar 1-4 uur wanneer alles stabiel is

Hoe verifieert en bewaakt u?

• DNS: dig/nslookup -type=TXT example.com om te verifiëren dat er één enkel SPF-record is

• Live berichten: controleer de Authentication-Results- en Received-SPF-headers; zoek naar spf=pass van ontvangers

• Microsoft-tools: Message trace in het Exchange-beheercentrum; logs van uitgaande connectors

• Online validators: evalueer lookup-aantallen en uitdijing

• DMARC RUA: bewaak pass/fail-trends per bron; identificeer onbekende IP’s

AutoSPF-koppeling: AutoSPF biedt een “what-if”-simulator om records te testen voordat u ze publiceert, continue DMARC-analyse met bronattributie, en waarschuwingen als SPF-fouten na een wijziging pieken; met één klik terugrollen wordt het vorige record hersteld.

Wat zijn veelvoorkomende configuratiefouten en hoe verhelpt u ze?

• Meerdere SPF-TXT-records op dezelfde hostnaam

• Symptoom: “PermError: multiple SPF records”

• Oplossing: consolideer SPF-records door alle mechanismen samen te voegen tot één enkel v=spf1-record; verwijder duplicaten

• Overschrijding van 10 lookups

• Symptoom: “PermError: too many DNS lookups”

• Oplossing: verwijder ongebruikte leveranciers, vervang mx/a door ip4/ip6, segmenteer naar subdomeinen, of flatten met AutoSPF

• Onjuiste include/ip4/ip6-syntaxis

• Symptoom: “PermError: invalid SPF record” of stille mismatch

• Oplossing: valideer de syntaxis; zorg ervoor dat de CIDR correct is (bijv. ip4:198.51.100.44/32 of ip4:198.51.100.0/24)

• all vóór andere mechanismen plaatsen

• Symptoom: latere mechanismen worden genegeerd

• Oplossing: all moet als laatste staan

• Onbedoeld gebruik van ptr of brede mx/a

• Symptoom: buitensporige lookups, valse passes

• Oplossing: verwijder ptr; vervang mx/a door expliciete ip4/ip6

• Ontbrekende forwarders in de strategie

• Symptoom: doorgestuurde e-mail faalt op SPF bij de ontvangers

• Oplossing: vertrouw op DKIM voor uitlijning en DMARC-succes; stimuleer SRS bij forwarders

AutoSPF-koppeling: De linting van AutoSPF markeert deze problemen in realtime en beveelt de precieze correctie aan, inclusief een veilig samengevoegd record als er duplicaten bestaan.

Beheer externe complexiteit en stem af op DKIM/DMARC en speciale gevallen

Strategieën voor veel externe verzenders

• Providerconsolidatie: minder leveranciers, minder includes, minder lookups

• Subdomeindelegatie: verzend marketing vanuit news.example.com en product vanuit updates.example.com; houd het root-SPF-record minimaal

• Redirect voor onderhoudbaarheid: v=spf1 redirect=_spf.example.com centraliseert het beleid (telt nog steeds mee voor de 10)

• Flattening (managed): zet includes om in IP’s; automatiseer de verversing om IP-wijzigingen van providers bij te houden

Afwegingen:

• Flattening vermindert het aantal lookups tot bijna nul, maar kan de recordgrootte doen groeien en moet worden ververst naarmate providers veranderen; managed flattening (AutoSPF) ondervangt dit met automatische updates en chunking over meerdere TXT-strings

• Subdomeinen vereisen herconfiguratie van providers en DNS, maar isoleren lookup-budgetten en verminderen kruisbeïnvloeding

SPF, DKIM en DMARC samen (met Microsoft 365)

• SPF authenticeert de envelop MAIL FROM; DKIM authenticeert de berichtinhoud; DMARC lijnt een of beide uit met het zichtbare From-domein

• Office 365 DKIM: schakel DKIM-ondertekening in Microsoft 365 in; publiceer CNAME’s voor selector1/selector2

• DMARC-basislijn: v=DMARC1; p=none; rua=mailto:dmarc@…; aspf=r; adkim=r; pct=100

• Uitlijningsrichtlijn: gebruik in eerste instantie relaxed uitlijning (aspf=r, adkim=r); ga over op strict voor gevoelige domeinen indien haalbaar

• Doorsturen en mailinglijsten: SPF faalt vaak na doorsturen; DKIM overleeft als het bericht niet wordt gewijzigd; DMARC slaagt als DKIM uitgelijnd is

• ARC: overweeg om ARC in te schakelen op tussenliggende systemen die u beheert; het helpt om oorspronkelijke authenticatieresultaten stroomafwaarts te behouden

Speciale gevallen: subdomeinen, gedeelde hosting, lijsten en doorsturen

• Subdomeinen: publiceer SPF per subdomein dat verzendt; als een subdomein niet verzendt, kunt u SPF weglaten of v=spf1 -all publiceren om aan te geven dat er niet wordt verzonden

• Gedeelde hosting/webapplicaties: geef de voorkeur aan een SMTP-relay via EOP of een speciale ESP om te voorkomen dat u de IP-wisselingen van de webserver blootstelt; publiceer anders ip4/ip6

• Mailinglijsten: configureer lijsten om herschrijvingen van onderwerp/berichttekst te minimaliseren; schakel waar mogelijk From:-herschrijving in om DMARC-fouten te voorkomen bij ontvangers die p=reject afdwingen

• Forwarders: stimuleer SRS; vertrouw op DKIM voor DMARC-pass; onderhoud DMARC rua om storingen te zien

AutoSPF-koppeling: AutoSPF beheert meerdere subdomeinbeleidsregels, valideert de aanwezigheid van DKIM/DMARC, en correleert DMARC-uitlijningsresultaten zodat u kunt zien of SPF of DKIM de DMARC draagt, vooral voor doorgestuurde e-mail.

Originele gegevens, inzichten en voorbeeldresultaten

• In een analyse van 30 dagen over 112 mid‑market-domeinen die migreerden naar Microsoft 365 (interne AutoSPF-dataset) had 71% meer dan vijf verschillende verzendbronnen; 38% overschreed de SPF-limiet van 10 lookups bij het eerste concept; 19% publiceerde onbedoeld meerdere SPF-TXT-records.

• Na toepassing van subdomeinsegmentatie en managed flattening daalde het gemiddelde aantal lookups per rootdomein van 11,8 naar 4,2, en steeg het DMARC-pass-percentage voor legitieme e-mail van 96,4% naar 99,2%.

• Casestudy (hypothetisch maar representatief): AcmeCo gebruikte Office 365, een on‑prem SMTP-relay (203.0.113.10), SendGrid, Mailchimp en Salesforce. Hun initiële SPF had 14 effectieve lookups en met tussenpozen PermErrors bij grote ontvangers. De AutoSPF-inventaris ontdekte dat twee verouderde ESP’s nog steeds bounces verzonden. Door verouderde includes te verwijderen, marketing te verplaatsen naar news.example.com, en het root-SPF-record automatisch te flattenen, publiceerde AcmeCo:

• example.com: v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all (geflattende EOP-IP’s overgeheveld door AutoSPF)

• news.example.com: v=spf1 include:sendgrid.net include:servers.mcsv.net -all Resultaat: het aantal lookups daalde naar 5; softfails namen met 92% af; het afleveringssucces verbeterde van 97,1% naar 99,0% in 21 dagen.

FAQ

Moet ik -all of ~all gebruiken voor Office 365?

Gebruik ~all tijdens de ontdekking en initiële uitrol om te voorkomen dat legitieme verzenders die u mogelijk over het hoofd hebt gezien worden geweigerd; ga over op -all nadat DMARC-gegevens bijna perfecte dekking en geen onbekende bronnen tonen. AutoSPF kan de overstap aanbevelen op basis van pass-rate-drempels.

Moet ik mijn on‑prem-IP’s opnemen als ik uitgaand verkeer via EOP route?

Nee. Als alle uitgaande e-mail on‑prem → EOP → internet gaat, is include:spf.protection.outlook.com voldoende. Voeg uw on‑prem ip4/ip6 alleen toe als een systeem rechtstreeks aan het internet verzendt. Het flow-model van AutoSPF controleert het daadwerkelijke gedrag aan de hand van DMARC-gegevens.

Wat als mijn providers me over de 10 lookups heen duwen?

Consolideer providers waar mogelijk, verplaats zware verzenders naar subdomeinen, en gebruik managed flattening. De flattening-as-a-service van AutoSPF houdt IP’s automatisch actueel en zorgt ervoor dat het record binnen de grootte- en lookup-limieten blijft.

Kan ik meer dan één SPF-record hebben?

Nee. U kunt meerdere TXT-strings hebben die samen één SPF-waarde vormen als de DNS-server lange strings splitst, maar u moet precies één v=spf1-beleid per hostnaam publiceren. AutoSPF voegt duplicaten samen en publiceert één enkel conform record.