TLS-RPT anmoder deltagende sendesystemer om at dele samlede SMTP TLS resultater. Dens DNS -post er adskilt fra MTA-STS opdagelse og adskille fra DMARC rapportering. Publicering af en gyldig registrering muliggør en rapporteringsanmodning; det muliggør ikke transporthåndhævelse eller garanterer, at hver afsender vil indsende en rapport.
Vælg en ejet destination
Referencer: RFC 8460 §3, RFC 8460 §5.4.
For example.com , udgiv en TXT ressourcepost på _smtp._tls.example.com . En minimal illustrativ værdi er v=TLSRPTv1; rua=mailto:tls-reports@example.com. Erstat eksempeladressen med en postkasse eller indsamlingstjeneste, som du kontrollerer og er autoriseret til at bruge. Bekræft leveringskapacitet, behandling, opbevaring og hvem der kan få adgang til de resulterende rapporter.
RFC 8460 understøtter mailto- og https-rapport-URI'er. HTTPS-rapportering bruger POST frem for GET, der bruges til at hente en MTA-STS -politik. En TLS-RPT destination er ikke politikværts-URL'en. Brug indsamlerens faktiske understøttede slutpunkt og godkendelsesproces i stedet for at sende rapporter til et generelt websted eller en vilkårlig leverandøradresse.
Offentliggør én relevant post
Referencer: RFC 8460 §3.
Versionsfeltet skal komme først med den nøjagtige TLSRPTv1-værdi, og rua er påkrævet. Flere destinationer er kommaseparerede URI-værdier i den samme post. Tegn med afgrænsningsbetydning inde i en URI har brug for passende kodning. En rapporterende afsender kan kun forsøge et af flere endepunkter; antag ikke, at identiske kopier kommer overalt.
Hvis flere TXT registreringer returneres, poster begynder ikke v=TLSRPTv1; er kasseret. Præcis én relevant registrering skal være tilbage for TLS-RPT opdagelse. Flere strenge inden for en TXT record sammenkædes uden at indsætte mellemrum. To uafhængige TLS-RPT politikker flettes ikke sammen til én liste over destinationer.
Gengiv registreringsgrænsekontrollen
Opret et laboratoriesvar med en v=TLSRPTv1; rua=mailto:tls-reports@example.com og en ikke-relateret bekræftelses TXT værdi. Den påtænkte udvælgelse efterlader én kandidat. Tilføj en anden uafhængig TLSRPTv1-post, og opdagelsesantallet bliver ugyldigt. Det medfølgende offline-armatur blev genkørt til denne gennemgang og udfører denne snævre sag om kandidatudvælgelse; det er ikke en komplet URI-validator, DNS server eller rapporteringsklient.
For det faktiske domæne skal du forespørge den absolutte ejer _smtp._tls.YOURDOMAIN. med type TXT direkte fra hver myndighed og gennem en rekursiv resolver. Bevar TTL'er, fulde optegnelser og eventuelle aliaser. Bekræft derefter opsamleren separat ved hjælp af dens dokumenterede testworkflow. Denne artikel indeholder ingen live DNS udgivelse, rapporttransmission eller bekræftet rapportmodtagelse.
Valider indgående rapporter, før du stoler på dem
Referencer: RFC 8460 §3, RFC 8460 §7.
For rapporter leveret af SMTP kræver RFC 8460 en gyldig DKIM signatur af rapporteringsdomænet og forbyder DKIM l= body-length limitation. Reports lacking the required valid signature must be ignored. The DKIM key should declare the tlsrpt service type; the specification permits a collector to ignore reports lacking that declaration.
Anvend grænser for parserstørrelse, og behold rapportørens identitet og rapporteringsperiode. Undgå at fortolke stilhed som sund transport: trafikmængde, afsendersupport, rapporteringsplaner og opsamlerfejl kan alle påvirke ankomster. Korreler modtagne transportrapporter med den navngivne politik og SMTP rute i stedet for at behandle dem som SPF, DKIM eller DMARC resultater for almindelige beskeder.
Beholdt historiske beviser og resterende omfang
Det følgende beskriver bevarede observationer fra 7. november 2026, ikke et netværkseksperiment genudført for denne anmeldelse. Nyt udførte offline kontroller registreres separat.
Den bevarede historiske pakke indeholder en syntetisk TLS-RPT JSON-rapport, der er knyttet til den faktiske loopback SMTP værtsnavnsfejl. Dens politikdomæne er eksempel.test, dens MX er mx.old.example .test, dens resultattype er certifikat-værts-mismatch, og dens antal af fejlede sessioner er 1. Rapportens periode står i parentes for laboratoriekørsel, og dens oversigt indeholder én fejl og nul vellykkede sessioner for det valgte scenarie. Den matchende SMTP hændelsesregistrering valid=false med værtsnavn-bekræftelsesfejlen. Denne rapport blev genereret lokalt fra den observerede hændelse, ikke modtaget fra en uafhængig afsender og ikke DKIM godkendt. Det var ikke nødvendigt at redigere, fordi alle navne og adresser kun er laboratoriebrugere. Det valgfrie yderligere informationsfelt er udeladt; RFC 8460 definerer dens værdi som en URI, så forklarende herkomst bevares uden for rapporten i stedet for at placeres i det felt. Det demonstrerer rapport-til-problem-kortlægningen, mens faktisk DNS udgivelse, samlerkvittering, signaturvalidering og enhver produktionsspecifik dokumentation forbliver adskilt fra dette uddannelseseksempel.