Wat is de syntaxis van een SPF-record en wat betekent die voor applicatiemail?

Een SPF-record is een geordende beleidsexpressie

RFC 7208 definieert een SPF-record als een DNS-TXT-string waarvan de eerste term v=spf1 is. De overige door spaties gescheiden termen zijn mechanismen, die kunnen matchen, en modifiers, die de verwerking veranderen. De evaluatie loopt van links naar rechts en stopt bij het eerste mechanisme dat matcht; de volgorde drukt dus het beleid uit. Een typisch record kan twee vaste adresbereiken autoriseren, één providerbeleid opnemen via include en eindigen met -all. Plak dat patroon niet ongewijzigd: het juiste record hangt af van de exacte SMTP MAIL FROM- of HELO-identiteiten en de echte verzendbronnen. Inventariseer eerst applicatieproviders, mailservers, supporttools, identiteitsplatforms, marketingsystemen, doorstuurpaden en afzenders voor noodherstel. Publiceer het beleid op het domein dat wordt geëvalueerd, niet automatisch op het zichtbare From-domein. Eén syntactisch geldig record kan nog steeds de verkeerde bronnen autoriseren, een productiestroom missen of de DNS-evaluatielimieten overschrijden.

Qualifiers koppelen een match van een mechanisme aan een SPF-resultaat

Een mechanisme kan beginnen met een qualifier: + voor pass, - voor fail, ~ voor softfail of ? voor neutral. Als er geen qualifier staat, geldt +. De qualifier is alleen van toepassing wanneer dat mechanisme matcht. Hij verandert niet of latere termen worden geëvalueerd wanneer het mechanisme niet matcht. Teams richten zich vaak op de laatste all-term, maar elk eerder include-, adres-, a-, mx- of exists-mechanisme heeft ook een qualifier en kan de evaluatie beëindigen. Gebruik expliciete review in plaats van aan te nemen dat ~all testmodus betekent of dat -all bewijst dat elke bron bekend is. Een fail-resultaat is bewijs voor de ontvanger over de geëvalueerde SMTP-identiteit en het IP-adres, geen universeel commando om mail te verwijderen. Ontvangers passen hun eigen beleid toe. Neutral en softfail zijn geen geslaagde autorisatie. Leg het bedoelde resultaat vast voor geautoriseerde, niet-geautoriseerde en tijdelijk onopgeloste bronnen en verifieer het met gecontroleerde fixtures voor IP en identiteit.

Adresmechanismen zijn direct, maar vereisen eigenaarschap

De mechanismen ip4 en ip6 autoriseren overeenkomende netwerkbereiken, uitgedrukt in de protocolspecifieke syntaxis met een optionele prefixlengte. Ze vermijden extra adreslookups tijdens de evaluatie, maar kunnen verouderen wanneer uitgaande netwerken veranderen. Gebruik publieke verzendadressen, nooit private runtime-adressen, en houd bereiken zo smal als failover operationeel toelaat. Elk bereik moet een eigenaar, bronsysteem, omgeving, wijzigingsprocedure en reviewdatum hebben. Het a-mechanisme zoekt een A- of AAAA-naam op en gebruikt standaard het huidige SPF-domein, tenzij een andere domain-spec is opgegeven. Het mx-mechanisme zoekt MX-hosts en hun adressen op. Die mechanismen voegen DNS-werk toe en kunnen infrastructuur autoriseren die buiten de release van de applicatie verandert. Gebruik a of mx niet als shortcut, tenzij alle opgezochte adressen bewust mogen verzenden met die exacte SMTP-identiteit. Monitor wijzigingen en test zowel IPv4- als IPv6-paden.

Include evalueert een ander beleid, geen tekstfragment

Het include-mechanisme evalueert het SPF-beleid van het domein waarnaar wordt verwezen en matcht wanneer die geneste evaluatie pass oplevert. Het plakt de termen niet mechanisch in de huidige string, en andere geneste uitkomsten hebben gedefinieerde effecten. Gebruik include alleen wanneer de organisatie waarnaar wordt verwezen dat domein expliciet documenteert voor jouw verzendrelatie. Het websitedomein, MX-domein of zichtbare From-domein van een provider is niet automatisch zijn SPF-include. Includes creëren operationele afhankelijkheden: een wijziging in het record van een provider kan de autorisatie veranderen, geneste DNS-lookups toevoegen of tijdelijke en permanente fouten opleveren. Leg de leverancier, dienst, het exacte include-domein, de contractbron, eigenaar en het verwijderingsplan vast. Test het resulterende beleid vanaf het werkelijke verzend-IP van de provider en je envelope-domein. Maak includes van providers nooit plat tot gekopieerde IP-lijsten, tenzij je ook de verantwoordelijkheid aanvaardt om elke adreswijziging van de provider bij te houden en de oorspronkelijke semantiek te behouden.

All, redirect en explanation hebben verschillende rollen

Het all-mechanisme matcht altijd en staat normaal gesproken als laatste; termen erna kunnen de evaluatie niet beïnvloeden. De qualifier bepaalt het resultaat voor bronnen die niet eerder zijn gematcht. De redirect-modifier vertelt SPF het beleid van een ander domein te gebruiken wanneer geen enkel mechanisme in het huidige record heeft gematcht. Redirect is niet hetzelfde als include: include is één geordend mechanisme, terwijl redirect onder de gedefinieerde voorwaarden de uiteindelijke beleidsbeslissing vervangt. Een record mag niet meerdere redirect-modifiers bevatten. De exp-modifier kan verwijzen naar een uitleg bij een fail-resultaat, maar autoriseert geen mail en brengt extra operationele en privacyoverwegingen met zich mee. Houd uitleg algemeen en vermijd gegevens van afzenders of ontvangers. Kies redirect wanneer domeinen bewust een volledig beleid delen en gecoördineerd eigenaarschap hebben. Kies include wanneer je de geautoriseerde bronnen van één provider toevoegt binnen een breder lokaal beleid. Test niet-gematchte paden, niet alleen verwachte passes.

Vermijd ptr en behandel exists en macro's als geavanceerd

RFC 7208 stelt dat het ptr-mechanisme niet gebruikt moet worden, omdat het traag, onbetrouwbaar en belastend is. Voeg geen ptr toe om een onbekend IP-adres te laten slagen. Het exists-mechanisme kan met een domain-spec een DNS-bestaanstest uitvoeren, en SPF-macro's kunnen onderdelen van identiteit en verbinding uitbreiden binnen ondersteunde velden. Deze hulpmiddelen kunnen gedelegeerde autorisatie of autorisatie per klant uitdrukken, maar verhogen de complexiteit, het DNS-werk, de privacyblootstelling en het aantal foutscenario's. De macrosyntaxis is geen willekeurige stringtemplating; alleen gedefinieerde letters, transformers, scheidingstekens en contexten zijn geldig. Zet nooit volledige ontvangeradressen, secrets of onbegrensde invoer van tenants in DNS-queries. Als een eenvoudige set eigen IP-bereiken en gedocumenteerde provider-includes het beleid kan uitdrukken, geef daar dan de voorkeur aan. Bouw voor geavanceerd beleid vóór productie deterministische fixtures voor meerdere domeinen, afzenders, IP-families, lege reverse paths, escaping van macro's, NXDOMAIN, timeouts en onverwachte DNS-antwoorden.

Respecteer de SPF-lookuplimiet van tien

RFC 7208 beperkt SPF-implementaties tot tien termen die tijdens één controle DNS-queries veroorzaken, inclusief de relevante verwerking van include, a, mx, ptr, exists en redirect. Geneste includes tellen mee. De specificatie beveelt ook aan void lookups, waarbij DNS een leeg antwoord of een name error teruggeeft, te beperken tot twee. Overschrijding van de verwerkingslimieten kan een permanente fout opleveren in plaats van een pass. Tel de uitgebreide evaluatiegraaf, niet alleen de termen die zichtbaar zijn in de TXT-string op het hoogste niveau. Eén provider-include kan meerdere geneste afhankelijkheden meebrengen, en een mx-mechanisme kan adreslookups voor meerdere hosts veroorzaken. Gebruik een evaluator die de standaarden kent, met vastgelegde DNS-fixtures, maar inspecteer ook zelf de afhankelijkheidsboom. Verwijder ongebruikte providers en overbodige mechanismen. Vermijd onveilig platmaken waarbij updates van providers stilzwijgend verloren gaan. Monitor beleidswijzigingen en laat ruimte in het lookupbudget voor de ontwikkeling van providers, in plaats van precies op het maximum uit te rollen.

Publiceer precies één SPF-beleid per domein

RFC 7208 gebruikt DNS-TXT-records voor SPF en vereist dat het record wordt geselecteerd dat begint met v=spf1. Meerdere SPF-records voor exact dezelfde eigenaarsnaam leiden tot een permanente fout in plaats van samengevoegde autorisatie. Pas het bestaande beleid aan onder gecoördineerd eigenaarschap; voeg geen tweede TXT-record toe omdat een andere applicatie toegang nodig heeft. Andere, niet-gerelateerde TXT-records op de naam kunnen naast elkaar bestaan, maar er mag slechts één geselecteerd SPF-beleid zijn. Controleer hoe het DNS-beheerplatform met aanhalingstekens en het splitsen van strings omgaat, vraag de gezaghebbende servers op en daarna onafhankelijke recursieve resolvers. Bewaar de vorige waarde en TTL om te kunnen terugdraaien. DNS-propagatie is niet onmiddellijk, en negatieve caches kunnen blijven bestaan. Een groen vinkje in een dashboard bewijst alleen de waargenomen query en het gedrag van de parser. Verifieer het exacte envelope-domein in productie aan de hand van ruwe ontvangen headers en providerlogs, inclusief subdomeinen en bounceadressen die mogelijk een eigen beleid publiceren.

Verbind SPF-syntaxis met DMARC zonder ze te verwarren

SPF evalueert normaal gesproken het MAIL FROM-domein of de HELO-identiteit volgens de protocolregels. DMARC gebruikt het zichtbare RFC 5322 From-domein en accepteert SPF alleen als pad wanneer het met SPF geauthenticeerde domein uitgelijnd is met dat zichtbare domein. Een return path van een provider kan dus voor SPF slagen en toch niet uitgelijnd zijn voor DMARC. Omgekeerd kan een uitgelijnde DKIM-pass aan DMARC voldoen wanneer SPF faalt of niet uitgelijnd is. Leg het SPF-resultaat, het geëvalueerde domein, het verbindende IP-adres, het zichtbare From, de DKIM-resultaten, de alignment en de DMARC-uitkomst afzonderlijk vast. Doorsturen verandert vaak het verbindende IP-adres en kan SPF breken, zelfs wanneer de oorspronkelijke afzender geautoriseerd was. Verruim SPF niet om willekeurige doorstuurders toe te voegen. Gebruik DKIM en, waar passend, mechanismen voor geauthenticeerde ketens en bewijs van ontvangers. Een SPF-pass bewijst geen integriteit van het bericht, veiligheid van de inhoud, toestemming van de ontvanger, acceptatie door de server of inboxplaatsing.

Valideer wijzigingen met een deterministische workflow

Exporteer vóór het bewerken van DNS het huidige record en som elk mechanisme of elke modifier op met eigenaar en doel. Parse de kandidaat volgens de grammatica van RFC 7208, breid DNS-afhankelijkheden uit vanuit gecontroleerde snapshots, tel de termen die lookups veroorzaken en test geautoriseerde en niet-geautoriseerde IPv4- en IPv6-fixtures. Controleer het gedrag van geneste includes bij pass, fail, neutral, softfail, temporary error en permanent error. Test de afhandeling van een leeg reverse path via HELO, subdomeinen, return paths van providers en een bron die door moet vallen naar all. Publiceer via de normale wijzigingsprocedures, vraag gezaghebbende en recursieve DNS op en verstuur daarna gecontroleerde berichten via elke echte stroom. Bewaar ruwe Authentication-Results van vertrouwde ontvangers en vergelijk ze met de verwachte identiteiten. Draai terug bij ontbrekende productiebronnen, selectie van meerdere records, fouten door de lookuplimiet, wijdverbreide temperror of onbedoelde autorisatie. Test nooit door ongevraagde mail te versturen.

Stel SPF in met SendHQ

SendHQ richt een SPF-TXT-beleid in als onderdeel van de configuratie van afzenderidentiteit. De configuratie stopt bij conflicterend SPF-beleid en rapporteert een aanbevolen samengevoegde SPF-waarde in plaats van een niet-gerelateerd beleid stilzwijgend te overschrijven. Houd exact één selecteerbaar SPF-beleid aan; raadpleeg de documentatie Domains and DNS voor configuratie- en reparatiedetails.

Veelgestelde vragen

Bronnen

• RFC 7208: Sender Policy Framework — RFC Editor
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC Editor
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor