TMA Systems SPF, DKIM and DMARC setup, step by step

WebTMA's documented Azure SaaS authentication workflow is support-assisted: request domain authentication from TMA Systems, publish the three account-issued CNAME records, complete the supplied confirmation, and have TMA verify the configuration. Do not copy another customer's selectors or substitute a generic SendGrid tutorial. This guide covers that managed WebTMA route, not on-premise SMTP, MEX, Facil-IT or other TMA products.

Evidence boundary: the public instructions establish a documentary workflow. They do not prove that your tenant has been provisioned, that DNS is correct, or that a real message passes. Branded DKIM success must be checked on the intended WebTMA message, separately from delivery and provider ticket closure.

Before requesting authentication

Choose the exact visible From domain you own and are authorized to use. Obtain a WebTMA administrator, the responsible DNS administrator, an approved change window, and a receiving mailbox you control. Save the relevant existing DNS records and configuration before changing anything.

The DNS administrator must identify the authoritative zone, which may be hosted somewhere other than the domain registrar. Confirm whether the sending domain, a child domain, or its _domainkey namespace is separately delegated. A domain registration login alone does not identify the place where authoritative records are managed.

Ask TMA to confirm that this Azure SaaS workflow applies to your environment and selected sending domain. The documented managed route uses SendGrid; it is not permission to open an independent SendGrid account or move an existing account between sending services.

TMA's DKIM article describes noreply@webtma.com as the alternative for addresses on public domains such as Gmail or Yahoo, where the customer cannot publish the required DNS records. That fallback is not authentication of your organization's domain. [1]

Obtain the WebTMA-issued DNS packet

1. Request DKIM setup through support@tmasystems.com for the intended domain and environment.
2. TMA provisions the managed environment; the requestor receives a link to the issued HOST and DATA values.
3. Publish the three CNAME entries from that packet, using the authoritative DNS host and the safeguards below.
4. Select I'm Done in the supplied workflow and reply to the original support ticket. TMA then verifies the setup and updates the ticket. [1]

The packet, not this article, supplies the real names and targets. Stop if it identifies a different domain, conflicts with an existing service, lacks a full value, or no longer matches TMA's instructions. Ask for a corrected packet rather than inventing a selector or assuming a screenshot is universal.

Do not send passwords, private signing keys or unrelated account data in a support request. If a message unexpectedly asks for credentials or security changes, verify it through the established support channel before acting.

Publish the three CNAME records safely

For each issued owner, record the full hostname, the authoritative zone, the editor's relative-name convention, the CNAME target and its existing dependencies. Preserve all unrelated records. An authentication alias does not call for changing parent nameservers, MX routing, DNSSEC or mailbox credentials.

These are name-mapping examples only, not WebTMA selectors or targets:

Some editors accept complete hostnames instead. Check the saved full owner so that the zone is not appended twice. An existing delegation must remain intact; use its authorized operator rather than deleting its NS records to make a tutorial fit.

A CNAME owner cannot also hold conflicting TXT, A, AAAA, MX or another CNAME record. Investigate a collision before editing: an old selector may still support another production sender. Do not overwrite it or choose an arbitrary replacement selector; have TMA issue a supported alternative if necessary.

Use DNS-only, not an HTTP proxy, for the issued authentication aliases. Where verification requires literal CNAME answers, turn off an available per-record flattening setting for those records and ensure zone-wide behavior does not hide the aliases. Check apex and same-zone exceptions too. If mandatory behavior cannot preserve the required answer, stop and agree a supported configuration with the DNS host and TMA; do not invent a switch or disable unrelated zone-wide protections. Cloudflare's documented controls illustrate these distinctions, not a requirement to use Cloudflare. [3]

After publication, inspect each complete issued owner against its authoritative DNS server and an independent recursive resolver. A read-only pattern is:

dig @<authoritative-nameserver> <full-issued-owner> CNAME
dig <full-issued-owner> CNAME

Replace both placeholders. Compare the complete answer with the issued target; no result shown here is a tested customer result. Authoritative correctness and resolver cache convergence are separate checks. Missing records, duplicated suffixes or concealed aliases need correction, not repeated random changes while waiting.

SPF: verify the actual envelope identity

The WebTMA packet workflow does not establish a universal SPF TXT string for your apex. Do not automatically add include:sendgrid.net, replace a Microsoft 365 or Google Workspace policy, or infer a Return-Path hostname from the three-record count.

SPF checks the SMTP MAIL FROM identity, with HELO relevant when the reverse-path is empty; it does not automatically check the visible From address. Obtain the actual envelope identity from a controlled message and confirm its expected ownership with TMA. The account-specific packet determines any required DNS delegation. [4]

If a policy change is genuinely required at a domain you control, maintain one v=spf1 TXT policy at that evaluated owner. Preserve legitimate existing authorizations and qualifiers, and evaluate the whole policy before adding a sender. The SPF limit is ten evaluated DNS-dependent terms, including nested mechanisms, not ten textual include entries. An all mechanism causes redirect to be ignored. Qualifiers do not guarantee a particular recipient's delivery decision. [4]

Treat these receiver results differently, even when DKIM already makes DMARC pass:

• spf=fail: the evaluated source was not authorized by that policy. Check the actual connecting source and envelope domain with TMA; do not authorize an unrelated IP just to remove the failure.
• spf=temperror: investigate a temporary DNS or processing problem, retry appropriately, and involve the responsible DNS operator or TMA. Do not weaken the policy as a retry strategy.
• spf=permerror: investigate a malformed or duplicate policy, an exceeded evaluated lookup budget, or another permanent evaluation defect. Correct a customer-controlled policy with its owner; refer provider-controlled identities to TMA.

Keep the intended From domain consistent

Authentication can be correctly provisioned for one domain while the application selects a different From address. WebTMA 7's Admin > Email Settings controls response text and suppression, not the managed DKIM provisioning step. [2]

Its sender selection depends on Default From Email in User Management's Identity settings. With that option selected, the documented order is user email, Repair Center mailbox, Dispatcher email, client email, then webtma@tmasystems.com. Without it, Repair Center and Dispatcher precede the user, followed by the client and final fallback. [2]

Do not treat that template fallback as interchangeable with the Azure SaaS DKIM article's noreply@webtma.com alternative. These documents describe different settings contexts. Inspect the actual route and ask TMA to resolve a mismatch rather than asserting a single universal fallback for every tenant.

For a controlled test, use the actual approved transaction and event. Check the response is not suppressed and verify its recipient before triggering it. The documented mappings include Authorizer for Approval Routing, Notification Recipients for Survey Response, Technician for Work Order/Schedule Tech, Trade for Schedule Trade, and Requestor for other combinations. Use controlled records and authorized recipients, not production customers as test targets. [2]

Verify aligned DKIM and preserve DMARC

Read the delivered message's original headers or the receiving service's trusted authentication diagnostic. Accept only results produced within that service's known receiving-processing boundary, using its documented treatment of externally supplied Authentication-Results. Header position or a familiar authserv-id string alone cannot establish trust; ignore attacker-inserted fields. [5]

For the intended WebTMA signature, capture header.d, the selector, the visible From domain, the SPF envelope identity and the receiver's DMARC result. The branded acceptance gate is:

• The intended WebTMA DKIM signature passes.
• That signature's signing domain aligns with the intended visible From under the applicable policy.
• Trusted receiver evidence reports dmarc=pass for that intended identity.

A DMARC pass obtained only through SPF does not prove DKIM works. A pass after changing the visible From to a provider-owned address does not prove your brand is authenticated. Ticket closure and visible inbox arrival are also not substitutes.

Relaxed alignment compares Organizational Domains; strict alignment requires exact domains. Under current RFC 9989, the Organizational Domain is determined through the DMARC DNS Tree Walk, not automatically a public-suffix-list result or a fixed two-label rule. A child envelope domain does not guarantee strict SPF alignment with its parent. [6]

Preserve existing direct and inherited DMARC protection and approved reporting recipients. Do not downgrade a working policy or publish duplicates. Only if there is no applicable policy, the domain owner approves and a monitoring plan exists, a first policy could be:

Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none

For mail.example.com, the full owner is _dmarc.mail.example.com: normally _dmarc.mail in the parent example.com zone, or _dmarc in a separately delegated mail.example.com zone. These examples omit report destinations deliberately. They neither prescribe the final enforcement policy nor authorize sending reports anywhere.

If an aggregate-report destination's Organizational Domain differs from the policy domain's Organizational Domain, the report-generating receiver must check the destination's DNS authorization; destinations within the same Organizational Domain are excepted. See RFC 9990 section 4. Independent owner approval of the report data-sharing and privacy arrangements is still required.

For further interpretation, see raw DKIM results versus aligned DKIM policy results.

Troubleshooting and completion

Retain the issued packet, approved before/after DNS evidence, TMA verification response, controlled-message identities and trusted authentication results. Any rollback must be limited to the authorized change and preserve shared dependencies. This article performs none of those customer operations.

Sources and scope

1. TMA: Digitally signing your email with DKIM. Azure SaaS support-assisted route; account applicability must be confirmed.
2. TMA: Email Settings Overview, WebTMA 7. Sender selection, suppression and event-recipient mapping.
3. Cloudflare: Set up CNAME flattening.
4. RFC 7208: SPF.
5. RFC 8601: Authentication-Results.
6. RFC 9989: DMARC.

Documentary review is distinct from authenticated account testing, DNS changes, message delivery testing and publication. None is claimed by this guide.