Skilj åt hosting, DNS och utgående e-post
Den här guiden täcker en domän vars e-post faktiskt skickas via xneelos värdbaserade e-posttjänst. En webbplats eller domän som finns där kan istället skicka via en extern brevlåda, redovisningssystem eller marknadsföringstjänst. Spela in brevlådan och SMTP rutten, xneelo-paketet och kontrollpanelen, den auktoritativa namnservrar, och den avsedda From-domänen. Spara befintlig DNS och ett originalmeddelande innan du redigerar något.
xneelos kontrollpanel DKIM artikel anger att nya värdpaket inkluderar DKIM som standard, medan externt värd DNS behöver dess relevanta post läggas till eller ändras hos DNS leverantören. Detta fastställer inte statusen för ett äldre konto, en självhanterad server eller en icke-relaterad SMTP tjänst. Skaffa den aktuella paketspecifika posten och signeringsstatusen istället för att utöka standardanspråket till alla xneelo-produkter. xneelo DKIM.
Granska den befintliga SPF policyn
xneelos SPF artikeln ger ett exempel med användning av a, mx och include:spf.host-h.net, som slutar med en soft-fail-kvalificering. Den instruerar kunder med extern DNS att ändra policyn hos den leverantören och varnar för flera SPF rekord. Behandla hela exemplet som en konfiguration att bedöma, inte ett kommando för att skriva över alla befintliga policyer. xneelo SPF.
Identifiera den faktiska kuvertdomänen som används av ett direkt testmeddelande. Inventera andra system auktoriserade på den domänen innan du slår ihop något. Bevara alla nödvändiga tillstånd och granska om breda a- eller mx-mekanismer hör hemma i din egen policy. Bekräfta syntax och hela uppslagsbudgeten. En policy kan vara syntaktisk närvarande men producera neutral, softfail , fail eller permerror snarare än att passera; likställ inte existens med framgång. SPF protokoll.
Håll inkommande MX routing stabil under en ändring av enbart autentisering. Lägg inte till orelaterade leverantörer bara för att en artikel från tredje part listar dem för ett liknande värdmärke. Namn och historiskt varumärke avgör inte vilken aktuell tjänst som skickar ditt meddelande.
Bekräfta den faktiska DKIM posten och undertecknaren
Hämta den offentliga nyckeln och väljare för paketet och domänen från dess nuvarande konfiguration eller support. På extern DNS , verifiera det exakta ägarens namn och posttyp, var noga med att inte lägga till domänen två gånger. Skapa inte en gissad standardväljare eller kopiera en annan kunds nyckel. Bekräfta det resulterande auktoritativa svaret innan du testar sändningsarbetsflödet.
En korrekt DNS nyckel är nödvändig för verifiering men visar inte att den utgående tjänsten använder den matchande privata nyckeln. Skicka ett kontrollerat meddelande genom den vanliga klienten och inspektera det faktiska DKIM-Signature. Fråga väljaren under dess d=-domän och jämför sedan den betrodda mottagarens valideringsresultat. DKIM.
Jämför direktreklam, webbmail och vidarebefordran
Använd separata bevisrader för banor som kan bete sig annorlunda. Följande är en syntetisk testplan, inte en uppsättning observerade xneelo-leveranser.
- Sökväg: Hosted postbox direktsändning; Bevis: SMTP mål, originalhuvuden och mottagarresultat; Beslut: Upprätta baslinjen för värdpost
- Sökväg: Webbplatsmeddelande; Bevis: Applikationstransport och observerade identiteter; Beslut: Bestäm om xneelo mail eller annan tjänst ska skicka det
- Sökväg: Vidarebefordrat meddelande; Bevis: Post-forward resultat och bevarade signaturer; Beslut: Diagnostisera vidarebefordran separat från originalsändningen
För varje prov, post synlig Från, kuvertdomän, varje d= och s= värde och mottagarens SPF , DKIM och DMARC resultat. För en syntetisk From av user@example.com är en godkänd d=example.com -signatur en exakt inriktning fall. En leverantörsägd signeringsdomän blir inte anpassad bara för att xneelo är värd för webbplatsen. Tillämpa den effektiva anpassningspolicyn på de faktiska identiteterna. DMARC.
Reparera med en paketspecifik plan
Om poster endast är synliga i en icke-auktoritativ panel, publicera dem via den faktiska DNS ägaren. Om DKIM saknas, bekräfta om detta paket och rutten har signering aktiverad istället för att anta att ett nytt paketstandard täcker dem. Om SPF misslyckas, inspektera den utvärderade domänen och tjänsten innan du redigerar den synliga Från-domänen. Om bara vidarebefordran misslyckas, behåll den godkända direktsändningsbaslinjen och undersök reläet separat.
Återställ det tidigare kända och goda DNS värdet om en sammanslagning stör andra avsändare, och upprepa testerna för direktsändning och påverkad tjänst. Koordinera nyckeländringar med leverantören istället för att ta bort en väljare som behövs för meddelanden i kö. Bevara DNS ögonblicksbilder, paketidentitet, testtidsstämplar och mottagna original. Kontrollera igen efter en paketmigrering, DNS flyttning eller SMTP ändring. Detta manuskript använde endast dokumentation och gör inga anspråk på levande hyresgäst eller leveransverifiering.
Bekräfta leverantörsgränsen
SPF artikelns 2019 neutrala policy-historik bevisar inte någon aktuell domäns policy eller godkänt resultat. Dess förenklade leveransbeskrivningar är inte mottagargarantier. Den offentliga DKIM sidan etablerar ett nytt paket som standard men tillhandahåller ingen universell väljare eller aktiveringsprocedur; skaffa de paketspecifika detaljerna och behåll den gränsen istället för att uppfinna panelsteg.
Arbeta igenom ett fiktivt diagnostiskt fall
Endast fiktivt skriftligt fall: XN-01 förutsätter direkt värdpost från help@shop.example har passerat d=shop.example, medan en webbplatsavisering från samma synliga adress använder en extern SMTP tjänst. Dess kuvert och signaturer är okända. E-postägaren behåller den direkta baslinjen och tilldelar webbplatsägaren att verifiera den externa tjänsten. En xneelo DNS nyckel eller ett nytt paket som standard kan inte fastställa den externa ruttens signeringsstatus. Inget konto, DNS , CRM, faktura, kampanj eller leverans testades 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änpublicering p=reject och varningar om 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.