Fastslå hvilket sted og hvilket varsel som må testes
En manglende bestillings-e-post kan begynne med en dagbokinnstilling, en feil avsenderadresse eller en mottakeravgjørelse. Behandle disse som forskjellige undersøkelser. Registrer spillested, område, varslingstype, tiltenkt fra-adresse og tidspunktet for den berørte bestillingen før du endrer autentiseringsposter. For en restaurantgruppe, oppretthold separate bevis for hvert sted i stedet for å anta at et sentralt domene gir hver dagbok samme konfigurasjon.
ResDiarys januar 2026 SPF veiledning sier at e-posten bruker SendGrid og identifiserer spf.resdiary.com som den publiserte sendeautorisasjonen. Det er ResDiarys støttede instruksjon, ikke en grunn til å opprette din egen SendGrid konto eller låne DNS verdier fra en annen SendGrid kunde. ResDiary SPF -konfigurasjon
De gjeldende offentlige kildene som er gjennomgått her, etablerer ikke en ResDiary-spesifikk tilpasset DKIM-klargjøringsprosedyre eller en støttet tilpasset konfigurasjon. Dette er et kildeomfang, ikke et bevis på at noen av mulighetene er fraværende. Før du beskriver en komplett DMARC implementering som klar, innhent leverandørbekreftelse for det eksakte stedet og inspiser en mottatt melding. Ikke oppfinn velgere, ta opp mål eller en skjult autentiseringsmeny.
Sørg for at en melding faktisk blir generert
ResDiary dokumenterer varslingskontroller på områdenivå under Innstillinger > Områder og identifiserer separate varslingsinnstillinger for påminnelser og meldinger etter middagen. Instruksjonene for avsenderadressen bruker Innstillinger > Lokale- og Dish Cult Listing Details, under arenaens kontaktinformasjon. Sjekk den tiltenkte innstillingen uten å behandle kontopåloggingsdetaljer som e-postavsenderens identitet. Feilsøking av ResDiary-varsling
Få spillestedseieren til å godkjenne prøveopplegget. En bestilling kan påvirke kapasitet, personalforberedelse og automatisert oppfølging, så bruk en bestemt testprosedyre og ryd opp i reservasjonen gjennom den normale operasjonelle prosessen. Bruk en autorisert testpostkasse og harmløse detaljer. Unngå å bruke en ekte middagsbestilling som et autentiseringseksperiment eller å utløse en uventet påminnelse til en kunde.
Kjør det spesifikke varselet som undersøkes. Sjekk om det var aktivert, om bestillingen oppfylte betingelsene, og om destinasjonsadressen var riktig. Registrer sendetidspunkt og eventuell tilgjengelig melding eller hendelsesreferanse. Hvis det ikke ble generert noen melding, må du løse den tilstanden før du tolker en DNS redigering som en rettelse. Hvis meldingen ble generert, separat avvisning, karantene, plassering av søppelpostmappe og ikke-kvittering uten tilgjengelig forklaring.
Velg en avsenderadresse på et domene lokalet kontrollerer og en svardestinasjon ansatte faktisk overvåker. ResDiary anbefaler et privat domene i stedet for å bruke en personlig postboksleverandøradresse for sine automatiske meldinger. Å bytte til en eid adresse er bare begynnelsen: det krever fortsatt riktig autentisering og en sannmeldingssjekk. Feilsøking av ResDiary-varsling
Forbered SPF -endringen mot den faktiske ruten
Leverandørens dokumenterte mekanisme er include:spf.resdiary.com. Veiledningen forklarer hvordan du slår dette inn i en eksisterende policy. Ikke skift ut lokalets komplette SPF rekord med et eksempel med én leverandør, fordi e-post til ansatte, nettsideskjemaer og andre legitime søknader allerede kan avhenge av det. ResDiary SPF -konfigurasjon
Be DNS administratoren om å fange opp gjeldende policy og identifisere konvoluttdomenet som evalueres. Publiser hos den tiltenkte eieren ved å bruke DNS vertens nåværende kontroller. Bevar eksisterende autoriserte avsendere og evaluer det resulterende oppslagsbudsjettet. SPF er ikke en sjekk av visningsnavnet eller svar-til-adressen; flere gjeldende SPF -poster hos én eier er også en feil snarere enn en måte å legge til tjenester på. SPF RFC 7208
Lagre de foreslåtte og tidligere verdiene i endringsbilletten. Registrer det autoritative navneservere, publiseringstid, TTL og uavhengig oppslagstid. Bekreft at DNS editoren ikke har lagt til domenet to ganger. Ikke kopier mottaksposter eller ikke-relaterte SendGrid merkeregistreringer inn i denne endringen. Ingen av disse handlingene er etablert av ResDiary SPF artikkelen.
Hvis en mottaker viser SPF pass for et tjenesteeid konvoluttdomene, kan det hende at det ikke endres dette resultatet ved å legge til en annen autorisasjon på det synlige Fra-domenet. Bestem først hvilket domene mottakeren evaluerte. Denne forskjellen forhindrer gjentatte DNS redigeringer som lar den faktiske meldingsidentiteten være uendret. Be ResDiary om å avklare den støttede konvoluttatferden i stedet for å gjette fra en IP-adresse alene.
Lukk DKIM og justeringsbevisgapet
Send en godkjent bestillingsbekreftelse til en postboks der fullstendige overskrifter kan inspiseres. Bevar mottakerens pålitelige Authentication-Results, synlig fra domene, konvoluttdomene og hver DKIM signatur'sd= og s= verdier. Disse signaturfeltene identifiserer signeringsdomenet og velger. Oppbevar det originale beviset sikkert; bruke en redigert kopi i rutinemessige gjennomgangsnotater. DKIM RFC 6376
Sammenlign de passerende domenene med det synlige Fra-domenet under det aktuelle justering modus. DMARC krever minst én passerende justert bane; to beståtte resultater for urelaterte domener gir det ikke. Bruk RFC 9989 for protokollvurderingen, i stedet for å utlede suksess fra leverandørens navn i et dashbord. DMARC RFC 9989
Hvis ingen av banene stemmer overens, be leverandøren om å bekrefte om kundedomenesignering støttes for denne spillestedets rute. Be om nøyaktige DNS poster, aktiveringstrinn og forventet signeringsidentitet hvis det er det. Hvis ikke, spør hvilken støttet avsenderordning som bevarer levering og representerer stedet nøyaktig. Registrer svaret uten å generalisere det til andre ResDiary-produkter eller fremtidige versjoner.
Gjenta sjekken for påminnelser og meldinger etter middagen som lokalet bruker. En bekreftelsestest kan ikke lukke en uprøvd påminnelsesrute. Ikke lov innboksplassering etter at autentisering lykkes, og ikke reduser organisasjonens DMARC håndhevelse bare for å omgå en uløst spillestedkonfigurasjon.
Fiktiv diagnose: SPF -posten var ikke det første problemet
På et fiktivt sted rapporterer en leder at bekreftelser fungerer, men at påminnelser aldri kommer. Det første forslaget er å legge til en annen SPF post. En kontrollert gjennomgang finner i stedet påminnelser deaktivert for den testede arbeidsflyten. Etter at eieren har aktivert den tiltenkte oppførselen, produserer en ny test en melding. Overskriftene kan deretter vurderes for autentisering. Dette scenariet er oppfunnet og er ikke et ResDiary-kundefunn.
Anta at meldingen også har en bestått signatur under et ikke-relatert leverandørdomene, uten justert SPF bane. Det er nå to distinkte funn: arbeidsflytinnstillingen forklarer hvorfor den tidligere meldingen var fraværende, mens den mottatte meldingen identifiserer et eget justeringsspørsmål. Etterforskeren beholder begge funnene og ber om støttede instruksjoner for domeneautentisering i stedet for å erklære at påminnelsesbryteren er en fullstendig sikkerhetsfiks.
Regneark for implementering av lokale
- Operativt omfang: sted, område, varslingstype, bedriftseier og godkjent testprosedyre.
- Avsenderkonfigurasjon: synlig adresse, svarhåndtering, domeneeier og dato for innstillingskontrollen.
- Generasjonsbevis: arbeidsflyt aktivert, testbestillingsreferanse, sendetidspunkt, destinasjon og observert resultat.
- DNS endring: eksisterende SPF , foreslått sammenslått policy, autoritativt oppslag, TTL og tilbakeføringsverdi.
- Meldingsbevis: Fra domene, konvoluttdomene, alt DKIM d=/s= pairs, trusted results, and alignment conclusion.
- Leverandøravklaring: tilpasset DKIM og konvoluttstøtte, kontospesifikke poster, aktiveringsbevis og uløste spørsmål.
- Lukking: bekreftelses- og påminnelsesprøver, bestillingsopprydding, anmelder og utløser for neste gjennomgang.
Ta vare på arbeidsarket med lokalets endringshistorikk. Gå tilbake til det når avsenderdomenet, gruppeeierskap, bestillingsarbeidsflyt eller leverandørinstruksjoner endres. Trekk tilbake foreldet autorisasjon først etter å ha sjekket at et annet aktivt spillested ikke fortsatt er avhengig av det.
Utgivelsesstatus
Manuskriptet har førstepartsbevis for spillestedskontroller og SPF veiledning, men ikke en komplett prosedyre for egendefinert domenesignering. Leietakerinspeksjon, live DNS , validering av mottatte meldinger, visuell gjennomgang, menneskelig SMB-godkjenning og publisering gjenstår. Det produktspesifikke signeringsventet må løses eller beholdes eksplisitt i det endelige omfanget.
Behold håndhevingsvedtaket mens SPF slås sammen
Bruk leverandørmekanismen innenfor den enkelt gjeldende TXT policyen etter å ha gjennomgått den faktiske SMTP identiteten. Eksemplet på softfail avslutningen er ikke tillatelse til å svekke en eksisterende policy. Hold DNS eierens avgjørelse og det uløste tilpassede signeringsspørsmålet atskilt fra om et bestillingsvarsling var aktivert.
Separat meldingsgodkjenning fra utrulling av retningslinjer
Et bestått justert SPF resultat kan tilfredsstille en meldingsevaluering, men rettferdiggjør ikke alene å flytte et helt domene for å avvise. RFC 9989 Seksjon 7.4 krever gyldig DKIM for domenepublisering p=reject og advarer om interoperabilitet med indirekte e-post. Inventar alle legitime avsendere og indirekte ruter før policyeieren godkjenner håndhevelse. Ingen DNS endring, leietakeroperasjon eller test av mottatte meldinger ble utført for denne artikkelen.