Start med videresendelsesruten i stedet for Gmail etiketten
En besked, der ankommer til Gmail efter videresendelse, har en anden leveringshistorik end en besked, der er sendt direkte dertil. Videresendelsestjenesten kan ændre SMTP konvolutten, bevare eller ændre den originale meddelelse og vedhæfte sine egne autentificeringsobservationer. Diagnostiser denne historie, før du beder den oprindelige afsender om at ændre DNS . En vellykket direkte levering etablerer en nyttig sammenligning, men den beviser ikke, at den indirekte rute bevarer den samme godkendelsessti.
Identificer den endelige kontotype og videresendelsesmekanismen. Googles generelle retningslinjer for afsender omhandler eksplicit personlige Gmail konti, mens en organisations Google Workspace routing kan involvere yderligere administrative valg. Registrer, om formidleren er en aliastjeneste, postkasseregel, gateway eller postsystem. Anvend ikke en regel for ét produkt eller en rute, blot fordi begge destinationer viser en velkendt Gmail grænseflade.
Læs udbydervejledningen inden for dens omfang
Googles nuværende videresendelsesvejledning anbefaler at bruge videresendelsesdomænet i konvolutafsender, der godkender videresendelsesinfrastrukturen i det pågældende domæne SPF politik, begrænser videresendelse af spam og undgår ændringer, der forstyrrer DKIM. Det siger også, at Gmail udfører sin egen autentificeringskontrol. Disse anbefalinger lover ikke indbakkelevering eller gør en tidligere servers pas autoritativ hos Gmail .
Hold denne vejledning adskilt fra personlige Gmail afsenderkrav. Kravene varierer med afsendelsesvolumen og meddelelsesformål. Denne artikel er ikke en erstatning for at bestemme, hvilke krav der gælder for den faktiske afsender. Det foreslår heller ikke at ændre en brugers kontoindstillinger, aktivere videresendelse eller tilføjelse af en adresse til enhver betroet liste uden den relevante ejerbeslutning.
Følg konvolutten og den synlige identitet hver for sig
Ved den endelige SMTP forbindelse evaluerer SPF den relevante identitet ved hjælp af den forbindende servers adresse. En speditør er en ny forbindelsesserver, hvorfor bevarelse af den originale konvolut kan ændre SPF resultatet. RFC 7208 afsnit 10.3 forklarer mediatorproblemet. Meddelelsens synlige Fra-adresse er en separat identitet og kan forblive uændret hele vejen igennem.
En kuvert, der er omskrevet under speditørens domæne, kan opnå SPF autorisation for det pågældende domæne. Det bliver ikke, blot ved at indeholde den oprindelige adresse i en lokal del, på linje med det oprindelige forfatterdomæne. Under RFC 9989 afsnit 4.4, DMARC kræver en passerende autentificeret identifikator med den påkrævede domænerelation. Registrer de faktiske domæner og justering tilstand i stedet for at behandle et SPF beløb som hele svaret.
Til undersøgelse skal du anmode om den originale kuvertidentitet fra betroede leveringsposter, hvor de er tilgængelige. En finale Return-Path kan være nyttigt, men beskriver ikke uafhængigt hver tidligere SMTP transaktion. Markér utilgængelige tidligere værdier som ukendte i stedet for at rekonstruere dem ud fra et vist navn eller citeret meddelelsestekst.
Bevar den justerede signatur, når videresendelse tillader det
DKIM kan overleve videresendelse, når det dækkede indhold stadig verificeres. Hvorvidt en ændring gør en signatur ugyldig afhænger af de signerede overskriftsfelter, kropsdækning, kanonisering og de faktiske bytes ved verifikation. RFC 6376 afsnit 3.4 og 5.4 give disse regler. Påstå ikke, at hver tilføjet header bryder DKIM , eller at hver meddelelse med en uændret synlig krop skal verificeres.
Undersøg den originale signaturs underskriftsdomæne og vælger, dens angivne signerede overskrifter og modtagerens bekræftelsesresultat. Et emnepræfiks, sidefod, MIME konvertering eller vedhæftningstransformation kan påvirke dækket materiale. Sammenlign meddelelserne før og efter den formodede transformation. Tilføjelse af en ny signatur fra et ikke-relateret videresendelsesdomæne reparerer ikke den originale signatur eller etablerer justering for den oprindelige forfatter.
En modtager kan overveje ARC bevis under sin egen politik. RFC 8617 beskriver den eksperimentelle mekanisme; en gyldig kæde er ikke et automatisk DMARC pas eller en leveringsgaranti. Fra denne anmeldelse er forslag om omklassificering af ARC fortsat arbejde i gang. Gør ikke et forslagsudkast til en påstand om, hvad Gmail har aktiveret eller deaktiveret.
Fiktiv sammenligning af direkte og fremsendte kvitteringer
Forestil dig den fiktive afsender. Eksempelbilletter sender en kvittering direkte til en kontrolleret Gmail postkasse og en anden tilsvarende kvittering via et alias på example.net . Det tilsigtede forfatterdomæne er example.com . I dette opfundne scenarie har den direkte kopi en gyldig justeret signatur, mens den videresendte kopi beholder denne signatur, men får en sidefod, der ændrer dens dækkede krop.
Antag, at den endelige konvolut omskrives under example.net , og SPF godkender denne identitet. Det hypotetiske pass stemmer ikke overens med example.com . Granskeren vil derefter undersøge, om en anden gyldig tilpasset signatur overlever, og hvad den endelige modtager rapporterer. Eksemplet hævder ikke en Gmail dom, en ARC tilsidesættelse eller en observeret afvisning; ingen beskeder blev sendt eller indsamlet.
Det foreslåede reparationsspørgsmål er snævert: Kan den autoriserede speditør bevare det relevante meddelelsesmateriale og samtidig opfylde servicens behov? Det er mere nyttigt end at føje videresenderen til den oprindelige afsenderes politik uden at forstå identiteten og autorisationskonsekvenserne.
Behold en bevispakke, før du erklærer succes
Brug godkendte testkonti og godkendte, ikke-følsomme beskeder. Registrer direkte og indirekte leveringstider, ruteidentifikatorer, kuvertobservationer, fulde signaturer og pålidelige endelige godkendelsesresultater. Registrer den faktiske disposition separat: SMTP accept, postkasselevering, spamplacering og brugersynlighed er ikke udskiftelige resultater. Hvis en mellemkopi ikke er tilgængelig, skal du angive, hvilken transformation der ikke kan lokaliseres.
Vurder en foreslået ændring i forhold til repræsentative formater og ruter, ikke kun én almindelig tekstmeddelelse. Bevar den tidligere konfiguration og definer, hvad der ville udløse gendannelse. Den nøjagtige katalogport forbliver åben: direkte og indirekte leveringsprøver med rute, konvolut, signaturer og pålidelige resultater sammenlignet. Dette manuskript indeholder en fiktiv øvelse og aktuel dokumentarvejledning, ikke disse originale eksempler eller en bekræftet Gmail udrulning.