Identify the domain and the Critical Impact account
Critical Impact documents sender authentication as an account workflow that produces domain-specific DNS instructions, compares published values with those instructions, and then starts authentication. This guide covers that documented Sender Authentication tool. It does not establish that a particular subscription exposes the tool, that a domain is already authorized, or that a message has passed a receiver's checks. Those require account and message evidence. The documented navigation is Account, then Sender Authentication; if the tool is missing, the provider directs the customer to their account manager. Availability is therefore a prerequisite, not a control that this article can assume. Critical Impact setup guide
Begin with the actual domain or subdomain intended for sending. Identify its business owner, the account using it, the authoritative DNS operator, and any other systems already sending under the same identity. A website domain and a campaign's visible From domain may differ. Recording the intended identity before obtaining DNS instructions helps avoid configuring an unused parent domain while leaving the campaign subdomain untouched. This is a proposed preparation step, not a claim about an automated inventory feature.
Obtain the unique instructions without treating them as reusable defaults
The documented sequence is Add Domain, enter the domain or subdomain, and Save. Select that domain in the grid and choose Authenticate Domain to obtain its instructions. Critical Impact describes a unique DKIM TXT record for each domain and an ip4 mechanism to add to the existing SPF policy. Do not replace these account-generated values with a record copied from another customer, another domain, or an old screenshot. Do not substitute a guessed include mechanism for the documented ip4 instruction. Sender Authentication explanation
Keep the generated owner names, record types and complete values together with the account and domain that produced them. A reviewer should be able to distinguish a requested new record from a modification to an existing record. DNS editors differ in their treatment of relative names and domain suffixes, so the intended fully qualified name should remain explicit in the change request. No selector, address or public key in this article is an implementation value.
The tool's Email Instructions action sends instructions to the logged-in user's email address. It is a communication action, not merely an on-screen preview. Decide whether that recipient and mailbox are appropriate before using it. This guide has not sent those instructions or contacted an account manager. The provider workflow is described so an authorized operator can plan it. Critical Impact setup guide
Preserve existing senders when preparing DNS changes
Critical Impact says not to delete an existing SPF record to add its authorization. Instead, update the existing policy with the issued mechanism. SPF permits only one selected SPF policy at a given owner name; publishing a second competing policy is not a safe way to preserve the first. Preserve the authorization for still-approved senders, check syntax and ordering, and assess the complete evaluated dependency path where DNS-lookup mechanisms are present. An ip4 term is not an include and does not itself perform a DNS lookup, but other terms in the resulting policy can still cause evaluation limits to be exceeded. Critical Impact authentication explanation RFC 7208
For DKIM, use the unique TXT owner and key supplied for this domain. Record whether the DNS panel displays presentation quotes or splits a long TXT value into character strings, then validate the resulting record rather than interpreting a screenshot as wire-level proof. A selector's published public key enables verification of matching signatures; publishing a key does not prove that the sending service has begun signing messages with it. The actual signature's domain and selector must later be checked against the intended configuration. RFC 6376
Separate comparison, activation and received-message evidence
The authentication popup distinguishes Existing DNS Values from Recommended DNS Values. Critical Impact's setup guide directs the operator to compare them and proceed with Begin Authentication when the values are green. A red mismatch needs investigation: wrong owner, copied value, missing record, stale resolver response or an uncompleted change are different problems. The explanation also describes timing allowances and a warning path when values do not yet match. This proposed acceptance procedure does not use that warning path to waive the comparison requirement. Critical Impact setup guide
After initiation, the documentation describes a notification email and an Authenticated state in the domain grid. Its timing estimates are planning information, not proof that a specific record will become correct by a deadline. Record the observed state and time instead of converting elapsed time into success. If DNS settings change later, the provider directs users to Authenticate Domain again and reverify the values. Preserve that revalidation dependency in the operational runbook. Sender Authentication explanation
An account's Authenticated label is one checkpoint. A later authorized message assessment should separately identify the visible From domain, SPF identity and result, DKIM signing domain and result, and DMARC alignment. DMARC can pass through an aligned passing SPF result or an aligned passing DKIM result; it does not universally require both to pass. Authentication also does not guarantee inbox placement or validate the business intent of a message. RFC 9989
Treat the displayed DMARC example as a policy decision
The provider explanation describes a current DMARC value and an example recommended DMARC value in the popup. An example is not permission to replace an organization's policy. Review all legitimate sending routes, reporting destinations and consequences before approving any policy change. The scope of this manuscript is configuration planning and evidence collection, not a recommendation to impose a particular enforcement policy on an unexamined domain. Keep DMARC decisions separate from copying the issued DKIM key or merging a sender authorization. Sender Authentication explanation
Blank acceptance worksheet
- Account, intended sending domain, business owner and tool availability: ____.
- Generated instructions captured on, approved DNS operator and exact owner names: ____.
- Existing SPF preserved, issued ip4 reviewed, complete policy checked: ____.
- Unique DKIM TXT value and domain binding reviewed: ____.
- Existing versus recommended values, mismatch explanation and approval: ____.
- Begin Authentication authorized, observed grid state and notification: ____.
- DMARC policy decision owner and separate approval, if any: ____.
- Authorized received-message evidence, alignment result and unresolved routes: ____.
- Revalidation trigger after later DNS changes and release owner: ____.
Fictional diagnosis: the green comparison was not the final test
A fictional charity prepares authentication for notices.example. Its operator initially copies a DKIM key previously issued for appeals.example. The reviewer stops the change because the instructions are domain-specific, retrieves the correct domain's proposed change record, and preserves the existing SPF senders while adding the issued authorization. Nothing in this illustration is a real DNS query or tenant action.
In the fictional review, the comparison later becomes green and the account eventually shows Authenticated. The team still leaves message acceptance open: a campaign draft uses a different From subdomain, and no received message has established its signing identity. They correct the inventory and seek an authorized route-specific check rather than declaring every organizational email authenticated. The useful outcome is a clear separation between matching DNS instructions, provider activation and evidence about the message actually sent.
Release remains conditional
The catalogue's required original evidence, current account applicability, live DNS, received-message behavior, human review, visual accessibility and owner release remain unverified. This documentary guide supplies a proposed workflow and an explicitly fictional diagnosis. It is not a completed deployment, a deliverability guarantee or authorization to alter DNS, send instructions, change policy or publish the article.