Et tilbudsvarsel kan være autentisk, men likevel inneholde en uautorisert endring av bankdetaljene etter en kontokompromittering. Autentisering hjelper til med å evaluere domeneidentitet. Anskaffelsesmyndighet kommer fra den godkjente prosessen og ansvarlige personer. Design de to sjekkene for å forsterke hverandre uten å la den ene erstatte den andre.
Kartlegg innkallingen til anskaffelsesprotokollen
For anbudspublisering, leverandørkunngjøringer og delegerte anskaffelser, registrere journalsystemet, kunngjøringsidentifikator, godkjent avsender og ansvarlig entreprenørrolle. Meldingen skal hjelpe en leverandør med å finne den autoritative anskaffelsesposten gjennom en kjent kanal. Unngå å behandle en kobling i en uventet melding som uavhengig bekreftelse av samme melding.
Ta opp applikasjonsleieren, Fra domene, konvoluttdomene, DKIM domene og velger for hver rute. En utkontraktert innkjøpsportal kan ha separat sendeinfrastruktur fra myndighetens personalpost. En merkevare-bunntekst eller svar-til-adresse etablerer ikke en justert autentiseringsbane. Fortsett svarhåndteringen i rutekartet fordi et ekte varsel kan sende svar til en annen operativ postboks.
Hold konsekvensendringer bak deres egen godkjenning
Klassifiser oppslag etter hva de ber mottakeren om å gjøre. En anbudsåpen utlysning, fristendring, tildelingskommunikasjon og betalingsdetaljforespørsel har ulike driftsmessige konsekvenser. Denne veiledningen anbefaler separat anskaffelses- og finansverifisering for sensitive leverandør- eller bankendringer ved bruk av etablerte kontaktoppføringer, ikke et telefonnummer som er oppgitt i den omstridte e-posten.
DMARC inspiserer ikke tilbudets vilkår eller fastslår hvem som har godkjent en tildeling. En forbigående signatur fastslår heller ikke at en bankkonto tilhører den tiltenkte leverandøren. Behold endringsmyndighet, godkjent journal og uavhengig verifikasjonsresultat i innkjøpssystemet. Dette er arbeidsflytanbefalinger, ikke en erklæring om noen jurisdiksjons anskaffelseslov.
Test den delegerte avsenderen før en frist
Kjør godkjente prøver for førstegangsvarsel, endring og kansellering, med fiktive anbudsdetaljer. Bekreft tiltenkt From-identitet, signaturresultat, aktuelt justering, svardestinasjon og vellykket tilgang til den offisielle posten. En signaturtest kan ikke fastslå at varselet kom før en lovlig frist. Oppbevar det relevante leverings- og publiseringsbeviset separat.
Dersom en entreprenør bytter plattform under et aktivt anbud, beholdes den gamle traseen inntil godkjent avskjæring og køhåndtering er forstått. Angi en eier for mislykkede varsler og en dokumentert alternativ varslingsprosess. Ikke send inn et varsel på nytt stille gjennom en ny identitet fordi en integrasjon mislyktes. En slik endring kan forvirre leverandører og må håndteres under innkjøpsteamets godkjente kommunikasjonsprosess.
Vurder den leverandørvendte grensen på nytt
Gjennomgå rapporter fra innkjøpstjenesten, ikke bare på tvers av avdelingens totale postvolum. Et tilsynelatende sunt aggregat kan skjule en endringsavsender med lavt volum. Eskaler uventede signeringsdomener, nye svar-til-destinasjoner og ueide leverandørkontoer. Før du pensjonerer et domene eller en velger, må du fastslå hvilke anbudsposter og tilbakevendende kunngjøringer som fortsatt avhenger av det. Autentiseringsbevis hører sammen med, snarere enn i stedet for, anskaffelsesrevisjonsposter.
Arbeid gjennom tre skriftlige ruteoppføringer
Disse reserverte eksempeldomenene, velgerne, rollene og forbigående DKIM lokaler er fiktive. Ingen signert melding, nøkkel, kryptografisk verifisering, DNS oppslag, SMTP transaksjon eller live-tjenestetest leveres eller utføres for disse tilfellene. Ingen testkode eller ekstern prøve er nødvendig for å inspisere resonnementet nedenfor.
- anbudspublisering: synlig fra domene tenders.civic.example ; DKIM d=tenders.civic.example; velgerdemo1; anta at DKIM passerer kun for denne skriftlige saken. SPF POST FRA identitet og resultat ukjent; andre signaturer ukjent; faktisk politikkoppdagelse og levering ukjent. Foreslått eier: Anskaffelsesleder. Neste handling: Skaff en autorisert prøve og et pålitelig mottakerresultat for denne eksakte leietakeren.
- leverandørmelding: synlig fra suppliers.civic.example ; DKIM d=suppliers.civic.example; velgerdemo2; anta at DKIM passerer kun for denne skriftlige saken. SPF -POST FRA identitet og resultat ukjent; andre signaturer ukjent; faktisk politikkoppdagelse og levering ukjent. Foreslått eier: Leverandørkommunikasjonseier. Neste handling: Bekreft denne separate ruten og dens forretningshendelse i stedet for å arve den første rutens resultat.
- delegert anskaffelse: synlig fra domene contracts.civic.example ; DKIM d=provider.example.net; velgerdemo3; anta at DKIM passerer kun for denne skriftlige saken. SPF -POST FRA identitet og resultat ukjent; andre signaturer ukjent; faktisk politikkoppdagelse og levering ukjent. Foreslått eier: Oppdragsgiver. Neste handling: Spør den bekreftede leverandøren om denne leietakerens støttede justerte signeringsbane; ikke utvide autorisasjonen til hele nettverket.
For de to første angitte signaturene er d= nøyaktig lik Fra-domenet, så identifikatoren tilfredsstiller både streng og avslappet justering. Gitt det angitte vellykkede DKIM resultatet, eksisterer det en justert autentiseringsbane for disse hypotetiske meldingene. Den tredje underskriveren er bevisst ikke relatert til forfatterdomenet og kan ikke oppgi den justerte banen. Ikke kall den tredje meldingen en DMARC feil: justert SPF eller en annen justert passering DKIM signatur kan fortsatt tilfredsstille mekanismen, og disse inngangene er ukjente. Ikke antyd reell distribusjon eller innboksplassering fra noen rad.
En kryptografisk signatur autentiserer et signeringsdomenes ansvar, ikke sannheten eller autorisasjonen for hver instruksjon. Endringer i dekkede kanoniserte bytes kan ugyldiggjøre en signatur; ikke alle synlige redigeringer endrer nødvendigvis den signerte inngangen. Autentisering og godkjenning på applikasjonsnivå forblir atskilt.
Bruk et varselspesifikt akseptkort
For fiktivt anbud T-01 endringsversjon 2, kreves godkjent postversjon, autorisert kontraktørrolle, Fra identitet, svardestinasjon, publiseringstidspunkt og mottaker-varslingsbevis. Hvis autentiseringen går gjennom, men den offisielle posten forblir versjon 1, stopp og avstem endringen med anskaffelse; ikke merk den godkjent. Hvis posten er korrekt, men varslingen mislykkes, påkaller du den allerede godkjente alternative varselprosessen og oppbevar tidsbevis. En endret mottaker utløser den separate økonomiverifiseringsprosessen uavhengig av begge resultatene. Dette er forslag til vedtak, ikke anskaffelsesrettslige krav eller gjennomførte prøver.
Bruk standardene uten å kreve overholdelse
RFC 9989 avsnitt 4.4 og 5.3.5 støtte justeringen og mekanismeskillet. Seksjon 7.4 advarer om interoperabilitet med indirekte e-post: domener som bruker p=reject må bruke gyldig DKIM , ikke SPF alene, og generell bruk av e-postlister krever spesiell forsiktighet. En rutebeholdning er ikke i seg selv tillatelse til å håndheve avvisning. RFC 6376 avsnitt 3.4–3.7 og 6.1 beskrive signerte inndata og verifisering. RFC 9990 Seksjon 3.1 gir rapporteringskontekst, ikke ankomstbevis per mottaker. RFC 5321 Seksjon 4.2.5 skiller serverakseptansvar fra senere leveringsresultater. Sektorarbeidsflytvalg her er redaksjonelle anbefalinger; juridisk omfang, faktor egnethet og lokal autorisasjon trenger sin egen ansvarlige vurdering.