USAePay-merkede kvitteringer krever et domene du kontrollerer. Gatewayens e-post fra-valg endrer hva mottakerne ser, slik at beholdningskvitteringer, fakturaer og eventuell partner-post flyter separat. Ikke bruk en kundes reelle transaksjon som en autentiseringstest eller legg inn betalingsdetaljer i diagnostiske tjenester.
Konfigurer tilpasset domenegodkjenning
Leverandørdokumentene include:spf.usaepay.com for SPF. Legg den til den eksisterende gjeldende SPF policyen, før terminalens all-mekanisme, i stedet for å publisere en annen SPF rekord. Den offisielle guiden fraråder å opprettholde en kopiert IP-liste fordi leverandøradressene kan endres.
Til DKIM, lag tre CNAME poster under avsenderdomenet: gps1. _domainkey peker til gps1._default.dkim.safewebservices.com ; gps2 og gps3 følger samme nummererte mønster. Erstatt kun din egen senderdomenedel, ikke leverandørens mål. Guiden sier at gps2 og gps3 offentlige nøkler er med vilje tomme reserver for rotasjon. Publiser delegasjonene deres selv om en nøkkelvalidator flagger de tomme målene; aksept av dagens melding avhenger av velger faktisk brukt. USAePay-konfigurasjonsreferanse
Portalen tilbyr SPF og DKIM validering. Bruk den som en konfigurasjonssjekk, og inspiser deretter en levert testkvittering. Dokumentasjonen sier at uautentisert tilpasset merkevarebygging kan falle tilbake til safewebservices.com . Registrer den observerte Fra-adressen i stedet for å anta at en levert kvittering fortsatt bærer merkevaren din. Hvis du ikke kan kontrollere det ønskede domenet, avtal en godkjent avsenderidentitet i stedet for å forfalske en offentlig nettadresse.
Leverandøren krever nå disse autentiseringspostene for alle tilpassede sendedomener, ikke bare massekampanjer. Behandle den offentlige prøve-IP-en brukt i et gammelt valideringseksempel som en diagnostisk illustrasjon, ikke som bevis på gjeldende utgående IP eller konvoluttidentiteten som faktisk sendes ut.
Bekreft DNS og et reelt mottaksresultat
Før du endrer innstillingene for selgerkvittering og fakturaavsender, eksporter de eksisterende DNS verdiene, noter den godkjente diff og navngi tilbakeføringseieren. Bekreft om DNS editoren forventer en relativ etikett eller et fullt kvalifisert navn; dobling av domene-suffikset skaper en rekord som ingen tiltenkt verifikator vil finne. Spør etter det faktiske eiernavnet etter lagring, inkludert eventuelle CNAME mål, i stedet for å stole på redaktørens suksessbanner.
SPF må forbli én policy på det relevante domenet og holde seg innenfor grensene for DNS-spørringsperiode i RFC 7208. Å legge til en inkludering etableres ikke i seg selv justering. Under RFC 9989, DMARC passerer når minst ett vellykket SPF eller DKIM resultat stemmer overens med det synlige Fra-domenet i gjeldende modus. Ikke kreve at begge mekanismene samsvarer som en betingelse pålagt av standarden, og ikke forveksle et leverandørdomenepass med et justert kundedomenepass.
Send en ufarlig testkvittering generert av den faktiske arbeidsflyten til en postkasse du kontrollerer. Lagre mottakssystemets pålitelige autentiseringsresultater, synlige Fra, konvoluttidentitet, DKIM d= og s= verdier, tidsstempel og leverandørstatus. Et DNS oppslag viser bare den tilgjengelige nøkkelen; RFC 6376 verifisering evaluerer også signaturen over den mottatte meldingen. Bruk ikke-sensitivt innhold og unngå å eksponere fullstendige kundemeldinger for offentlige kontrollører.
Bruk en avgrenset beslutning om aksept og tilbakeføring
Kun fiktiv skriftlig diagnostisk sak: UP-01 antar at en ufarlig kvittering var ment å bruke receipts@shop.example , men den synlige fra er noreply@safewebservices.com . SPF og alle DKIM identiteter/-resultater er ukjente. Levering oppfyller ikke kravet til spesialtilpasset merke. Selgeren må sjekke gateway-identiteten og valideringsstatusen, og DNS eieren må sammenligne alle de tre dokumenterte delegeringene før en ny godkjent test. Tomme reservenøkler alene etablerer ikke feil på den aktive velgeren. Ingen konto, DNS , relé eller melding ble testet for dette eksemplet.
Hvis testen mislykkes, separer manglende DNS , feil velger, inaktiv leverandørkonfigurasjon, uventet ruting og meldingsendring før du gjør en ny endring. Test den samme arbeidsflyten på nytt etter hver godkjent korreksjon. Ikke svekk hele domenets DMARC policy for å skjule et enkelt avsenderproblem. Der tilbakerulling er nødvendig, gjenopprett den godkjente tidligere rutingen eller avsenderkonfigurasjonen og beholder nøkkelposter mens signerte meldinger i kø fortsatt trenger dem. Behold testbeviset og uløste unntak med domenebeholdningen. Ingen leietakertilgang, DNS endring eller reell sending ble utført ved utarbeidelsen av denne veiledningen.
Hold en ansvarlig akseptoppføring
Opprett én rad per konto, domene og en vesentlig annen rute. Registrer bedriftseier, DNS eier, endre referanse, tiltenkt Fra, observert Fra, konvoluttdomene og SPF resultat, hver DKIM d= og s= med sitt resultat, gjeldende justeringsmodus, pålitelig mottaker og tidsstempel, leverandøraktiveringsstatus, plasseringsobservasjon, uløst spørsmål og neste handling. Merk manglende verdier som ukjente i stedet for å behandle dem som bestått eller ikke bestått. Eieren godtar kun den tiltenkte ruten og identiteten som støttes av de registrerte bevisene; ellers hold den ruten og følg den godkjente gjenopprettingsplanen.
Skille en bestått melding fra håndhevingsberedskap
RFC 9989 Avsnitt 7.4 krever gyldig DKIM for en domenepublisering p=reject og advarsler om interoperabilitet med indirekte e-post. Et enkelt justert SPF resultat rettferdiggjør ikke i seg selv en utrulling av avvisningspolicy. Gå gjennom alle legitime ruter og policyeierskap separat fra dette leverandøroppsettet.