Keep the current setup gap visible
This draft addresses mail attributed to simPRO, with the current Simpro Help Guide as the starting point. It remains on hold for current first-party configuration evidence. The Help Guide landing page lists an SPF Records topic and a Helpdesk route, but the SPF link resolved to a generic article portal in this research. That retrieval did not establish the required SPF value or the current signing procedure.
A provider-hosted DKIM discussion contains a staff reply dated September 2021 directing the requester to support. It is useful historical evidence of the support route, not a current promise of availability, a self-service procedure or a source of account-specific DNS values. Do not turn that reply into a universal setup recipe.
Start with the affected business message
Identify the actual message the business needs to deliver. A quote, invoice or notification should be tied to its originating workflow and responsible owner. Include only workflows that exist in the organization’s deployment. Do not assume that similarly branded add-ons or integrations share the core application’s outbound infrastructure.
Record the instance identifier, product or module, visible sender domain and any known mail relay. When several business units use different domains, create separate rows. The technical contact needs to know whether the problem affects every message, one workflow, one sender or one recipient system. That distinction determines what evidence to request and what a useful retest looks like.
Also record the business consequence. A delayed internal notice may permit a planned investigation; a customer waiting for a time-sensitive document may require an already approved fallback process. Authentication work should not silently create duplicate invoices, alter customer commitments or resend an entire batch.
Prepare a support request that can be answered
Ask the verified current provider channel to confirm the authentication requirements for the exact instance and domain. Provide the intended sender identity and a controlled message identifier rather than a broad request to “enable DMARC.” Ask which team performs activation, which records the DNS owner publishes and how completion is confirmed.
For DKIM, request the supported signing domain, selector, record owner, record type and public value. Ask whether the scope is a domain, instance or other account boundary and whether multiple domains require separate work. For SPF, request the current supported authorization and the envelope identity to which it applies. For custom envelope support, ask explicitly about the feature and bounce handling rather than inferring it from a reply address.
Keep the response with its date and scope. If support supplies a document for a different product or deployment, ask for clarification before publishing anything. This draft does not open a support request or assert that support has approved a configuration.
Review the proposed DNS change in context
Before a change is authorized, export the current relevant records and identify the authoritative DNS owner. Compare the proposed selector name with existing records. A collision should be resolved with the provider, not by overwriting another service’s key. Avoid copying a key, selector or server authorization from a different customer’s example.
RFC 7208 defines SPF processing, including the DNS lookup limit. Evaluate the complete policy after the proposed addition and preserve unrelated active senders. Do not substitute a historic server hostname merely because it resembles the instance’s web address. The browser hostname and the system sending mail are separate observations.
RFC 6376 defines how the signing domain and selector identify the DKIM verification key. Once support issues values, compare public DNS with those exact values and record observation times. A saved DNS form does not establish that receivers can retrieve the correct key.
Coordinate publication and provider activation
Agree on the order of operations with the provider. Record when DNS was published, when the provider checked it, and when signing was activated for each domain. An elapsed waiting period alone is not proof of activation. A successful record lookup also cannot establish which key the application uses on a newly generated message.
If the first sample lacks the expected signature, confirm that it was generated after activation and through the intended workflow. Check whether a different sender domain or intermediary route explains the result. Avoid repeatedly issuing new keys while the original request’s state is unclear; that can leave multiple versions of the configuration in circulation.
Keep private keys, login credentials and unrelated customer content outside the evidence packet. The publication step concerns public verification records, not account secrets. Any account login or credential configuration requires its own approved process.
Test without generating real customer obligations
Use a permitted test environment or a harmless controlled workflow agreed with the business owner. Do not create a real charge, acceptance deadline or customer-facing commitment merely to generate an email sample. If the only available route is consequential, stop and obtain approval for the precise test rather than treating it as routine mail troubleshooting.
Capture one sample for every meaningful domain and workflow boundary. Keep message identifier, UTC send time and recipient system so support can correlate the observation. An ordinary email sent from the employee’s mailbox cannot validate the application-generated route, even when both show the same From address.
Record the final visible From, Reply-To, envelope domain, each DKIM d= and s= pair and the trusted receiver’s authentication results. RFC 9989 explains alignment; identify the actual passing path rather than recording only “SPF green” or “delivered.” Keep inbox placement and business receipt as separate outcomes.
Use the instance and document workflow worksheet
The inline support and message verification worksheet below connects the support case, domain, DNS change, activation event and received sample. It also records whether the test could create a business obligation and who approved the safe method. Leave current provider values blank until they are supplied through a verified channel.
Where there is more than one company identity or workflow, require a coverage decision. The owner should either supply a test or explicitly mark the route outside the release scope. Do not allow a successful sample from one branch to silently approve every other sender.
Fictional diagnostic case involving a second business domain
Fictional example only: Harbour Mechanical reviews rejected application-generated documents. One business unit’s controlled message has the intended aligned signature, while another unit uses a different From domain and does not. The administrator initially treats the first result as proof that the application is fully configured.
The worksheet exposes the missing domain row. The team asks support to confirm the second domain’s scope and activation status, then prepares a harmless retest. It leaves the rollout incomplete instead of changing the whole organization’s policy. No Harbour account, Simpro support case, DNS record or successful activation was observed for this example.
Recover the route and preserve the acceptance hold
Agree on a fallback before any production change. If a new configuration interrupts an important workflow, pause that rollout and coordinate recovery with the application, mail and DNS owners. Do not delete a key that queued messages may still need, and do not broaden recipient bypasses without understanding the actual rejection.
The remaining gates are current provider-owned setup instructions, exact original product scope, supported account values, live DNS and received-message evidence. Visual review and human SME approval are also pending. This is a complete research-and-verification draft with an explicit setup hold, not proof that any simPRO route has been authenticated.
Inline support and message verification worksheet
All fields are pending until an authorized operator supplies evidence. Keep secrets and customer content outside this record.
- Instance, product, business workflow and owner: pending.
- Sender domain, reply handling and affected document: pending.
- Consequence of delay, safe test method and approval: pending.
- Current support reference, dated instructions and applicability: pending.
- Issued DKIM domain, selector, owner, type and public value: pending.
- SPF authorization, evaluated envelope domain and custom-envelope support: pending.
- DNS publication, lookup and provider activation timestamps: pending.
- Controlled message reference, final From, Reply-To, envelope and every DKIM identity: pending.
- Trusted receiver results, aligned mechanism and route coverage: pending.
- Fallback owner, queued-message dependencies and unresolved release gates: pending.
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.