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

Quick answer: Zenly connects to your chosen email service. Configure that connection in Zenly, then verify authentication at the service that actually sends the message. Do not add an invented Calyx SPF include or DKIM selector. This guide covers Zenly's documented company and user email settings, not Calyx Point, Path or a Calyx-managed signing service.

No customer account, DNS change or live email test was performed.

Choose the sending route before changing anything

First identify the mailbox, approved From address, sending provider and person responsible for its DNS. Confirm that your current Zenly version and that provider support the same authentication method. A provider supporting SMTP does not mean every credential type or tenant policy will work.

Calyx documents a Microsoft modern-authentication option and an SSL/TLS option with an app password. This article describes the latter connection workflow only when your provider and administrator permit it. It does not reconstruct Microsoft application registration, permission grants or consent from incomplete instructions. If your tenant requires a different method, resolve the supported integration with Calyx and the mailbox administrator before proceeding.

Do not disable MFA, weaken access policies, enable obsolete authentication or paste an ordinary account password to force a connection. Keep credentials out of screenshots, support transcripts and DNS. DNS uses public authorization and signing records, never your SMTP password or client secret.

Decide whether company settings or a user override applies

Company settings affect users who inherit them. A user override can produce a different sending identity and delivery path. Record both before making a change, and test the actual user who will send.

For the shared route, supply the sender name/address and approved server connection. Do not change the whole company's settings merely to fix one person's override. The display name is not the authenticated domain. Calyx company email settings

Connect Zenly to an approved SMTP service

1. Open the appropriate settings scope above. For an individual exception, enable Override Company Defaults only with approval.
2. Enter the intended sender address, server hostname and port from your current provider configuration. For the documented SSL/TLS route, Calyx requires Sender Email to match the Username email address. Arbitrary Send-As aliases are not established by these instructions; obtain Calyx confirmation before using a different address.
3. Select the secure SSL/TLS credential option. Use the mailbox username and its authorized app-specific password, when supported. Never reuse a sample credential from documentation.
4. Save the configuration. Enter an approved test destination in Receiver Email, then use Send.
5. Inspect the application's result and the received message. A failed connection must be resolved before treating the route as operational.

The native documentation distinguishes Save from Send. It describes a successful connection changing the status from Disconnected to Connected; that is a connection result, not proof of aligned DKIM. Calyx user email settings

Resolve the published Gmail port discrepancy

Calyx's example lists SSL port 464. Google's current app instructions specify 465 for SSL or 587 for TLS with smtp.gmail.com. Use the provider's current setting and confirm that Zenly's selected security mode matches it; do not follow 464 merely because it appears in the Calyx example. Google's app SMTP instructions, option 2

Google's option 2 documents a complete account address and app password, but availability is conditional. App passwords require two-step verification and may be unavailable under organizational restrictions, security-key-only verification or Advanced Protection. Prefer the provider's supported stronger sign-in method when available. If an app password is unavailable, stop and agree a supported route rather than removing protections. Changing the main Google password revokes existing app passwords, which can explain a previously working connection failing. Google app-password guidance

Do not transfer these Google settings to Microsoft, Yahoo or another service. In particular, Calyx's Microsoft examples are not sufficient evidence for your tenant's current authentication eligibility. This article does not promise that an app-password fallback works there.

Where SPF and DKIM actually belong

Zenly's connection screen does not issue a universal Calyx authentication record. Use the actual sending provider's verified domain-authentication workflow. A corporate Microsoft 365 route, for example, belongs with the Microsoft 365 DMARC guide, not a guessed Calyx include.

SPF: The receiving system evaluates the SMTP MAIL FROM domain, not automatically the visible From address. Confirm that actual envelope identity from the delivered message and sending configuration. Maintain one SPF TXT policy at that owner, preserving legitimate senders and qualifiers. The SPF limit is ten evaluated DNS-dependent terms, including nested mechanisms, not ten literal includes. An all mechanism causes redirect to be ignored. Do not replace an existing policy with a sample just to add this application. SPF specification

DKIM: Obtain the complete public record from the sending provider. Preserve its exact type, selector owner and full tagged TXT value or CNAME target. Publish it in the authoritative zone, enable signing using that provider's instructions, and test the intended identity. DNS publication alone does not activate signing. DKIM specification

For an illustrative signing domain mail.example.com and selector key1, the complete owner is key1._domainkey.mail.example.com. In the parent zone example.com, a relative field may need key1._domainkey.mail; in a separately delegated mail.example.com zone, key1._domainkey; in an _domainkey.mail.example.com zone, key1. Confirm how your DNS editor appends its zone. These are owner-mapping examples, not Zenly-issued values.

For provider-issued CNAME records, follow the actual provider and DNS-host publication guide, including its required-answer and flattening checks. This article does not provide a CNAME publication recipe. No MX change is part of this Zenly connection workflow: leave existing inbound routing intact.

Prove the intended identity on a delivered message

Send a non-sensitive test through the actual Zenly account and inspect results produced by your known receiving infrastructure. Header position or an authserv-id string alone does not establish trust; use the receiving service’s documented treatment of externally supplied Authentication-Results, including its boundary sanitization rules, to identify results genuinely generated inside the trusted infrastructure. Reject attacker-inserted results rather than trusting a matching label. RFC 8601, trust boundaries and header handling

Record visible From, evaluated envelope domain, and the intended DKIM signature's d= and selector. For a newly configured branded signing route, require that signature to pass and align with visible From, plus a trusted receiver dmarc=pass. A pass through SPF alone does not prove DKIM works. A provider-rewritten From is not successful authentication of the original brand.

Strict DKIM alignment requires an exact domain match; relaxed alignment uses the Organizational Domain. Apply the current policy to the actual identities. Likewise, a child envelope domain might align under relaxed SPF alignment but not strict alignment. Do not infer a universal Return-Path from Zenly's sender field. DMARC identifier alignment

Preserve DMARC and reporting decisions

Keep applicable direct and inherited policies intact. This connection guide does not create a first DMARC record, reduce enforcement or change report recipients. If no applicable policy exists, treat policy creation as a separate approved configuration task.

For aggregate reports, compare the destination's Organizational Domain with the policy domain's Organizational Domain. A different Organizational Domain requires the report-generating receiver to check DNS authorization; a destination within the same Organizational Domain is excepted. That check does not replace the owner's approval to share reporting data. RFC 9990, section 4

Troubleshooting by failure stage

Investigate SPF errors even if DKIM currently makes DMARC pass. Keep sanitized timestamps and rejection details for support, not credentials or borrower information.