Identify which server actually sends
AFAS documents configuration of the AFAS Online mail server and a separate own-mail-server option in Profit. Authentication instructions for one route should not be applied automatically to the other. Start by identifying the environment, application workflow, sender address and selected outgoing server. A message generated by Profit can still depend on another mail provider’s configuration when the own-server route is used.
The scope here is the retained AFAS Online and Profit documentation. It does not establish every AFAS product’s behavior or any live environment setting. Record which business messages are in scope, such as invoices or notifications, and identify their owners before planning a change. No message content or customer data is required merely to define that inventory. AFAS: Set the email server and sender
Review SPF in the complete sender policy
The AFAS setup guide identifies include:spf.afas.online for its Online mail-server SPF authorization. That is a documented product mechanism, not a complete replacement policy for every organization. Preserve other legitimate sending services and evaluate the combined policy before proposing a change. The guide’s illustrative address values must not be copied blindly into production.
SPF evaluates the applicable envelope or HELO identity; the visible From address does not by itself identify the domain to troubleshoot. A proposed verification table therefore needs the actual identities from the chosen route. Adding a mechanism to a familiar corporate domain does not prove that the message’s evaluated identity uses that policy.
The separate AFAS conditions page also distinguishes an older SPF configuration from the documented current mechanism, but contains historical timing statements. Do not turn an old date in that guidance into a fresh rollout announcement. Confirm the current environment’s supported conditions rather than inferring them from a legacy status description. AFAS setup; AFAS server conditions; RFC 7208, section 2.3 and 2.4
Keep the SPF prerequisite discrepancy explicit
The retained setup page says the AFAS Online SPF record must already be configured before making its DKIM request. The conditions page says that using DKIM can remove the need for SPF under its described server conditions, while allowing both together. These statements should not be silently merged into a new rule that neither page actually states.
For an operational change, confirm which prerequisite applies to the current product route and request process. Record the answer and its source before omitting an existing authorization or assuming the request will succeed without it. The documentary discrepancy does not prove the service is broken; it means the article cannot independently establish one universal sequence for every environment.
Do not resolve the uncertainty by broadening DNS authorization unnecessarily. Keep the intended legitimate routes, existing policy and proposed change visible to the administrator. This article does not contact support or assert that the prerequisite conflict has been resolved. AFAS setup; AFAS server conditions
Follow the documented DKIM request boundary
The setup guide describes requesting DKIM through the AFAS customer portal and creating two specified CNAME records for the requested domain. It identifies afasonline1._domainkey and afasonline2._domainkey owner labels, with corresponding afasonline1.domainkey.afas.online and afasonline2.domainkey.afas.online targets. The exact fully qualified owners must be constructed for the intended domain without duplicating the zone suffix in the DNS editor.
The source recommends a one-hour TTL and describes rejection and reassessment when the required records are not yet present. Those are product instructions, not evidence that a request or query succeeded here. Verify the current account’s supplied requirements and preserve the proposed public values before approval.
The documented process then provides credentials for configuration in the Profit environment so the requested domain is signed on that route. Treat those credentials as secrets and persistent-access material, not as content for an evidence table or support screenshot. No credentials are requested, collected or configured in this manuscript. AFAS DKIM request and environment configuration
Verify environment, domain and message separately
Use an acceptance worksheet with environment identifier, selected outgoing route, sender-domain source, requested DKIM domain, CNAME owners and targets, prerequisite interpretation, request status and authorized configuration owner. Record whether additional domains require their own request and whether multiple environments are intentionally included. Do not infer that one environment’s configuration covers every related domain.
The received-message section should retain the actual From domain, envelope identity, DKIM signing domain and selector, trusted authentication results and the exact workflow that generated the sample. DKIM is signing, not content encryption. A signature’s presence is not enough to establish alignment with the organization’s intended From domain. RFC 6376, sections 1 and 3.5; RFC 9989, section 4.4.
Keep provider validation, authoritative DNS and message outcomes as distinct evidence. A configured CNAME can coexist with a request that has not been activated, an environment using the wrong server or a message sent through an unrelated route. The review should explain which layer is verified and which remains open.
Fictional diagnosis: records exist, wrong environment route
Imagine a fictional organization that prepares the two documented CNAME owners and submits a DKIM request for one domain. A later hypothetical invoice message still lacks the expected custom signing identity. No real DNS or message was examined for this example. The existence of records alone does not establish that the sending Profit environment uses the configured AFAS Online route.
The reviewer would compare the environment’s selected server, the request’s domain and the credentials/configuration status through an authorized process. If the environment uses the organization’s own mail server, authentication must be investigated through that provider rather than by repeatedly changing the AFAS CNAME records. If the route is correct but prerequisite interpretation is uncertain, retain that uncertainty and obtain current product confirmation.
The proposed next action is a bounded route review and received-message identity comparison. It is not a promise that adding the CNAMEs guarantees delivery or a request to disclose the environment’s secrets. The scenario illustrates a diagnostic distinction, not a tested AFAS outcome.
Publication and operational holds
The catalogue requires current first-party setup evidence and a received-message identity table from the exact product and route. The retained pages support the described setup boundaries, but current prerequisite reconciliation, account state and original message evidence remain open. No customer-portal request, DNS edit, environment login or test send occurred.
All six release gates remain open. Before operational publication, a qualified reviewer should confirm the applicable route and document the resolved prerequisite question. The article must preserve existing legitimate mail and avoid treating a vendor status or a DNS record as proof of complete authentication or inbox delivery.