Decide which identity customers should see
WeFact documents two sender methods: a default mijnweFact identity and sending from the business's own email address. The default method carries the business's name while replies go to its own address. Custom-address sending requires domain authentication. Do not confuse a working reply destination with a custom authenticated From domain. WeFact sender methods.
Before editing DNS, ask the invoice-process owner to confirm the intended method and address. Record which administration and domain are involved, who can edit its settings, and who controls authoritative DNS. Inventory reminders, quotations and other outbound workflows separately. Their shared branding is not evidence of identical sender settings. Keep a baseline original message and the previous configuration so a change can be reversed without interrupting accounts receivable.
Obtain the personalized setup document
In the administration, open Instellingen and then SPF & DKIM. Choose domain validation and download the personalized instructions. Have the responsible DNS administrator publish the specified records. The public article does not supply a universal DKIM key or a complete universal DNS recipe, so this guide does not invent one. WeFact validation instructions.
Treat the downloaded instructions as a versioned change input. Record the domain, generation date, exact public owner names, record types and values. If the document names a different domain from the approved invoice address, stop and correct the configuration before publishing anything. Share only the public DNS setup information with the administrator, not a mailbox password or an unrelated invoice containing personal data.
Make the DNS change reviewable
Export the current zone and identify an existing SPF policy. If the instructions require an SPF include, merge the applicable mechanism into the one policy at the evaluated envelope domain rather than creating another v=spf1 record. Preserve other authorized senders. Validate syntax and lookup cost before approval. DKIM requires the actual selector and public key supplied for this domain, not a key copied from another administration. SPF, DKIM.
Check how the DNS editor handles relative owner names and TXT quoting. Query the authoritative service after saving, then follow the current WeFact verification workflow. Do not alter inbound MX routing as part of this change. Keep an existing DMARC policy intact unless a separately reviewed policy change is required for all senders on the domain.
Test a non-customer invoice workflow
Create a harmless test document through an approved test process and send it only to controlled recipients. Avoid creating a real collectible invoice or sending a payment reminder to a customer just to inspect mail headers. Capture both the document workflow and the received original, since the sender used by a preview can differ from the operational send path.
- Evidence: Administration; What to record: Approved sender method and address; Acceptance question: Was the intended custom identity selected?
- Evidence: Received message; What to record: From, envelope, all DKIM d= and s= values; Acceptance question: Which identity was actually used?
- Evidence: Receiver results; What to record: SPF, DKIM and DMARC outcomes; Acceptance question: Did a passing method align?
- Evidence: Reply test; What to record: Destination reached by a harmless reply; Acceptance question: Does the finance team receive responses?
The matrix is a synthetic test design, not a record of a real WeFact message. For From invoices@example.com, a validated DKIM d=example.com is an exact alignment example. A reply addressed to invoices@example.com does not itself prove that alignment. DMARC.
Restore the business workflow safely
If the message still uses the default identity, check the selected sender method and completion of the current validation flow. If the custom From appears but DKIM is absent, compare the configured domain and selector with the message before changing keys. If the signature fails, inspect the public key location and any modifying relay. Preserve a redacted sample for support rather than repeatedly sending live invoices.
If customer-critical delivery is affected, pause the relevant send workflow or restore the previous approved method with the finance owner's agreement. Recheck replies as well as authentication. Keep the personalized instruction document, DNS snapshots, test originals and acceptance sign-off together. Review them when the sender address, administration or DNS host changes. This guide is documentary and does not claim a live WeFact validation or delivery test.
Confirm the provider boundary
The public page establishes the two sender methods and personalized-document workflow, but not a universal selector, current account status or automatic switching rule. Keep those account-specific facts explicitly unresolved until the administrator supplies them. Verification of the downloaded domain is a separate decision from approving an invoice send.
Work through a fictional diagnostic case
Fictional written case only: WF-01 assumes the finance owner selected the default method and a harmless test invoice arrives with a provider-domain From while Reply-To is invoices@atelier.example. SPF and DKIM identities/results are unknown. A successful reply reaches finance but does not satisfy a requested custom From. The finance owner must approve the custom method, obtain the domain-specific setup document and verify a new controlled invoice route without creating a collectible debt. No account, DNS, CRM, invoice, campaign or delivery was tested for this case.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.