A DMARC TXT värdet vid fel namn kan vara perfekt skrivet och fortfarande vara irrelevant för meddelandet du undersöker. Innan du ändrar policyn, bevisa att mottagaren kan upptäcka den för domänen som används i den synliga Från-adressen.
En vanlig fälla är att testa företagets webbplatsdomän medan applikationen skickar som en underdomän. En annan är att ange ett fullständigt kvalificerat namn i ett DNS fält som lägger till zonnamnet. Botemedlet är en exakt namnjämförelse, följt av auktoritativa DNS bevis.
Härled uppslagsnamnet från meddelandet
Ta ett mottaget meddelande från det berörda arbetsflödet och identifiera domänen i dess Från-adress. För ett syntetiskt meddelande från notices@billing.example.com , frågar den första policyupptäckten TXT på _dmarc.billing.example.com . Ett rekord på example.com , www.example.com eller den sändande leverantörens orelaterade domän är inte samma uppslag. Om den första sökningen inte hittar någon giltig policy kan upptäckten fortsätta enligt tillämpliga DMARC regler. RFC 9989 , avsnitt 4.10.1.
Byt inte ut Return-Path domän för den synliga Från-domänen. Under RFC 7208 §2.4, kuvertets identitet har betydelse för SPF, men det bestämmer inte denna initiala DMARC policysökning. Behåll de två fälten i separata kolumner medan du diagnostiserar problemet.
Skriv det förväntade absoluta ägarnamnet innan du öppnar DNS redigeraren. Detta lilla steg förhindrar att användargränssnittets etiketter blir källan till sanning.
Hitta den auktoritativa zonen och inmatningsmodellen
Identifiera vilken namnservrar för närvarande betjäna den relevanta zonen. Ett registrarkonto, värdinstrumentpanel eller tidigare använd DNS tjänst kan visa poster som inte längre är auktoritativa. Om billing.example.com delegeras, fastställa vem som kontrollerar den underordnade zonen innan du redigerar föräldern.
Kontrollera redaktörens hjälp för dess namn eller värd-fält. Vissa gränssnitt accepterar relativa namn; vissa accepterar fullständiga namn och normaliserar dem. En zonfilkonvention är inte ett löfte om ett webbformulär. I DNS masterfiler är ett namn som slutar på en punkt absolut, medan ett relativt namn tolkas med det aktuella ursprunget. RFC 1035 , avsnitt 5.1.
Som ett dokumenterat exempel på användargränssnittet säger Cloudflare nuvarande postarbetsflöde att välja posttyp och fylla i de obligatoriska fälten, som varierar från post till post. Använd leverantörens nuvarande registreringsinstruktioner och verifiera det sparade resultatet istället för att projicera en annan leverantörs fältbeteende på det. Cloudflare DNS -posthantering.
Arbeta igenom fallet med dubbla namn
Tänk på en illustrativ redigerare konfigurerad för example.com som lägger till zonen till varje relativ namnvärde. Om du anger _dmarc.example.com som ett relativt värde skapas _dmarc.example.com.example.com . En validator som pekade på det oavsiktliga namnet kunde hitta en post, medan den avsedda _dmarc.example.com -sökningen inte har någon.
Jämför tre saker explicit:
- Avsedd absolut ägare: _dmarc.example.com .
- Sparad ägare visas av DNS tjänsten eller zonexporten.
- Auktoritativa TXT -svar för både de avsedda och misstänkta oavsiktliga namnen.
Om svaret med fel namn innehåller den avsedda policyn, bevara det som bevis. Publicera eller korrigera den godkända posten hos den avsedda ägaren, var noga med att inte introducera en andra DMARC kandidat där. Ta bort den felaktiga posten genom normal ändringskontroll efter att ha kontrollerat att den inte har någon separat avsedd användning. Behandla inte ett exempelnamn från den här artikeln som din produktionsdomän.
Verifiera reparationen utan en falsk deadline
Fråga den auktoritativa tjänsten om exakt ägare och posttyp. Jämför sedan en rekursiv resolvers svar och notera tidsstämpeln, svarsstatusen och TTL. Om det avsedda namnet inte fanns tidigare, kan en negativ cache fortsätta att returnera det tidigare resultatet under dess återstående livstid. En nyligen vald positiv TXT TTL raderar inte en äldre negativ cache. RFC 2308 §3, RFC 2308 §4 och RFC 2308 §5.
Användning av kvalificerande inaktuella svar kan fortsätta efter att TTL löper ut under RFC 8767 §4, så TTL är inte en global konvergensdeadline. Ett meddelande om att spara på instrumentpanelen bekräftar formuläråtgärden, inte global synlighet. På samma sätt fastställer inte ett korrekt offentligt DNS svar att din tjänst signerar e-post med en anpassad domän. Skicka ett nytt meddelande genom den ursprungliga rutten och inspektera det mottagande systemets pålitliga resultat.
Stäng namngivningsproblemet separat från e-postautentisering
Behåll det ursprungliga ägarens namn, korrigerade ägare, godkänt värde och testtidsstämplar i ändringsposten. Om DMARC nu gäller men meddelandet misslyckas, fortsätt med identitets- och anpassningsdiagnos. Det är framsteg: posten kan hittas och det återstående problemet tillhör sändningsvägen.
Om mottagare fortfarande verkar upptäcka olika policyer, jämför deras observerade From-domäner, DNS svar och implementeringsbeteende. Fortsätt inte att flytta en korrekt post mellan namn bara för att få två icke-relaterade pjäser att komma överens.
Anteckna ett beslut som kan omprövas
För fixturen med dubbla namn, jämför de avsedda och sparade absoluta namnen innan du ändrar TXT värdet. En giltig policy som hittats hos den oavsiktliga ägaren visar inte att den avsedda första sökningen hittar den. Bevara den oavsiktliga journalen som bevis och använd sedan separat godkända korrigerings- och borttagningsåtgärder. Detta är en illustrativ redaktörsmodell, inte ett påstående om att Cloudflare lägger till namn på det sättet eller att någon DNS ändring har gjorts.