Ett anbudsmeddelande kan vara giltigt men ändå innehålla en otillåten ändring av bankdetalj efter en kontokompromiss. Autentisering hjälper till att utvärdera domänidentitet. Upphandlingsmyndigheten kommer från den godkända processen och ansvariga personer. Designa de två kontrollerna så att de förstärker varandra utan att låta den ena ersätta den andra.
Kartlägg meddelandet till upphandlingsprotokollet
För anbudspublicering, leverantörsmeddelanden och delegerad upphandling, anteckna registersystemet, meddelandeidentifierare, godkänd avsändare och ansvarig entreprenadroll. Meddelandet bör hjälpa en leverantör att hitta den auktoritativa upphandlingsposten via en känd kanal. Undvik att behandla en länk i ett oväntat meddelande som en oberoende verifiering av samma meddelande.
Spela in applikationshyresgästen, Från domän, kuvertdomän, DKIM domän och väljare för varje rutt. En utlagd upphandlingsportal kan ha separat sändningsinfrastruktur från myndighetens personalpost. En märkt sidfot eller svarsadress upprättar inte en anpassad autentiseringsväg. Behåll svarshanteringen i ruttkartan eftersom ett äkta meddelande kan dirigera svar till en annan operativ brevlåda.
Håll följdändringar bakom sitt eget godkännande
Klassificera meddelanden efter vad de ber mottagaren att göra. Ett öppet anbudsmeddelande, ändring av deadline, tilldelningskommunikation och begäran om betalningsuppgift har olika operativa konsekvenser. Den här guiden rekommenderar separat inköps- och finansverifiering för känsliga leverantörs- eller bankbyten med hjälp av etablerade kontaktuppgifter, inte ett telefonnummer som anges i det omtvistade e-postmeddelandet.
DMARC granskar inte anbudsvillkoren eller avgör vem som godkänt en tilldelning. En förbigående signatur visar inte heller att ett bankkonto tillhör den tilltänkta leverantören. Behåll ändringsbefogenhet, godkänd journal och oberoende verifieringsresultat i upphandlingssystemet. Dessa är arbetsflödesrekommendationer, inte ett uttalande om någon jurisdiktions upphandlingslagstiftning.
Testa den delegerade avsändaren före en deadline
Kör godkända prover för första meddelande, ändring och annullering, med fiktiva anbudsdetaljer. Bekräfta avsedd From-identitet, signaturresultat, tillämpligt inriktning, svarsdestination och framgångsrik tillgång till den officiella posten. En underskriftstest kan inte fastställa att meddelandet kommit före en laglig tidsfrist. Bevara relevant leverans- och publiceringsbevis separat.
Om en entreprenör byter plattform under ett aktivt anbud, behåll den gamla sträckan tills godkänd brytning och köhantering är förstått. Ange en ägare för misslyckade meddelanden och en dokumenterad alternativ aviseringsprocess. Skicka inte in ett meddelande igen i tysthet genom en ny identitet eftersom en integrering misslyckades. En sådan förändring kan förvirra leverantörer och måste hanteras under upphandlingsteamets godkända kommunikationsprocess.
Omvärdera den leverantörsvända gränsen
Granska rapporter från inköpstjänsten, inte bara över avdelningens totala postvolym. Ett till synes hälsosamt aggregat kan dölja en ändringsavsändare med låg volym. Eskalera oväntade signeringsdomäner, nya Svara-till-destinationer och oägda leverantörskonton. Innan du avbryter en domän eller väljare, fastställa vilka anbudsuppgifter och återkommande meddelanden som fortfarande är beroende av den. Autentiseringsbevis hör ihop med, snarare än i stället för, upphandlingsrevisionsprotokoll.
Arbeta igenom tre skrivna ruttposter
Dessa reserverade exempeldomäner, väljare, roller och passerande DKIM lokaler är fiktiva. Inget signerat meddelande, nyckel, kryptografisk verifiering, DNS sökning, SMTP transaktion eller live-tjänsttest tillhandahålls eller utförs för dessa fall. Ingen testkod eller externt prov behövs för att inspektera resonemanget nedan.
- anbudspublicering: synlig från domänen tenders.civic.example ; DKIM d=tenders.civic.example; väljare demo1; anta att DKIM passerar endast för detta skriftliga fall. SPF MAIL FRÅN identitet och resultat okända; andra signaturer okända; faktisk policyupptäckt och leverans okänd. Föreslagen ägare: Upphandlingsledare. Nästa åtgärd: Skaffa ett auktoriserat prov och ett pålitligt mottagarresultat för just denna hyresgäst.
- leverantörsmeddelande: synlig från domänen suppliers.civic.example ; DKIM d=suppliers.civic.example; väljare demo2; anta att DKIM passerar endast för detta skriftliga fall. SPF MAIL FRÅN identitet och resultat okänt; andra signaturer okända; faktisk policyupptäckt och leverans okänd. Föreslagen ägare: Leverantörskommunikationsägare. Nästa åtgärd: Bekräfta den här separata rutten och dess affärshändelse istället för att ärva den första ruttens resultat.
- delegerad upphandling: synlig från domänen contracts.civic.example ; DKIM d=provider.example.net; väljare demo3; anta att DKIM passerar endast för detta skriftliga fall. SPF MAIL FRÅN identitet och resultat okänt; andra signaturer okända; faktisk policyupptäckt och leverans okänd. Föreslagen ägare: Upphandlande myndighet. Nästa åtgärd: Fråga den verifierade leverantören om den här hyresgästens stödda anpassade signeringsväg; breddar inte behörigheten till hela nätverket.
För de två första angivna signaturerna är d= exakt lika med From-domänen, så identifieraren uppfyller strikt såväl som avslappnad justering. Med tanke på det angivna framgångsrika DKIM resultatet finns en anpassad autentiseringsväg för dessa hypotetiska meddelanden. Den tredje undertecknaren är medvetet inte relaterad till författarens domän och kan inte tillhandahålla den anpassade sökvägen. Kalla inte det tredje meddelandet för ett DMARC fel: aligned SPF eller annan aligned passing DKIM signatur kan fortfarande uppfylla mekanismen, och dessa ingångar är okända. Dra inte slutledning om verklig distribution eller placering i inkorgen från någon rad.
En kryptografisk signatur autentiserar en signeringsdomäns ansvar, inte sanningen eller auktorisationen för varje instruktion. Ändringar av täckta kanoniserade bytes kan ogiltigförklara en signatur; inte varje synlig redigering ändrar nödvändigtvis den signerade inmatningen. Autentisering och godkännande på applikationsnivå förblir separata.
Använd ett meddelandespecifikt acceptkort
För fiktivt anbud T-01, ändringsversion 2, krävs den godkända postversionen, auktoriserad kontraktsroll, Från identitet, svarsdestination, publiceringstid och mottagare-aviseringsbevis. Om autentiseringen godkänns men den officiella posten förblir version 1, stoppa och stämma av ändringen med upphandlingen; märk den inte godkänd. Om posten är korrekt men meddelandet misslyckas, åberopa den redan godkända alternativa meddelandeprocessen och behåll tidsbevis. En ändrad förmånstagare utlöser den separata ekonomiverifieringsprocessen oavsett resultat. Det är förslag till beslut, inte upphandlingsrättsliga krav eller genomförda prov.
Tillämpa standarderna utan att hävda efterlevnad
RFC 9989 avsnitt 4.4 och 5.3.5 stödja inriktningen och mekanismskillnaden. Dess avsnitt 7.4 varnar för interoperabilitet med indirekt e-post: domäner som använder p=reject måste använda giltig DKIM , inte SPF ensam, och allmän användning av e-postlistor kräver särskild omsorg. En ruttinventering är inte i sig tillåtelse att verkställa avslag. RFC 6376 avsnitt 3.4–3.7 och 6.1 beskriv signerade inmatningar och verifiering. RFC 9990 Avsnitt 3.1 tillhandahåller rapporteringssammanhang, inte ankomstbevis per mottagare. RFC 5321 Avsnitt 4.2.5 skiljer ansvar för serveracceptans från senare leveransresultat. Sektorns arbetsflödesval här är redaktionella rekommendationer; juridisk räckvidd, faktorlämplighet och lokal auktorisation behöver en egen ansvarig granskning.