Autotask SPF, DKIM and DMARC setup, step by step

To authenticate email sent by Autotask PSA, validate each sending domain in Domain Settings, merge include:autotask.net into its existing SPF policy, and publish the domain-code TXT record shown in the account. For branded DKIM, publish the CNAME from Authentication Details, then select Authenticate Domain. Finish by checking a delivered notification for a passing signature aligned with its visible From domain. Domain validation and DKIM authentication are separate results. Autotask Domain Settings.

This guide covers Autotask PSA's documented outbound-domain workflow, not other Datto or Kaseya products or an unrelated SMTP service. No customer account, DNS change or delivery test was performed.

Identify every domain Autotask actually uses

Autotask requires validated domains for Send from addresses. Inventory the support address, resource email addresses, alternate sending addresses and addresses entered in templates, workflow rules, surveys, invoice emails and contact groups. A ticket reply and an invoice may use different domains even within one tenant. Addresses affected by domain validation.

Record the complete domain after @. For example, help@example.com and help@service.example.com are distinct sending-domain entries. Do not assume validating the parent covers the child.

The documented DKIM allowance is five customer domains in addition to the preconfigured system domains autotask.com and datto.com. Those system-domain states are not evidence for your brand. If you need more customer domains, resolve the limit with the service owner before changing working authentication. Domain list and authentication limit.

Obtain the records and permissions first

You need an Autotask security level with administrative permission for Email Notifications & Surveys and an administrator who can edit the authoritative DNS zone. Open Admin > Admin Categories > Automation > Email Notifications & Surveys > Domain Settings. Select the domain's context menu and Authentication Details. To add a new domain, use New > Add Domain. Official navigation and prerequisites.

Keep a change worksheet containing the selected domain, full DNS owner, record type, exact value, existing records and rollback owner. Copy the domain code from this account, not from an illustration. Save the current SPF and DMARC policies before preparing changes.

Configure the required TXT records safely

Autotask requires two different TXT functions. The ownership record proves control of a specific DNS name to Autotask. The SPF record authorizes senders under the SPF protocol. Neither is a DKIM public key.

Autotask's current instructions use include:autotask.net. Do not substitute a different hostname from an older tutorial. If there is no SPF policy and Autotask is the only legitimate sending service for this exact owner, the documented starter value is:

v=spf1 include:autotask.net ~all

This is not a replacement for a shared corporate SPF record. Keep existing legitimate authorizations and the approved terminal policy. Insert the include before an existing all mechanism; content after all will not authorize another sender. Autotask advises placing its include among the first three entries of a long record and notes a validation preference for ~all, while allowing -all. These are application-specific compatibility instructions. Have the policy owner review ordering and any qualifier change rather than weakening -all automatically to obtain a green status. Autotask validation details.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

SPF permits only one SPF policy at a given owner. Other TXT records, including ownership tokens, can coexist. Multiple quoted strings within one TXT record are not necessarily multiple policies. Evaluate the full SPF tree, including nested includes, against the ten DNS-lookup-causing-term limit. Do not copy temporary provider IP addresses into the policy as an unmanaged shortcut. SPF record selection and lookup limits.

Use the exact apex or child-domain owner

All names below use fictional example.com domains. Replace DOMAIN-CODE with the account value.

If your editor requires a fully qualified name, enter that instead. Confirm the resulting owner to avoid an accidental suffix such as .example.com.example.com. Publish in the authoritative child zone when delegation exists, not in an unused parent-zone entry. Do not replace MX records or change nameservers to complete this setup.

If employees separately send through Microsoft 365, preserve that mailstream and use the Microsoft 365 authentication guide for its tenant-issued records and signing controls. Autotask validation does not authenticate those employee messages.

Publish and activate Autotask DKIM

The official Domain Authentication dialog image, linked from the current help page, shows this DKIM arrangement:

Read the DKIM Settings in your own domain's Authentication Details and copy that exact record. The table describes the current official illustration; it is not permission to ignore a different account-issued target or reuse another tenant's instructions. Do not construct a domain-encoded target from a third-party example.

For the sending domain service.example.com, the full illustrative owner is autotask._domainkey.service.example.com. In the parent example.com zone, its relative name is autotask._domainkey.service; in a delegated service.example.com zone, it is autotask._domainkey.

Before publishing, inspect that exact owner. A CNAME cannot coexist with ordinary TXT, MX or another conflicting record at the same name. If an existing service owns it, resolve the conflict with the DNS administrator and Autotask rather than deleting the working record. Use a hostname as the target, with no https://, and disable any web-proxy treatment for this DNS alias. Publish only public DNS information, never a private signing key.

For authentication CNAMEs, preserve the visible alias rather than flattening it into address records. On Cloudflare, check both the record’s Flatten option and the zone-wide flatten-all setting, as well as DNS-only status. Coordinate any shared setting change with the DNS owner; preserve legitimate child-zone delegation. Cloudflare CNAME verification guidance, flattening controls.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

After the records are publicly visible, reopen Authentication Details and select Authenticate Domain. Autotask documents a five-minute to 48-hour processing/propagation window and separate validation and DKIM error outcomes. Check both Domain Verified and DKIM Authenticated. A valid ownership record does not compensate for a failed CNAME. Authentication action and errors.

Understand SPF alignment and retain DMARC protection

SPF checks the SMTP envelope MAIL FROM identity, often visible in Return-Path and in the trusted receiver's smtp.mailfrom result. It does not check the display name, Reply-To or visible From address directly. Adding an include cannot change the envelope identity Autotask sends. The reviewed Autotask procedure does not establish a configurable custom Return-Path feature; inspect the actual message and obtain current account guidance if you need one. SPF identities.

DKIM signs using a d= domain and s= selector. DMARC compares the visible From domain with a passing SPF or DKIM identity. Relaxed alignment permits the applicable organizational-domain relationship; strict aspf=s or adkim=s requires an exact domain match. A provider-domain SPF pass can therefore coexist with unaligned SPF and a legitimate aligned DKIM-based DMARC pass. DKIM key selection, DMARC alignment.

Inspect the effective DMARC policy for the actual From domain, including child-domain policy and parent discovery. Preserve existing enforcement, alignment settings and reporting destinations. Never add a second DMARC record or replace an established policy with p=none merely for Autotask.

If no applicable policy exists, an approved monitoring rollout can begin with a policy such as the following at _dmarc.example.com. The example mailbox must be replaced with an authorized, monitored destination:

For that approved first-policy example, use type TXT with full owner _dmarc.example.com, or relative name _dmarc in the example.com zone. Preserve any direct or inherited policy; do not duplicate it. DMARC policy publication, relative DNS names.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

For a dedicated child policy, _dmarc.service.example.com belongs at _dmarc.service in the parent zone or _dmarc in the delegated child zone. External report recipients can require destination-side authorization. Aggregate reports help discover other legitimate sources and failures; they are not guaranteed to cover every message. Review all senders and indirect routes before stronger enforcement. RFC 9989 specifically requires domains publishing p=reject to use valid DKIM rather than rely on SPF alone. DMARC interoperability, aggregate reporting.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Verify public DNS, then a delivered notification

These are instructions for a separately authorized test, not results obtained for this guide. Substitute your exact domain, code and authoritative nameserver:

dig +short NS example.com
dig @AUTHORITATIVE-NAMESERVER TXT service.example.com
dig @AUTHORITATIVE-NAMESERVER TXT DOMAIN-CODE._autotask.service.example.com
dig @AUTHORITATIVE-NAMESERVER CNAME autotask._domainkey.service.example.com
dig @1.1.1.1 TXT service.example.com
dig @1.1.1.1 TXT autotask._domainkey.service.example.com
dig @1.1.1.1 TXT _dmarc.service.example.com

Use the server authoritative for the actual owner, including delegated zones. Expect one applicable SPF policy, the correct ownership token record, the account's DKIM alias and a reachable nonempty public-key TXT record at its destination. A recursive TXT query may show the alias and final key; query the returned CNAME target explicitly if needed. Inspect response status: a timeout or SERVFAIL is not proof that a record is absent. Compare authoritative answers with public-resolver caches before repeatedly editing DNS.

Then send harmless samples through each relevant Autotask workflow to controlled external mailboxes. Include a ticket notification and an invoice or other automation if they use different From addresses. Save the receiving system's original message source and trusted authentication results. Which Authentication-Results to trust.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Do not approve branded DKIM setup solely because DMARC passed through SPF. Conversely, SPF pass but unaligned is different from SPF fail, softfail, neutral, none, temperror or permerror. A passing aligned DKIM signature can satisfy DMARC while an SPF error remains unresolved. Investigate that error: repair a customer-owned policy, or give Autotask the observed envelope identity and receiver error for a provider-owned policy. A forwarding-only SPF failure needs a documented indirect-path diagnosis, not an unrelated include on your root domain.

Troubleshoot Autotask authentication problems

If a change breaks another sender, pause the affected rollout, restore only the approved change and retest after caching. Keep older public keys available while relevant signed mail may still be in transit, unless a security incident requires revocation. Do not disable shared DMARC protection as a substitute for fixing Autotask.