On this page: Prepare the sender and the DNS change · Obtain the records from the sender entry · Configure Moosend SPF without losing other senders · Publish the account’s DKIM TXT record · Keep DMARC rollout separate from sender setup · Verify DNS and Moosend status · Accept a real campaign using receiver evidence · Troubleshooting and FAQs
To authenticate a Moosend campaign sender, open More → Settings → Senders, obtain the sender’s SPF and DKIM information, publish the required DNS records and run Verify DNS records. Complete the sender-address confirmation as well. Then inspect a delivered campaign: a green DNS check is not proof that the message’s authenticated identity aligns with its visible From address.
This guide covers Moosend campaign senders on a domain you control. It does not substitute Constant Contact settings merely because the products share corporate ownership. SMTP and transactional applications need their own route-specific acceptance tests; a working newsletter does not prove an application selected the same sender.
Prepare the sender and the DNS change
Identify the exact From address, Moosend account and authoritative DNS zone. Get permission to administer that account and zone, and retain the existing DNS values. A branded website, tracking domain and receiving mailbox are separate things from a campaign’s authenticated sending identity.
In More → Settings → Senders, use Add new for a new sender, enter its name and email, and save. After the sender passes Moosend’s checks, complete the emailed activation link and check its verified state. Rejections can involve a free webmail address, no website associated with the sender domain, or the website/domain/address failing Moosend’s reputation threshold. Moosend documents restrictions on certain sender prefixes, including admin, postmaster and no-reply; investigate a rejected sender address rather than trying to fix it through DNS. Add a sender, manage sender confirmation
The reviewed authentication instructions do not establish a special paid-plan prerequisite for this campaign workflow. They also do not certify that every SMTP or transactional feature is included in every account. Confirm the actual route and account entitlement before planning that separate implementation. Do not buy an upgrade simply because authentication has not yet verified.
Create a small implementation ledger: sender address, domain, DNS owner, record type, requested value, publication time, confirmation state, verification state and message evidence. Distinguishing those last three fields prevents a common mistake: treating mailbox confirmation as domain authentication.
Obtain the records from the sender entry
Open the sender’s DNS setup information. Use the SPF and DKIM tabs for that sender’s records, rather than a public key copied from a tutorial screenshot. Moosend’s current documentation describes a TXT-based DKIM setup with ms._domainkey examples and the sender-specific public key value. Moosend DNS-host instructions
Write down the complete owner before shortening it for a DNS editor. For example.com, a documented ms selector would resolve at ms._domainkey.example.com; for news.example.com, it would resolve at ms._domainkey.news.example.com. If the account shows a different owner, preserve the account-issued name and resolve the difference before publication.
For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.
A public DKIM key belongs in DNS. Your account password, API credentials and SMTP password do not. If a field asks for a hostname target, do not paste a long k=rsa; p=... public-key string into it. That string is TXT data, not a CNAME destination. Resolve conflicting DNS-host instructions with the account’s actual type and your DNS administrator.
Configure Moosend SPF without losing other senders
Moosend documents this SPF authorization:
include:spfa.mailendo.com
A new policy for a domain whose reviewed sending requirements consist only of that authorization can look like this:
Owner: example.com
Type: TXT
Value: v=spf1 include:spfa.mailendo.com ~all
If the owner already has SPF, edit the existing policy instead. Keep existing legitimate mechanisms and the established terminal qualifier. Insert Moosend’s include before all; anything after an unconditional all cannot provide the intended authorization. Do not create two separate SPF records. Official SPF examples
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.
SPF authenticates the SMTP MAIL FROM domain, usually reflected in Return-Path, not the visible From address. It does not automatically inherit an apex record for every subdomain. Audit the entire policy’s DNS-lookup-causing terms, including nested includes and redirects, against the ten-term limit. A long policy that exceeds that limit can produce permerror. SPF specification
For that reason, this guide does not promise SPF alignment merely from publishing an include. Record the delivered smtp.mailfrom identity and compare it with your From domain. If the route uses a provider-owned envelope domain, a passing SPF result can still be unaligned. Aligned DKIM can independently satisfy DMARC.
Publish the account’s DKIM TXT record
The following is a record worksheet, not a publishable key:
Owner: ms._domainkey.example.com (use the account-issued owner)
Type: TXT
Value: the complete public DKIM TXT value from this sender's setup
Copy the full public-key value from Moosend without truncation, typographic quotation marks or line-wrap corruption. Use the account-specified owner and TXT type. Where the DNS editor appends the zone automatically, enter the relative name only; check the resulting fully qualified name before saving.
Do not replace an existing ms._domainkey record without identifying its owner. Another sending account or service may still depend on it. Two incompatible keys at one selector are not a safe way to support two signing systems. Ask for a supported coexistence or migration arrangement if a collision exists.
Some published Moosend examples begin with k=rsa; p=. A DKIM key’s v tag is optional and defaults to DKIM1; when present, it must be first. Therefore, do not assume a key is invalid solely because it lacks an explicit version tag, and do not add a duplicate tag to an already complete account-generated value. DKIM public-key syntax
A long TXT value may appear as several quoted character strings in a DNS lookup. Those chunks can belong to one record and be concatenated by the reader. That differs from publishing multiple competing TXT records for one DKIM key. Ask the DNS host how its editor handles long TXT data rather than shortening the key.
Keep DMARC rollout separate from sender setup
Before adding DMARC, inspect the exact From domain and applicable parent policy. A subdomain without its own record may inherit protection. Do not create a child monitoring record that unintentionally overrides a parent’s enforcement, and do not replace an established policy with a tutorial example.
Only for a new, approved monitoring deployment with no applicable established policy, an illustrative record for example.com is:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Use your actual domain and an authorized reporting mailbox. The semicolons are required tag separators; retain mailto: for the reporting URI. Publish one DMARC record at this owner. An external report service may need destination authorization. A monitoring policy does not force inbox delivery and does not ask receivers to reject spoofed mail.
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.
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.
DMARC needs either an aligned SPF pass or an aligned DKIM pass. Relaxed alignment accepts matching organizational domains; strict alignment requires exact matching. Preserve an organization’s chosen modes rather than loosening them to clear a dashboard. Current RFC 9989 replaces RFC 7489 and removes pct; older examples containing pct=100 are not a model for a new rollout. Current DMARC specification
Verify DNS and Moosend status
Return to the sender setup and choose Verify DNS records. Moosend documents a combined SPF, DKIM and DMARC check, rechecking in the campaign wizard when a sender is added, and a 48-hour verified-status window. A failed combined check can therefore involve more than the DKIM key. The documentation separately allows 30 minutes to 48 hours for newly published DNS records before the verification step; that propagation allowance is not the 48-hour verified-status cache. Working with DNS records
Use read-only queries like these, substituting your domain and account-issued selector:
dig +short TXT example.com
dig +short TXT ms._domainkey.example.com
dig +short TXT _dmarc.example.com
Expect the correct complete SPF policy, public DKIM key and intended DMARC policy at their respective owners. Compare authoritative nameserver answers with recursive answers if caches differ. DNS propagation is not a single guaranteed timer. A record at the wrong owner will remain wrong after its TTL expires.
Treat Moosend’s verification behavior as a product check, not a replacement for protocol-level evidence. In particular, a provider’s parent-domain lookup or cached verified status does not prove the actual message’s SPF identity, selector or policy alignment.
Accept a real campaign using receiver evidence
Send an authorized test through the exact campaign or automation route to a controlled external mailbox. Open its original headers. Trust the receiving system’s own Authentication-Results, not every similarly named field in a forwarded or copied message. Authentication-results trust model
Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.
Capture the From domain, smtp.mailfrom, DKIM signing domain (header.d or signature d=), selector and DMARC outcome. For this DKIM setup, require trusted DKIM pass for the intended Moosend signature, reconciling its observed d= and s= with the account-issued setup. Its signing domain must align with the unchanged intended visible From under the applicable alignment mode, and the trusted receiver must report dmarc=pass for that From. An SPF-only DMARC pass, an unrelated added signature or an unnoticed provider-domain From rewrite does not demonstrate that your Moosend DKIM configuration works. Investigate a genuine receiver spf=fail, permerror or temperror against the envelope domain even when DKIM makes DMARC pass. Mere SPF nonalignment is a different observation. Retain date, route and recipient system so the evidence has a defined scope.
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.
If an application also sends through Moosend, test its actual messages separately. The existing transactional email identity and delivery guide explains why application credentials and transport success are different from branded identity acceptance.
Troubleshooting and FAQs
Why is the sender confirmed but DNS verification failing?
Mailbox confirmation proves access to the address. Inspect SPF, DKIM and DMARC independently, including inherited policy, owner-name suffixes and the sender domain selected in Moosend. Do not reset all three records at once: isolate the failure and preserve working senders.
Why did a previously verified sender become unverified?
Check for DNS changes, deleted values, domain migrations and cached status. Re-run the documented check and compare the current public answers with your saved implementation ledger before changing anything again.
Can I copy the example DKIM key from a guide?
No. Retrieve the key for your own sender. A syntactically valid sample key cannot verify a signature made with a different private key.
Does successful authentication guarantee the inbox?
No. Recipient filtering, consent, complaints, content and reputation still matter. Authentication success is a useful technical result, not an inbox-placement promise.
What was verified for this article?
Direct opens of several documentation pages timed out or returned service errors, so their indexed bodies were used and the access limitation retained in the research log. No account, DNS modification, sending test or production website behavior was tested.