Everlytic SPF, DKIM and DMARC setup, step by step

Authenticate an Everlytic sending domain through Domains → Add Domain → Verify and Authenticate Domain by DNS → Generate Records. Publish the complete record set issued for that domain, then use Verify and check its status. Everlytic's authentication reference describes two DKIM CNAME selectors and a branded bounce CNAME. SPF is evaluated on that bounce identity, so adding an SPF include at your root domain is not a substitute for the correct bounce configuration. Domain setup and email-authentication reference

This guide covers authentication of your own domains for mail sent through Everlytic, including the need to verify actual bulk and transactional routes. It does not replace the authentication configuration for your separate corporate mailbox provider, and it does not treat an email-approval link as proof that branded SPF and DKIM work.

For a distinct corporate-mailbox route, see the Microsoft 365 authentication guide when that is your mail service. Its tenant controls do not replace Everlytic domain verification.

The current official pages were read, including through a browser when direct text retrieval timed out. No customer account, DNS zone or sending workflow was changed, and no customer message was tested.

Start with the domain and sending route you actually use

Identify the visible From domain for each stream: newsletters, automated campaigns, transactional notifications and any separately configured applications. A successful newsletter test is not evidence for an application's transactional configuration.

You need access to the correct Everlytic account and its Domains controls, permission to use the intended sender, and an authorized DNS administrator for the domain. If those controls are unavailable, ask your account administrator or Everlytic support to confirm the access needed. Do not authenticate a public mailbox provider's domain, such as gmail.com, which you do not control.

Before editing, record:

• The chosen From address and domain.
• Existing SPF, DKIM and DMARC records, including other active senders.
• The exact authoritative zone for each proposed owner.
• Hostnames already serving mail, websites, tracking or integrations.
• Who owns the change, the DNS backup and the recovery decision.

Everlytic's release notes state that domain validation applies to both bulk and transactional emails, with validation errors available in Message History and Message Details. Do not interpret the older general account page's email-approval alternative as a way to bypass those authentication requirements. Domain-validation release note

Generate the records and complete domain verification

1. Open the username menu in Everlytic and choose Domains.
2. Select Add Domain and enter the domain used by the email's From address, not a full email address or website URL.
3. Choose Verify and Authenticate Domain by DNS, then Generate Records.
4. Copy every issued record's type, complete owner and value/target into the change plan. The account guide refers to generated TXT and CNAME fields; do not assume that means exactly one of each.
5. Publish the records safely at the correct DNS provider. Reconcile any SPF or DMARC instruction with the policies already there rather than creating duplicate policies.
6. Select I have added these records, click Verify, and check the Verification status on the Domains dashboard. The guide says this DNS route prevents sending until validation is complete. Official domain-verification workflow

Everlytic gives a 24–48-hour validation window in this workflow. If the authoritative DNS answer is wrong, fix it first rather than waiting out that interval. If the records are correct but validation remains incomplete, provide support with the exact domain, issued owner names, DNS answers and error details.

Understand the Everlytic DKIM and bounce records

The official authentication reference describes these record patterns. [DOMAIN] means the particular sender domain being configured. These are reference patterns, not a replacement for your account's generated instructions.

The reference uses eversrv for one owner and everserv inside the additional nested owner. Do not silently change either spelling or construct a missing record by analogy. Publish the names issued for your domain. If its record list conflicts with this reference, ask Everlytic to confirm which owners and targets apply before changing DNS. Everlytic record table

For DKIM, the aliases lead to provider-hosted public keys. Everlytic holds the signing private key. You should neither upload a private key to public DNS nor replace the CNAME with a public key copied from a momentary lookup. Keep both assigned selectors in place even if one test message uses only everlytickey1; do not retire the other without the provider's instructions.

The reference also labels an SPF TXT policy at the sender domain as optional. That is separate from the bounce record used for the normal envelope route. Its DMARC row is an illustrative policy, not permission to overwrite your existing protection or copy example reporting mailboxes.

How Everlytic SPF works, and when it aligns

Everlytic's reference says that its envelope Return-Path is rewritten to a domain like eversrv.[DOMAIN]. Receivers evaluate SPF against that domain, following the bounce CNAME to the provider-managed data. The visible From domain and the technical MAIL FROM domain therefore need to be inspected separately. Everlytic's SPF explanation

For example, assume the actual message uses these identities:

Visible From: newsletter@example.com
MAIL FROM domain: eversrv.example.com
Branded DKIM signing domain: example.com

If SPF passes for eversrv.example.com, it can align with example.com under relaxed aspf=r, assuming their organizational domain is example.com. It does not align under strict aspf=s, which requires identical domains. A valid signature with d=example.com aligns with that From domain under either DKIM alignment mode. These are illustrative identities, not measured Everlytic headers. DMARC identifier alignment

The optional root-domain mechanism documented by Everlytic is include:eversrv.com. Add it only when the current account instructions and DNS owner establish a need for that owner. It cannot repair a broken bounce CNAME, change the envelope address or make strict alignment pass for unequal domains. If an approved amendment is required, merge it into the existing single SPF policy while preserving other authorized services and the intended ending mechanism.

Never publish two v=spf1 policies at one owner. SPF does not combine them. Check the full recursive evaluation against the limit of ten DNS-query-causing terms, including nested includes and redirects. Do not broaden authorization with +all or copy a provider's changing IP addresses into a static list to hide an error. SPF record selection and DNS limits

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.

Put records in the correct root or child zone

The account's full owner name is the source of truth. Your DNS host's input format determines whether you enter that full name or only a prefix. Check the fully qualified result after saving.

@ identifies the apex of the zone currently open. It does not always mean example.com. If a child is delegated elsewhere, its records must be published through that child's authoritative operator. Data below a delegation left in the parent zone does not override the child's DNS. DNS delegation

A CNAME owner must not also carry ordinary A, AAAA, MX or TXT records. Do not add a TXT SPF record alongside the bounce CNAME, and do not replace the root domain with a bounce alias. Preserve provider aliases as DNS-only records instead of putting them behind an HTTP proxy. If an existing service occupies a proposed name, stop and resolve the collision with the DNS owner and Everlytic. CNAME rules

Keep the issued DKIM and bounce CNAMEs unflattened: public DNS must return their exact aliases, not substituted IP addresses. In Cloudflare, DNS only is necessary but insufficient. Check that each issued CNAME has Flatten turned off. Cloudflare CNAME verification

Also check that the zone-wide CNAME flattening for all CNAME records setting is off; it can prevent per-record overrides. Coordinate any shared-setting change with the DNS owner and assess unrelated services first. Cloudflare flattening controls

For these issued authentication aliases, also account for Cloudflare’s mandatory behavior: a CNAME at the zone apex is flattened by default, and a target in the same zone is flattened regardless of the CNAME Flattening setting. If that behavior or a shared setting prevents the literal issued CNAME answer, stop and coordinate a supported configuration with the DNS owner and Everlytic. Do not invent an override, rename issued owners yourself, remove NS delegation or disrupt dependent website/mail records. Other authoritative DNS hosts may have different controls; verify their actual behavior rather than assuming Cloudflare options exist there. Cloudflare apex and same-zone behavior.

Preserve legitimate child-domain NS delegation and publish/check at the child's authority. Do not remove its NS records just to force the parent editor's CNAMEs into service.

If the actual _domainkey namespace is itself delegated, publish at that authority: for full owner ISSUED-SELECTOR._domainkey.news.example.com in the delegated _domainkey.news.example.com zone, the relative owner is only ISSUED-SELECTOR. This is a placement illustration, not a provider-issued selector or a new sending-domain assignment. Preserve the existing NS delegation, other selectors and exact issued record type/target. DKIM owner construction, relative DNS names.

Add DMARC reporting without resetting an existing policy

DMARC connects the authenticated domains to the From domain recipients see. A message passes when SPF passes and aligns, or DKIM passes and aligns. Having a DKIM signature is not enough; it must verify successfully. Likewise, an SPF pass for an unrelated envelope domain does not provide branded alignment. DMARC alignment requirements

Read the existing policy at the exact From domain and any applicable inherited policy before adding anything. Preserve existing enforcement, alignment settings and reporting destinations unless a deliberate change is approved. Adding p=none to a child can weaken the policy that it previously inherited from its parent. DMARC policy discovery

For a domain without an established applicable policy, an approved monitoring example is:

For this apex From-domain example, the full TXT owner _dmarc.example.com maps to relative name _dmarc in the authoritative example.com zone, not @. Check the saved full owner; use the existing child/delegated-child mappings above when the actual From domain is a child. This first-policy example remains conditional on no direct or applicable inherited policy and the owner’s approval. Relative DNS names.

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Substitute a real domain and report mailbox or your reporting provider's exact issued destination. Do not paste the example verbatim. p=none does not itself request aggregate reports; rua supplies that request. External destinations may require authorization by the receiving organization. Avoid copying the vendor table's example forensic-report destination without a privacy review. Aggregate reporting and external destinations

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.

Review aggregate reports after representative mail has flowed. Identify the real Everlytic sources, their SPF and DKIM outcomes and their alignment, while also accounting for other legitimate systems using your domain. A report's policy disposition is not a measurement of inbox placement. Tighten policy only after the full legitimate sending inventory has been assessed.

Check public DNS and the application's status

Replace the uppercase placeholders with the exact values from the account and the relevant authoritative DNS server. These commands are read-only examples and have not been executed against a customer domain for this guide.

dig +short NS DNS_ZONE
dig @AUTHORITATIVE_NS DKIM_OWNER_1 CNAME +noall +answer
dig @AUTHORITATIVE_NS DKIM_OWNER_2 CNAME +noall +answer
dig @AUTHORITATIVE_NS BOUNCE_OWNER CNAME +noall +answer
dig @AUTHORITATIVE_NS DMARC_OWNER TXT +noall +answer
dig DKIM_OWNER_1 TXT +noall +answer
dig DKIM_OWNER_2 TXT +noall +answer
dig BOUNCE_OWNER TXT +noall +answer
dig DMARC_OWNER TXT +noall +answer

Expect the CNAME answers to match the account's supplied targets exactly. Recursive TXT lookups should follow the DKIM aliases to usable public-key records and the bounce alias to the policy needed for the envelope's SPF check. If a resolver does not show the full chain, inspect the CNAME target directly. Check every additional owner that the account issued, not only those in the command example.

Confirm the same answers at the authoritative servers and at a public recursive resolver. For a delegated child, query that child's authority. Missing or wrong authoritative data means a publication problem; differences only in recursive caches can be temporary. After public DNS is correct, confirm Everlytic's Verification status. Neither an application badge nor a DNS lookup proves which identity a real message will use.

Require a branded DKIM pass and alignment in received mail

After testing is authorized, send a harmless message through the actual production-style route to an external mailbox you control. For example, test one campaign and one transactional notification if both are in scope. Use the full received original, not a preview or a forwarded copy as your first baseline.

Read the receiving service's trusted Authentication-Results. Record the visible From domain, Return-Path, smtp.mailfrom, each DKIM d= and s=, and the receiver's SPF, DKIM and DMARC outcomes. An Authentication-Results header supplied by an untrusted sender is not proof. Authentication-Results security

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Your acceptance record should show:

1. The expected branded From address without an unexpected rewrite.
2. DKIM pass for the intended branded signing domain and alignment to From. Identify the passing signature if several are present. A pass for d=eversrv.com alone does not align with From at example.com.
3. SPF pass for the actual envelope domain on the direct route, plus an explicit assessment of relaxed or strict alignment.
4. DMARC pass for the intended From domain, explainable by a passing aligned mechanism.
5. The correct domain selected by the specific campaign or transactional workflow, not merely another stream in the same account.

The provider's authentication article contains a signature example using d=eversrv.com. It illustrates the signature fields; it is not an acceptance example for an unrelated branded From domain. The decisive evidence is the domain on the signature that actually passed in your message.

If DMARC passes through aligned SPF but branded DKIM fails, the DKIM setup remains unfinished. If branded DKIM passes and aligns but SPF returns fail, softfail, neutral, none, temperror or permerror, do not label the whole result fully verified. Investigate the actual SPF issue. Forwarding can change the connecting sender, so compare a direct baseline before diagnosing a forwarded copy. SPF result meanings

Troubleshooting Everlytic authentication

For a support escalation, supply the domain, route, time, generated-record list, public lookup results and redacted headers. Keep credentials, private keys and unnecessary recipient data out of the evidence packet.