Hoe check je een SPF-record voor applicatiemail?

Begin bij de identiteit die SPF daadwerkelijk controleert

Een SPF-check heeft drie invoerwaarden nodig: het IP-adres van de SMTP-client, het domein waarvan het autorisatiebeleid wordt geëvalueerd en de afzenderidentiteit. Bij gewone applicatiemail komt dat domein uit het SMTP MAIL FROM-adres, ook wel envelope sender of return path genoemd. Dat kan afwijken van het adres dat mensen in de From-header van het bericht zien. Als MAIL FROM leeg is, zoals meestal bij een delivery status notification, gebruikt SPF de HELO-identiteit voor de MAIL FROM-check. Leg het echte verbindings-IP en de envelope-identiteit vast uit een ontvangen testbericht of de configuratie van de verzendprovider voordat je DNS opvraagt. example.test controleren omdat het in From staat, levert geen uitsluitsel op als de applicatie in werkelijkheid verstuurt met MAIL FROM op bounce.provider.test of bounces.example.test.

Vraag TXT op bij precies het MAIL FROM-domein

Vraag DNS TXT op bij precies het domein dat je in de eerste stap hebt gekozen. RFC 7208 vereist dat SPF-beleid van versie 1 wordt gepubliceerd als TXT-records op de eigenaarnaam waarvoor het geldt. Negeer ongerelateerde TXT-waarden en selecteer records waarvan de versiesectie exact v=spf1 is. Is er geen geselecteerd record, dan is het SPF-resultaat none. Meer dan één geselecteerd SPF-record geeft permerror; aparte records publiceren voor verschillende leveranciers is geen geldige manier om ze te combineren. DNS-tooling kan één TXT-resource record opsplitsen in strings tussen aanhalingstekens, maar die strings worden zonder extra spaties aan elkaar geplakt voordat SPF wordt geparset. Leg het volledige antwoord, de resolver, het tijdstip van de query en de TTL vast, zodat je de check na een wijziging kunt herhalen.

Valideer de syntaxis en evalueer de termen van links naar rechts

Een SPF-record is een geordend beleid, geen ongeordende lijst met providers. Na v=spf1 worden mechanismen van links naar rechts geëvalueerd tot er één matcht. Een qualifier aan het begin bepaalt het resultaat: + betekent pass en is de standaard, - betekent fail, ~ betekent softfail en ? betekent neutral. De mechanismen ip4 en ip6 vergelijken het clientadres met een adres of netwerk. De mechanismen a en mx lossen DNS op, terwijl include het SPF-beleid van een ander domein evalueert en alleen matcht volgens de include-regels. exists voert een test op basis van DNS uit. all matcht altijd en sluit het record meestal af. Syntaxfouten waar dan ook leiden tot permerror nog vóór de normale evaluatie. Een bruikbare checker rapporteert welk mechanisme matchte, met welke qualifier, en elk uitgevouwen domein, in plaats van alleen een gekleurd label te tonen.

Volg include en redirect zonder ze als aliassen te behandelen

Volg elke include en redirect binnen dezelfde evaluatiecontext. Include is een mechanisme: het vraagt of het ingesloten beleid pass teruggeeft voor de huidige client en afzender, en gaat verder in het oorspronkelijke record als dat niet matcht. Redirect is een modifier die pas meetelt nadat geen van de mechanismen van het huidige record heeft gematcht; het draagt de evaluatie over aan een ander beleid, met behoud van het client-IP en de afzender. Een redirect wordt genegeerd als all ergens in het record voorkomt. Die verschillen doen ertoe bij migraties. Als je include:vendor.test vervangt door redirect=vendor.test, kun je het volledige fallbackbeleid van de domeineigenaar vervangen in plaats van alleen een leverancier toe te voegen. Detecteer cycli, ontbrekende doelen, ongeldige doelen en geneste permanente of tijdelijke fouten, en bewaar de afhankelijkheidsketen in het resultaat, zodat een beleidswijziging aan de kant van de provider zichtbaar is.

Tel het volledige budget aan DNS-query's

Tel de termen die DNS-query's veroorzaken over de volledige recursieve evaluatie, niet alleen in het record op het hoogste niveau. RFC 7208 beperkt include-, a-, mx-, ptr-, exists- en redirect-termen tot tien per SPF-evaluatie; wordt die limiet overschreden, dan is permerror verplicht. De mechanismen all, ip4 en ip6 tellen niet mee voor dat budget. De verwerking van MX en PTR kent aanvullende limieten voor adresquery's. De RFC raadt ook aan void lookups, dus succesvolle lege antwoorden of name errors, te beperken tot twee en permerror te geven als die limiet wordt overschreden. Het ptr-mechanisme wordt afgeraden omdat het traag en onbetrouwbaar is. Een record kan er kort uitzien terwijl includes van providers uitvouwen tot zoveel geneste termen dat het misgaat. Rapporteer daarom het totaal, elke term die meetelt, void lookups en de exacte tak die voor het geteste IP is gevolgd.

Interpreteer het SPF-resultaat zonder het te overschatten

Gebruik de standaardterminologie voor resultaten. Pass betekent dat de geteste client de gecontroleerde SMTP-identiteit mag gebruiken. Fail betekent dat er een matchende negatieve autorisatie is gevonden. Softfail is een zwakke negatieve uitspraak, terwijl neutral aangeeft dat het domein niets over die client beweert. None betekent dat er geen SPF-record is geselecteerd. Temperror wijst op een tijdelijk evaluatieprobleem, meestal DNS; permerror wijst op een beleid dat niet correct te evalueren is. Als geen mechanisme matcht en er geen redirect van toepassing is, is het resultaat neutral, gelijk aan een impliciete ?all. Rapporteer het resultaat samen met de identiteit, het client-IP, de gematchte term, de DNS-trace en het tijdstip. Vertaal pass niet naar veilig bericht, gewenste mail, acceptatie door de provider, bezorging in de mailbox of inboxplaatsing, want SPF beslist niet over die uitkomsten.

Controleer een echt bericht, niet alleen het gepubliceerde record

Een statische recordcheck beantwoordt of een beleid te vinden en te parsen is. Het bewijst niet dat de applicatie het verwachte MAIL FROM-domein of uitgaande IP heeft gebruikt. Stuur een gecontroleerd bericht via elk echt productiepad naar een ontvangeraccount dat je zelf beheert en inspecteer daarna de ontvangen headers. Vergelijk het verbindende IP, de envelope sender en de Authentication-Results-regel van de ontvanger met de DNS-evaluatie. Herhaal dit voor elke provider, regio, dedicated of gedeelde pool, elk fallbackpad en elke berichtklasse die het return path kan veranderen. Bewaar headers in afgeschermde opslag, want adressen en routeringsdetails kunnen gevoelig zijn. Als het dashboard van een provider en het ontvangen bericht elkaar tegenspreken, is het bericht sterker bewijs voor het pad dat daadwerkelijk is gebruikt, al mag je het resultaat van één ontvanger nog steeds niet generaliseren naar universeel bezorggedrag.

Beoordeel DMARC-alignment als aparte stap

SPF kan slagen voor een return-path-domein van de provider terwijl DMARC dat resultaat toch niet kan gebruiken. De huidige DMARC-regels vergelijken het RFC5321.MailFrom-domein waarvoor SPF-authenticatie is geslaagd met het auteursdomein in het zichtbare RFC5322.From-veld. Strict alignment vereist hetzelfde DNS-domein. Relaxed alignment staat domeinen toe die volgens de discovery-regels van DMARC tot hetzelfde organisatiedomein herleiden. Zo kunnen bounces.example.test en example.test in relaxed-modus aligned zijn, terwijl bounce.provider.test en example.test dat niet zijn. Een DMARC-resultaat kan ook steunen op een gealigneerde, geverifieerde DKIM-handtekening, dus een niet-gealigneerd SPF-resultaat betekent op zichzelf niet dat DMARC faalt. Rapporteer authenticatie en alignment los van elkaar en gebruik de actuele procedure voor domeindiscovery in plaats van een hardgecodeerde vergelijking van de laatste twee labels.

Test de providerspecifieke MAIL FROM-configuratie

De instellingen bij de provider bepalen welke SPF-identiteit er daadwerkelijk over de lijn gaat. Amazon SES documenteert bijvoorbeeld een aangepast MAIL FROM-domein dat een eigen MX-record en SPF-TXT-record nodig heeft. SES kan terugvallen op een regioafhankelijk MAIL FROM-domein onder amazonses.com als de MX van het aangepaste domein verkeerd is geconfigureerd, of de verzending weigeren, afhankelijk van het ingestelde gedrag. Die fallback kan de DMARC-alignment veranderen, ook als het zichtbare From-adres gelijk blijft. Leg voor elke provider het geconfigureerde return-path-domein vast, de vereiste DNS-waarden, het fallbackgedrag, de verzendregio's en het eigenaarschap. Wacht na een DNS- of providerwijziging tot de relevante gecachte antwoorden zijn verlopen en herhaal dan de DNS-evaluatie en de gecontroleerde verzendingen. Kopieer de include van een leverancier niet naar het zichtbare From-domein, tenzij dat werkelijk de identiteit is en de volledige afzenderinventaris van het domein dat ondersteunt.

Gebruik een reproduceerbare SPF-audit bij wijzigingen

Houd per verzendpad één rij bij met een eigenaar, applicatie, berichtklasse, zichtbaar From-domein, MAIL FROM-domein, HELO-domein, verwachte bronbereiken, providerafhankelijkheid en het tijdstip van de laatste gecontroleerde test. Sla elke SPF-check op met het geselecteerde record, de recursieve trace, het aantal DNS-query's, het gematchte mechanisme, het resultaat, de alignmentbeslissing en een niet-gevoelige test-ID. Houd tijdens een migratie oude en nieuwe legitieme bronnen alleen geautoriseerd voor de noodzakelijke overgangsperiode, verifieer het nieuwe pad en verwijder verouderde autorisatie daarna bewust. Monitor permanente en tijdelijke authenticatiefouten in plaats van alleen op weigeringen te reageren. Voer de audit opnieuw uit na providerwijzigingen, verhuizingen van IP-pools, domeinwijzigingen, DNS-aanpassingen of nieuwe applicaties. Deze workflow vangt zowel te krap beleid dat legitieme paden blokkeert als te ruim beleid dat ongebruikte autorisatie laat staan.

Controleer SendHQ met dezelfde bewijsstandaard

SendHQ documenteert dat een directe verzending een adres op een geverifieerd workspace-domein moet gebruiken. Dat verifieert de afzenderidentiteit, maar vervangt geen SPF-evaluatie. Een gecontroleerd SendHQ-bericht vereist nog steeds dezelfde DNS-trace, inspectie van ontvangen headers, SPF-resultaat en DMARC-alignmentcontrole als hierboven beschreven.

Veelgestelde vragen

Bronnen

• RFC 7208: Sender Policy Framework — IETF
• RFC 5321: Simple Mail Transfer Protocol — IETF
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — RFC Editor
• Een aangepast MAIL FROM-domein gebruiken in Amazon SES — Amazon Web Services
• OpenAPI-contract van SendHQ — SendHQ