Met een toepasselijk beleid en een afgeronde evaluatie, SPF En DKIM kunnen allebei voorbijgaan DMARC faalt onder RFC 9989 §5.3.5. Dat gebeurt wanneer de domeinen die door deze mechanismen worden geverifieerd niet overeenkomen met het domein dat mensen zien in het Van-adres.
Elk mechanisme beantwoordt een andere vraag. SPF controleert of de verbindende bron geautoriseerd is voor de geëvalueerde envelopidentiteit. DKIM verifieert een handtekening die is gekoppeld aan een ondertekeningsdomein. DMARC controleert vervolgens of een passerende identiteit de vereiste relatie heeft met het zichtbare Van-domein. De manier om dit probleem te diagnosticeren is door die identiteiten te vergelijken, en niet door de groene paslabels mee te tellen.
Verzamel de identiteiten uit een ontvangen bericht
Verkrijg een origineel bericht van het ontvangende systeem, inclusief de vertrouwde authenticatieresultaten. Een willekeurige koptekst die zegt: 'pass' kan worden geleverd door een niet-vertrouwde afzender; identificeer de ontvangstgrens waaronder het bewijsmateriaal is gegenereerd RFC 8601 §7.1.
Noteer deze velden:
- Bewijs: zichtbaar vanuit domein; Wat het vaststelt: het auteurdomein, dat wil zeggen het domein in het zichtbare Van-adres
- Bewijs: SPF resultaat en geëvalueerd MAIL VAN identiteit; Wat het vaststelt: of de verbindende bron geautoriseerd was voor die envelopidentiteit
- Bewijs: elk DKIM -resultaat en zijn d= domein; Wat het vaststelt: De handtekening van welk domein is geverifieerd
- Bewijs: Toepasbare aspf- en adkim-modi; Wat het vaststelt: Of exacte of ontspannen domeinrelaties vereist zijn
- Bewijs: vertrouwd DMARC -resultaat en diagnostische context; Wat het vaststelt: de waargenomen evaluatie van de ontvanger
Onder RFC 5321 §4.4, voor gewone berichten, de afgeleverde Return-Path kan helpen bij het identificeren van de identiteit van de retourzending van de envelop. Correleer het met vertrouwde SPF resultaten en routeer bewijs in plaats van aan te nemen dat een weergaveveld het hele SMTP verhaal vertelt.
Uitgewerkt voorbeeld: twee passen, geen afgestemde identiteit
Dit is een synthetische illustratie waarbij wordt uitgegaan van een toepasselijk geldig beleid en voltooide controles, en niet van een vastgelegd klantbericht:
- Veld: Van; Waargenomen waarde: accounts@example.com
- Veld: SPF ; Waargenomen waarde: ga door voor bounce.example.net
- Veld: DKIM ; Waargenomen waarde: geslaagd met d=example.org
- Veld: DMARC uitlijning; Waargenomen waarde: geen van beide passerende domeinen komt overeen met example.com
Beide mechanismen slaagden in hun eigen werk. Geen van beide legt de vereiste relatie vast example.com, dus ze bieden geen DMARC doorgangspad voor dat zichtbare Van-domein.
Een ondersteunde oplossing kan een klantdomein configureren DKIM -handtekening. Een andere mogelijkheid is een ondersteund aangepast envelopdomein dat een uitgelijnd SPF pad produceert. Welke optie beschikbaar is, hangt af van het daadwerkelijk verzendende product en de route.
Bedenk geen DNS waarden. Haal de ondersteunde configuratie op van de service, publiceer deze onder de juiste eigenaarsnamen, schakel de relevante verzendfunctie in en verzend een nieuwe test via dezelfde applicatieworkflow.
Pas een strikte en ontspannen uitlijning correct toe
Bij strikte afstemming moeten de relevante domeinen precies onder overeenkomen RFC 9989 §3.2.10.2, voor beide mechanismen. De relevante DKIM en SPF identifiers zijn gespecificeerd in RFC 9989 §4.4.1 En RFC 9989 §4.4.2respectievelijk. Met ontspannen afstemming gebruikt DMARC de toepasselijke relatie- en ontdekkingsregels tussen organisaties en domeinen RFC 9989 §4.10.2.
Voor een eenvoudig illustratief geval: een passerende envelop-identiteit op bounce.example.com kan worden uitgelijnd met een Van-domein van example.com onder ontspannen SPF uitlijning. Het voldoet niet aan een strikte SPF uitlijning omdat de twee namen verschillen.
Generaliseer de ontdekking van organisatiedomeinen niet in een regel die altijd de laatste twee labels gebruikt. Domeingrenzen en huidige DMARC -detectieregels zijn van belang. Controleer het daadwerkelijke beleid en de implementatie voor complexere domeinstructuren.
Als er meerdere DKIM handtekeningen bestaan, controleer dan alle relevante handtekeningen. Eén niet-uitgelijnde passerende handtekening maakt een afzonderlijke uitgelijnde passerende handtekening niet ongeldig. Omgekeerd creëert de aanwezigheid van uw domein in een mislukte handtekening geen doorgangspad.
Zoek de ondersteunde identiteitsinstellingen in de verzendende service
Dit verschijnt vaak nadat een team een CRM, factureringstool of campagneservice gaat gebruiken. De leverancier zegt dat authenticatie is ingeschakeld, maar sommige ontvangers weigeren de berichten. Beide uitspraken kunnen waar zijn als het platform zijn eigen domein verifieert terwijl het bedrijf het jouwe weergeeft.
Vraag de telefoniste om één getroffen bericht te tonen en de zichtbare afzender, de envelopafzender en het ondertekeningsdomein toe te lichten. Een bruikbare oplossing laat zien dat de daadwerkelijke zakelijke workflow via een ondersteunde, afgestemde identiteit verloopt. Een screenshot met twee groene vinkjes is onvoldoende.
Houd de applicatie-eigenaar betrokken. De juiste oplossing kan een instelling of planspecifieke mogelijkheid in die service zijn, in plaats van een verandering in het medewerkersmailplatform.
Test de correctie via de oorspronkelijke route
Stuur een gecontroleerd vervangingsbericht via de betreffende service. Vergelijk het Van-domein, de envelopidentiteit en elke relevante DKIM handtekening met het voorgaande voorbeeld. Houd het resultaat van de vertrouwde ontvanger en de configuratiewijziging bij elkaar.
Als een eenvoudige directe test slaagt, maar de zakelijke route nog steeds mislukt, inspecteer dan de doorsturing, gateways en berichtwijzigingen. Ze kunnen veranderen welk authenticatiepad overleeft. Maak ook onderscheid tussen een DMARC -pas en inboxplaatsing; de ontvanger kan er extra filtering onder toepassen RFC 9989 §5.4.
Gebruik de Microsoft 365 handleiding of Google Workspace handleiding waarbij deze systemen de daadwerkelijke afzenders zijn. Als het bericht een andere applicatie gebruikt, onderzoek dan de eigen route van die applicatie. Gebruik geaggregeerde rapporten om te zoeken naar hetzelfde patroon in het waargenomen verkeer.
Bepaal wat de mislukking u vertelt
Een uitlijnfout leidt tot een technisch resultaat. Het stelt op zichzelf niet vast of het bericht legitiem was, een niet-geautoriseerde dienst, een doorgestuurd slachtoffer of een poging tot nabootsing van identiteit.
Een eigenaar en zakelijk doel voor een afzender vereisen voordat u een nieuwe vertrouwensrelatie goedkeurt. Gedeelde infrastructuur en een herkenbare providernaam zijn nuttige aanwijzingen, maar bewijzen niet dat uw organisatie het account of de workflow heeft geautoriseerd.
Leg de geaccepteerde reikwijdte van de oplossing vast. Een uitgelijnde ondertekeningsidentiteit kan DMARC tevreden stellen terwijl het account later wordt gecompromitteerd of de applicatie onveilige inhoud genereert. Ga door met accountcontroles, applicatievalidatie en onafhankelijke goedkeuring van gevoelige transacties.
De praktische afhaalmaaltijd
Sluit het probleem wanneer de getroffen workflow een nieuw bericht produceert met een vertrouwd, uitgelijnd resultaat. Houd de identiteitsvergelijking en de configuratiewijziging bij elkaar. Dit verklaart zowel waarom het oorspronkelijke bericht mislukte als waarom de correctie werkt.
Maak de volgende beslissing expliciet
Voor de twee-pass-fixture registreert u 'geen uitgelijnd passeerpad' in plaats van ' SPF gebroken'. Kies de door de service ondersteunde identiteit die u wilt herstellen en laat de wijziging in behandeling totdat een nieuw bericht met dezelfde workflow wordt geverifieerd. Als de beleidsdetectie of DNS verwerking onvolledig is, forceer de observatie dan niet in een pass/fail-label; RFC 9989 §5.3.6 behandelt vereiste DNS fouten afzonderlijk. Er is geen klantconfiguratie of leveringstest uitgevoerd.