En skik MAIL FRA domæne kan lade en tjeneste godkende en konvolutidentitet relateret til dit synlige Fra-domæne. Det nyttige resultat er en fungerende og tilpasset poststi, ikke blot en grøn DNS indikator i udbyderens konsol. Bekræft de genererede DNS indstillinger, faktiske SMTP identitet, SPF resultat og DMARC justering som separate trin.
Vælg domænet bevidst
Opgørelse af forfatterdomænerne brugt i synlige fra-adresser og udbyderens understøttede tilpassede konvolutdesign. Et bounce-underdomæne kan være praktisk praktisk, men streng SPF justering kræver et nøjagtigt match med Author Domain. Under afslappet justering bestemmes organisations-domæneforholdet under RFC 9989 §4.10.2 kan tillade et underdomæne at justere. Udled ikke justering ud fra et mærkenavn eller feltet Svar til. RFC 9989 §3.2.4, RFC 9989 §4.4.
Brug de aktuelle kontospecifikke DNS værdier leveret af din tjeneste. En udbyder kan kræve yderligere registreringer til afvisningsbehandling samt SPF ; disse krav er servicespecifikke. Denne vejledning giver bevidst intet universelt MX værtsnavn, inkluderer mål eller kliksekvens. Bekræft, at domænet er dedikeret, eller at ændringen ikke vil være i konflikt med et eksisterende mailflow.
Udgiv uden at miste politikintegritet
Vedligehold et på det nøjagtige SPF identitetsdomæne SPF rekord i stedet for at tilføje en anden v=spf1 -post ved siden af en eksisterende politik. Valider de komplette kombinerede krav, når et domæne har flere legitime afsendere. En forældreforsikring dækker ikke automatisk barnet. Undersøg indlejrede afhængigheder og repræsentative evaluerede stier for den DNS-forespørgselsforårsagende termgrænse. RFC 7208 §4.5, RFC 7208 §4.6.4.
Registrer gamle DNS værdier og en sikker tilbagerulningsplan før cutover. Bekræft autoritativ udgivelse og relevante rekursive svar, og aktiver eller bekræft derefter den tilpassede konvolut i tjenesten. En verificeret DNS post alene viser ikke, at meddelelser er begyndt at bruge den.
Bevis forholdet på modtaget post
Illustrerende eksempel, forudsat en gældende DMARC -politik: en meddelelse bruger Fra receipts@example.com og MAIL FRA return.bounce.example.com . Hvis det kuvertdomæne er SPF-autoriseret og deler det gældende organisatorisk domæne example.com , den kan justeres i afslappet tilstand. Det passer ikke i streng tilstand, fordi de fulde domænenavne er forskellige. Hvis udbyderen i stedet stille falder tilbage til bounce.provider.example.net , kan rå SPF passere, mens SPF justeringen går tabt.
Send testmeddelelser gennem alle væsentligt adskilte ruter, inklusive failover, hvor det understøttes. Optag faktisk MAIL FRA, tilsluttende IP, betroet modtager SPF resultat, justeret SPF resultat og DKIM signering af domæne. DMARC kan passere med justeret DKIM , selv når konvolutten er ujusteret; rapportere, at ærligt snarere end at hævde, at den brugerdefinerede MAIL FROM fungerede. RFC 9989 §4.4.
Valider den operationelle side
Test den udbyder-understøttede afvisningshåndtering, og kontroller, at den forventede applikation modtager leveringsstatusoplysninger. Hvor dit system afgiver beskeder med en nul omvendt sti, bruger SPF sin definerede postmaster-plus-HELO-identitetskonstruktion, så test det som et separat tilfælde. Send ikke en loop-genererende afvisningstest i produktion. RFC 7208 §2.4, RFC 7208 §10.1.3.
Fuldfør kun ændringen, når afsendelse, godkendelse, justering og afvisningsbehandling har bevis. Behold udbyderens fallback-adfærd og ejerskab i runbooken, og gentag tests efter routing eller kontoændringer.
Brug en konkret beslutningsoversigt
Brug to hypotetiske acceptrækker: normal rute udsender return.bounce.example.com og SPF -pas; fallback udsender et ikke-relateret udbyderdomæne og SPF pas. Med From= example.com kan den første kun tilpasses under det kvalificerende afslappede forhold, mens det andet ikke gør det. Hvis DKIM leverer et samlet DMARC -pas, skal du stadig markere tilpasset MAIL FRA fallback som ikke opfylder den anmodede identitet. Behold afvisningsbearbejdningsbeviser uafhængigt. Ingen udbyderkonfiguration eller testmail blev udført.