SPF beantwoordt een beperkte vraag: is de verbindende server geautoriseerd om het domein te gebruiken dat wordt gepresenteerd in een bepaalde SMTP identiteit? Het begint niet met de naam van de afzender die wordt weergegeven in een inbox. Dat onderscheid verklaart waarom het wijzigen van het verkeerde DNS record een authenticatieprobleem onaangeroerd kan laten.
Voor een normaal niet-leeg omgekeerd pad is de relevante identiteit het domein in SMTP MAIL VAN. Het adres kan een door de provider beheerd bounceadres zijn in plaats van de zichtbare auteur. Een aparte HELO controle kan ook plaatsvinden. Wanneer MAIL FROM leeg is, construeert SPF de MAIL FROM-identiteit met behulp van het HELO domein en het lokale deel postmaster. Deze identiteitsregels zijn gedefinieerd in RFC 7208 §2.3 En RFC 7208 §2.4.
Volg de envelop door één bezorging
Stel je een applicatie voor die een factuur verzendt. De SMTP verbinding is afkomstig van 192.0.2.44 , de MAIL FROM is receipts@bounce.example.com en de berichtkop zegt From: billing@example.com . Dit zijn synthetische waarden die zijn gereserveerd voor documentatie, en niet voor een implementatierecept.
De ontvanger evalueert het verbindende IP-adres aan de hand van het SPF beleid op bounce.example.com . Er wordt niet SPF beleid van example.com geselecteerd simpelweg omdat dat domein in From voorkomt. Een polis bij de ouder autoriseert niet automatisch het kind.
Stel dat bounce.example.com publiceert v=spf1 ip4:192.0.2.44 -all. Het ip4-mechanisme komt overeen en het resultaat is geslaagd. Als het verbindingsadres 192.0.2.45 was, zou het niet overeenkomen; de evaluatie zou -all bereiken en de terugkeer mislukken. Geen van beide uitkomsten zegt of de factuur echt is of dat het account dat de factuur verzendt, is gecompromitteerd.
Identificeer bewijsmateriaal waarop u kunt vertrouwen
Vraag om het origineel ontvangen bericht in plaats van een screenshot van de weergavenaam. Registreer de ontvanger, ontvangsttijd, verbindings-IP, geëvalueerde SMTP identiteit en SPF resultaat. Onder RFC 8601 §7.1, zijn de vertrouwde authenticatieresultaten of logbestanden van de ontvanger sterker bewijs dan een header die door een willekeurige afzender wordt aangeleverd.
Onder RFC 5321 §4.4, een afgeleverd Return-Path kan helpen de afzender van de envelop te onthullen, maar het is eerder een spoor van bezorging dan een opdracht die u veilig kunt bewerken om SPF te wijzigen. Gateways, opnieuw indienen en doorsturen kunnen een nieuwe SMTP transactie veroorzaken. Stel een diagnose van de transactie waarbij de falende ontvanger zijn controle heeft uitgevoerd.
Houd een kort identiteitswerkblad bij: zichtbaar Van domein; MAIL VAN domein; HELO naam; IP-adres verbinden; SPF record destijds waargenomen; resultaat; en eventueel uitgelijnd DKIM resultaat. Het punt is om te voorkomen een record editor niet de eerste diagnostische stap wordt.
Behandel bounces en doorsturen afzonderlijk
Een leeg omgekeerd pad is normaal voor bepaalde bezorgmeldingen. Behandel het niet als ontbrekend bewijs en vervang het door het zichtbare Van-domein. Leg HELO vast en pas in plaats daarvan de nulpadregel toe.
Doorsturen introduceert een ander probleem. De volgende ontvanger ziet het verbindende IP-adres van de forwarder, dat mogelijk niet is geautoriseerd door het oorspronkelijke envelopdomein. Het herschrijven van de envelop kan de identiteit die wordt gecontroleerd, wijzigen. Een pas voor de herschreven identiteit wordt niet automatisch afgestemd op de zichtbare auteur. Onderzoek de volledige route en eventuele overlevenden op één lijn DKIM -handtekening in plaats van elke expediteur aan uw polis toe te voegen.
Koppel SPF aan de zakelijke beslissing
DMARC voegt een identiteitsvergelijking toe: een passerend SPF resultaat moet overeenkomen met het auteurdomein om aan het SPF pad te voldoen. Een afzonderlijk uitgelijnde DKIM pas kan aan DMARC voldoen, zelfs als SPF niet doet. RFC 9989 beschrijft die relatie.
Evalueer voor het factuurvoorbeeld uitlijning onder de toepasselijke regels voor modus- en organisatiedomeindetectie; ga er niet van uit dat een gedeeld tekstachtervoegsel de uitlijning in elke naamruimte bewijst. Strikte SPF uitlijning vereist exacte domeingelijkheid onder RFC 9989 §3.2.10.2; ontspannen ontdekking van organisatiedomeinen is gespecificeerd in RFC 9989 §4.10.2.
Voordat u een wijziging goedkeurt, vraagt u de eigenaar van de service welke envelopidentiteit het product ondersteunt en wie de DNS beheert. Bewaar het vorige record, breng de kleinste geautoriseerde wijziging aan en stuur een nieuwe representatieve factuur via de getroffen route. Sluit het issue pas af als de waargenomen identiteit, het resultaat en de vereiste afstemming voldoen aan het beoogde resultaat.
De praktische afhaalmaaltijd
Begin met de SMTP envelop en het verbindende IP-adres. Het bewerken van een domein dat SPF nooit heeft geëvalueerd, is geen reparatie, zelfs niet als een tool voor recordcontrole groen wordt.
Houd de beslissing reproduceerbaar
Voor de factuurbevestiging behoudt u het verbindende IP-adres 192.0.2.44 , MAIL FROM domein bounce.example.com en zichtbaar auteurdomein example.com als afzonderlijke velden. Een bovenliggende TXT -bewerking is geen bewijs van een gerepareerde onderliggende controle. Voor een doorgestuurde kopie legt u een nieuwe transactierij vast in plaats van het originele IP-adres door te geven. Dit zijn hypothetische inputs, geen uitgevoerde SPF of leveringswaarnemingen.