MAILINGWORK SPF, DKIM and DMARC setup, step by step

To authenticate a MAILINGWORK newsletter domain, create it under Administration > DKIM and Sender Domains, publish the generated DKIM key and the required SPF and MX records, verify the domain, and select it in the mailing's settings. MAILINGWORK documents include:_spf.sendnode.com for its sending subdomains and the MX destination mail10.sendnode.com.. The DKIM key and selector belong to your configuration, not to a universal example. Official sender-domain setup; required DNS records.

This guide covers newsletters sent by MAILINGWORK using its native sender-domain feature, including domains shared with tenant subaccounts. It does not configure your everyday mailbox service or authenticate mail sent by an unrelated integration. No customer account, DNS zone or delivered message was tested.

Plan the sending subdomain before changing DNS

Use a domain you control, preferably a dedicated subdomain such as news.example.com. Its sender address might be updates@news.example.com. MAILINGWORK recommends a sending subdomain; its DNS requirements include inbound mail routing as well as outbound authentication. Sender-domain setup.

Before creating anything, have the DNS owner record:

• The exact intended From domain and all existing mail services using it.
• Its TXT, MX and CNAME records, existing DKIM selectors, and authoritative nameservers.
• The applicable DMARC policy, including inherited policy, alignment settings and reporting recipients.
• Whether news.example.com is managed inside the example.com zone or delegated to different nameservers.
• Where human replies and automatic replies should arrive.

Do not replace your company's working MX records with MAILINGWORK's MX destination. An MX change redirects incoming mail for that exact domain. An unused dedicated subdomain avoids many conflicts, but confirm that no mailbox, bounce service, website alias or other application already depends on it. If it is in use, choose a different subdomain or obtain a reviewed migration plan.

The detailed manual says the sender-domain menu is available in all accounts without extra rights or requirements. In a tenant system, however, the administrator controls sharing with subaccounts. If a shared domain cannot be edited in a child account, work through the parent administrator rather than duplicating its DNS. Detailed MAILINGWORK manual.

Create the domain and its DKIM key

1. Open Administration > DKIM and Sender Domains and create a sender domain.
2. Enter the domain only, for example news.example.com, not a full email address or an HTTPS URL. Check it carefully: the domain cannot be changed after creation.
3. Choose whether this is the account's default sending domain. This changes a default, not the authentication of every existing mailing.
4. Choose a unique DKIM selector that does not collide with another sender. A simple alphanumeric label avoids differences between the help pages' descriptions of allowed characters.
5. Choose 2048 bits where supported. MAILINGWORK documents 1024 and 2048 bits and recommends 2048. The selector and key length cannot be edited after creation.
6. Configure forwarding to a monitored mailbox, save, and open the generated DNS instructions.

The current help center describes these creation fields; the detailed manual supplies the account and mailing-selection behavior. Copy your own generated owner and complete public key, not a key from an illustration. MAILINGWORK keeps the private key. Creation fields; domain-management details.

For replies, MAILINGWORK supports forwarding to the parent-domain address or a specified address; ensure the destination mailbox exists. Its current help also offers no forwarding, which can lose replies. A mailing's Reply-To can direct normal replies to another mailbox. Reply handling is separate from the envelope identity used by SPF. Reply-management options.

Before saving or activating forwarding, obtain the mail owner’s separate approval of the exact destination address and what replies it will receive. Reconcile the chosen parent-domain or specified-address option with that approved recipient, not merely with a mailbox that exists. Stop on a mismatch; do not enable no-forwarding or redirect messages to another recipient as an incidental authentication fix.

Publish the right records at the right names

The following names illustrate a dedicated news.example.com sending domain. Replace them with the actual domain and selector from your account.

MAILINGWORK's record reference provides the SPF mechanism, MX destination and account-generated DKIM process. The detailed manual says to specify an MX priority; it does not establish a universal number to invent here. DNS record reference; DNS configuration details.

SPF: new policy or careful merge

For a genuinely new subdomain used only by this MAILINGWORK route, its documented SPF example is:

v=spf1 include:_spf.sendnode.com -all

Publish that as TXT, not the obsolete SPF resource-record type. If a v=spf1 policy already exists at the same owner, do not add a second one. Add the authorization to the existing policy, before its terminal all, while preserving other legitimate senders and the intended failure qualifier. A policy using redirect= needs evaluation of its existing logic rather than blind string concatenation.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

An SPF policy is specific to its owner name: the root domain's policy does not automatically cover a sending subdomain. Unrelated TXT records may remain. Multiple quoted strings forming one TXT record are also different from two separate SPF policies. RFC 7208, SPF records.

Check the complete SPF evaluation against the limit of ten DNS-lookup-causing terms, including nested include and redirect processing. Counting only the visible includes is insufficient. a, mx, exists and ptr can also consume that budget; literal ip4, ip6 and all do not. Exceeding the limit can produce permerror. Do not freeze provider infrastructure into a copied IP list as a casual workaround. RFC 7208, DNS lookup limits.

DKIM: keep the key and owner intact

For a chosen selector mw2026, an illustrative fully qualified owner is mw2026._domainkey.news.example.com. In the example.com zone, a DNS editor that automatically appends the zone might require mw2026._domainkey.news. In a delegated news.example.com zone, it might require mw2026._domainkey. Use the DNS host's input convention and then query the fully qualified name to confirm the result.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Copy the complete key from MAILINGWORK, including its tags. Do not add a second competing key at the same selector or overwrite another service's key. A DNS interface may split a long TXT value into character strings within one record; the reconstructed value must be unchanged. If the interface rejects the key, have the DNS host explain its supported format before choosing weaker settings or recreating the domain.

MX: protect existing inbound mail

The MAILINGWORK MX belongs to the selected sending subdomain, not automatically to the root. Obtain the complete intended MX set from the account instructions or MAILINGWORK Support and have the DNS owner approve it: every fully qualified owner, numeric priority and target must be specified. Do not invent a priority or assume that the expected target is the only relevant record. A trailing dot identifies an absolute target in zone-file notation; check that the DNS editor has not appended your domain to it. Do not leave unrelated MX destinations at the same owner without an intentional routing design.

If the chosen subdomain is already a CNAME, it cannot also host these TXT and MX records. Resolve the conflict with the DNS owner, usually by choosing an unused sending subdomain, rather than deleting a working alias.

Retain the existing DMARC policy

Check direct and inherited DMARC before using MAILINGWORK's suggested records. Its interface offers standardized policy examples, but an example does not authorize replacing an existing policy, removing report destinations, or weakening a parent policy with a new child record. MAILINGWORK DMARC guidance.

Only if no direct or inherited policy applies, and the domain owner approves a first observation-stage policy, this minimal example uses a TXT record at _dmarc.news.example.com:

v=DMARC1; p=none

This requests no DMARC-based enforcement and requests no reports. It is not a promise that messages will be accepted. Add rua only for an approved reporting destination you control or have contracted to use. A destination outside the applicable organizational domain needs the required receiving-domain authorization. Review access, retention and privacy before collecting reports; do not copy somebody else's reporting address or enable detailed failure reports by default.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

Retain existing adkim, aspf and subdomain-policy decisions. Strict alignment requires exact domain matching; relaxed alignment uses the applicable organizational-domain relationship. Move toward enforcement only after evaluating all legitimate senders, not just this newsletter service. DMARC identity and policy rules; aggregate-report authorization.

Verify DNS, then select the domain in the mailing

Query the public records using your actual values. These are inspection commands, not DNS changes:

dig +short TXT news.example.com
dig +short TXT mw2026._domainkey.news.example.com
dig +short MX news.example.com
dig +short TXT _dmarc.news.example.com

For an explicit MX comparison, query the authoritative server for the actual delegated zone and a recursive resolver. Replace ns1.dns-host.example below with that zone's real authoritative nameserver; the second command uses your configured resolver. Repeat the authoritative query against the other nameservers serving the zone.

dig @ns1.dns-host.example +norecurse +noall +answer MX news.example.com
dig +noall +answer MX news.example.com

Accept the MX setup only when the complete returned owner/priority/target set matches the DNS-owner-approved configuration from the account or Support. Merely finding mail10.sendnode.com. somewhere in the answer is insufficient: investigate additional destinations or different priorities before accepting it. Preserve the approved inbound-mail design; do not remove a legitimate destination simply to force a match to an incomplete example.

Check authoritative and recursive answers for the other records too: one SPF policy, the intact generated DKIM key, and the correct DMARC policy or inheritance. Use the TTL and negative-cache timing to interpret differing answers; repeatedly editing correct records can make diagnosis harder.

Return to the sender-domain overview. The current help describes checks for DKIM, SPF, DMARC and MX, with green checks for correctly detected records. Let the service refresh its results. If an inherited policy is valid but its DMARC indicator remains red, ask MAILINGWORK how it evaluates that configuration instead of adding a weaker direct policy merely to clear the indicator. Provider verification.

For a tenant system, the administrator can edit the domain, use Release sender domain for subaccounts, select the intended child accounts through Select accounts, and save the release. The shared domain becomes selectable in those accounts but cannot be edited or deleted there. Verify the actual sending subaccount has access. Tenant-sharing workflow.

Then open the mailing's Basic settings, set the local part before @, and select the verified sender domain. This is an important separate step: MAILINGWORK says the dropdown can show domains even when their DKIM configuration is invalid. Inspect older mailings and every relevant tenant account rather than assuming the default updates them all. Selecting sender domains.

Prove the intended DKIM signature and DMARC result

Send a fresh representative MAILINGWORK message to a mailbox you control and inspect its original headers or trusted receiving-server trace. Include each sending subaccount or distinct domain used in production. Use harmless test content and avoid sending confidential campaign data to a public diagnostic service.

Trust Authentication-Results only when your receiving infrastructure establishes its provenance and excludes untrusted incoming versions. An attacker can prepend a field, including a plausible authserv-id. A matching server name alone is not proof. If the receiver cannot make that distinction, use a separate trusted mailbox or trace. Authentication-Results trust boundary.

Accept the setup only when you can establish all of the following:

1. The delivered visible From uses the intended MAILINGWORK sender domain.
2. The specific branded MAILINGWORK DKIM signature has the expected d= domain and s= selector, verifies successfully, and aligns with From under the applicable policy.
3. DMARC passes for that From domain. A pass produced only by another signature or by SPF does not prove this DKIM setup works.
4. The actual SPF identity and result are understood, and any SPF error is resolved or explained with the responsible operator.
5. Replies reach the intended monitored mailbox.

The public MAILINGWORK setup pages do not establish one universal envelope-sender hostname or guarantee SPF alignment. Record the actual smtp.mailfrom and Return-Path. SPF normally evaluates the envelope domain, not the visible From address. If the authenticated envelope domain differs, determine whether it aligns rather than assuming the published include made it align. A successful unaligned SPF result is different from fail, temperror or permerror.

Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

For messages with multiple DKIM signatures, use EmailAuth's guide to separating raw DKIM results from aligned DKIM results. DNS checks establish publication; receiving evidence establishes what the service actually signed.

Troubleshooting MAILINGWORK authentication