Fortsätt att skicka och biljettintag separat
En supportadress har två uppgifter: acceptera en kunds begäran och identifiera svaret. Att bevisa det ena bevisar inte det andra. Starta denna förändring med Gorelo-administratören, auktoritativ DNS ägare och nuvarande postlådeadministratör tillsammans. Anteckna den önskade allmänna adressen, dess befintliga mottagningsrutt och biljettgrupperna som ska hantera den. Behåll en kopia av befintliga DNS svar och inställningar för vidarebefordran innan du gör en ändring.
Gorelo dokumenterar en Mailgun-baserad leveranstjänst med hjälp av en dedikerad sändande underdomän medan kunder fortsätter att interagera med den offentliga adressen. Behandla inte underdomänen som en begäran om att ersätta din organisations normala postlådetjänst. De exakta uppgifterna måste komma från kontot, inte ett generiskt Mailgun exempel. Gorelo leveransdesign
Konfigurera domänen och adresserna
I Inställningar > E-post > Inställningar, välj Lägg till domän, ange den avsedda domänen och publicera de visade posterna på din DNS värd. Bevara goreloetiketten i de genererade ägarna och använd Verify. Om du lägger till en domän skapas standardhjälp@ biljetter och konton@ faktureringsadresser; den senare är endast utgående. Redigera biljettadressen för att granska dess Från/Svara-till-identitet och gruppbegränsningar. Anpassade domäner
Innan du publicerar, expandera varje relativ DNS namn till dess fullständiga ägarnamn på ett kalkylblad. Vissa DNS gränssnitt lägger till zonen automatiskt. Ett korrekt kopierat värde hos fel ägare är fortfarande en misslyckad installation. Om en ägare redan har data, fastställa dess syfte innan du ersätter den. Bevara en singel SPF policy hos varje tillämplig ägare och kontrollera dess totala DNS uppslagskostnad, inklusive kapslade inkluderar.
För biljettintag, använd kontots vidarebefordrandestination för motsvarande befintliga brevlåda. Begränsa eventuella undantag för extern vidarebefordran till den godkända postlådan i stället för att öppna vidarebefordran globalt. En ruttändring kan exponera inkommande biljettinnehåll, så skaffa normalt internt godkännande innan du aktiverar det. Skapa inte en loop mellan den ursprungliga brevlådan och destinationen.
Kör ett acceptanstest med tre vägar
Ursprunglig testplan: skicka först en ofarlig begäran direkt till den konfigurerade destinationen för vidarebefordran. Skicka sedan en till till den offentliga supportadressen. Bekräfta att båda når den avsedda kön och att testet för publika adresser inte skapar dubbletter eller loopingbiljetter. Slutligen, svara från ärendet och skicka ett kontrollerat faktureringsexempel om fakturering är i omfattning. Använd syntetiskt innehåll och kontrollerade mottagare, aldrig en riktig obetald faktura bara för att testa leveransen.
För varje utgående meddelande, behåll den betrodda mottagarens autentiseringsresultat, synligt från domän, SMTP kuvertsändare, DKIM signeringsdomän och väljare. Kontrollera att en passerande SPF eller DKIM identitet överensstämmer med From under det tillämpliga DMARC inriktning läge. En framgångsrik biljettskapande och Gorelos DNS verifiering är användbara observationer, men ingen av dem ersätter denna kontroll av mottagna meddelanden.
Illustrativt misslyckande: testet för direkt vidarebefordran av destination fungerar, men det gör inte den offentliga adressen. Det pekar nästa undersökning mot den befintliga postlådans vidarebefordranregel eller begränsningar, inte en omedelbar DKIM-nyckelersättning. Om intag fungerar men svar misslyckas med anpassning, undersök den utgående identiteten istället.
Återställ utan att störa annan e-post
Pausa den berörda adressen eller arbetsflödet innan du ändrar flera lager samtidigt. Återställ endast den senaste godkända vidarebefordran eller DNS ändringen som orsakade felet och kontrollera att den ursprungliga brevlådan fortfarande är tillgänglig. Behåll gamla giltiga signeringsposter tills köade meddelanden och cachning har beaktats. Upprepa trevägstestet efter en DNS migrering, postlådeflyttning eller byte av avsändaradress.
Detta är en dokumentationsbaserad guide som granskades den 8 november 2026. Inget Gorelo-konto, DNS zon, biljett eller mottaget meddelande testades; acceptplanen och exemplet på misslyckande är original belysande vägledning.
Tilldela fel till rätt e-postsökväg
Skriftligt fall GO-01 stipulerar att en ofarlig förfrågan adresserad direkt till den konfigurerade Gorelo-vidarebefordrandestinationen når den avsedda gruppen, men samma typ av begäran som skickas till help@example.com gör det inte. Ett svar via den direkta sökvägen har From help@example.com och betrodd DKIM pass med d=example.com och s=ticket1; dess SPF resultat är okänt. Det enda svaret har exakt DKIM anpassning, men säger ingenting om det saknade offentliga adressintaget. Den befintliga postlådeadministratören bör inspektera sin godkända regel för vidarebefordran och destination, medan biljettägaren bevarar den fungerande svarsrutten. Byt inte ut DKIM nycklar för att reparera insug utan bevis. Alla identiteter och resultat är undervisningsantaganden; ingen biljett, faktureringsdokument eller meddelande skapades.
Bevara verkställighetsgränsen
RFC 9989 Avsnitt 7.4 kräver giltig DKIM , inte enbart SPF , för domänpublicering p=reject, och varnar för interoperabilitet med indirekt e-post och e-postlistor. Ett enda framgångsrikt test för direktmeddelanden är inte ett bevis på att varje legitim väg är redo för en starkare politik. Behåll befintligt godkänt skydd medan du diagnostiserar det faktiska gapet; varje policyändring behöver ett eget beslut.