Scope authentication to the mailbox and both delivery paths
Helprace's documentation describes mailbox-specific settings for its own outbound service and an optional custom SMTP route. The critical operational detail is fallback: if custom SMTP cannot send, Helprace says it falls back to its own mail servers. An acceptance plan that covers only the preferred SMTP server is therefore incomplete for the documented arrangement. Identify the mailbox domain, normal sender and fallback responsibility before deciding which DNS authorizations are needed.
The custom SMTP guide describes configuration under Settings, TICKETS, Mailboxes. This article does not create an SMTP integration, enter credentials or change account security. The retained page contains legacy Gmail authentication instructions that are outside this guide's implementation scope; current authentication support for any external SMTP provider requires its own review. A successful DNS check cannot establish that a third-party SMTP login method remains available.
Publish both DKIM CNAME records
The Helprace DKIM guide directs administrators to open the relevant mailbox and expand its DKIM section. It provides two CNAME records and explicitly requires both for proper rotation. Its examples use helprace1._domainkey and helprace2._domainkey under the mailbox domain, pointing to corresponding provider-hosted targets. Use the current mailbox's displayed configuration and preserve both dependencies rather than publishing only whichever selector happens to appear on one observed message.
A second selector is not redundant merely because the current signer uses the first. The documented rotation requirement is a provider prerequisite and should remain a hard acceptance item. Before adding either record, check existing data at the proposed owner and identify any other service that depends on it. Do not overwrite an active key or alias without an approved migration plan. Keep the public owners and targets in the change record; private signing material is not required.
The guide notes that some DNS panels accept only the relative label while others require a complete name. Compare the resulting fully qualified owner with the intended mailbox domain to avoid duplicate suffixes. It gives 3600 seconds as an optional TTL example; that is not proof that every resolver will immediately observe a change after exactly one hour. Review existing TTLs and actual published values when the authorized change is made.
Use the mailbox Test result as one checkpoint
After publication, the guide says to return to the mailbox and choose Test. A green checkmark indicates that the provider's configuration check succeeds. Keep the requested DNS change, published record and provider observation as distinct evidence. A successful check is useful, but it does not prove that every normal or fallback message carries a valid aligned signature at its recipient.
If a check fails, compare both issued CNAMEs with the authoritative zone and confirm the selected mailbox domain. A wrong target or missing second record requires correction, not merely waiting for the longest advertised propagation estimate. Record the exact state and time rather than collapsing all failures into a generic DNS-delay diagnosis. No Test control, DNS query or mailbox setting was executed for this manuscript.
RFC 6376, section 3.5 defines the signing domain and selector carried in an actual signature. Use those fields in a separately authorized acceptance exercise to determine which key is being used. Do not infer active signing solely from the existence of a public key location. DNS prepares verification; the sending system must still generate the appropriate signature on the message that leaves the actual route.
Preserve SPF authorization for documented fallback
The SPF setup guide directs the administrator to the custom mailbox's SPF section, where a suggested policy is displayed. It documents include:spf.helprace.com and distinguishes updating an existing policy from adding a new one. Review the complete existing sender inventory rather than replacing it with the page's illustrative policy. The page correctly notes that SPF is published as TXT rather than the deprecated dedicated SPF resource-record type.
Because the sources describe fallback to Helprace during SMTP failure, do not remove Helprace authorization solely because custom SMTP is configured. Record whether that documented behavior applies to the current account and what identities the fallback route uses. An organization requiring an exclusive mail route should resolve the fallback requirement with the provider and its own policy owner before deployment, not assume the setting guarantees exclusivity.
RFC 7208, sections 2.4, 3.2 and 4.6.4 identify the MAIL FROM identity, multiple SPF-record behavior and evaluated DNS-dependent term limits. The correct policy is the one for the actual envelope identity, not automatically the visible mailbox address. Review nested dependencies and preserve one coherent policy at the relevant owner. SPF authorization does not establish SMTP credential validity or create a network route.
Separate provider recommendations from DMARC semantics
Helprace recommends DKIM and SPF, and its fallback discussion stresses retaining Helprace as a permitted sender. Those operational recommendations should not be translated into a universal claim that DMARC always requires both mechanisms to pass. RFC 9989, section 4.4 explains that a passing aligned authentication mechanism can satisfy the authentication condition. The relationship to the visible author domain is essential; unrelated passing identities do not establish alignment.
The provider pages also contain broad delivery assurances and discuss a “via” display label. Neither a label's presence nor its absence is a complete authentication verdict. Receiver presentation, filtering and local policies can differ. Do not promise that publishing SPF virtually guarantees avoidance of spam filters, or that a green provider check establishes inbox placement. Evaluate authentication, message acceptance and user-visible delivery separately.
Review the normal and fallback paths safely
A proposed acceptance matrix should have a row for the intended SMTP path and a separate row for the documented Helprace fallback. Retain the mailbox domain, route, author domain, envelope identity, signing domain, selector and trusted receiver results for each authorized observation. Do not deliberately break production SMTP merely to force a fallback test. Any controlled failure exercise needs its own bounded plan, authorization and non-production or otherwise safe scope.
Use harmless test content and minimize diagnostic data. Support tickets may contain personal information, credentials or confidential attachments that do not belong in a public checker. Record references to approved evidence rather than copying whole conversations. If fallback has not been observed safely, label that row unverified instead of inferring its behavior from the preferred-route sample. No real ticket, external upload or test message was created here.
Fictional diagnosis and blank acceptance worksheet
A fictional service team, North Quay Support, configures custom SMTP and deletes Helprace's SPF authorization because normal messages appear to come from its own server. During a later review, the team notices the provider's documented fallback behavior and realizes that its acceptance matrix covers only the preferred path. The proposed response is to reopen the fallback authorization and identity assessment, not to trigger an outage or blindly loosen domain policy. This is a fictional scenario without actual account results or message evidence.
- Mailbox domain and normal transport: ______
- Documented fallback applicability and policy-owner decision: ______
- Both issued DKIM CNAMEs and dependency review: ______
- Complete SPF policy, including applicable fallback authorization: ______
- Authoritative DNS and provider Test evidence: ______
- Current custom-SMTP authentication support, without secrets: ______
- Normal-route and fallback-route acceptance rows: ______
- Untested conditions, rollback owner and release decision: ______
Original implementation evidence, human subject-matter review, current applicability, production routes, visual accessibility and owner release remain open. No DNS record, credential, mailbox control or security setting was changed. The catalogue's broader implementation requirement remains dependent on authorized evidence for the actual supported delivery paths.