Start with the legacy identity, not a guessed SPF include
An inventory entry named “Roaring Penguins” is not enough to configure a sender. The historical company name is Roaring Penguin Software, and its products included several CanIt variants. Before editing DNS, identify what the organization actually uses: an installed appliance or software version, a hosted service, a reseller-managed route, or a historical label left behind after migration. This article provides an audit and evidence workflow, not a verified current deployment recipe.
A company-issued November 2010 release describes CanIt-PRO, CanIt-Domain-PRO, and Hosted CanIt. It announces DKIM support in a filtering context, including use of signer information when evaluating mail. That historical statement does not establish a modern customer-domain signing interface or an SPF include that is safe to publish today. Roaring Penguin’s CanIt 7.0.8 announcement
Marlin’s March 2018 acquisition announcement places Roaring Penguin within AppRiver’s email-security business. Acquisition history helps explain old labels, but it does not prove which successor service a particular customer uses, whether its old installation is supported, or which DNS instructions apply. Marlin acquisition announcement
Current provider-owned setup documentation for the exact legacy deployment was not established in this research. Lack of a verified current setup source is not evidence of product retirement. Do not turn search snippets, third-party mirrored manuals, or an acquisition announcement into current production instructions. Keep the product and source hold visible until the deployment owner supplies a supported reference.
Reconstruct the actual mail path
Begin with the system owner, service agreement, installed version, management endpoint, and responsible support organization. Record where the name appears: a mail inventory, an SPF mechanism, an MX target, a received header, or a billing record. These clues answer different questions. A filtering hostname in an inbound path is not proof that the service originates the organization’s outbound email.
Draw a simple route inventory in the change ticket. Identify the originating application or mailbox, any relay or filter, the public egress service, and the destination used for testing. Mark each hop as observed, documented, or still inferred. If a reseller manages the service, ask it to identify the underlying product and the exact scope of its current support without assuming the customer has the vendor’s original administration interface.
Collect a controlled outbound message and, separately, any inbound example needed to understand the filter. Use harmless content and authorized recipients. Preserve timestamps and relevant routing headers with personal information minimized. Do not assume a header bearing a product name is trusted proof of ownership; correlate it with the organization’s configured route and the receiver’s own observations.
An administrator may discover that the legacy component only receives mail, while outbound traffic leaves through another provider. In that case, move outbound authentication to the actual sending service’s guide. Keep the legacy component in the inbound-service inventory and do not add a sending permission merely to make every inventory entry appear “configured.”
Separate signature validation from signature creation
Inbound DKIM validation asks whether a received signature verifies. Outbound signing creates a signature for messages leaving an authorized domain. A filtering rule that gives a valid signer a lower spam score does not create the organization’s signature. The historical announcement supports the presence of DKIM-related filtering capability, not an account-specific signing procedure. Roaring Penguin’s historical DKIM announcement
For an outbound signing claim, require evidence of the signing system, domain, selector, public-key publication, and a passing received signature. DKIM’s d= and s= values identify the signing domain and selector used in the lookup. A DNS record found under an old selector does not show that any current message is still being signed with it. DKIM RFC 6376
Ask the current operator for supported instructions that match the installed version and deployment model. Establish who holds the private key and how rotation and recovery are managed, without requesting the key itself. Record whether downstream systems modify messages after signing. Keep a test before and after any approved change so the reviewer can distinguish a missing signature from one that becomes invalid later.
Do not publish a new selector, replace a public key, or toggle a signing control based solely on an old manual. Even a historically authentic procedure can be wrong for a changed service or unsupported installation. The safe next step is an evidence request and a scoped test plan, not a guessed menu path.
Evaluate SPF and DMARC only on observed identities
Identify the SMTP envelope domain and public egress path for the outbound message. SPF authorizes sending systems for the evaluated SMTP identity; it does not make an inbound filtering service the sender. Preserve existing legitimate authorization, maintain one applicable SPF policy at each owner, and assess lookup limits before proposing any replacement. SPF RFC 7208
No universal Roaring Penguin include is supplied here. Obtain current provider instructions or administrator-verified egress details for the exact route. Do not reuse a domain merely because it appears in an archived example. Record the evidence connecting each proposed permission to active mail, including the service owner who can confirm it.
Then compare the passing SPF or DKIM domain with the visible From domain. DMARC requires a passing aligned path, not merely the presence of an old product name or an authentication pass somewhere in the headers. Apply RFC 9989 and preserve the receiver’s result with the domains that explain it. DMARC RFC 9989
If the route cannot be supported or verified, plan a controlled migration with the mail owner. First inventory critical senders, establish the replacement route, verify alignment there, and document recovery. Do not remove old records until the remaining traffic and dependencies have been checked.
Fictional diagnosis: an inbound filter is mistaken for an outbound sender
A fictional organization sees a Roaring Penguin label in its mail documentation and assumes it must add a new SPF include. The investigator follows an outbound test and discovers that the legacy filter is present only on inbound mail. The message actually leaves through a separately managed relay. This invented scenario illustrates an inventory error, not a measured Roaring Penguin deployment.
The team verifies the relay’s envelope and DKIM identities and assigns its authentication work to the relay owner. It keeps the inbound filter’s support question open but makes no speculative SPF change. A second review checks whether old signing selectors are still used before retiring anything. The outcome is a corrected route inventory and a justified change plan, rather than a green status created by unnecessary authorization.
Legacy-route worksheet
- Identity: historical label, exact product, version, deployment model, operator, and current support contact.
- Direction: inbound filtering, outbound relay, signing, or unresolved; include the evidence for each classification.
- Route: originating workload, intermediate systems, public egress, timestamp, and authorized test recipient.
- Authentication: visible From, envelope domain, DKIM d=/s= pairs, trusted results, and alignment finding.
- Documentation: current provider reference, version applicability, issued public values, and unresolved capabilities.
- Transition: supported replacement if needed, critical senders, rollback owner, and retirement dependencies.
Publication boundary
This is a complete legacy audit candidate with an explicit implementation hold. No current provider-specific SPF value, selector, or interface procedure has been verified. Live deployment, DNS, header, visual, human SME, and publication gates remain pending. Before publication, the editor must decide whether resolved evidence supports a setup guide or whether the topic should remain a clearly labeled legacy assessment.
Label historical evidence by what it can establish
The 2010 release establishes a historical filtering feature, and the 2018 announcement establishes acquisition history. Neither establishes the active customer route, current support entitlement or a successor signing configuration. Record those as separate questions for the present operator; do not turn the company history into an executable DNS recipe.
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.