CATS Software SPF, DKIM and DMARC setup, step by step

To authenticate native email sent from CATS, open Settings > Administration > Custom Email Domain, choose Configure, enter the approved sending domain and select Continue. Publish the exact records displayed for that domain, then select Verify Settings. The documented record screen contains SPF TXT, DKIM TXT and CNAME rows, with a Verified status. Finish by checking an actual, controlled CATS message for the intended aligned DKIM signature and a trusted receiver’s DMARC result.

Do not copy a selector, public key or CNAME target from a screenshot. The values in your own CATS account are the configuration source. A verified domain is not, by itself, evidence that a particular message authenticated correctly.

This guide covers CATS’ native Custom Email Domain feature, not email/calendar synchronization, an external mailbox’s SMTP configuration, open-source CATS, or another Top Echelon product. The public setup instructions do not state a subscription-tier or regional entitlement; confirm that the feature and the required administration access exist in your account before proceeding. [CATS’ official setup instructions](https://help.catsone.

Before you configure the domain

Confirm all of the following with the account and DNS owners:

• CATS is authorized to send native email for the chosen domain, including the user identity that will initiate the test.
• You have approved administration access and know which service actually hosts authoritative DNS. A registrar or website account is not necessarily that service.
• You have a copy of the current relevant TXT, CNAME and NS records, including existing SPF and direct or inherited DMARC policy.
• Each issued CNAME owner and destination is approved for its actual routing consequences. The documented screen includes a CNAME; do not treat it as another DKIM TXT record or replace an existing website/mail alias to accommodate it.
• A valid, controlled recipient and harmless test content are approved. No candidate list, job pipeline or customer recruitment activity should be used merely to test authentication.

Agree to the effect of activating the custom sending domain before publishing records that can satisfy verification. If a record conflicts with existing services, stop for a supported resolution. Do not change nameservers, MX, DNSSEC, credentials or security settings as a shortcut.

1. Retrieve the records from CATS

Go to Settings > Administration > Custom Email Domain. Click Configure, enter the approved domain name and click Continue. Use the actual domain, not an email address or a website URL.

CATS displays Type, Hostname, Add This Value and Status. Use each row’s Copy button to obtain the complete value. Record the full hostname and type alongside it so that a copied value cannot be placed at the wrong owner.

The official screenshot illustrates a single domain with these three rows. Treat it as an explanation of the interface, not a deployable DNS packet. If your current account presents different records, do not force it to match the image; establish the supported configuration for that account with CATS before continuing. Never obtain or publish a private signing key. See Custom Email Domains.

2. Map every DNS owner to the correct zone

Work from the full hostname CATS issued. DNS editors vary: some accept a full name, some append the selected zone, and some use @ for that zone’s root. Check the published full name rather than relying on how the field looks.

For illustration only, suppose the approved sending domain is mail.example.com and the issued DKIM owner is SELECTOR._domainkey.mail.example.com:

• In an authoritative example.com zone whose editor appends that suffix, the relative owner is SELECTOR._domainkey.mail.
• If mail.example.com has its own NS delegation, edit that child zone; the relative owner is SELECTOR._domainkey.
• If _domainkey.mail.example.com is separately delegated, its authoritative zone uses SELECTOR for this owner.

Replace SELECTOR with the actual account-issued selector. These names are mapping examples, not CATS defaults. The same rule applies to the issued SPF and CNAME owners: in a separately delegated sending-domain zone, its own root is @, not the parent domain’s root. Do not create duplicate suffixes or modify a parent zone when a delegated child is authoritative. Preserve NS delegations, other selectors and shared dependencies.

3. Publish SPF without breaking other senders

SPF authenticates the SMTP MAIL FROM domain, or HELO in relevant cases, not automatically the visible From address. CATS supplies an SPF row for its domain configuration, but this alone does not establish the envelope identity that a delivered message will use.

At the issued SPF owner, check for an existing TXT record beginning v=spf1:

• If one exists, reconcile the CATS authorization into that single policy with the DNS owner. Preserve other legitimate senders, the intended qualifier and the rest of the policy’s semantics.
• If none exists, publish the approved account-provided policy at the issued owner after checking that it is the intended authorization scope.
• Never add a second SPF policy at the same owner or replace an organization’s working policy with a tutorial example.

Evaluate the complete policy, including nested mechanisms, against SPF’s limit of ten evaluated DNS-dependent terms. That is not simply a limit of ten include strings. An all mechanism causes redirect to be ignored, so do not append a redirect expecting it to extend a policy that already has all. SPF qualifiers do not guarantee a particular inbox or rejection outcome. See RFC 7208.

4. Publish DKIM and the issued CNAME

Create the TXT (DKIM) record at its exact full owner. Copy the complete tagged public-key value from CATS, retaining its tags and all key characters. DNS interfaces may display one TXT record as several quoted character strings; distinguish that representation from multiple competing records. Do not manually truncate or retype a long key from an image.

Create the CNAME only at the approved owner with the approved destination. A CNAME owner cannot also hold conflicting TXT, A, AAAA, MX or another CNAME record. If that hostname is already in use, do not delete its contents or silently omit the CATS row. Ask for a supported, approved configuration instead.

The required alias must remain visible as a literal CNAME answer where CATS expects a CNAME. Use DNS-only rather than an HTTP proxy for the issued alias. Where supported, turn off the relevant per-record flattening control if it hides that answer; also check applicable zone-wide, apex and same-zone behavior. Do not disable flattening across an entire zone without a separately assessed change. If mandatory behavior prevents the required answer, stop rather than inventing a switch or moving a delegation. For Cloudflare’s actual controls and exceptions, see its CNAME flattening setup guidance.

Inspect the resulting public DNS records at their full names. Successful resolution is necessary evidence, not proof that CATS is signing your messages.

5. Verify in CATS

Return to Custom Email Domain and select Verify Settings in the upper-right corner. Review each record’s status and the domain’s status. The official screen shows Verified for the domain and its rows after successful configuration.

CATS says changes may take up to 24 hours to propagate. If verification fails, first compare exact hostnames, types and values against the account screen and authoritative DNS. Repeatedly editing correct records can extend confusion; waiting will not fix a duplicated suffix, a conflicting CNAME or a wrong key.

The documented activation route is configuring the records and using Verify Settings. It does not document an additional “Start signing” switch, so do not invent one. Likewise, do not treat Verified as proof of the signature on every message. The next step tests that distinct observation. Official verification instructions.

6. Send a safe test through the native route

CATS’ Sending emails instructions say messages are sent under the address name on file for the user initiating the action. Check that this user’s actual sender address uses the intended authenticated domain. Do not assume configuring a domain changes every user’s identity.

With explicit permission for the test:

1. Open More (…) > Emails, then use Quick Create to create an email. From another screen, use the Quick Create dropdown and select Email.
2. Set Regarding to General. Selecting a job can add candidate recipients to that job’s pipeline and move them into its mapped Contacted status. That is not an authentication test.
3. Under To (BCC), use Add Recipients and choose only the approved controlled recipient. Enter Details allows a recipient not already in the system; do not select candidate/contact lists or groups by accident. Review the final recipient set.
4. Use harmless content with no CVs, candidate fields, personal attachments or job data. Confirm the intended sender and immediate versus scheduled delivery before selecting Send.
5. Retrieve the original message at the receiving service. Record its actual From, envelope identity, DKIM signature identity and trusted authentication results.

Send Preview checks formatting and is not a substitute for a controlled message through the intended native sending path. Respect account sending limits; do not buy extra usage or enable unrelated automation to complete this check. CATS’ separate Email integration synchronizes correspondence into activity records. Enabling that integration is not required by the Custom Email Domain setup and entails separate access and data-sharing decisions.

What a successful authentication check looks like

Use receiver-generated Authentication-Results from inside the actual receiving service’s known processing boundary, with its documented treatment of externally supplied result headers. A familiar authserv-id string or the position of a header is not sufficient to establish trust. Ignore attacker-supplied or otherwise untrusted result fields.

For this newly configured branded DKIM route, require all of the following:

• The intended CATS-generated signature has dkim=pass; identify its d= signing domain and s= selector together. An unrelated passing signature is not enough.
• That signing domain aligns with the intended visible From domain under the effective DMARC adkim mode. Relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match.
• The trusted receiver reports dmarc=pass for the intended visible From domain. A pass supplied only by aligned SPF does not prove this DKIM setup works.

Separately inspect SPF for the actual MAIL FROM identity. Under relaxed aspf, Organizational Domains must align; under strict aspf, the envelope domain must exactly match the From domain. A child envelope domain does not promise strict alignment. Do not invent a CATS Return-Path or accept a provider-rewritten From as successful authentication of your brand.

For interpretation, see raw DKIM results versus aligned DKIM policy results, DKIM, RFC 6376, and the current DMARC standard, RFC 9989.

Preserve DMARC while adding CATS

Read the existing direct policy and any applicable inherited policy before changing DMARC. Keep its protection and approved reporting destinations. Adding CATS does not justify replacing a working policy with p=none, creating duplicate records, or changing enforcement merely to make a test pass.

Only if no applicable direct or inherited policy exists, the owner approves a first monitoring policy, and someone will review the results, this minimal example may be appropriate:

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

Here example.com is illustrative. For a separately delegated mail.example.com sender zone, a direct policy’s full owner would be _dmarc.mail.example.com, normally _dmarc in that child zone’s relative-name editor. Confirm the effective policy rather than assuming an empty direct lookup means none exists. This example contains no report destination; add one only under an approved monitoring and data-sharing plan.

When the report destination’s Organizational Domain differs from the Organizational Domain of the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination within that same Organizational Domain is excepted. See RFC 9990, section 4. That protocol check does not replace the owner’s approval to share report data with the recipient.

Troubleshooting

For support, provide only approved diagnostic details, such as the domain, affected public record and relevant redacted results. Do not send credentials, private keys, candidate data or an entire sensitive mailbox message by default.