Omfattning och förutsättningar
Den tidigare webbadressen för ZeptoMail-domänverifiering presenterar nu Zoho CPaaS-dokumentation, uppdaterad 22 oktober 2026. Domäninställningen nedan följer den aktuella sidan och dess transaktionella e-postomfång. Bekräfta produktetiketten och kontorutten hos din hyresgäst istället för att anta att en historisk skärmdump fortfarande matchar. Sidan utesluter uttryckligen e-post med reklam i massmedia; en marknadsföringskampanj hör till en stödd marknadsföringstjänst.
Konfigurera den dokumenterade rutten
- Steg 1. I Domäner, välj Lägg till domän och ange den exakta domänen. Associera lämplig agent eller agenter. Registrera vilken applikation som använder varje agent så att testet täcker produktionsvägen.
- Steg 2. Välj den overifierade domänen och hämta den genererade DKIM TXT och CNAME värd/värdepar. Använd DNS-leverantören väljare eller Annat för att förstå det förväntade värdformatet.
- Steg 3. Publicera båda genererade posterna på den auktoritativa DNS tjänsten. DKIM posten innehåller den publika nyckeln; CNAME upprättar avvisningen eller Return-Path underdomän. Ersätt inte en godtycklig MX post eller en gissning SPF omfatta.
- Steg 4. Gå tillbaka till produkten och välj Verifiera. Dess nuvarande dokumentation rekommenderar DKIM plus returvägen CNAME och anger att en separat SPF rekord krävs inte för detta verifieringsflöde. Befintlig icke-relaterad SPF policy måste förbli intakt.
- Steg 5. Om verifiering väntar, jämför den aktiva namnservrar och exakta register. Det dokumenterade uppdateringsfönstret är 24–48 timmar; använd Check DKIM och Check CNAME i dess verifieringsverktyg för att undersöka snarare än att upprepade gånger återskapa nycklar.
- Steg 6. Skicka en representant transaktionsmeddelande via den tilldelade agenten. Spela in både DKIM och SPF identiteten som valts av den genererade Return-Path .
- Steg 7. Spara uppgifterna efter lanseringen. Tjänsten kontrollerar dem kontinuerligt och kan avbryta sändningen om nödvändiga uppgifter saknas efter kontots angivna deadline.
Produktspecifika risker
En ny DKIM väljare måste verifieras före användning. Sidan beskriver hur man lägger till upp till två nya nycklar efter att den befintliga nyckeln har verifierats; använda kontots rotationsflöde, inte en omedelbar radering av den gamla DNS nyckeln. Om en domän stängs av efter DNS ändringar, återställ de saknade genererade posterna och verifiera igen. Se till att sökvägen för avvisade meddelanden fungerar: enbart ett DKIM pass bevisar inte att avvisningsbearbetningen har bevarats.
Bevisa rutten i den mottagande änden
Använd en godkänd extern brevlåda och spara hela råmeddelandet med dess tidsstämpel och meddelandeidentifierare. Inget levande hyresgästtest görs anspråk på i denna guide. Följande är ett godkännande arbetsblad att fylla i under implementeringen, inte ett rekord av observerade resultat.
- Bevisfält: Synlig från; Vad som ska registreras: Faktisk adress och domän; Acceptansfråga: Är detta den avsedda avsändarens identitet?
- Bevisfält: Kuvert; Vad som ska spelas in: Return-Path och mottagarrapporterad SPF domän; Acceptansfråga: Vilken domän autentiserade SPF egentligen?
- Bevisfält: SPF ; Vad som ska spelas in: Resultat av betrodd mottagare och utvärderad identitet; Acceptansfråga: Gick det igenom och stämmer den identiteten överens?
- Bevisfält: DKIM ; Vad som ska spelas in: Varje d= domän, s= väljare och mottagarresultat; Godkännandefråga: Stämmer minst en godkänd signatur?
- Bevisfält: DMARC; Vad som ska spelas in: Mottagarens resultat och tillämplig policy; Acceptansfråga: Finns det en anpassad passeringsväg?
- Bevisfält: Rutt; Vad som ska registreras: Produkt, konto och meddelandetyp; Acceptansfråga: Använde testet produktionsvägen?
DMARC behöver minst en anpassad, passerande SPF eller DKIM sökväg. En passerande signatur från en icke-relaterad tjänstedomän räcker inte. Sträng inriktning kräver exakt domänlikhet; avslappnad anpassning använder den tillämpliga organisation-domän-relationen. Kontrollera domänens faktiska anpassningsinställningar innan du förklarar framgång. En underdomän är inte en automatisk strikt matchning. SPF använder SMTP identiteten, inte visningsnamnet eller Reply-To. Rådfråga justering ordlista vid protokollföring av beslutet.
Använda Authentication-Results från det mottagande systemet du litar på, inte en rubrik som tillhandahålls av en godtycklig avsändare. Fånga alla signaturer istället för att sluta vid det första misslyckandet. För vidarebefordrad e-post, jämför ett direkttest med en vidarebefordrad kopia: vidarebefordran kan ändra SPF utvärderingen eller ändra signerat innehåll. Diagnostisera inte dessa effekter genom att lägga till speditörens adress till din leverantörsbehörighet.
Diagnostisera fel utan att utöka åtkomsten
Jämför auktoritativ DNS med de exakt konfigurerade postnamnen först, kontrollera sedan rekursiv synlighet och tjänstevalidering. Ett felaktigt namn, trunkerad nyckel eller konflikt CNAME åtgärdas inte genom att vänta på cacher. Behåll endast en SPF policy hos en ägare och kontrollera gränsen för tio DNS-uppslagsperioder för utvärderade inkluderar och omdirigeringar innan du slår samman en annan avsändare. DKIM väljare tillhör individuella signeringskonfigurationer; skriv inte över ett annat programs post för att tvinga fram ett valideringsresultat.
Om autentiseringen godkänns men leveransen är dålig, inspektera mottagarens svar, rykte, innehåll och sändningsbehörigheter separat. DMARC pass lovar inte acceptans eller placering i inkorgen. Om ingen av vägarna är i linje, stoppa expansionen och korrigera den faktiska avsändarkonfigurationen. Försvaga inte hela domänens DMARC policy för att dölja ett enskilt produktfel.
Överlämning och återhämtning
Spara den godkända DNS differensen, offentliga uppslagningsresultat, tjänststatus och redigerat kalkylblad för mottagna meddelanden med en namngiven ägare. Håll inloggningsuppgifter och privata nycklar borta från biljetter. Vid fel, pausa det berörda sändningsjobbet eller använd en tidigare testad rutt under tjänsteägarens kontroll. Återställ endast de ändrade poster som hör till denna integration; behålla offentliga nycklar som behövs för meddelanden under flygning. Testa om efter återställning, nyckelrotation, domänmigrering eller en förändring av utgående relä. Stäng ändringen endast när produktägaren och e-postadministratören kan förklara den observerade identitetskedjan.
Bekräfta leverantörsgränsen
Den aktuella sidan begränsar funktionen dela post till postmästare och ingenjörsroller och listar ett kontotak på 100 domäner. Dess valfria DNS flöde med ett klick är ett separat auktoriseringsval, inte ett krav för manuell installation. Läs själva varningsdeadline snarare än att uppfinna en universell frist. En verifierad befintlig nyckel krävs innan du lägger till de dokumenterade ytterligare nycklarna.
Arbeta igenom ett fiktivt diagnostiskt fall
Endast fiktivt skrivet fall: ZP-01 antar att From alerts@shop.example har passerat d=shop.example på en Agent, men en andra applikation använder en Agent vars domänassociation är obekräftad. Inga andra applikationskuvert eller signaturresultat är tillgängliga. Applikationsägaren måste verifiera den föreningen och endast skicka ett godkänt transaktionstest. Den första agentens resultat bevisar inte den andra vägen eller marknadsföringsberättigande. Ingen hyresgäst, DNS , serverkommando eller meddelande utövades för detta fall.
Separera ett passerande meddelande från verkställighetsberedskap
RFC 9989 Avsnitt 7.4 kräver giltig DKIM för en domän som publicerar p=reject och varnar för interoperabilitet med indirekt e-post. Ett enda anpassat SPF resultat motiverar inte i sig en utrullning av avvisningspolicy. Granska alla legitima rutter och policyägande separat från denna leverantörskonfiguration.