Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Establish the mailing-list sender and service route
MailCamp stores the sender name, sender address and reply-to address in the mailing-list configuration. Its instructions use Mailinglijsten > Beheer Mailinglijsten to change them. When a campaign spans several lists, the final sender settings can also be reviewed in the send flow's advanced options. Record that final From address rather than assuming every selected list uses the same identity. MailCamp sender configuration.
Confirm whether the account is provided directly by MailCamp or through a reseller. Capture the account, sending list or segment, campaign or automation, intended domain and operator. Identify who controls DNS and who can pause the send. Preserve the current records and list settings before making changes. If the From domain changes, repeat the approval and authentication checks for the new domain; an authenticated old domain does not cover an unrelated replacement.
MailCamp says a newly introduced sender domain may require confirmation through an email before the list becomes active. That is a control-of-address step, separate from the DNS and cryptographic checks. Keep both statuses in the change worksheet, without treating the confirmation email as evidence of DMARC alignment.
Obtain the current DNS instructions for that route
MailCamp's checking guide distinguishes include:spf.mailcamp.nl for the direct service from include:_spf.emailclick.nl for resellers. It discourages an older hosting-provider include because that authorizes more addresses than necessary. Confirm the current choice for the actual account instead of adding all variants together. Preserve other authorized senders in the domain's existing SPF record. MailCamp record checks.
SPF must remain one policy at the evaluated DNS name. Review the complete result, including nested lookup costs, before publishing. Do not copy an IP range from a troubleshooting page as a permanent substitute for a provider-maintained include without agreeing how future changes will be maintained. Document the complete owner name, record type, value and old answer for every edit. SPF specification.
For DKIM, obtain the selector, record type and value from the current onboarding instructions or support confirmation. MailCamp's 2048-bit article shows CNAME examples and distinguishes mailrelay2048 from the older mailrelay selector. Other support material includes TXT-key examples, so the record type must be confirmed for the account rather than combined indiscriminately. Never publish a CNAME and a TXT key at the same selector name. MailCamp 2048-bit DKIM support.
Finish provider activation as well as DNS publication
MailCamp's checking instructions say to report that the records have been created and checked so the provider can add the DKIM configuration to its sending server. This is a separate completion step: a public key in DNS cannot sign a message by itself. Check the exact selector issued to the account and retain confirmation that signing is active. MailCamp record checks.
The mailing-list overview may lag behind DNS changes. MailCamp describes daily checks and a fresh check when the list is edited and saved. Before changing records again, distinguish a stale account indicator from a malformed record or a cache that still has the old answer. Recheck the authoritative owner name and avoid changing unrelated list settings merely to trigger a check. MailCamp verification delays.
Inspect alignment before changing DMARC
MailCamp publishes a troubleshooting recommendation to remove aspf=s when strict SPF alignment causes problems. Do not apply that recommendation without inspecting the actual envelope and DKIM identities. Removing aspf=s changes the domain's SPF alignment mode to its relaxed default and can affect more than MailCamp. A valid aligned DKIM signature may already satisfy DMARC even if SPF does not align. MailCamp strict-SPF guidance and DMARC specification.
SPF checks the envelope identity, not simply the sender address shown to the recipient. DKIM uses the signing domain in d= and the selector in s=. DMARC requires one aligned passing path. The reviewed setup sources do not establish a universal customer-configurable Return-Path workflow for every MailCamp or reseller route. Leave that capability unconfirmed until current account guidance and a received message establish it. DKIM specification.
Verify the exact campaign and retain a recovery route
Original acceptance worksheet, not an executed test: send harmless content to controlled external recipients through the actual list, combined-list segment or automation being changed. Record the final From address, account, workflow, timestamp and message identifier. Preserve the original received message. Build an identity table with the visible From domain, Return-Path, SPF identity and result, every DKIM d= and s= pair, and the trusted receiver's DMARC result.
Compare the passing identities with the domain's actual alignment modes. For combined lists, verify the final sender selected by the send process. Separately send a controlled reply to check the intended reply-to destination. If the message is unsigned or has the wrong selector, confirm provider-side activation before repeatedly rewriting DNS. If a domain transition fails, pause the affected workflow and restore the previously verified list settings and DNS changes covered by the recovery plan.
No MailCamp tenant, authoritative DNS answer or received message was tested here. Exact direct/reseller scope, current DKIM record form and activation, custom-envelope capability where needed, and the received-message identity table remain evidence gates. Independent technical review and human SME approval are pending before publication or production acceptance.