[ Email sender guides ]

ServiceTitan SPF, DKIM and DMARC setup, step by step

By the EmailAuth research team · 9 min read

On this page

For ServiceTitan’s native customer communications, add your own domain in Email Domains, publish the three account-issued CNAME records and use Verify. Then separately configure the approved sender for the intended template or business unit and inspect an actual received message. A verified domain does not automatically change every notification’s From address.

This guide covers native invoices, estimates, appointment confirmations and follow-ups. Marketing Pro uses an independent domain setup and is not configured by this procedure. There is no universal ServiceTitan SPF include or reusable DKIM selector to paste into DNS. Native email-domain setup.

No customer account, DNS change, permission change or message send was performed. The procedure is supported by complete published prose; inaccessible linked screenshots were not visually inspected or used to infer record values.

Confirm the account, permissions and intended sender

Identify the ServiceTitan tenant, business unit, notification type, intended From domain and responsible DNS administrator. Confirm that this is native customer communication rather than Marketing Pro. Use a domain your organization controls, not gmail.com, yahoo.com or outlook.com.

An authorized operator needs Email Domain Authentication permission. Enterprise Hub accounts require the applicable admin-role assignment. The documentation says a Manage permission change turns on MFA and requires signing in again. Do not casually grant privileges, change security controls or disable MFA to expose the page. Have the account/security owner approve any necessary access change separately, or use an already authorized administrator. Feature access requirements.

Before changing DNS, inventory existing records, selectors, policies, delegations and routing dependencies. Save the approved before-state. A website receipt or detected provider is a clue, not proof of current DNS authority. Confirm where the live zone is actually hosted.

Obtain and approve the three issued CNAMEs

Open Settings > Communications > Email Domains > Add Domain. Enter the intended company domain, then use Copy All to obtain the three CNAME Host/Value pairs. Use the current tenant packet, not sample owners or another account’s targets. Record issuance.

Do not assume all three aliases are DKIM selectors. Review the actual labels and purposes, and confirm any routing function with ServiceTitan if unclear. Approve each exact destination before publication, especially if it handles message returns, links or other traffic. A generated packet does not authorize repointing an existing website or sending data to an unexpected destination.

Share the packet only with an approved IT/DNS recipient through an approved channel. The product’s Share with IT Team control is not blanket permission to disclose account information. Never include private signing keys, account passwords or authentication tokens.

Publish at the real authority without breaking existing records

For each issued CNAME, preserve the exact owner and target. Map the full owner to the zone being edited. For example, selector._domainkey.mail.example.com may need selector._domainkey.mail in an example.com editor, or selector._domainkey in a separately delegated mail.example.com zone. If _domainkey itself is delegated, work at that authority without deleting its NS records. These are zone-mapping examples, not ServiceTitan-issued values. DNS zones and delegation.

Check the saved full name. Some editors append the zone automatically; others require a full hostname. Do not create a doubled suffix such as example.com.example.com. If a newly created record is wrong, have its owner correct that exact record after confirming its identity and dependencies; do not delete unrelated records because a tutorial says to start again.

A CNAME owner cannot also hold ordinary TXT, A, AAAA, MX or another CNAME. If occupied, stop and obtain a supported resolution instead of overwriting a service. Preserve existing mail routes, nameservers, DNSSEC, other senders’ selectors and shared dependencies. DNS record representation.

ServiceTitan requires Cloudflare CNAMEs to be DNS Only, not HTTP-proxied. Also inspect per-record, zone-wide, apex and same-zone flattening where the validator needs literal CNAME answers. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those issued aliases. Do not make blanket changes to unrelated records. If mandatory behavior hides a required alias, coordinate a supported configuration rather than inventing a switch or removing a delegation. Cloudflare flattening controls.

Understand SPF without inventing an extra record

The documented native procedure issues three CNAMEs, not a universal SPF TXT recipe. Do not add ServiceTitan’s website domain to SPF or copy an unrelated sending platform’s include.

SPF evaluates the SMTP MAIL FROM domain, not automatically the visible From. Inspect the actual envelope identity on a received native message. A parent’s SPF policy does not automatically cover a child domain. If an administrator must adjust an applicable SPF policy, retain one v=spf1 TXT policy at that owner and preserve legitimate senders and qualifiers.

The limit is ten evaluated DNS-dependent terms, including nested mechanisms, not ten top-level includes. An all mechanism makes redirect ineffective; authorization placed after all does not repair the policy. Distinguish authorization failure from temporary DNS errors and permanent syntax, duplicate-policy or lookup-budget errors. Do not create conflicting TXT data at a CNAME owner. SPF evaluation rules.

Treat the optional DMARC row as a policy decision

ServiceTitan offers an optional DMARC TXT record. Optional does not mean safe to paste over an established policy. Check existing direct and applicable inherited policy first. An empty lookup at one name does not establish that no policy applies. Preserve enforcement and approved report recipients; never downgrade quarantine or reject, create a child monitoring override or add duplicate DMARC records.

Only if no applicable policy exists, the domain owner approves and monitored introduction is appropriate may an initial TXT policy be v=DMARC1; p=none. For From example.com, the owner is _dmarc.example.com; for From mail.example.com, it is _dmarc.mail.example.com. The latter maps to _dmarc.mail in the parent zone or _dmarc in the delegated child zone. This minimal example does not request reports. Do not copy obsolete pct rollout instructions or sample report recipients. Current DMARC standard.

Any aggregate-report destination needs owner approval. When its Organizational Domain differs from the Organizational Domain of the domain where the policy was found, the receiver generating the report must check DNS authorization. A destination within that same Organizational Domain is excepted. DNS authorization does not replace the privacy/data-sharing decision. RFC 9990 section 4.

If the optional account suggestion conflicts with a protective policy, keep the policy and ask ServiceTitan and the domain owner to resolve compatibility. Do not weaken protection for a green status.

Verify DNS, then separately configure the sender

Return to Email Domains, open the domain and select Verify. The documentation says verification succeeds when all required records are found. Inspect authoritative answers and the saved full names first if checks fail. The stated propagation window can reach 48 hours, but waiting does not repair a wrong owner, proxy setting or target. Verification and sender transition.

After verification, changing the sender is a separate operational step. Obtain approval for the exact templates/business units and sender addresses affected. Do not enable a disabled notification or change every business unit merely to test authentication.

For an already approved active customer-notification workflow, the documented customization path is Settings > Communications > Customer Notifications > the intended notification type > Email > Customize. Review the intended sender and content, use Preview Edits, then Save only the approved change. Preserve the existing authorized Enable state; switching it on can release real customer communications. ServiceTitan says custom From and Reply-To addresses require an approved domain, otherwise it may substitute a provider no-reply address. Current notification-template behavior.

For the specifically documented legacy Job Completion Survey, the Email customization includes Sender Name and From. Its Business Unit Official Email Address token draws from the relevant business unit’s Email field under Settings > Operations > Business Units > Edit Business Unit. Check the resolved sender for each affected unit; a token is not a fixed address. Do not apply this legacy survey UI to every invoice or notification. Legacy survey sender example.

If your intended template exposes different controls, have the administrator confirm that exact workflow before changing it. DNS verification alone is not evidence that the correct sender was selected.

Test the actual native communication safely

Use an approved controlled external recipient and the intended native communication path. Do not create a false invoice, charge a card, schedule a real appointment, alter a customer job or release a live notification as a casual test. If a safe controlled workflow cannot be arranged, leave real-message verification pending rather than claiming success from a preview.

Obtain the original message and results generated inside the actual receiving service’s known processing boundary. Consult its documented handling of externally supplied Authentication-Results or request an administrator trace. A familiar authserv-id string, header position or copied result is not enough; ignore injected external result fields. Authentication-Results trust rules.

Record the actual visible From, SMTP MAIL FROM, intended ServiceTitan DKIM d= domain and s= selector, plus trusted SPF, DKIM and DMARC results. Acceptance requires the intended company From, passing aligned intended-provider DKIM and dmarc=pass, alongside correct account and DNS state. A substituted onservicetitan.com From is not proof that the company domain is authenticated.

DMARC can pass through either aligned SPF or aligned DKIM. Relaxed alignment compares Organizational Domains; strict aspf or adkim requires exact domain equality. A child envelope domain can align relaxed but fail strict alignment. Require the intended DKIM signature itself to pass and align even if SPF independently satisfies DMARC. See raw DKIM versus aligned DKIM results.

Investigate SPF failures and errors separately. Keep evidence private and test distinct business-unit/template identities separately when they differ. A green domain status, template preview or a successful Marketing Pro message does not certify this native route. Authentication does not guarantee delivery or inbox placement.

Troubleshooting and recovery

Email Domains is missing: check the existing approved permission and Enterprise Hub role with the account administrator. Do not bypass MFA or grant broad privileges.

Verification fails: compare all three exact aliases with authoritative DNS, including suffix mapping, conflicts and proxy/flattening. Escalate persistent errors to Support after checking the actual configuration; do not repeatedly delete records.

Mail still uses the provider From: verify that the domain is approved and the actual intended template/business-unit sender was updated. A display-name change does not alter the authenticated identity.

One business unit works and another does not: inspect the resolved sender token and domain for each unit rather than assuming a shared template produces the same From everywhere.

DKIM fails after verification: inspect the intended signature and downstream signed-content changes. Preserve mandatory security controls while the responsible administrators investigate.

Delivery fails for another reason: use the actual rejection/workflow diagnostic. A DMARC failure alone does not establish the cause; recipient policy, consent, throttling or an inactive workflow may require separate action.

There is no documented self-service delete option for this domain feature; ServiceTitan directs removal to Technical Support. Do not invent a delete button or remove DNS as a substitute. For recovery, pause affected sending where operationally safe and coordinate restoration to the approved state, preserving queued-message and shared-record dependencies.

[ FAQs ]

Frequently asked questions

Are all three CNAMEs DKIM records?

Do not assume that. Use the complete account packet and actual labels; all required rows must be present. Validate the intended DKIM signature on a received native message.

Do I need a universal ServiceTitan SPF include?

The reviewed native procedure does not provide one. Follow its issued records and diagnose SPF against the actual envelope domain instead of inventing a TXT policy.

Will Verify change every notification’s sender?

No. Sender selection in the intended template or business unit is a separate approved step after verification.

Can I enable a notification to test it?

Not without approval for the operational effect. Use an already authorized controlled workflow and recipient, not real customer activity.

[ Sources ]

Sources

  1. Native email-domain setup
  2. Legacy survey sender example

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base