Start with the Autotask domain state, not a generic DNS recipe
Autotask’s Domain Settings documentation, displaying version 2026.6, separates permission to use a sending domain from optional DKIM authentication. The page says that, from release 2023.3, Send from addresses must use validated domains. That product requirement is distinct from the general email protocols. A valid-looking address is not necessarily an address the application permits, and a permitted address is not by itself proof of aligned authentication at a recipient. Autotask Domain Settings
The supported scope includes the documented Autotask outgoing-email domain workflow. It does not establish that an unrelated mail service, a separately configured application, or every notification path in a customer tenant is ready. Before changing anything, identify the actual environment, affected From addresses and responsible administrator. No account access, DNS change or message test has been performed for this draft.
Inventory the addresses affected by validation
The provider identifies support addresses, primary user addresses used as Send from Resource Email, alternate sending addresses, and manually entered addresses in templates, workflow rules, surveys, invoice emails and contact groups. Review those categories rather than treating a single test notification as representative of all business mail. The catalogue’s received-message evidence requirement still applies to the exact routes eventually approved. Autotask Domain Settings
Create one inventory row per actual domain and sending use. Record whether the application discovers the domain automatically or an administrator proposes adding it. Assign an owner who can explain why that domain should remain usable. An obsolete alternate address can otherwise create a misleading requirement to retain a domain after a business process has moved elsewhere.
The provider distinguishes Active, Domain Verified and DKIM Authenticated status. Its system domains autotask.com and datto.com are configured by Kaseya and cannot be edited or deactivated through this workflow. Customer-domain decisions should not be based on the status of those system domains. The documented customer DKIM allowance is five additional domains; that limit is separate from the existence of other address categories. Autotask Domain Settings
Confirm administrative authority before obtaining values
The documented permissions are an administrative security level able to configure Email Notifications & Surveys and permission to edit the company’s DNS entry. The navigation is Admin, Admin Categories, Automation, Email Notifications & Surveys, then Domain Settings. Adding a unique domain uses New followed by Add Domain, which opens the authentication dialog. These instructions describe a proposed authorized workflow, not a grant of access or a claim that a domain was added. Autotask Domain Settings
Separate the application administrator from the DNS change approver when those responsibilities belong to different teams. Preserve the domain context with every supplied record. A screenshot showing a value without the selected domain is weak change evidence. An operator should be able to match the proposed owner name, record type and content to the intended application domain without guessing.
Treat the two validation records as different controls
Autotask’s mandatory validation uses an SPF TXT policy and a Domain Validation TXT record. The latter has an account-provided domain code before ._autotask. The documentation lists provider-dependent content choices for that validation record: a blank space, a period, or the word Name as required. Do not invent the domain code, assume the value proves anything independently, or confuse this owner name with the domain’s SPF owner. Resolve the actual dialog and DNS-editor requirements before publication. Autotask Domain Settings
The SPF example includes include:autotask.net. The provider says to retain existing content, place this include among the first three entries in a lengthy policy, and notes a validation preference for ~all while acknowledging -all can work. These are product-specific instructions and compatibility concerns, not new SPF protocol rules. Do not silently weaken an existing fail policy to satisfy a checker. Escalate any conflict to the accountable policy owner and establish a supported configuration before approval. Autotask Domain Settings
Keep one applicable SPF policy at its owner name. Preserve still-authorized senders and review the entire evaluation path. SPF’s limit on DNS-querying terms is not a recommendation to place every provider first, nor a simple count of network packets. Reordering mechanisms can change behavior and must be evaluated with the complete policy rather than as a cosmetic edit. RFC 7208, multiple records and DNS lookup limits
Do not confuse optional DKIM with completed signing
The provider calls DKIM authentication optional in this application workflow. That does not make it irrelevant to the organization’s authentication goal. A route whose SPF identity is not aligned with its visible From domain may need a qualifying aligned DKIM result for DMARC to pass. The reviewer must establish the actual identifiers rather than infer them from a green validation icon. RFC 9989, identifier alignment
The retained current page describes the DKIM status, domain limit and authentication action but does not expose a complete selector record recipe in its readable instructions. Obtain the supported account-specific DKIM details before proposing a record. Do not copy an older third-party CNAME recipe into this workflow and label it current provider evidence. The selector and signing domain in an actual message determine the key lookup; the public DNS value must correspond to that signing configuration. RFC 6376, DKIM-Signature and key storage
Verify each layer with the right evidence
After the intended records are published through an approved process, the provider instructs the operator to reopen the dialog and select Authenticate Domain. Its documentation describes a possible five-minute to 48-hour interval and distinguishes validation errors from DKIM errors. Treat those timing statements as troubleshooting guidance, not a guarantee that waiting alone fixes an incorrect record or an exceeded domain allowance. Autotask Domain Settings
Record public DNS observations separately from application status. Then obtain authorized received-message evidence for each relevant route, including visible author, envelope identity, signing domain, selector and recipient authentication results. An application validation result cannot substitute for that message-level table. Authentication also does not guarantee inbox placement or prove that the message’s business request is safe. RFC 9989, scope and receiver actions
Fictional diagnosis: validation succeeds, acceptance does not
A fictional service company, Fernbridge Support, prepares invoice and ticket notifications from two domains. Its administrator sees Domain Verified for the first domain and reports that both routes are fully authenticated. A reviewer notices that the second domain’s status was never documented and that no received-message identities were collected. This is an invented review scenario, not an observed customer incident.
The reviewer separates domain validation, DKIM status and route evidence into distinct rows. The first domain’s validation is preserved as a narrow fact rather than discarded or exaggerated. The second domain remains unresolved. Both routes still require an authorized message assessment before release. The correction is an evidence-boundary fix: one status cannot establish outcomes for another domain or a different layer of authentication.
Blank acceptance worksheet
- Product version and tenant applicability confirmation: ______
- Sending domain and affected address categories: ______
- Application administrator and DNS approver: ______
- Active and Domain Verified states with timestamps: ______
- Account-generated validation owner and exact content: ______
- Existing SPF policy and reviewed proposed change: ______
- Product validation constraints versus organizational policy decision: ______
- DKIM allowance, generated details and current status: ______
- Public DNS evidence and authoritative source: ______
- Received-message identity table for each route: ______
- Rollback, subject-matter review and release decision: ______
Remaining release conditions
The worksheet is unfilled and the fictional diagnosis is not operational proof. Account applicability, original implementation evidence, human subject-matter review, production routes, visual accessibility and owner release remain open. Source descriptions of domain syntax and improved delivery are not adopted as universal Internet rules or guarantees. The final acceptance decision must use the current supported tenant workflow and actual evidence from the intended route.