Een SPF include voor een gedeelde e-mailservice kan de infrastructuur autoriseren die door veel klanten wordt gebruikt. Zo is de dienst vaak ingericht, maar de toestemming verdient een duidelijke uitleg. SPF controleert een verbindende host op basis van een domeinbeleid; een brede positieve match is geen huurderspecifieke cryptografische referentie.
De praktische vraag is of uw provider verhindert dat een andere klant met uw SMTP identiteit verzendt, en of het beleid alleen de infrastructuurrechten verleent die uw gebruik daadwerkelijk nodig heeft.
Breng de vertrouwensrelatie in kaart
Registreer voor elk inclusief of gedeeld IP-bereik de service, de bedrijfseigenaar, het ondersteunde envelopdomein en de gedocumenteerde providerinstellingen. Bepaal of uw e-mail een envelopdomein van de provider gebruikt of een aangepast domein dat u beheert. Als de provider eigenaar is van het daadwerkelijk geëvalueerde domein, heeft het toevoegen van een include aan uw hoofddomein mogelijk helemaal geen invloed op het SPF resultaat van dat bericht.
Lees de huidige documentatie van de provider voor domeinverificatie en afzendercontroles. Als de documentatie onduidelijk is, identificeer dan de vraag voor de service-eigenaar of de ondersteuningsprovider. Beweer niet dat alle huurders geïsoleerd zijn alleen maar omdat een test van uw eigen account slaagt.
Begrijp de limiet van een op IP gebaseerde beslissing
RFC 7208 §11.4 beschrijft de risico's van vervalsing door meerdere gebruikers waarbij een gedeeld systeem gebruikers in staat stelt de identiteit van andere gebruikers te claimen. Met een SPF -pas kan worden vastgesteld dat de verbindende host geautoriseerd is voor het geëvalueerde domein, zonder te bewijzen welk klantaccount het bericht heeft geïnitieerd. Handhaving aan de aanbiederzijde maakt daarom deel uit van de beveiligingsgrens.
Dit betekent niet dat elke gedeelde dienst onveilig is. Het betekent dat het autorisatiemodel twee lagen heeft: DNS verleent toestemming aan de infrastructuur, en de service moet beperken hoe klanten identiteiten op die infrastructuur gebruiken. Bewijs voor de ene laag mag niet worden gepresenteerd als bewijs voor de andere laag.
Kies de smalst ondersteunde configuratie
Geef de voorkeur aan de exacte include- of domeinconfiguratie die de provider ondersteunt voor uw verzendende product en regio, waar dergelijke verschillen zijn gedocumenteerd. Vermijd het toevoegen van de volledige netwerktoewijzing van een leverancier als er een beperkter onderhouden beleid beschikbaar is. Bedenk geen smallere include-opties en vervang geen door de leverancier beheerd beleid door een momentopname van IP-adressen, tenzij u dat ontwerp veilig kunt handhaven.
Een toegewijd retourpad subdomein kan SPF beleid van een service scheiden van andere e-mail. Het verbetert het eigendoms- en levenscyclusbeheer, maar bewijst op zichzelf niet dat er sprake is van isolatie tussen klanten die de provider delen. Bekijk andere authenticatie- en accountcontroles als afzonderlijke onderdelen van het ontwerp.
Vergelijk twee configuraties zorgvuldig
Illustratief voorbeeld: v=spf1 ip4:192.0.2.0/24 -all autoriseert elk IPv4 adres in dat documentatienetwerk voor de geëvalueerde identiteit. Alleen een beleidsnaam ip4:192.0.2.10 geeft toestemming voor één adres. Het smallere beleid verkleint de bronset, maar is alleen nuttig als de provider dat adres ook daadwerkelijk garandeert voor uw dienst. Een niet-ondersteunde beperking kan de legitieme levering tijdens een failover verbreken.
Onder RFC 7208 §5.2, evalueert een include een beleid waarnaar wordt verwezen; de huidige uitbreiding is een observatie, geen vast contract. Het kan veranderen als de aanbieder zijn beleid wijzigt. Leg de afhankelijkheid en het eigenaarschap vast in plaats van de opgeloste adressen van vandaag als de uiteindelijke waarheid te behandelen.
Beoordeel zonder andere tenants te testen
Gebruik uw eigen geautoriseerde accounts en gecontroleerde ontvangers voor validatie. Bevestig uw verwachte identiteiten en leg vast welke infrastructuur een pas produceert. Beoordeel tenantbeperkingen via documentatie, goedgekeurd configuratiebewijs of een expliciet geautoriseerde beveiligingstest. Probeer niet het domein van een andere klant na te bootsen om een theoretisch probleem aan te tonen.
Controleer op nieuwe aanbiedingen, ongewoon brede netwerkbereiken en diensten zonder eigenaar. Bij een beleidsherziening moeten ook de recursieve evaluatielimieten worden gecontroleerd, omdat verschillende gedeelde providers een bronprobleem kunnen veroorzaken, zelfs als elke opname afzonderlijk legitiem is.
Maak het acceptatiebesluit expliciet
Houd een kort overzicht bij van de verleende infrastructuurtoestemming, identiteitscontroles aan de providerzijde, bekende lacunes in het bewijsmateriaal en de verantwoordelijke eigenaar. Plan een beoordeling wanneer de provider- of serviceconfiguratie verandert. Het accepteren van gedeelde infrastructuur kan redelijk zijn, maar de beslissing moet berusten op het volledige vertrouwensmodel en niet alleen op een groene SPF badge.
Noteer de volgende beslissing
Gebruik twee bewijsrijen: infrastructuurtoestemming (feitelijk beleid, envelopdomein en waargenomen bron) en tenantcontrole (gedocumenteerde verificatie/handhaving, configuratiebewijs en onopgeloste hiaten). Uw eigen succesvolle SPF resultaat vult alleen de eerste rij. Als een smaller adres niet door de provider wordt gegarandeerd, mag u een niet-ondersteunde beperking niet als een geverifieerde beveiligingsverbetering beschouwen. Er is geen cross-tenanttest of wisseling van provider uitgevoerd.