Start with the mailbox and relay route
E-Zorg's documentation distinguishes mailbox hosting from relay signing. Its SPF article directs customers whose mailboxes are hosted elsewhere to use their mail-hosting provider's outgoing server rather than treating an E-Zorg connection as permission to send through E-Zorg. For domains whose mailboxes are hosted by E-Zorg, it documents adding include:_spf.ezorg.nl to the existing SPF policy. DNS administration remains with the domain administrator. E-Zorg SPF guidance
That distinction should be resolved before a DNS change is proposed. Record who hosts the mailboxes, which system initiates each message and which service submits it to the public internet. A workstation connected through a particular network does not automatically inherit every email feature offered by that network's operator. Likewise, the recipient-facing MX records do not establish all outbound routes used by applications, scanners or hosted services.
This article reviews the documented E-Zorg mail and relay boundaries. It does not establish eligibility for a particular customer's relay service or claim that a Zorg Messenger installation is configured. Current account applicability and the original received-message identity table remain open. No account access, relay activation, DNS modification or test message has been performed.
Separate default signing from customer-domain authentication
The relay article covers connected domains using smtpnodes.ezorg.nl and also describes internet-bound mail through inside-relay or Zorg Messenger SMTP servers. It states that these messages receive signing using ezorg.nl. That provider-domain signature must not be mistaken for proof that the customer's visible From domain aligns. E-Zorg relay DKIM guidance
DMARC evaluates the relationship between the visible author domain and qualifying authenticated identifiers. A valid DKIM signature can identify a different responsible domain without satisfying the customer's alignment requirement. Conversely, an aligned passing SPF result can provide the qualifying path even when another signature does not align. Capture all relevant identifiers rather than labeling a message simply authenticated or unauthenticated. RFC 9989, section 4.4
Before requesting a change, ask which signing identity the service intends to use after activation, which domain it will cover and which sending paths are included. These are acceptance questions, not assumptions that the service will accept arbitrary identifiers. Document the account owner's answer alongside the provider instructions and leave unresolved discrepancies visible to the release reviewer.
Meet the documented activation prerequisite
E-Zorg requires the necessary DNS records to be active before DKIM activation and before submitting the form. Its standard option uses two CNAME records, ezorgmail1._domainkey and ezorgmail2._domainkey, targeting their corresponding names beneath ezorg.nl. The alternative permits custom selector names with E-Zorg's keys. The page directs customers to the helpdesk for domain setup. E-Zorg activation instructions
Treat the two supplied owners as a coordinated change, not an invitation to publish one and see what happens. Determine whether either owner is already used by an active signing service. A conflict must be resolved with the domain and service owners before an overwrite is approved. If custom selectors are proposed, record their exact approved spelling and mapping; do not infer production names from the illustrative examples.
Record the evidence used to establish that the published records are active. The DNS editor's saved state and the externally visible DNS answer are different observations. A proposed activation request should identify the reviewed record version and the person responsible for any remaining discrepancy. Do not weaken the provider's prerequisite into a suggestion to publish the records sometime after activation.
Review SPF as a complete policy
The existing policy may authorize more than the E-Zorg route. Inventory those dependencies before adding an include or changing the final all mechanism. Creating a separate SPF policy at the same name is not the correct way to preserve an older policy while adding a service. Review one coherent policy at the evaluated owner, with explicit responsibility for every proposed removal. RFC 7208, sections 3.1 and 3.2
Two shorthand statements in the provider's general explanation need protocol precision. A TXT character string has a 255-octet limit, but that is not a universal 255-character limit for the entire SPF record: a single record can contain multiple strings. The evaluation limit concerns specified DNS-lookup-causing terms across the evaluation path, including relevant recursive evaluation, rather than a simple count of packets or visible top-level includes. RFC 7208, sections 3.3 and 4.6.4
Also, -all produces the SPF fail result when evaluated; it does not force every receiver to reject a message. Receiver policy and the wider authentication context remain relevant. Do not use a successful SPF change as a promise that all legitimate mail will reach an inbox or all impersonation will be rejected. RFC 7208, section 8
Preserve record names and public data
Write each intended owner as a fully qualified name in the change plan, then translate it into the syntax required by the actual DNS editor. The @ convention in a DNS master file denotes the current origin; it does not establish a universal graphical-interface rule. Check whether the interface appends the zone suffix before approving the resulting name. RFC 1035, section 5.1
Keep the record type and target from the applicable instructions. A public-key delegation is not an instruction to disclose a private key. A reusable worksheet needs only public record data, ownership and evidence references; it should never collect mailbox passwords, SMTP credentials, patient information or the contents of confidential healthcare messages. A synthetic, non-sensitive message can be proposed for a separately authorized operational test without including real business data.
Diagnose each result independently
The relay documentation notes that additional signing can occur when the domain is also signed through E-Zorg's spam filters. A second signature is therefore a reason to inspect both identities, not automatically a sign of error. E-Zorg relay signing
For each observed signature, record the signing domain and selector, the public-key lookup outcome and the trusted receiver result. DKIM verification concerns the signature and signed message data, not merely the connecting IP. Changing an SMTP route may affect SPF while leaving an existing signature verifiable; changing signed content can affect DKIM without changing the source address. Do not collapse these distinct checks into one troubleshooting label. RFC 6376, sections 3.5 and 3.6.2.2
If the message never reaches the receiver, retain the sender-side event and available delivery response as a separate delivery investigation. A missing message does not itself demonstrate an alignment failure. Likewise, a delivered message is not enough to prove that all intended identities passed. The acceptance decision should state both what was observed and which checks could not be completed.
Fictional case: a signature for the wrong identity
In a fictional review, Harbor Example sees a passing DKIM result naming a provider domain and assumes that its own From domain is ready for an enforcement policy. The reviewer asks for the actual identities and discovers that no customer-domain activation evidence is attached to the change request. The observation is insufficient to establish aligned DKIM; it does not prove the service is broken.
The team first confirms the actual relay entitlement and intended post-activation identity. It prepares the complete record pair, checks for existing-selector dependencies and keeps the activation request pending until the prerequisite evidence is ready. It would then use a separately authorized message to assess the resulting identity path. This example is fictional and supplies no live DNS result, successful activation or patient-data finding.
Blank worksheet and release boundary
- Domain owner and mailbox-hosting provider: ______.
- Sending application, relay route and account eligibility: ______.
- Intended visible From and expected SMTP identity: ______.
- Provider-domain signing versus requested customer-domain identity: ______.
- Standard or custom selectors and complete CNAME mapping: ______.
- Existing-selector ownership and conflict resolution: ______.
- Current SPF baseline, retained senders and evaluated dependencies: ______.
- Evidence that all prerequisite DNS records are active: ______.
- Authorized activation request reference and provider response: ______.
- Non-sensitive message reference, trusted results and every signature: ______.
- Alignment assessment, unresolved delivery issue and rollback owner: ______.
- Independent reviewer and release decision: ______.
This worksheet is intentionally blank. Original evidence, human SME review, current source applicability, production-route validation, visual accessibility and owner release remain open. Documentation can justify a proposed workflow, but it cannot replace the account-specific observations needed to accept an implementation.