Name the Retarus service before changing DNS
This guide covers Retarus Transactional Email. It does not apply the same record set to Secure Email Gateway, an unrelated Retarus service, or every product administered through a Retarus portal. Record the contracted service, application, technical account, sending domain, interface, and data center before preparing an authentication change. Similar branding does not establish an identical delivery route.
Retarus’s onboarding guidance recommends considering separate Technical Accounts for multiple applications and separate sending domains when transactional and marketing content differ. It also treats additional data-center use as a service arrangement that must be reported and ordered. Use those dimensions to organize the inventory; do not infer that a DNS edit provisions a new region or account. Retarus onboarding considerations
For each application, identify the business event that generates mail and the team responsible for missed or delayed delivery. A password reset, invoice notice, and marketing campaign can have different operational recovery needs even when they share infrastructure. Select harmless test content that exercises the actual submission path. Keep customer documents, access tokens, and production message bodies out of the shared authentication evidence.
Obtain and publish the registered-domain records
The Transactional Email basic configuration documents include:_spf.general.transactional-mail-a.com and requires the relevant MAIL FROM domain to have SPF authorization. It also makes DKIM mandatory for each registered sender domain, using keys generated and provided by Retarus. Obtain the current issued values for the service rather than constructing a selector from the company name. Retarus basic configuration
Ask the implementation owner to provide the registered-domain list, the expected envelope identity, the signing domain, and all required public DNS values. Match those to the application inventory. If an application uses several From domains, establish which have actually been registered. Do not assume that a successful test from one domain extends authorization to every address the application can place in a message.
Capture the current DNS records before publication. Merge any required SPF authorization with the existing policy at the correct owner, preserving other legitimate routes. Check the full lookup evaluation rather than counting only visible include terms. SPF evaluates the SMTP sender identity, and publishing multiple applicable SPF policies at an owner is not a valid way to combine services. SPF RFC 7208
Use the issued DKIM record name, type, and value exactly. Confirm the final owner after any DNS-zone suffix expansion and query the authoritative service independently. Connect the DNS evidence to the implementation ticket and record when Retarus considers domain setup active. Public DNS availability and provider activation are separate checkpoints; neither should be inferred from a screenshot of the proposed change.
The basic-configuration page describes possible charges for repeated verification when required entries are not completed within its stated window. The service owner should confirm the applicable agreement and onboarding deadline rather than treating this guide as pricing advice or acceptance of terms. Retarus basic configuration
Review who can use the authenticated domain
Domain authentication grants a meaningful sending capability. Retarus documents that addresses within a registered domain are usable by default and provides an Allowed Sender Address option requested during implementation or through a service request. The documented feature applies to SMTP and REST. Confirm its current constraints with the implementation owner before designing a restricted sender list. Retarus Allowed Sender Address
Map the intended senders to the applications that need them. Review whether a shared technical account lets unrelated workloads use the same identity. This is an access-design question in addition to a DNS question. A perfectly aligned signature is not evidence that every application using the account should have permission to send as the organization’s finance or security team.
Keep credentials in the approved secret-management system. Record account identifiers and responsible teams in the worksheet without copying passwords or API keys. Any proposal to create a new credential, expand access, or alter account restrictions belongs in its own approved change. Do not hide those actions inside an authentication troubleshooting task.
Treat envelope rewriting as an unresolved configuration branch
Retarus has a separate EnvelopeFrom Address Rewriting service and says to contact it for details and activation. The reviewed page contains inconsistent wording: its title and examples discuss EnvelopeFrom and rewriteFrom, while a descriptive sentence refers to EnvelopeTo. That inconsistency prevents this article from treating the page as an unambiguous implementation recipe. Retarus envelope rewriting
If rewriting is required, ask Retarus which identity changes for this interface and account, how the mapping is applied, and how bounce handling is affected. Obtain a clear before-and-after example using non-sensitive test addresses. Confirm whether the visible From remains unchanged. Do not copy a request-body sample into production while these questions are unanswered.
A provider event reporting successful delivery is useful operational evidence, but it does not replace the destination’s authentication assessment. Collect both sides: the job or message reference identifies the attempted delivery, while the received headers identify the envelope and signatures that arrived. A rewritten envelope should be evaluated from that received evidence rather than from its requested input alone.
Prove alignment on each released route
Send controlled messages through the actual SMTP or REST integration being released. Preserve the trusted receiver results, visible From, envelope domain, and every DKIM signing domain and selector. DKIM’s d= and s= values identify the signature’s domain and key lookup. A published key without a corresponding passing message signature is incomplete evidence. DKIM RFC 6376
Compare the passing identity with the visible From under the configured alignment mode. DMARC permits a passing aligned SPF or DKIM path; the requirement is not that every signature must pass or that unrelated passing identities become aligned. Use RFC 9989 for the protocol interpretation where simplified vendor wording is less precise. DMARC RFC 9989
Test each registered domain and any application branch that changes the sender or envelope. Include the intended region and technical account in the evidence. If authentication fails, preserve the exact result and isolate DNS publication, activation, domain selection, message modification, and rewriting as separate hypotheses. Make one justified correction at a time and repeat the same test.
Fictional diagnosis: a second application uses an unreviewed identity
A fictional company validates emma@billing.example through its invoice integration. A second application shares the account but submits alex@ops.example. Its team assumes the earlier test covers both. In this invented case, the second domain has not completed the agreed signing setup, so its received message lacks an aligned passing path. This is a hypothetical teaching example, not observed Retarus behavior.
The reviewer checks registered-domain scope and application ownership instead of adding arbitrary SPF permissions. The service team completes the supported domain configuration, confirms the permitted sender, and tests the second application independently. If envelope rewriting is also involved, that branch stays open until Retarus resolves the documentation ambiguity and the receiver shows the actual result.
Route worksheet and acceptance gates
- Service: Transactional Email, application, interface, Technical Account, region, and business owner.
- Domain: registered From identity, approved sender addresses, envelope identity, and provider confirmation.
- DNS: issued public values, previous records, merged SPF, authoritative observations, and activation time.
- Test: event, timestamp, job reference, received identities, trusted results, and alignment decision.
- Rewriting: requested behavior, provider clarification, bounce implications, and unresolved scope.
- Recovery: previous supported route, rollback owner, retest conditions, and retirement dependencies.
This candidate has documentary support, not customer validation. Live tenant, DNS, header, visual, human SME, and publication gates remain pending. Secure Email Gateway and ambiguous envelope-rewriting implementation details remain outside the verified scope.
Review the required SPF ending as a separate policy decision
Retarus basic configuration requires the sender-domain SPF record to end in -all or ~all. Preserve the existing authorized sending services when merging the required mechanism, but do not interpret preservation as permission to retain an incompatible ending. Have the domain owner review the existing ending and the effect on other legitimate senders before approving any change. This provider prerequisite does not authorize an automatic move from softfail to hardfail and does not replace alignment or DKIM checks.
Confirm allowed-sender constraints before account expansion
The current Allowed Sender Address page states a maximum of 50 addresses per registered sender domain and excludes role-based addresses, referring to its prohibited-names policy. Confirm the exact names and current applicability with the provider before designing the restriction. Do not infer that domain registration overrides these limits. The fictional addresses are teaching labels, not provider-approved senders; no restriction or message test was executed.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.