MyGuestlist SPF, DKIM and DMARC setup, step by step

In MyGuestlist, open Email → Manage Sending Domains, add the approved domain with an email address on that same domain, then open View Setup Instructions. Publish the exact DNS records supplied for your account and use Test DNS. The Ready to use? column reports the domain's authentication status. Complete the job by checking an authorized native campaign message for the intended aligned DKIM signature and trusted DMARC pass. MyGuestlist's sending-domain instructions.

There is no universal MyGuestlist SPF include, DKIM selector or fixed record count established by the public instructions reviewed here. The live account's setup packet supplies those details. Do not substitute a guessed email platform's records or treat a green DNS result as proof that the intended campaign was signed correctly.

This guide covers an existing, approved MyGuestlist native Email campaign route and its authorized sending domain. It does not cover account creation, subscription changes, external SMTP integrations, list imports or changing who receives campaigns. Check that your present account exposes the same controls before acting.

Prepare the domain, access and change plan

You need approved access to the MyGuestlist account, authority to authenticate the chosen sending domain, and access to the DNS service actually authoritative for it. Use an approved email address on that domain. A provider login or a domain appearing in the UI does not grant permission to change its policies or send to its contacts.

Before editing, preserve the existing DNS records, TTLs, SPF policy, DKIM selectors, DMARC policy and any child-zone or _domainkey delegations. Identify other legitimate senders that share the domain. Record the intended campaign From identity and how you will obtain a harmless message at a controlled recipient without touching the production audience.

The registrar is not necessarily the authoritative DNS host. MyGuestlist's article describes the domain host as the registrar, but registration and DNS can be operated by different companies. Confirm the nameservers and delegated zone that serve each issued owner. Editing a registrar's inactive DNS zone will not publish a working record.

Do not change nameservers, DNSSEC, security settings, credentials, website routing or inbound mail routing to make an authentication tutorial match. If the account-issued packet includes MX, address records, tracking aliases or other routing changes, compare the exact destinations with the approved operational plan and obtain explicit approval before publishing or activating them. An authentication request is not blanket authorization for those consequences.

Retrieve MyGuestlist's actual setup instructions

Follow the documented account workflow:

1. Sign in using your existing approved access.
2. Open Email and select Manage Sending Domains in the orange menu.
3. For an approved domain that has not yet been added, choose + Add New Domain.
4. Enter the domain and an approved email address using that same domain. For example, the source requires an address ending in @myvenue.com when registering myvenue.com; that is an illustration, not your account value.
5. Once the domain is listed, select View Setup Instructions for that domain.
6. Capture every required record's type, full owner and complete value, along with any separate account instructions.

If the domain is already listed, inspect its setup instructions and status rather than creating duplicate entries. Confirm the selected domain before copying anything.

The screenshots show the domain list, View Setup Instructions, Test DNS, and an initial not-yet-authenticated message. They do not show the DNS packet itself or a successful status example. Accordingly, this guide does not invent a TXT-versus-CNAME design, the number of records, a literal success label or a tenant-generated key.

Use a change worksheet like this, filled from the actual account:

If a value is truncated, a type is missing, the domain is wrong or the packet conflicts with your current setup, stop and ask MyGuestlist to clarify the account's instructions. Do not reconstruct missing values from a screenshot, another tenant or an assumed upstream vendor. DNS operators can help publish a known correct tuple; they cannot invent the sender's signing configuration.

Publish only the approved records

Copy the account-issued records to the authoritative DNS service. Preserve exact types and full values. A DKIM TXT public key and a CNAME pointing to provider-managed key data are different forms, not interchangeable choices. Never publish a private key. DKIM record format.

For a TXT value, retain all issued tags and complete key material. Multiple quoted character strings in a DNS tool can represent one logical TXT record; they are not instructions to create multiple independent records. For a CNAME, copy the exact hostname target rather than a public-key string.

Map names correctly across delegated zones

Suppose the actual packet supplied a full DKIM owner shaped like SELECTOR._domainkey.news.example.com. This example explains naming only; SELECTOR is a placeholder, not a MyGuestlist selector.

Use only the correct zone for your current delegation. An editor expecting a full name may instead need the full issued owner. Preview the final name to avoid doubling the domain suffix. Preserve existing NS delegations and other selectors; do not delete a delegation merely to publish into the parent zone.

Conditional CNAME checks

If the account requires a CNAME, inspect the exact owner for conflicts. Do not add TXT, A, AAAA, MX or another CNAME alongside it. An existing record may support another sender or shared service; resolve that dependency with the owner before replacing anything.

Where literal CNAME answers are required, the alias must remain visible in public DNS. Use DNS-only rather than HTTP proxying for the relevant mail-authentication alias. If your DNS host supports a per-record Flatten control, turn it off for that alias where needed; also check applicable zone-wide flattening. Apex and same-zone behavior can be mandatory even when a per-record option is unavailable. Do not globally disable unrelated settings. If the required alias answer cannot be preserved, stop and coordinate a supported configuration instead of removing shared records or inventing a switch. Cloudflare's exact CNAME-flattening controls.

Query each full owner at its authoritative DNS service and through a public resolver, using the account's actual type. Compare the complete answers with the issued packet. An empty answer can mean an incorrect owner, wrong authority or lookup failure, not simply propagation delay.

Handle SPF according to the real envelope identity

SPF checks the SMTP MAIL FROM domain, or HELO in relevant cases, not automatically the visible From address. MyGuestlist's public setup article does not establish a universal envelope domain or a customer-controlled Return-Path feature. Use the current account instructions and observed message identity to identify the correct SPF owner. SPF specification.

If the packet requires an SPF TXT update at a customer-controlled owner:

• Maintain one v=spf1 policy at that owner. Review and merge the required authorization into an existing policy rather than adding a second policy or replacing other senders.
• Preserve the approved qualifier and legitimate authorizations. Do not weaken -all to ~all or +all just to clear a test.
• Check the 10 evaluated DNS-dependent term limit, including nested mechanisms and redirects. It is not a simple count of visible includes.
• Remember that redirect is ignored when an all mechanism is present.
• If no policy exists, design the complete policy for all actual senders with owner approval; do not fabricate a MyGuestlist include.

Do not edit your apex policy to “repair” a different provider-owned MAIL FROM domain. If the actual envelope differs from what the account instructions appear to cover, clarify the intended route with MyGuestlist. A passing SPF result does not alone establish alignment or DKIM success.

Preserve DMARC rather than overwriting protection

Inspect the direct and applicable inherited DMARC policy before making changes, including any DMARC suggestion in the packet. Preserve its enforcement, alignment modes and authorized reports. A missing direct policy on a child domain does not prove no policy applies; check inheritance and distinguish absence from DNS failure.

Only if no applicable policy exists, the domain owner approves monitoring, and an appropriate monitoring plan is in place, a first policy could be this TXT value:

v=DMARC1; p=none

The full owner is _dmarc beneath the intended policy domain. For news.example.com, it is _dmarc.news.example.com: relative _dmarc.news in the parent zone or _dmarc in a delegated news.example.com zone. Use the actual authoritative zone, not both. This example adds no report recipient and is never a replacement for existing protection. Do not duplicate DMARC or use obsolete pct rollout advice. Current DMARC standard.

When the report destination's Organizational Domain differs from the Organizational Domain of the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination within that same Organizational Domain is excepted. RFC 9990, section 4. Separately secure the owner's approval for sharing report data with that recipient; DNS authorization does not replace the privacy decision.

Run Test DNS and interpret readiness correctly

After the approved DNS updates, return to the intended domain entry and click Test DNS. The Ready to use? column indicates when MyGuestlist considers that domain authenticated. The source advises waiting a few hours after changes before testing, because DNS updates are not instant. Check actual answers and TTLs rather than assuming every failure is waiting time. Provider verification instructions.

The public procedure does not expose a separate signing-activation toggle. Do not import “Start authentication” or “Use for sending” controls from another platform. If your current account gives additional steps, follow only the verified applicable instructions after the necessary approvals. Do not silently omit a required row, bypass a failed check or switch routes to obtain readiness.

DNS readiness is an account validation checkpoint. It does not prove which signature a campaign actually uses, that the visible From remains your brand, or that strict alignment will succeed. Complete the message check before treating the setup as accepted.

Validate a controlled native campaign message

Use an authorized harmless message through the same MyGuestlist native Email campaign route and intended From identity that you plan to use. Keep the recipient scope confined to valid controlled test addresses. Do not import contacts, change a live recipient list, trigger an event workflow or launch to customers just to test authentication.

The reviewed source does not document a specific campaign test button. Use the existing approved controlled-test process for your account; if no isolated native test is available, coordinate one with MyGuestlist before sending. A generic email from your own mailbox, or a different SMTP integration, cannot validate this route.

At the recipient, inspect original full source and results created inside the receiving service's known processing boundary. Confirm that service's documented treatment of externally supplied Authentication-Results; header position or a familiar authserv-id string alone is not proof. Ignore attacker-supplied results. Authentication-Results trust guidance.

Acceptance requires all of the following:

1. The visible From is the intended customer domain, not an unexpected provider-domain rewrite.
2. The intended MyGuestlist route's DKIM signature passes, with its actual d= and s= consistent with the configured account and published record. Another passing signature is not a substitute.
3. That intended signature aligns with From under the applicable adkim policy.
4. The trusted receiver reports dmarc=pass for that intended From.
5. SPF's actual MAIL FROM identity and result are recorded and any failure/error investigated separately.

Relaxed DKIM alignment compares Organizational Domains; strict alignment requires the exact d= domain to match From. SPF alignment similarly compares the authenticated MAIL FROM domain under aspf. A child envelope domain may align in relaxed mode and fail strict alignment. No strict-alignment or customizable-envelope guarantee follows from the public MyGuestlist setup page.

A DMARC pass through SPF alone is not proof of branded DKIM. DNS-ready status, a delivered message and authenticated aligned delivery are three different observations. See raw DKIM results versus aligned DKIM policy results.

Troubleshoot the specific failure

For escalation, retain the domain entry, redacted packet, public DNS answers, timestamps and redacted controlled-message results. Do not share passwords, private keys, customer lists or full customer communications unnecessarily. Authentication does not guarantee inbox placement; use the actual receiver rejection diagnostic rather than weakening security controls.

Sources and verification boundary

Primary source: MyGuestlist: Setting up & authenticating your sending domain. The DNS packet remains account-specific and is not exposed by those screenshots.

This is a documentary foundation guide, not an automated account-configuration tool or certification of a sender-and-DNS combination. No customer account, DNS edit, campaign send, CMS rendering or website publication was performed for this article.