Your Mailing List Provider SPF, DKIM and DMARC setup, step by step

In Your Mailing List Provider (YMLP), open Configuration → Sending Newsletters to obtain domain-authentication instructions. Publish the records approved for your domain, run the DNS verification, and then inspect a controlled newsletter’s actual authentication results. A green setting alone does not prove that the delivered message kept the intended From address and passed branded DKIM. YMLP authentication help.

On this page

• Scope and preparation
• Obtain the account instructions
• Publish DKIM at the correct owner
• Add SPF without breaking existing senders
• Handle DMARC separately
• Verify DNS and a delivered newsletter
• Troubleshooting and recovery
• Frequently asked questions
• Sources and verification limits

Scope and preparation

This guide covers YMLP’s hosted newsletter sender-domain authentication. It does not configure another mailing-list product, your regular employee mailboxes or an independent SMTP server. The public authentication article does not establish a universal plan entitlement, regional setting or named account role. An operator who can access the sending settings must confirm that the documented controls are available in the intended account.

Use a domain your organization controls, with permission from its owner to authorize YMLP. Coordinate with the DNS administrator and the newsletter owner. A personal freemail address is not a domain you can authorize by editing your own DNS zone.

Before changing records, save the existing SPF and DKIM configuration, direct and inherited DMARC policy, active newsletter sender identities and a rollback plan. Check for shared selectors, delegated DNS namespaces and other services using the same names. Do not change inbound MX routes, parent nameservers, DNSSEC or credentials simply to follow a newsletter-authentication guide.

Obtain the account instructions

Use the domain-authentication section under Configuration → Sending Newsletters. YMLP’s official illustration shows a domain-setup link, the DNS instructions, VERIFY DNS RECORDS, and per-domain SPF, DKIM and DMARC status columns. Treat each status separately. Official illustrated authentication panel.

The illustration contains these sample values:

SPF: TXT at the sending-domain owner
 v=spf1 a mx include:spf.ymlp.com ?all

DKIM: CNAME at ymlp._domainkey.SENDING-DOMAIN
 target dkim.ymlp.com.

DMARC: TXT at _dmarc.SENDING-DOMAIN
 v=DMARC1; p=none;

SENDING-DOMAIN is a placeholder, not a literal DNS name. The official panel labels these sample screenshots. Copy the actual instructions shown for your domain, then review them against existing records. Do not copy the sample’s a, mx, ?all or p=none into an established configuration without an owner-approved reason. YMLP’s illustrated examples.

Record issuance, DNS verification and delivered-message signing are different stages. If the account shows a different selector or target, resolve the difference with verified YMLP Support before publishing. Do not generate an unrelated key online, paste another customer’s public key, or disclose private signing keys.

Publish DKIM at the correct owner

The illustrated DKIM route is a CNAME, not a TXT public key pasted beside the alias. For a sender domain of example.com, the illustrated owner is ymlp._domainkey.example.com, pointing to dkim.ymlp.com. Confirm that these remain the values in your account.

The selector is ymlp; _domainkey is the namespace. The lookup for a signature using s=ymlp and d=news.example.com is ymlp._domainkey.news.example.com. DKIM selector and signing-domain lookup.

Match the full owner to the authoritative zone:

• example.com sending domain in the example.com zone: relative name ymlp._domainkey.
• news.example.com sending domain managed in the parent zone: relative name ymlp._domainkey.news.
• The same sender domain in a separately delegated news.example.com zone: ymlp._domainkey.
• A separately delegated _domainkey.news.example.com namespace: its administrator publishes the relative owner ymlp there.

Do not double the zone suffix. Preserve existing NS delegations and shared key dependencies. If the owner already carries another CNAME, TXT, A, AAAA or MX record, stop and reconcile the conflict rather than stacking incompatible records or deleting an unrelated service.

Use DNS-only where the DNS host offers HTTP proxying. If verification requires a literal CNAME, make sure flattening does not replace its public answer with addresses. On Cloudflare, turn the relevant per-record Flatten control off when available and check whether zone-wide flattening is suppressing the alias. Apex and same-zone targets have separate behavior. Review shared consequences before any global change; if mandatory behavior prevents the required answer, stop and agree on a supported configuration instead of removing delegations or inventing controls. Cloudflare flattening reference.

Add SPF without breaking existing senders

SPF checks the actual SMTP MAIL FROM identity, or the applicable HELO identity in cases such as a null reverse path. It does not automatically authenticate the address readers see in From. Determine which identity YMLP actually uses in your delivered message before interpreting its SPF result. SPF identities.

The illustrated authorization mechanism is include:spf.ymlp.com. Where the current account instructions require it at your sending domain, add that authorization to the one existing policy at the correct owner, preserving all legitimate senders and intentional qualifiers. Do not publish a second v=spf1 policy.

The sample’s a and mx mechanisms authorize addresses associated with those DNS records; they are not harmless formatting. Its ?all is neutral, not a mandatory newsletter setting. Do not replace a reviewed policy with the sample or append mechanisms after a terminal all. If the existing policy uses redirect, have its administrator integrate the authorization deliberately: redirect is ignored when all is present. SPF mechanisms, redirect processing.

For a policy at the full owner example.com in the example.com zone, use the DNS host’s documented apex input; YMLP’s sample explicitly leaves Name/Host blank. Some DNS hosts use @ instead, so verify the resulting full owner. For a policy at news.example.com, use news in the parent zone or the apex convention, often @ or blank, in a delegated child zone. Do not accidentally edit example.com instead. A conflicting TXT must not be added at a CNAME owner; resolve a supported design with the owners when the intended policy owner is an alias.

Count all evaluated DNS-dependent mechanisms and modifiers, including nested lookups, against the limit of ten. Ten written includes can already exceed the budget. Diagnose syntax and duplicate-policy errors separately from authorization failures. An SPF qualifier does not guarantee a receiver’s final delivery decision. SPF lookup limits.

Handle DMARC separately

Inspect direct and applicable inherited policies before creating anything. Retain existing enforcement, alignment modes and approved report destinations. The provider’s p=none example is not a reason to downgrade an existing policy.

Only when there is no applicable policy, the domain owner approves and a monitoring plan is appropriate, an initial policy can use:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none;

For example.com, the relative name in that zone is _dmarc. For a sender domain news.example.com, the owner is _dmarc.news.example.com: enter _dmarc.news in the parent zone or _dmarc in a delegated child zone. Do not duplicate the policy. This minimal example does not itself arrange report collection. DMARC policy location and discovery.

If you add aggregate reporting, obtain approval for the destination and purpose, provision the approved recipient and monitor report receipt. Compare the report URI’s destination-host Organizational Domain with that of the domain where the policy was found, not automatically the visible From domain. When those Organizational Domains differ, the report-generating receiver must check DNS authorization. The same-Organizational-Domain case is excepted, even where the individual hostnames differ. This protocol check does not replace the owner’s data-sharing and privacy decision. Never copy someone else’s report address. RFC 9990 section 4.

Plan enforcement across all legitimate senders, not only YMLP. Review reports and forwarding or mailing-list paths before tightening policy. RFC 9989 section 7.4 warns of indirect-flow disruption and requires valid DKIM rather than sole reliance on SPF for p=reject domains. General-user domains whose users participate in mailing lists need that specific risk assessment. Do not use obsolete pct rollout instructions. DMARC interoperability considerations.

Verify DNS and a delivered newsletter

First compare authoritative answers and a public resolver with the approved account values. These commands are examples with placeholder domains, not evidence of a successful setup:

dig +short CNAME ymlp._domainkey.example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig @AUTHORITATIVE-NS CNAME ymlp._domainkey.example.com
dig @PUBLIC-RESOLVER-IP CNAME ymlp._domainkey.example.com
dig @PUBLIC-RESOLVER-IP TXT dkim.ymlp.com

Replace AUTHORITATIVE-NS with the actual authoritative server for that owner and PUBLIC-RESOLVER-IP with the chosen recursive resolver. The first lookup should expose the intended alias; follow it to a usable DKIM public-key TXT record at its target, not merely a present CNAME. At the SPF owner, distinguish the single SPF policy from unrelated TXT verification records. For all records, compare exact owners and values rather than relying on a green icon.

Return to VERIFY DNS RECORDS and check the individual statuses for the intended domain. The official screenshot distinguishes Active from Inactive. If a status remains inactive, revisit the failed record instead of replacing all DNS settings. YMLP verification panel.

Next, the authorized newsletter operator should send harmless test content to controlled valid recipients through the actual intended newsletter route. No live send was performed for this article. Use the original received message’s headers rather than a copied or forwarded body.

Identify results produced inside the receiving service’s known processing boundary and its documented treatment of externally supplied Authentication-Results. Neither header position nor a familiar authserv-id string alone proves authenticity. Ignore attacker-supplied result fields; consult the receiving administrator when provenance is uncertain. Authentication-Results trust boundary.

Require all of the following before approving branded DKIM:

1. The delivered visible From remains the approved intended address, not a provider-owned rewrite.
2. The intended YMLP signature is present, with its d= and s= recorded together and trusted receiver dkim=pass for that signature.
3. Its passing signing domain aligns with the intended From under the applicable adkim policy.
4. The receiver records dmarc=pass for that intended From domain.
5. The actual SPF identity and result are recorded, with failures and errors investigated even if DKIM supplied DMARC pass.

Strict alignment requires exact domain equality; relaxed alignment permits the applicable same-Organizational-Domain relationship. A child envelope domain is not strict SPF alignment with its parent. A generic DMARC pass via SPF does not prove branded DKIM. Keep multiple signatures and their outcomes separate. Raw versus aligned DKIM results.

Troubleshooting and recovery

DKIM remains inactive: compare the current account’s selector, full owner and target. Check underscore spelling, duplicated suffixes, existing records, delegation, proxying and flattening before assuming propagation is the only issue.

DNS is active but the intended signature is missing: verify the configured domain and sender selection for the actual newsletter. Do not invent an undocumented activation switch; ask verified Support to resolve a mismatch between account validation and delivered signing.

SPF reports fail: inspect the actual MAIL FROM authorization. A temperror indicates a transient evaluation problem that needs investigation and retesting. A permerror indicates a persistent evaluation problem such as invalid syntax, multiple policies or excessive evaluated lookups. A DKIM pass does not erase these errors. SPF result meanings.

Authentication passes but DMARC fails: compare the passing identities with the unchanged From and the applicable alignment modes. Do not assume an SPF include guarantees an aligned Return-Path or accept an unrelated provider signature as brand authentication.

A change breaks newsletters or another sender: with the affected owner’s approval, pause only the affected send and restore the last known-good approved configuration. Preserve selectors and shared authorizations needed by queued messages or other services. Keep the failed sample and retest both the failed path and a known-good path after recovery. Do not downgrade DMARC as a shortcut.

Before a production launch, the newsletter owner should also confirm audience consent, working unsubscribe handling and appropriate sending practices. Authentication is not an inbox-placement guarantee.

Sources and verification limits

YMLP’s full public authentication help and its linked DNS-instruction/status screenshot were read. No publication or update date was established from that page. Its example values do not replace the current account’s instructions.

No account login, DNS change, message send, mailbox test, live browser render or website publication was performed. The article does not establish a universal plan entitlement, custom return-path feature, specific account permissions or your current signing state. Resolve those account-specific questions before rollout.