E-Zorg SPF, DKIM and DMARC setup, step by step

On this page: Choose the correct mailbox and relay branch · Add the E-Zorg SPF authorization safely · Understand default signing before requesting customer-domain DKIM · Publish both DKIM CNAMEs before activation · Request activation and confirm its scope · Preserve DMARC and evaluate alignment · Run DNS and delivered-message acceptance checks · Troubleshooting and recovery · Frequently asked questions · Documentation review and testing boundary

Quick answer: For mailboxes hosted by E-Zorg, its documented SPF authorization is include:_spf.ezorg.nl, merged into the appropriate existing SPF policy. For customer-domain DKIM on an eligible E-Zorg relay, publish both required CNAMEs and verify they are live before requesting activation. The relay's default signature uses ezorg.nl; that alone does not establish alignment with your own From domain. E-Zorg SPF instructions, E-Zorg relay DKIM instructions

This guide separates E-Zorg-hosted mailboxes from explicitly connected relay domains. It does not assume that an E-Zorg network connection authorizes every mailbox or application to use E-Zorg's sending servers, or that every healthcare messaging product has the same signing workflow.

Choose the correct mailbox and relay branch

Establish who hosts your mailboxes and which system actually submits each message to the public internet. An application's From address, the network it uses and its SMTP relay can identify three different services.

E-Zorg explicitly directs externally hosted mailboxes to their own hosting provider's outgoing server. Its separate DKIM article covers connected smtpnodes.ezorg.nl domains and describes signing for inside-relay and Zorg Messenger SMTP traffic. Resolve that product boundary with the service owner rather than treating the relay article as permission to reroute externally hosted mail. Mailbox hosting and SPF, Relay scope

Before changing DNS, record the domain, mailbox provider, sending application, SMTP route, current From domain and known envelope identity. Have the authorized account owner confirm which relay arrangement is active. Gather access to the authoritative DNS service and the current SPF, DKIM and DMARC records. No mailbox password, patient data or private signing key is needed for a DNS plan.

Add the E-Zorg SPF authorization safely

For an E-Zorg-hosted mail domain, the provider documents this component:

include:_spf.ezorg.nl

This is a mechanism to add to an appropriate SPF policy, not a standalone TXT record. E-Zorg's published example includes other mechanisms and a final qualifier; do not assume that sample describes your complete sender inventory. Official SPF authorization

SPF usually checks the SMTP envelope MAIL FROM domain against the connecting sender's IP. The visible From address is separate. Confirm the evaluated domain from trusted receiver results as smtp.mailfrom; a null reverse-path uses the HELO identity. If the route uses a provider-owned envelope domain, changing your apex SPF does not rewrite that identity. The public E-Zorg instructions do not establish a universal customer-configurable Return-Path procedure. RFC 7208 identities

1. Identify the SPF owner that applies to the intended E-Zorg mail flow. Do not automatically substitute the From domain for an observed envelope subdomain.
2. Query its existing TXT records. Retain a copy of the complete policy and the authorizations used by other legitimate senders.
3. Add include:_spf.ezorg.nl only for the confirmed applicable route. Merge it into the existing policy before its terminal all; keep the established qualifier. Do not replace another supplier's policy or create a second full v=spf1 record.
4. For a genuinely new owner, build one policy containing all approved senders with the domain administrator. The E-Zorg include alone is not evidence that an application has relay access.
5. Save the reviewed TXT value at the authoritative DNS provider. Verify its public owner and full value before treating the publication as complete.

There must be one selectable SPF policy per evaluated owner. Unrelated TXT verification records can stay. A single TXT record may contain multiple character strings, joined without inserted spaces; the 255-octet limit applies to an individual string, not necessarily the whole SPF policy. This corrects an overbroad size shorthand in the provider's explanatory article. RFC 7208 sections 3.2–3.3

Count the ten evaluated DNS-dependent terms across the evaluation, including nested include and redirect work. The affected terms are include, a, mx, ptr, exists and redirect; ip4, ip6 and all do not consume that term budget. Too many produces permerror. RFC 7208 processing limits

Do not alter ~all or -all just to match an example. Those produce SPF results when evaluated; they do not themselves force every receiver to accept or reject mail. For existing duplicate policies, follow the SPF merge guide.

Understand default signing before requesting customer-domain DKIM

E-Zorg says mail from connected domains through the documented relays is signed with selectors ezorgmail1 or ezorgmail2 and the signing domain ezorg.nl. It also notes that additional signing may occur when its spam filters sign the domain. E-Zorg's default signing behavior

A fictional message from appointments@example.com with dkim=pass for d=ezorg.nl has authenticated E-Zorg's signing domain. It has not established DKIM alignment with example.com. An aligned SPF pass could still satisfy DMARC, but neither a provider signature nor successful delivery proves that customer-domain DKIM is active. DMARC identifier alignment

Before activation, confirm with E-Zorg the domain it will sign as, the included relay routes and the selectors it will use. The acceptance target is the agreed customer-domain signing identity, not merely the presence of any signature. Keep a separate row for each additional signature instead of treating multiple signatures as an automatic error.

Publish both DKIM CNAMEs before activation

For E-Zorg's standard selector option, the official records are:

These public targets are E-Zorg's documented standard mappings, not values inferred from another customer. They belong beneath the customer domain being configured. For a fictional signing domain example.com, the complete owners are ezorgmail1._domainkey.example.com and ezorgmail2._domainkey.example.com. Official CNAME pair

E-Zorg also supports custom selector names using its keys. Arrange the exact approved names and their mapping with E-Zorg; do not copy the documentation's eigenselector1 and eigenselector2 examples as universal production values.

1. Identify the authoritative zone for the intended signing domain. If the signing domain is mail.example.com within the example.com zone, a relative first owner is ezorgmail1._domainkey.mail. In a separately delegated mail.example.com zone, it is ezorgmail1._domainkey instead.
2. Check both intended owners for existing records and service dependencies. Save the baseline before changing anything.
3. Create each CNAME using the correct owner entry for your DNS editor and the exact corresponding target. Avoid an automatically repeated zone suffix. Where a DNS provider offers a web-proxy option, use ordinary DNS resolution for these aliases, not web proxying.
4. Preserve selectors used by other senders. A CNAME owner cannot coexist with ordinary TXT, A, MX or another conflicting record. Resolve a collision with the service owners or an approved custom selector; do not delete working records blindly.
5. Query both complete owners publicly and check that their target key records resolve. Only then continue to activation.

The CNAME constraint is a DNS rule; the key lookup uses the selector and signing domain, not the From display name. Never publish a private signing key. CNAME coexistence, DKIM DNS lookup

Request activation and confirm its scope

E-Zorg explicitly requires the records to be active before the form is submitted and before DKIM is activated. Publishing one selector, submitting the request and planning to add the other later does not meet that prerequisite. Activation prerequisite

Use E-Zorg's DKIM relay-domain request form through an authorized account owner:

1. Enter the domain or domains for the approved relay arrangement. The form currently allows up to 25 domain entries.
2. Choose Activeren for activation, rather than the change or deactivation options.
3. Select standard settings or the approved custom-selector option. Supply a custom selector only when its exact mapping is agreed.
4. Confirm the required DNS-record checkbox only after the complete public record set is verified.
5. Provide the organization, customer number, requester name and contact email requested by the form, then submit the approved request.
6. Retain E-Zorg's response and confirm the intended signing domain and covered routes. A submitted form is not proof that activation has completed.

The knowledge-base page also directs domain setup questions to helpdesk@ezorg.nl. Do not send credentials or clinical message contents. After E-Zorg confirms the change, run the delivered-message acceptance checks below; the actual d= domain and selector must match the confirmed arrangement.

Preserve DMARC and evaluate alignment

DMARC passes when an authenticated SPF or DKIM identifier aligns with the visible From domain. Relaxed alignment permits the same organizational domain; strict aspf=s or adkim=s requires an exact match for that mechanism. With From example.com, an envelope domain bounce.example.com can align in relaxed mode but not strict SPF mode. ezorg.nl does not align with the unrelated example.com in either mode. RFC 9989 alignment definitions

Do not invent a custom envelope-domain setting to resolve a mismatch. Ask E-Zorg which envelope identity the approved route actually uses. If an aligned DKIM pass supplies DMARC, SPF can be unaligned without making DMARC fail; nevertheless, investigate genuine SPF errors separately. See custom MAIL FROM and alignment.

Review the existing applicable DMARC policy before publishing anything. For From example.com, the direct owner is _dmarc.example.com: enter _dmarc in the example.com zone when the DNS editor appends the zone suffix. For From mail.example.com, it is _dmarc.mail.example.com: enter _dmarc.mail in the parent zone, or _dmarc in a separately delegated mail.example.com zone. Publish in the actual authoritative zone.

An absent child record does not prove that no DMARC policy applies; parent policy discovery can supply one. Preserve existing or inherited enforcement, reporting destinations and alignment modes. Do not replace a working policy with p=none to make onboarding seem easier. A new monitoring policy is a deliberate option only where no applicable established policy exists and reporting will be reviewed. DMARC policy discovery and domain-owner actions

Only if there is no existing direct or inherited DMARC policy, a new approved monitoring deployment can start with this minimal illustrative TXT value at the correct owner:

v=DMARC1; p=none

This alone does not request reports. For approved aggregate reporting, append ; rua=mailto: followed by the actual approved destination address, not a sample address or placeholder. Keep established reporting and policy settings when they already apply. DMARC policy syntax

Use a report destination your organization has approved. An external aggregate-report recipient must provide the necessary DNS authorization described in RFC 9990 section 4. Review aggregate reports across all legitimate senders before considering enforcement changes. Avoid patient information in troubleshooting or reporting examples.

Run DNS and delivered-message acceptance checks

Replace these fictional domains and the nameserver placeholder with actual values. Use custom selectors instead if E-Zorg approved them. These commands illustrate read-only checks for the authorized operator; no customer lookup was performed for this guide.

AUTH_NS='replace-with-authoritative-nameserver'
SPF_OWNER='example.com'
SIGNING_DOMAIN='example.com'
DMARC_OWNER='_dmarc.example.com'

dig @"$AUTH_NS" "$SPF_OWNER" TXT +norecurse
dig @"$AUTH_NS" "ezorgmail1._domainkey.$SIGNING_DOMAIN" CNAME +norecurse
dig @"$AUTH_NS" "ezorgmail2._domainkey.$SIGNING_DOMAIN" CNAME +norecurse
dig "ezorgmail1._domainkey.$SIGNING_DOMAIN" TXT
dig "ezorgmail2._domainkey.$SIGNING_DOMAIN" TXT
dig "$SPF_OWNER" TXT
dig "$DMARC_OWNER" TXT

Repeat against each delegated authoritative server and compare recursive answers. Both CNAME owners must map to their corresponding E-Zorg targets, and recursive lookups must reach public key material. A source authority may return only the CNAME because the target lies in another zone. Check full response status, not just blank short output: NXDOMAIN, an empty answer, timeout and SERVFAIL are different findings. Save timestamps and TTLs; caches may temporarily retain earlier records or absence.

After activation confirmation, send a non-sensitive test through each relevant mailbox/application/relay path to a mailbox you control. Inspect the trusted receiving system's raw headers. Do not reuse a pre-activation message as proof that the new configuration works. Trusted authentication results

For customer-domain DKIM commissioning, require that intended signature to both pass and align. Do not mark DKIM activation successful merely because DMARC passes through SPF. SPF fail, softfail and none are different from an SPF pass that is unaligned: investigate unexpected authorization failures, missing policy or evaluation errors even when DKIM supplies DMARC. If the message never arrives, investigate the sender's submission and delivery response separately; absence is not proof of a DKIM or alignment failure. Authentication also does not guarantee inbox placement or establish that message content is safe.

Troubleshooting and recovery

If a DNS edit breaks a working sender, compare it with the saved baseline and restore only the affected approved records, accounting for intervening changes. Coordinate any selector or activation rollback with E-Zorg. Keep working old selectors until their use is resolved, and repeat DNS and message tests after recovery. Do not weaken DMARC or remove forwarding automatically as a troubleshooting shortcut.

Documentation review and testing boundary

No account was accessed, form submitted, support message sent, DNS changed, customer domain queried or email sent. The activation and acceptance steps remain actions for the authorized account and DNS owners.