EZLynx SPF, DKIM and DMARC setup, step by step

For EZLynx Email Campaigns, obtain your domain's DNS records in Communication Center → Email Campaigns → Settings → Custom Domains. Publish the account-issued CNAMEs, return to Validate, then check a newly delivered campaign for the intended branded DKIM signature and DMARC pass. Do not paste a universal EZLynx SPF TXT record: the reviewed native procedure issues domain-specific aliases, not a generic authorization string.

This guide covers the agency-admin Custom Domains workflow, not every email sent by an EZLynx product. The official setup guide identifies agent@agencyinbox.com as the default sending identity and explicitly excludes eSignature mail from this branding change. Authentication reduces spoofing risk; it does not guarantee inbox placement.

Before you change the agency's sending identity

You need agency-admin permissions, access to the Email Campaigns product, a domain your agency controls, and an authorized administrator for its authoritative DNS. A personal Gmail or Yahoo address is not an agency-controlled domain for this feature. Your registrar, website company and authoritative DNS host may be different organizations; identify the one actually serving the domain's DNS before requesting changes.

Agree the intended visible From address, affected agency and campaign path with the sending owner. Keep a baseline of current records and the existing sending configuration. Check existing selectors, delegations and other services before adding anything. The DNS owner should approve the exact account-issued owner/type/target set, not simply approve “follow the screenshot.”

The official page also describes logos and Global Signature settings. Those signatures are message-body branding, not DKIM cryptographic signatures. Changing a logo, reply address or footer does not authenticate a sending domain. Do not change agency-wide signature or branch controls as an incidental part of this DNS task. Native prerequisites and feature boundaries.

Get the records from your actual EZLynx account

1. Open Communication Center, then Email Campaigns → Settings.
2. Choose Custom Domains → Add Domain.
3. In Step One – Add Domain, enter the domain used in the approved agency email address. Enter a domain, not an entire email address or a website URL.
4. Select Next to open Step Two – Validate Changes.
5. Capture the complete Type, Host and Data for every issued row. Keep the account and selected domain associated with that packet.
6. Select Save and Validate Later while the DNS owner publishes the approved records.

The official illustration shows three CNAMEs: one mail-domain alias and two _domainkey aliases. Its em, s1 and s2 labels and SendGrid destinations illustrate one account; they are not a record generator for yours. Use the current screen's exact values, including any differing selector or account identifier. If no records appear, your role, product access or domain association needs EZLynx support, not guessed DNS. Official record issuance and validation.

Publish the aliases at the correct DNS authority

A CNAME aliases one DNS owner to another hostname. Keep each row's type as issued, its full owner unambiguous and its destination complete. Do not convert the two DKIM aliases into locally generated TXT keys or copy another tenant's targets. Only public DNS data belongs in this process; never share private signing keys.

These are owner-mapping examples, not values to publish:

Follow the actual DNS host's full-versus-relative field behavior, then inspect the resulting full owner. Preserve existing NS delegations and shared selectors. A child zone must be edited at its actual authority, not by creating a shadow record at the parent. If an issued owner is already in use, stop and ask the DNS owner and EZLynx for a supported conflict resolution; deleting another sender's working DKIM record is not a setup step.

The native troubleshooting examples mix domain spellings and include an http:// prefix. A DNS CNAME owner is a hostname, not an HTTP URL. Do not copy that prefix, a customer example domain or arbitrary trailing punctuation. Diagnose the exact final DNS name instead of repeatedly shortening it until a screen accepts it. Native examples requiring interpretation, DNS aliases.

At each CNAME owner, avoid conflicting TXT, A, AAAA, MX or a second CNAME. Preserve the issued literal CNAME answer: use DNS-only rather than HTTP proxying. If your host has an applicable per-record Flatten control, turn it off for that alias where supported, and ensure whole-zone, apex or same-zone behavior does not hide the required CNAME. If mandatory behavior prevents a literal answer, stop and coordinate a supported placement. Do not disable a shared zone-wide feature indiscriminately or invent a switch. Cloudflare's relevant primary guidance explains proxy status and CNAME flattening controls; use your actual host's instructions, not a different host's UI labels.

No change to corporate MX, nameservers, DNSSEC or unrelated mail routing is part of these three CNAME steps. An unexpected request to change those requires a separate approved routing plan.

What to do about SPF

SPF checks the actual SMTP envelope sender domain, normally shown through the receiver's smtp.mailfrom result, not automatically the visible From domain. For an empty envelope sender, the HELO identity matters. The EZLynx source reviewed here does not establish a universal Return-Path or a standalone SPF TXT include. The mail-domain CNAME is not permission to rewrite your apex SPF or paste a generic SendGrid include.

After a controlled message, identify the actual evaluated domain and ask EZLynx to resolve any mismatch between that route and the issued packet. If an account-specific supported procedure additionally requires an SPF TXT change, reconcile it with the existing policy at that actual evaluated owner: keep one v=spf1 policy, preserve legitimate senders and the approved qualifiers, and evaluate the maximum ten DNS-dependent terms across nested processing. That is not merely a limit of ten includes. An all mechanism causes redirect to be ignored. Neither a qualifier nor a successful lookup guarantees delivery. SPF identities and processing.

Do not add TXT at an issued CNAME owner. If support's proposed SPF instructions conflict with the active alias, obtain a reconciled record set before publishing either.

Validate in EZLynx, then verify delivered DKIM

Return to Step Two – Validate Changes and select Validate. The native guide describes green check marks when the records connect correctly; the screenshot says the custom domain will not be active until all records validate. Do not invent a separate universal signing-enable switch. A green account status confirms the provider's validation stage, not the authentication results of a delivered message. Native activation boundary.

For read-only DNS checks, replace every uppercase placeholder with your own approved packet's full hostname:

dig +short CNAME ISSUED_MAIL_ALIAS_FQDN
dig +short CNAME ISSUED_DKIM_OWNER_ONE_FQDN
dig +short CNAME ISSUED_DKIM_OWNER_TWO_FQDN
dig +short TXT ISSUED_DKIM_TARGET_ONE_FQDN
dig +short TXT ISSUED_DKIM_TARGET_TWO_FQDN

Compare alias answers to the exact issued targets and resolve both DKIM targets to usable public-key TXT answers. Follow any documented alias chain. No answer, the wrong tenant target or a missing key is not success. Inspect authoritative answers and cached responses separately; do not promise a universal propagation interval. DKIM key retrieval.

Use only a controlled, authorized recipient and synthetic content. The official page identifies Send Test Email Campaign on the Create Campaign step for preview testing, but does not prove that preview and all live campaign routes authenticate identically. Validate the actual intended campaign path with its owner before general release; do not send to customers merely to test configuration.

At the receiving service, inspect original message headers through its own tools. Use results generated inside that service's known processing boundary and follow its documented handling of externally supplied Authentication-Results; ignore injected or untrusted fields. A familiar authserv-id string or header position alone is not proof of origin. Receiver trust boundary.

Acceptance for this new branded route requires all of the following:

• The visible From remains the intended agency address, not a rewritten provider address.
• The intended EZLynx campaign signature passes DKIM, with the observed selector and signing d= domain matching the approved configuration.
• That signing domain aligns with the visible From: relaxed alignment permits the same Organizational Domain; strict alignment requires an exact domain match. Current DMARC determines the Organizational Domain through its DNS Tree Walk, not an automatic last-two-label rule.
• The trusted receiver reports dmarc=pass. A pass achieved only through SPF does not prove branded DKIM is working.
• The actual SPF identity and result are recorded separately. Investigate fail, temporary DNS temperror and invalid-policy permerror as different faults, even if aligned DKIM makes DMARC pass.

For the distinction between a valid signature and an aligned one, see raw DKIM results versus aligned DKIM policy results and the current DMARC standard. This guide does not claim any customer message has been sent or tested.

Preserve your existing DMARC policy

Keep the existing direct or applicable inherited DMARC policy and authorized report recipients. This guide does not create a new policy, downgrade protection to p=none, or duplicate a record. If no policy applies, plan initial monitoring separately with the domain owner rather than treating a pasted example as an approved rollout.

If a future reporting change sends aggregate reports to a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone does not make it external. That protocol check does not replace the owner's privacy/data-sharing approval. External reporting authorization, RFC 9990 section 4.

Troubleshooting the actual EZLynx workflow

If a change regresses a working flow, preserve the failed-message evidence and the previous approved baseline. Coordinate with sending and DNS owners to pause affected campaigns or restore the approved prior configuration; retain selectors needed by queued messages and other services. Recheck the failed path and a known-good control using controlled recipients. Do not deliberately break live DNS or route customer mail as a test.

Documentation and testing boundary

Its full text and all three decisive domain-entry, issued-record and validation screenshots were read. Account-generated examples were not copied as deployment values. No customer login, DNS publication, account change, support request, campaign send, receiver test or CMS publication was performed.