WeFact SPF, DKIM and DMARC setup, step by step

To authenticate email sent from your own address in WeFact, first choose that sender method, then open Instellingen > SPF & DKIM, select domain validation and download the personalized DNS instructions. Publish the records for that administration and domain, complete the current validation process, and check a controlled delivered message. The default mijnweFact method uses a provider sender identity with replies directed to your address; a working reply does not prove custom-domain authentication. WeFact sender methods and domain validation.

This guide is based on public documentation, not an accessed WeFact account or an executed DNS, invoice or delivery test.

Quick answers

• Where do I get the SPF and DKIM values? Download your personalized instructions from the selected administration's SPF & DKIM settings. Do not copy another company's selector or key.
• Must I change DNS for the default method? WeFact describes mijnweFact as the method that does not require your technical DNS changes. It is a different sender identity, not proof that your business domain is authenticated.
• What counts as complete custom-domain setup? The approved visible From address, passing and aligned branded DKIM, a DMARC pass, an understood SPF result and a working reply destination on the actual intended workflow.
• Can I use a template test? Yes for an initial layout and delivery check. Its fictitious document data and non-working personalized links do not establish that an operational invoice workflow is ready.

1. Choose the sender method before editing DNS

Confirm which identity customers should see. WeFact distinguishes two methods:

These choices are documented in WeFact's sender-quality guide. The display name and Reply-To address are not the domains that DMARC authenticates.

Record the administration, intended sender address, message types and responsible finance owner. Include quotations, invoices and reminders as separate test rows rather than assuming a successful invoice test proves all three. Check any distinct administration or brand independently. This is a testing boundary, not a claim that WeFact necessarily gives every workflow a different transport.

Before starting, have access to the relevant WeFact settings, the authoritative DNS service for the domain, the existing mail-sender inventory and controlled receiving mailboxes. Preserve the current settings and a redacted baseline original message. Obtain finance approval for a harmless test process that will not create a collectible debt, trigger a customer reminder or request an unintended payment.

2. Obtain and review the personalized instructions

In the intended administration, open Instellingen, choose SPF & DKIM, select the option to validate the domain and download the instructions. WeFact recommends giving these to the hosting company or IT administrator when they manage DNS. Official setup path.

Keep a dated copy and check:

1. The domain is the one intended for the sender address. A document for a different administration or domain is not interchangeable.
2. Every record has an exact owner name, record type and value. Identify whether the owner is the apex, a subdomain or a DKIM selector.
3. The SPF instruction can be reconciled with the existing sender inventory rather than pasted over it.
4. The DKIM public value belongs to this setup. Never generate a replacement key independently: WeFact's signer would need the corresponding private key.
5. Any instructions beyond SPF and DKIM are understood before they are applied. Do not change receiving MX records merely because you are authenticating outgoing invoice mail.

The public WeFact page does not establish a universal selector, public key, custom return-path feature or automatic identity-switch rule. Use the current personalized document and the administration's validation controls to settle those details. If they do not explain where a record belongs or how to finish activation, ask WeFact support for this administration's instructions before changing DNS.

3. Publish SPF without disrupting other senders

SPF checks the domain used by the SMTP envelope sender, normally shown by the trusted receiver as smtp.mailfrom and reflected in the delivered Return-Path. That can differ from the visible From address. Adding authorization to example.com does not affect an SPF check performed on a provider-owned envelope domain. Do not invent a custom bounce domain to force alignment. SPF identities, RFC 7208.

Use the exact SPF mechanism and owner in the personalized instructions after confirming the intended route. If that owner already has a policy beginning v=spf1, edit the one existing SPF policy and preserve other legitimate senders. Do not publish a second SPF policy or append an entire second v=spf1 ... all string. A terminal all mechanism must remain last; mechanisms after it cannot authorize a sender. Do not switch the existing ~all or -all decision as a side effect of adding WeFact. SPF record selection and evaluation.

The limit is ten evaluated DNS-dependent terms, including nested processing through include and redirect, not ten TXT records or ten literal includes. a, mx, ptr, exists, include and redirect consume this budget when evaluated. ip4, ip6 and all do not consume it. Separate limits apply to MX/PTR processing and void answers. Test every relevant sending path, including late matches that evaluate more of the policy. RFC 7208 section 4.6.4; trace the SPF evaluation path.

Do not flatten a provider include into today's IP addresses as a quick fix. That creates an obligation to track infrastructure changes and can miss future legitimate senders. Remove only confirmed obsolete authorizations, or review a maintained design with the domain's mail administrator.

4. Publish DKIM and complete validation

For DKIM, copy the public owner, type and value from the personalized document. If it specifies TXT, keep the supplied public-key value intact. DNS tools may display a long TXT value as several quoted strings within one record; that is different from creating multiple separate records with competing keys.

If the instructions instead specify a CNAME, preserve the exact target hostname. Do not convert it into a copied TXT key. A CNAME owner cannot coexist with ordinary TXT, A or other record data at that same name. If there is a collision, determine which service owns it before removal or replacement. DKIM key retrieval; CNAME constraints.

Check how your DNS editor adds the zone name. An example owner issued-selector._domainkey.example.com may need only issued-selector._domainkey in the example.com zone. For a separately delegated subdomain, work in the zone actually authoritative for that owner. A doubled suffix such as example.com.example.com publishes a different record.

For an illustrative issued owner issued-selector._domainkey.billing.example.com, a suffix-appending editor in the parent example.com zone needs issued-selector._domainkey.billing; an editor in the separately delegated billing.example.com zone needs issued-selector._domainkey. If the editor expects a fully qualified owner instead, use the complete issued name. The selector is a placeholder: keep the actual provider-issued selector and signing domain unchanged.

Only if your DNS service offers proxying or flattening for the supplied CNAME, keep this authentication record in ordinary DNS-only form and ensure the public answer still exposes the required alias. Do not globally disable website settings. A TXT instruction needs no proxy toggle.

After the authoritative records are correct, return to the current WeFact domain-validation workflow. Check its result and confirm the intended sender method and address are selected. The public documentation does not establish a universal activation button or guarantee that publication automatically changes the sender identity. Resolve unclear validation or activation states with WeFact before sending customer invoices. Application validation is a checkpoint; the delivered-message test below remains necessary.

5. Preserve DMARC and map its DNS owner correctly

DMARC compares the visible From domain with authenticated identifiers. A pass requires SPF pass plus SPF alignment, or DKIM pass plus DKIM alignment. Strict alignment requires identical domains; relaxed alignment requires the same Organizational Domain under the applicable discovery rules. Sharing a display name, Reply-To address or some trailing labels is not sufficient. Current DMARC standard, RFC 9989.

For custom-domain commissioning, require the intended branded DKIM signature to pass and align, as well as an overall DMARC pass. An aligned SPF result can make DMARC pass while a newly configured DKIM signer is still broken. Do not accept that as completed DKIM setup. RFC 9989 also requires valid DKIM for domains publishing p=reject, rather than relying on SPF alone. Interoperability requirements.

Keep any existing effective DMARC policy, including inherited policy and established reporting, unless its owner separately approves a change. When there is no established policy and a monitored introduction is appropriate, the owner can start with a single monitoring record. This is an illustration, not a WeFact-issued value:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and mailbox with an approved domain and a functioning report destination. In the example.com zone, the relative host is _dmarc, not @. For From invoices@billing.example.com, the direct policy owner is _dmarc.billing.example.com: enter _dmarc.billing in the parent example.com zone, or _dmarc in a separately delegated billing.example.com zone. Check direct and inherited policy before adding a child record, because a child policy can change the effective protection.

If reports go to an outside organization, it must authorize external reporting. For policy domain example.com and destination reports@reports.example.net, the authorization lookup is example.com._report._dmarc.reports.example.net; the report receiver publishes the authorizing TXT response containing v=DMARC1 or an applicable wildcard. Confirm the exact owner with the report service. Do not add this authorization under your own unrelated zone. RFC 9990 section 4.

Aggregate reports reveal sending infrastructure and authentication information. Use an approved reporting destination and access controls. A successful WeFact message does not justify enforcing policy on every other sender, and p=none does not itself protect against unauthenticated mail.

6. Check public DNS before sending

These are reader-run, read-only examples. Replace every .example name and selector with the exact approved values. ENVELOPE_DOMAIN is the actual SPF-evaluated domain, not automatically the visible From domain; DKIM_OWNER combines the actual selector and signing domain.

ENVELOPE_DOMAIN='actual-envelope.example'
DKIM_OWNER='issued-selector._domainkey.signing.example'
DMARC_OWNER='_dmarc.from-domain.example'
AUTH_NS='authoritative-nameserver.example'

dig +short TXT "$ENVELOPE_DOMAIN"
dig +short TXT "$DKIM_OWNER"
dig +short CNAME "$DKIM_OWNER"
dig +short TXT "$DMARC_OWNER"
dig @"$AUTH_NS" TXT "$DKIM_OWNER" +noall +answer

Use the authoritative nameserver for the exact record's zone; different owners can belong to different zones. For a CNAME setup, also query that authoritative server for CNAME and query the returned target for TXT. Compare authoritative answers with an independent recursive resolver after the old positive or negative cache TTL has expired.

Expected observations are one valid SPF policy at the evaluated owner, the issued DKIM key or correct alias chain ending in a usable key, and the intended DMARC policy at its actual owner. Empty answers, NXDOMAIN, SERVFAIL and different answers across authorities need investigation. A positive DNS lookup cannot demonstrate that WeFact signed any message.

7. Test layout, then the authorized invoice route

WeFact documents a layout-test route: Instellingen > Huisstijl, choose an item under E-mailberichten, select Testbericht versturen?, enter your controlled receiving address and save. The test uses fictional document data, and personalized payment or acceptance links are not usable. It is suitable for an initial check, not proof that those links or the operational sending path work. WeFact test-message instructions.

Next, use the finance-approved harmless workflow for the actual message type being commissioned. Do not send a reminder to a customer or create a real collectible invoice merely to inspect headers. WeFact explains that a genuinely sent quotation or invoice is needed to test its personalized links; any such test needs its own approved accounting treatment and controlled recipient. Authentication alone does not require paying an invoice or clicking an acceptance link.

Save the received original, not a forwarded copy. Trust only the receiving service's own Authentication-Results or its authenticated message-details view; sender-inserted results or quoted headers can be forged. RFC 8601 trust boundary.

A provider-domain SPF pass may be healthy yet unaligned. Distinguish it from spf=fail, softfail, neutral, none, temperror or permerror. Do not dismiss an actual SPF error because DKIM rescued DMARC. Record the cause and correct it or obtain a documented explanation of the route's limitation.

8. Troubleshoot and restore service safely

If business-critical mail is affected, pause the affected workflow or restore the previous approved sender method with the finance owner. Do not roll back the entire DNS zone and overwrite intervening changes. Revert only the affected change after checking dependencies. Preserve active DKIM records long enough for in-flight messages and coordinate retirement with the provider. Retest both authentication and replies after recovery.