MailCamp SPF, DKIM and DMARC setup, step by step

For MailCamp, first identify the mailing list's actual sender and whether the account is direct or reseller-provided. The documented SPF permissions are include:spf.mailcamp.nl for direct accounts and include:_spf.emailclick.nl for reseller accounts. Publish the DKIM selector and record supplied in your current onboarding instructions, then confirm MailCamp has enabled signing on its sending server. DNS publication alone does not complete setup. MailCamp record checks

This guide covers the MailCamp platform at mailcamp.nl, its mailing-list sender settings and the documented reseller variant. The MailCamp DKIM selector named mailrelay is not a reason to use Mailrelay.com's DNS instructions. Keep these two services separate.

No authenticated MailCamp account, customer DNS zone or delivered-message headers were tested for this guide.

Establish the sender before asking for DNS changes

In MailCamp, open Mailinglijsten → Beheer Mailinglijsten and inspect the list's sender name, sender email and Reply-To address. When sending to multiple lists or a segment spanning lists, review the final sender in the send process under Meer Opties → Geavanceerde Instellingen (Optioneel). The final campaign identity matters more than the identity of one selected list. MailCamp sender configuration

If the sender domain changes, authenticate the new domain before using it. MailCamp says a newly introduced domain may also need confirmation through an email to the new sender address before the list becomes active. This confirms control of an address; it does not prove that DNS is correct or that messages are signed and aligned.

Collect the current onboarding DNS instructions from MailCamp or the reseller responsible for your account. Confirm:

• The exact From domain and whether it is a root domain or a subdomain.
• The applicable SPF include, DKIM selector, record type and complete value.
• Whether signing activation is pending, automatic or awaiting provider action for this account.
• Any supported custom envelope/Return-Path configuration, if SPF alignment is a requirement.
• The DNS administrator and an owner who can pause the campaign or automation.

Keep a copy of existing SPF, DKIM and DMARC records and list settings. Adding MailCamp must not remove Google Workspace, Microsoft 365 or another legitimate sending service. Preserve existing mailbox-routing MX records.

For a distinct employee-mail path, preserve and test the Microsoft 365 authentication configuration if that service sends your mail. MailCamp settings do not configure that tenant.

Choose the correct MailCamp SPF authorization

MailCamp's checking guide distinguishes these permissions:

These are mechanisms, not three records to publish. Do not remove an older include if it still authorizes another live system. Review the complete sender inventory before narrowing permissions. Direct and reseller SPF guidance

SPF belongs at the exact owner specified for the route. If a sending subdomain needs its own policy, a root-domain SPF record is not inherited. Merge approved mechanisms into one v=spf1 TXT record at that owner. Preserve unrelated TXT records, existing authorized senders and the intended terminal qualifier. Multiple separately published SPF records cause a permanent error. SPF record selection

A safe change worksheet records the full old policy, the proposed single policy and why each authorization remains. Put an added include before the terminating all mechanism, not after it. Do not paste two complete policies together or add an extra all. ~all produces softfail for an unmatched server, not an authorization pass; -all produces fail. SPF evaluation

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

Check the full SPF lookup cost

The ten-term limit applies to evaluated DNS-query-causing mechanisms and modifiers, including nested includes and redirects, not simply ten visible include strings. Check the full dependency chain. Start by identifying genuinely retired senders if the limit is exceeded. SPF lookup limits

MailCamp's lookup troubleshooting page discusses replacing includes with IP ranges. Treat such flattening as a maintenance decision, not a permanent copy-and-paste fix: a stale IP list can break authentication when a provider changes infrastructure. Do not remove an active sender solely to make a checker green. MailCamp lookup troubleshooting

Obtain the current DKIM selector, type and value

MailCamp documents both mailrelay2048 and the older mailrelay selector. Its 2048-bit support article gives these CNAME examples:

2048-bit example
Owner: mailrelay2048._domainkey.example.com
Type: CNAME
Target: dkim1-di.rect.to.

Older selector example
Owner: mailrelay._domainkey.example.com
Type: CNAME
Target: dkim2-di.rect.to.

These illustrate the documented options; they are not instructions to install both. Confirm which selector and record form your account has been issued. MailCamp recommends the 2048-bit option, but a selector change also requires the sending server to use the matching key. Publishing a new selector without coordinating signing activation is insufficient. MailCamp 2048-bit DKIM support

Other MailCamp support material includes TXT-key examples. For a TXT-based configuration, copy the complete public key from the current onboarding message or confirmed account instructions, not a public article's example. For a CNAME-based configuration, publish the exact issued target instead. Do not combine the two forms at the same owner.

The verification-delay page's displayed 2048-bit TXT example contains a duplicated key prefix. Do not reproduce that malformed example or try to repair a copied key by guessing. Request the current complete record if the supplied value is ambiguous. A selector lookup must match the actual selector issued, not whichever example happens to be on an older checker page. MailCamp verification-delay guidance

Only public verification material belongs in DNS. Never publish a private DKIM signing key. If a TXT value is long, the DNS host may store it as multiple quoted character strings in a single record; DKIM concatenates those strings. That differs from creating multiple competing key records. DKIM public-key DNS representation

Finish provider-side signing activation

MailCamp's record-checking guide instructs customers to tell the provider when the DNS records have been created and checked so it can add the domain's DKIM configuration to the sending server. Retain confirmation that the correct domain and selector are active. A key in public DNS cannot sign a message on its own. Provider activation step

The newer lookup guide also describes DNS-checker results that distinguish a newly added domain from one correctly configured in the MTA, MailCamp's sending server. For a newly added domain, it recommends allowing roughly four hours for synchronization where possible. Use that as operational guidance, not proof that activation succeeded or a universal deadline. Confirm the current account's status, follow any required provider handoff and then inspect a delivered message. MailCamp sending-server status

Mailing-list indicators can lag: MailCamp describes checks every 24 hours and a fresh check when a list is edited and saved. An authorized operator can re-save the intended list without changing unrelated settings to request that check. If the indicator stays red, compare DNS and activation evidence before republishing records. List verification timing

Publish at the exact DNS owner, including subdomains

Use these examples to translate a full record owner into the name accepted by your DNS panel. SELECTOR means the actual issued selector, not text to publish.

A panel accepting full names may need no shortening. Check the final saved owner to prevent example.com.example.com suffix mistakes. @ means the apex of the current zone, not always your company's root. If the child is delegated to separate nameservers, edit the child's authoritative zone; preserve the parent delegation. DNS authority and zones

If _domainkey.news.example.com itself is delegated, the full owner SELECTOR._domainkey.news.example.com is relative SELECTOR in that zone. Retain the existing NS delegation and publish at its authority.

Do not delete existing selectors belonging to another sender. At a CNAME owner, ordinary TXT, A, AAAA and MX data cannot coexist with that alias. Do not replace a functioning selector without coordinating its retirement. A normal zone apex already has SOA/NS data, so do not place a DKIM or bounce CNAME there. DNS alias rules

If your issued record is a CNAME and Cloudflare hosts the zone, keep it DNS-only and unflattened, checking both per-record and zone-wide flattening options. Verification needs the alias, not substituted proxy addresses. Coordinate any shared-setting change before applying it. Cloudflare CNAME checks

For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

Check SPF identity and DMARC alignment separately

SPF evaluates the envelope MAIL FROM identity, usually reflected in Return-Path, rather than the visible sender address. DKIM authenticates the signing domain in d= using the selector in s=. Reply-To, display name and a branded link are separate identities. SPF identity and DKIM signature fields

The reviewed MailCamp documentation does not establish a universal self-service custom Return-Path procedure for all direct and reseller accounts. If branded SPF alignment is required, ask the account provider to confirm support, the exact envelope domain and its configuration. Do not invent a bounce CNAME or assume the From-domain include changes the envelope.

MailCamp recommends removing aspf=s in a strict-alignment troubleshooting article. Do not make that domain-wide change automatically. First inspect the actual SPF and DKIM identities and the effective DMARC policy. Removing aspf=s switches SPF alignment to its relaxed default; it does not repair an actual SPF failure and it does not make unrelated provider domains align. MailCamp strict-SPF guidance

For From: news@example.com, an SPF pass for bounce.example.com can align in relaxed mode but not strict mode. A DKIM pass with d=example.com aligns in either mode. DMARC needs at least one passing aligned path, so working branded DKIM may already satisfy DMARC without weakening SPF alignment. Have the domain owner assess any mode change across all senders. DMARC alignment rules

Preserve DMARC policy and approve report destinations

Inspect the exact From-domain policy and any inherited parent policy. Preserve established quarantine or reject protection; do not replace it with a monitoring example just to complete MailCamp setup. Adding a child-domain policy can also override stronger inherited protection. DMARC policy discovery

For a domain without an established applicable policy, an owner-approved monitored rollout could use this shape:

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

Replace the example address with a real managed mailbox or reporting-service destination. Publish one applicable DMARC record at that owner. A p=none policy without rua does not request aggregate reports, and a monitoring policy does not guarantee delivery.

For the approved first policy at From example.com, full TXT owner _dmarc.example.com maps to _dmarc in that zone. For From news.example.com, full owner _dmarc.news.example.com maps to _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve any existing direct or inherited policy; this mapping does not authorize a child monitoring override.

MailCamp offers a DMARC wizard and documents its own report destinations. Sending reports there is a separate information-sharing choice, not a required reason to replace your current reporting service. Review external-recipient authorization and access before adding addresses. Forensic reports can contain more sensitive message information; do not add ruf or related failure-report options mechanically. MailCamp DMARC reporting and aggregate-report authorization

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Read aggregate reports for all legitimate sources and repair authentication/alignment before a separate enforcement decision. Keep the valid policy spelling quarantine; do not use the Dutch spelling found in some explanatory text as a DNS value.

Verify DNS and a real MailCamp message

First: public DNS and provider status

Replace every uppercase placeholder with the appropriate account/domain value. Query the authoritative parent or delegated child zone, then a recursive resolver. These commands are examples only.

dig NS ZONE +short
dig @AUTHORITATIVE-NS SENDING-DOMAIN TXT +noall +answer
dig @AUTHORITATIVE-NS SELECTOR._domainkey.SENDING-DOMAIN CNAME +noall +answer
dig @AUTHORITATIVE-NS SELECTOR._domainkey.SENDING-DOMAIN TXT +noall +answer
dig @RECURSIVE-RESOLVER SELECTOR._domainkey.SENDING-DOMAIN TXT +noall +answer
dig @AUTHORITATIVE-NS _dmarc.SENDING-DOMAIN TXT +noall +answer
dig @RECURSIVE-RESOLVER ACTUAL-MAIL-FROM-DOMAIN TXT +noall +answer

For a TXT-based DKIM route, no CNAME answer is expected. For a CNAME route, require the issued alias and a usable key at its destination. Confirm the complete key or target, not only the first few characters. Check one SPF policy, its full lookup chain, the correct DMARC policy and MailCamp signing activation.

If a shortened lookup is blank, repeat it with full output. NXDOMAIN, no matching record, SERVFAIL and timeout call for different fixes. Compare authoritative answers and cache TTLs; lowering TTL now does not erase answers already cached with an older TTL.

Then: the actual list, segment or automation

Use harmless content and controlled external recipients. Keep the original received message and read the trusted receiver's Authentication-Results. A familiar authserv-id or a header's position is not proof of origin: both can be forged. Use only results your receiving system or administrator confirms were added inside its trusted boundary, with untrusted look-alike fields removed. Authentication-Results trust boundary

A DMARC pass via SPF does not excuse missing or broken branded DKIM. A provider-domain DKIM pass does not prove the intended branded signing setup. Conversely, SPF can pass yet remain unaligned while branded DKIM satisfies DMARC. Document that distinction. DMARC pass conditions

Investigate actual SPF fail, softfail, neutral, none, temperror and permerror, even when DKIM passes. Check the precise evaluated envelope owner, duplicates, syntax, lookup limits, DNS availability and sender authorization. If the owner is provider-controlled, supply the direct-message result, timestamp and connecting IP to MailCamp or the reseller. Compare direct delivery with forwarded delivery before broadening SPF. Do not label a real SPF error “alignment only.”

Diagnose SPF at the actual smtp.mailfrom independently, even when aligned DKIM supplies DMARC pass. fail or softfail calls for checking whether the connecting sender is authorized for that envelope route; temperror indicates transient evaluation trouble such as a DNS timeout; permerror calls for checking malformed syntax, duplicate policies and the evaluated DNS-term budget. A passing but unaligned SPF identity is a separate condition. SPF result meanings.

Troubleshooting MailCamp setup

Pause the affected workflow if the intended identity is not verified. Restore only the recorded settings covered by your recovery plan. Keep old selectors until the provider has changed signing and assessed messages still in transit.