On this page: Start with the contracted service and application route · Obtain the registered-domain DNS package · Configure SPF at the actual envelope domain · Treat envelope rewriting as a separate acceptance branch · Check allowed senders and provider validation · Publish safely and inspect public DNS · Retain DMARC and test the trusted receiver result · Troubleshooting and FAQ · Review boundary
For Retarus Transactional Email, register the intended sender domains through your onboarding arrangement, publish the Retarus-supplied DKIM public records, and authorize the relevant MAIL FROM domain using the assigned SPF configuration. Retarus documents include:_spf.general.transactional-mail-a.com and requires DKIM for registered sender domains. Confirm provider validation and then test each real SMTP or REST route at a receiving mailbox. Basic configuration.
Start with the contracted service and application route
This guide covers Transactional Email, not Retarus Secure Email Gateway, inbound mail protection, or every product administered through a Retarus portal. Do not transfer this record set to an unrelated Retarus service.
Prepare a route inventory with application, Technical Account, interface and version, data center, visible From domain, envelope domain and DNS contact. Retarus's onboarding guidance distinguishes application accounts and regional processing, and says additional data-center use must be reported to and ordered from Retarus. A functioning account in one region does not establish readiness in another. Service administration and onboarding.
You need the registered-domain list, the current record package from Retarus, DNS administration permission, the existing SPF and DMARC policies, and a controlled test mailbox. Ask the provider contact which domains have completed validation and which account can use them. Do not invent a self-service “Generate DKIM” button or assume an add-on is included in your contract.
New credentials, expanded account access, or changes to Allowed Sender restrictions require a separate explicitly approved security change. DNS troubleshooting or receipt of a provider record packet does not authorize those changes. Preserve existing restrictions until the responsible owner approves the specific access change.
Save all pre-change DNS values. Identify other applications using the same domain. The change plan should name who can pause a failing route and who approves its release; an authentication change should not silently expand which applications can impersonate a brand.
If the application currently relays through Microsoft 365, first distinguish that path using the Microsoft 365 application-mail route guide. A message that still leaves through Microsoft 365 is a separate authentication task, not proof of Retarus readiness.
Obtain the registered-domain DNS package
Request a worksheet for each sender domain with these fields:
- Exact DNS owner, record type and full public value or target.
- DKIM signing domain and selector, plus validation/activation status.
- Envelope MAIL FROM domain and applicable SPF authorization.
- Technical Account, interface and data center covered by the configuration.
- Any rewriting or bounce-management feature that changes the envelope identity.
Retarus generates and supplies the DKIM key for each registered sender domain. Publish only the corresponding public material at the supplied owner. Do not infer a selector from retarus, reuse a sample tenant's key or publish private signing material. The basic-configuration page also states a ten-business-day DNS-entry period and possible re-verification billing under agreed rates; confirm the schedule with your implementation contact. Registered-domain requirements.
Treat the provider's completed check and a real receiver test as distinct gates. Neither a support ticket marked resolved nor a DNS key's existence proves that a particular application's message carries the intended signature.
Configure SPF at the actual envelope domain
The documented general authorization is include:_spf.general.transactional-mail-a.com. Confirm it against the record package for your contracted route before use. If SPF already exists at that owner, merge the needed authorization rather than replacing it or adding another SPF record. Retarus requires an SPF ending of -all or ~all; retain an existing approved ending that meets the requirement rather than copying the example's ~all indiscriminately. Retarus SPF requirement.
SPF checks the SMTP MAIL FROM identity, not the visible author merely because the two addresses look related. A record at example.com is not inherited by bounce.example.com. Keep one v=spf1 policy per exact owner and preserve unrelated TXT records. Count all evaluated DNS-querying terms, including nested include, a, mx, ptr, exists and redirect, against SPF's limit of ten. ip4, ip6 and all are outside that term budget. Excess produces permerror; adding a second record or +all is not a remedy. SPF standard.
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
If your existing policy ends differently, have the DNS/security owner review the complete sender inventory and agree the change with Retarus. Do not quietly weaken an enforced domain to satisfy an onboarding example.
Treat envelope rewriting as a separate acceptance branch
Retarus's EnvelopeFrom Address Rewriting page describes a contact-activated service and exposes from, rewriteFrom and notification fields. However, its prose also refers to modifying EnvelopeTo, despite the page's EnvelopeFrom title. That inconsistency is consequential: it is not reliable evidence of which address your configured route will actually rewrite. Envelope rewriting documentation.
If rewriting is enabled or planned, obtain explicit confirmation of the before/after MAIL FROM, the visible From, protocol coverage and bounce handling from Retarus. Capture those identities on a real delivered message. Until that is settled, do not approve the rewriting-dependent route or choose SPF ownership from the feature name alone. The base registered-domain setup can be documented without guessing the unresolved branch.
For example, an SMTP test from one application does not certify a REST application whose request or provider processing changes the envelope. Keep separate acceptance rows even when both applications use the same visible From domain.
Check allowed senders and provider validation
By default, Retarus permits addresses within a registered sender domain. Its optional Allowed Sender Address feature restricts that set, is enabled during implementation or by Service Request, and applies to SMTP and REST. The published limit is 50 addresses per sender domain, with additional role-based-address restrictions. Confirm the actual allowed address rather than assuming domain registration permits every local part in a restricted account. Allowed Sender Address.
Before release, ask the operator to confirm all relevant sender validations are current. Retarus documents REST FORBIDDEN_BY_CONFIG failures associated with spf.lastCheck and dkim.lastCheck; account locking, data center and interface restrictions can also block requests. A different FORBIDDEN_SENDER error can involve an unconfigured sender domain or incompatible From identities. Repair the identified condition rather than repeatedly modifying DNS for every HTTP 403. Job validation errors.
Publish safely and inspect public DNS
Copy the complete records into the authoritative DNS zone using its required name convention. If the editor appends the domain, use a relative owner; if it expects a full name, use the exact fully qualified owner. Confirm the result does not repeat the domain suffix. Preserve other selectors, MX records and unrelated verification data.
For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.
For any provider-issued CNAME, keep the value as a hostname and resolve conflicts before publishing: it cannot coexist with ordinary TXT or other records at the same owner. A supplied public-key TXT must remain a TXT, not be converted to a CNAME because another vendor uses aliases. DNS alias constraints.
Only for an actual provider-issued alias, not a TXT public-key record: Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.
Use these read-only checks with your actual values; only run the DKIM query type that matches the issued package:
dig +short TXT ENVELOPE_DOMAIN
dig +short TXT DKIM_OWNER_FQDN
dig +short CNAME DKIM_OWNER_FQDN
dig +short TXT DKIM_TARGET_FQDN
dig +short TXT _dmarc.FROM_DOMAIN
Expect one SPF policy at the envelope owner. Expect the DKIM owner to return the issued public key or the issued alias leading to that key. Compare authoritative and recursive answers if validation is stale. An empty response requires a name, delegation and cache check, not an assumption that the provider has activated signing.
Retain DMARC and test the trusted receiver result
DMARC requires a passing, aligned SPF or DKIM identifier. Relaxed alignment accepts the same organizational domain; strict alignment requires an exact domain match. Preserve established policy and reporting. Where no applicable policy exists, consider a monitored non-enforcing policy before broad enforcement, but never replace existing quarantine or reject merely to onboard Retarus. Inspect applicable parent/subdomain policy too. RFC 9989 is the current DMARC standard; its removal of pct means percentage-tag rollout recipes are obsolete. DMARC standard.
Retarus's sample DMARC record contains example report addresses and ruf. Do not copy those destinations. Approve your aggregate-report recipient, establish external authorization when needed, and review reports across all legitimate senders. RFC 9990. Failure reporting can disclose content and personal data, so add it only after a deliberate privacy decision. RFC 9991.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
Publish a first DMARC policy only when appropriate
First inspect the applicable exact-domain and inherited policies. Only if there is no existing direct or applicable inherited policy, and the domain owner approves a monitored rollout, create a TXT record at _dmarc beneath the visible From domain with the minimal value v=DMARC1; p=none. For From addresses at example.com, the full owner is _dmarc.example.com; for From addresses at news.example.com, it is _dmarc.news.example.com. In the example.com DNS zone, relative-name fields take _dmarc and _dmarc.news respectively. A separately delegated news.example.com zone instead takes _dmarc. Confirm how your DNS editor handles names before saving.
These are illustrative names, not records to publish unchanged. Maintain one DMARC policy at the intended owner: edit the existing record after review rather than adding a duplicate or overriding a protective inherited policy with p=none. A minimal policy requests no aggregate reports. If monitoring is approved, append ; rua=mailto:AGGREGATE_REPORT_ADDRESS only after replacing the placeholder with a provisioned, authorized report address. Have an external reporting service establish the required destination authorization. External report authorization, RFC 9990 section 4.
An authorized operator should submit a non-sensitive test using each production-representative route. In the receiving mailbox, open the original message and identify the trusted receiver's Authentication-Results. Record:
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust. For this branded-DKIM deployment, require the intended provider signature itself to have trusted dkim=pass and a d= domain aligned with the intended unchanged visible From under effective adkim, plus the trusted receiver’s dmarc=pass for that From. A DMARC pass through SPF alone does not complete the DKIM task. DMARC alignment. Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.
- Visible From and the receiver's
header.from. - SPF result and
smtp.mailfrom, compared with the expected envelope. - DKIM result, signing
header.dand selectors=. - DMARC result and the passing aligned mechanism.
- Application, Technical Account, interface, region, timestamp and message identifier.
Accept the route only when the intended identities are observed and DMARC passes through aligned authentication. Retarus job acceptance, delivery events or a 250 response do not establish inbox placement or independently prove these header results. Test direct delivery first and investigate forwarding separately. Restrict stored headers to authorized reviewers; do not upload confidential customer mail to public analyzers.
Troubleshooting and FAQ
Why does REST return a configuration error after DNS was corrected?
Public DNS and Retarus's last validation state may differ. Check the named error field, verify authoritative answers and request re-validation of the registered domain. Also inspect account, interface and data-center permissions before assuming an SPF error.
Can one approved SMTP test cover all applications?
No. Compare account, interface, From address and post-processing envelope. Rewriting and allowed-sender restrictions can make another route behave differently.
Does Retarus Message Signing replace DKIM?
No. The Transactional Email Message Signing feature is certificate-based S/MIME, separate from domain authentication. Do not use its activation as proof of DKIM. Message Signing FAQ.
Should I publish the SPF example as a second record?
No. Merge the applicable authorization into the existing policy at the exact envelope owner. Preserve the domain's other senders and check the complete evaluation budget.
What should I give support if DMARC fails?
Provide the affected account and route, timestamp, registered domain, DNS owner/value comparison, named validation error and sanitized receiver headers. State whether rewriting is enabled. Do not send passwords, API secrets or DKIM private keys.
Review boundary
No account configuration, DNS publication or delivered-message test was performed. Rewriting behavior requires tenant-specific confirmation because the public page is inconsistent. Complete provider validation and route-specific receiver tests before production release. Authentication does not guarantee inbox placement.