En failover-rute kan bevare meddelelseslevering, mens den ændrer identiteten SPF autentificerer. Test af kun, at backup-IP'en er autoriseret, går glip af en vigtig fejl: SPF kan passere for et udbyderejet konvolutdomæne, der ikke stemmer overens med det synlige From-domæne. Et elastisk design skal specificere både rutetilgængelighed og autentificeringsresultater.
Definer identitetskontrakten
For de primære stier og backupstier skal du registrere de afsendende IP-puljer, MAIL FRA domæne, HELO adfærd, synlig Fra domæne og DKIM signering af domæne. Inkluder, hvad der sker, når tilpasset domæne- DNS ikke er tilgængelig, eller en udbyder falder tilbage til sit eget domæne. Få disse detaljer fra den faktiske tjenestekonfiguration og den aktuelle udbyderdokumentation i stedet for at antage, at begge stier har identiske standardindstillinger.
SPF evaluerer SMTP identiteten, mens DMARC sammenligner det autentificerede SPF domæne med Author Domain i From. Streng justering kræver et nøjagtigt domænematch under RFC 9989 §3.2.10.2. Afslappet justering følger organisationsdomæneopdagelse under RFC 9989 §4.10.2. Et delt suffiks gættet fra de sidste to etiketter er ikke en pålidelig implementering til generelle formål. RFC 7208 §2.3, RFC 7208 §2.4; RFC 9989 §3.2.4, RFC 9989 §4.4.
Test en switch som en komplet transaktion
Brug en sikker testmeddelelse gennem den primære rute, og gentag den gennem failover-ruten. Gem afsendertransaktionen og betroede modtagergodkendelsesresultater. Registrer rå SPF resultat, autentificeret domæne, SPF justering, hvert DKIM resultat og signeringsdomæne, samlet DMARC resultat, SMTP accept og observeret placering separat. En accepteret meddelelse er ikke bevis for korrekt godkendelse eller indbakkeplacering andre steder.
Illustrativt scenarie, forudsat en gældende DMARC -politik: normal brug af post Fra billing@example.com og MAIL FRA bounce.example.com . Sikkerhedskopien bruger bounce.vendor.example.net . Forudsat at example.com er det relevante organisatorisk domæne, den normale SPF identitet justeres i afslappet tilstand; backup-identiteten gør det ikke. Begge kan bestå SPF . Hvis sikkerhedskopien også producerer en aflevering DKIM signatur med d=example.com, har DMARC stadig en tilpasset godkendelsessti. Uden den sti kan failover introducere DMARC fejl.
Inkluder de ekstraordinære stier
Test tvungen failover, gendannelse til primær, forsinkede genforsøg og leveringsstatusmail, hvor dit system stammer fra. For en tom omvendt sti konstruerer SPF MAIL FROM-identiteten ved hjælp af postmaster og HELO domænet. Et selvstændigt HELO pass på almindelig ikke-null MAIL FROM-trafik er ikke en erstatning for den SPF identitet, som DMARC bruger. RFC 9989 §3.2.4.
Hold testmatrixen lille nok til at gentage, men bred nok til at inkludere hver enkelt konfiguration. Hvis udbyderen ikke kan bevare en tilpasset tilpasset kuvert, skal du beslutte, om aligned DKIM leverer den påkrævede modstandskraft, og om separate modtagerkrav er opfyldt. Undlad at svække justeringen eller tilføje ikke-relaterede domæner til SPF som erstatning for forståelsen af designet.
Indstil en sikker genopretningstilstand
Dokumenter, hvilken godkendelsesfejl, der blokerer cutover, og hvem der kan godkende en undtagelse. Gendan primær routing, når den er sund, og ændringen er sikker, og bevarer logfiler fra begge retninger. Luk kun øvelsen, når de forventede identiteter matcher de modtagne beviser, og genforsøgs adfærd er forstået. Resultatet er en testet reservekontrakt, ikke en påstand om, at alle fremtidige modtagere vil acceptere post.
Brug en konkret beslutningsoversigt
Optag primære, backup- og gendannede stier som separate rækker: forbindende IP, MAIL FRA/ HELO kontekst, SPF identitet/-resultat, alignment-tilstand/-resultat, hver DKIM identitet/-resultat og overordnet DMARC . For From= example.com og MAIL FROM= bounce.example.com mislykkes streng SPF justering, selvom SPF består; en verificeret d=example.com -signatur kan stadig levere DMARC -pas under en gældende politik. Dette er et hypotetisk forventet resultat, ikke en udført failover.