Start with the identity the receiver will check
An email-authentication change begins with a name, a record type and a responsible operator. “Add authentication to our domain” is too broad to identify the correct DNS editor or the answer a receiver needs. A marketing service may sign with one domain, use another for its SMTP envelope, and display a third in the From field. An inventory should preserve those differences before anyone edits a zone.
For SPF, obtain the domain used by the SMTP MAIL FROM identity; the HELO identity has its own check, including the null reverse-path case. Query the applicable domain for TXT. Do not select the SPF owner merely by reading the visible From address. RFC 7208, sections 2.3–2.4 and 3.1.
For DKIM, take the selector from s= and the signing domain from d= in the signature. The key lookup name is selector, then _domainkey, then the signing domain. For DMARC, policy discovery starts with a TXT query beneath _dmarc at the Author Domain and can continue using the specified DNS tree walk. An absent initial record does not by itself establish that no policy applies. RFC 6376, section 3.6.2; RFC 9989, sections 4.5 and 4.10.
Separate the owner name from the people who own the change
In DNS, the record's owner is a domain name. In a change ticket, its owner is often a person or team. Record both. The domain registrar, authoritative DNS host, sending-platform administrator and approving domain owner can be different parties. Registration access is not evidence that a particular DNS console controls today's public answer.
Identify the delegated authoritative servers for the zone containing the requested name. A subdomain may have its own delegation, so the correct editor may differ from the parent domain's editor. Keep the zone, full owner name, requested type, proposed data and accountable operator together. DNS delegation defines where authority changes; it does not follow an organization's support-team boundaries. RFC 1034, sections 4.2 and 4.2.1.
Ask the sender administrator to supply account-issued values and explain any aliases. A provider's CNAME instruction points a name at another name; it is not the same operation as delegating a child zone with NS records. Capture who maintains the alias target as well as who can change the customer-side record.
Read the published record set rather than the editor's appearance
DNS consoles often accept a relative host label and append the zone name. A copied fully qualified name entered in the wrong mode can therefore land at an unintended owner. Verify the final absolute name, including every subdomain and underscore label. An editor's saved value is preparation evidence; an authoritative DNS answer is publication evidence.
TXT presentation also needs care. A single TXT resource record may contain several character strings. For SPF those strings are concatenated without inserting spaces. That differs from publishing two separate SPF records at the same owner, which is prohibited. Preserve record boundaries when reviewing an export or screenshot rather than counting quotation marks. RFC 1035, section 3.3.14; RFC 7208, sections 3.2–3.3.
MX records identify mail exchangers for receiving mail. They do not independently prove which outbound service is authorized or which key signs a message. An SPF policy can refer to MX through a mechanism, but that relationship must come from the actual policy, not from an assumption that all mail-related DNS records authenticate sending. RFC 1035, section 3.3.9; RFC 7208, section 5.4.
Work through a fictional ownership inventory
Suppose a fictional service sends mail with From news@example.com, MAIL FROM bounce@mail.example.com, and a DKIM signature containing d=example.com; s=nov26. The initial inventory has three separate TXT questions: mail.example.com, nov26._domainkey.example.com, and _dmarc.example.com. These are illustrative names and identities, not observed messages or recommended production values.
The email administrator confirms the intended route and selector. The DNS administrator checks which zone contains each name and whether any provider-required alias changes the lookup path. The domain owner approves the scope. If the selector is issued by a vendor, the vendor must retain the corresponding private key; only public-key material belongs in DNS. A private key must never be copied into the ticket or a public TXT record.
An inventory row should distinguish “supplied by the service,” “present in authoritative DNS,” and “observed on received mail.” Leaving one of those columns unknown is more useful than checking a single “authenticated” box prematurely.
Collect evidence before closing the change
Proposed checks are dig @AUTH_IP nov26._domainkey.example.com. TXT +norecurse and dig @RESOLVER_IP nov26._domainkey.example.com. TXT. Replace the uppercase placeholders with approved endpoints. Repeat for each actual owner and relevant authoritative server. Retain UTC time, server address, question, response code, flags, answer and authority sections, TTLs and any alias chain. These commands have not been executed for this article.
If authority and recursion disagree, investigate publication consistency, caching and the resolver path before adding duplicate records. A DNS answer still cannot prove a signature verifies, SPF authorizes the actual sending IP, or DMARC aligns. Close those questions with a controlled received message and trusted receiver results. Timestamped authoritative and recursive transcripts remain an open original-evidence gate for this documentary draft.