Evicertia SPF, DKIM and DMARC setup, step by step

Quick answer: Treat domain authentication as three separate jobs: publish the correct authorized DNS records, activate the intended sender in the application, and verify the resulting message at a trusted receiver. Do not copy an example environment's records into production or mistake mailbox verification for working DKIM.

This guide covers EviMail's default-selector domain route, not custom-key administration, API integration, EviSign or every Namirial product. No customer configuration or sending test was performed.

The documented Evicertia workflow

The official domain-management guide, gives this sequence:

1. A Site Administrator opens Organization > Management of domains > Add domain.
2. Enter the domain and obtain its personalized DNS instructions.
3. Publish the required records, then select Verify domain.
4. A user with Sender emission permission registers an address through My Data > Management of sender e-mail addresses, also labelled Profile > Emails. Complete Send PIN verification using that mailbox. Activation also depends on domain verification.
5. In New EviMail > FROM > Email address, select the registered sender.

The prose documents SPF include:_spf.evicertia.com and two default DKIM CNAMEs: herma-a._domainkey.<domain> → herma-a._domainkey.evicertia.com. and equivalent herma-b entries. However, its screenshot shows staging selectors and ecertia.com targets. Use the current account's complete production packet; resolve discrepancies with Evicertia before publication. Do not combine the two examples. “Legacy” indicates historical use, not verified authentication. Custom selectors are a separate route.

Before changing anything: decide which identities matter

Write down the intended visible From address, selected EviMail account, authorized sending domain and DNS administrator. Confirm this workflow really produces the messages you want to authenticate. A separate product or integration can use different identities even when the interface shares the same brand.

Obtain approval for the exact changes and retain a dated DNS inventory. Include existing SPF, active DKIM selectors, the direct or inherited DMARC policy, relevant NS delegations and other systems using the same domain. The objective is to add a legitimate sending path, not silently replace an existing mail system.

The domain shown to recipients is not automatically the domain SPF evaluates. SPF normally evaluates SMTP MAIL FROM; HELO is relevant in applicable empty-envelope cases. Record the actual evaluated identity from a controlled message and clarify its ownership before editing policy. A provider-owned envelope domain is controlled by the provider. Adding an include to your apex does not alter its SPF or establish alignment with your visible From.

This guide does not invent a custom Return-Path feature or promise that a child-domain envelope passes strict alignment. If the intended domain, environment or record owners remain unclear, stop before publication. The production packet must identify complete record types, owners and values, not merely a screenshot fragment.

Publish SPF without breaking other senders

At the approved SPF owner, query TXT and identify the existing v=spf1 policy. There should be one SPF policy for that owner, not a new policy for every service. Merge the verified authorization into the existing policy while retaining legitimate mechanisms, qualifiers and the intended final all behavior.

An include mechanism alone is not a complete SPF TXT value. Conversely, copying a complete example containing unrelated IP addresses or mx authorizations can authorize systems you never intended. Obtain a reviewed complete policy rather than pasting the documentation's illustrative IPs.

For a new policy, first confirm that no other service needs authorization and agree the policy with the domain administrator. Do not use a tutorial to change an existing -all to ~all, or add +all. If duplicate policies already exist, inventory and reconcile them before adding more records.

SPF permits at most 10 evaluated DNS-dependent terms, including nested lookups in mechanisms such as include; this is not a limit of ten visible includes. Evaluate the complete expansion. An all mechanism causes redirect to be ignored, so appending an include after all or assuming a redirect still governs the policy is unsafe. See RFC 7208.

Publish the actual DKIM aliases in the correct DNS zone

Use the complete CNAME owners and targets from the confirmed account packet. Do not remove _domainkey, guess a missing suffix or transplant a staging target. Preserve the record type: a CNAME alias and a TXT public-key record are not interchangeable. Never put a private key in DNS, tickets or this configuration handoff.

Translate the full issued owner into the authoritative zone's input convention. For illustration only, suppose a packet specifies a selector named SELECTOR for notices.example.com. These are placeholders, not Evicertia-issued values:

If the editor accepts full names, use its documented convention instead. Query the final name to detect doubled suffixes. Preserve existing _domainkey NS delegations; editing a non-authoritative parent copy cannot fix a delegated child. Never remove a shared delegation to make a form accept a record.

A CNAME owner cannot also contain competing TXT, A, AAAA, MX or another CNAME. Investigate collisions before replacement: an existing selector might still authenticate queued messages or another active system. Keep unrelated selectors intact.

Authentication aliases should be DNS-only, not HTTP-proxied. Also inspect flattening: per-record, whole-zone, apex and same-zone behavior can hide a required CNAME answer. Where the provider requires literal aliases, disable the applicable per-record flatten option when supported and ensure relevant zone behavior preserves those aliases. Do not indiscriminately change global settings. Cloudflare's flattening setup guidance describes its controls and conditions. If mandatory behavior prevents the required answer, stop and arrange a supported configuration rather than inventing a switch or altering shared infrastructure.

Do not change MX, parent nameservers, DNSSEC or inbound routes merely to complete sender authentication.

Check public DNS, then application state

Use the packet's exact full owners and compare authoritative DNS with an independent recursive lookup. These commands are read-only templates; substitute approved actual names before running them:

dig TXT APPROVED_SPF_OWNER
dig CNAME APPROVED_FIRST_DKIM_OWNER
dig CNAME APPROVED_SECOND_DKIM_OWNER

The SPF response should contain the intended single complete policy. Each DKIM alias should return the exact confirmed target. Follow the alias to check that the associated public-key lookup can resolve. Do not manufacture output or infer a pass merely because a hostname exists.

If records differ, check the authoritative zone, relative-name convention, record type, conflicts, proxy/flattening behavior and cached answers. Respect actual TTLs rather than promising a fixed propagation time. If public DNS is correct but application verification still fails, supply the provider with the domain, exact failing owner, timestamp and public lookup evidence, without private keys or unrelated customer data.

After application domain and sender checks succeed, record that as configuration evidence. It is not proof that the selected production path signs a delivered message correctly. Keep mailbox control, domain recognition and message authentication as distinct acceptance checks.

Verify the intended message, without creating a legal event

EviMail is a certified-communications workflow. Do not use a real demand, contractual notice, signature request or uninformed recipient as an authentication test. Arrange an explicitly authorized harmless test with controlled recipients and appropriate provider guidance. If a safe test route is unavailable, leave message validation pending rather than treating a documentation review as deployment proof.

For an approved test, capture the original message at the receiving service, the intended From, envelope identity and intended provider DKIM signature. Use Authentication-Results produced inside that service's known processing boundary, following its documented handling of externally supplied results. Header position or a familiar authserv-id string alone cannot distinguish a forged result. Ignore attacker-supplied or untrusted result fields. RFC 8601 explains this trust boundary.

Accept the branded DKIM route only when:

• The visible From is the intended address, not a provider-rewritten substitute.
• The intended provider signature passes cryptographic verification.
• Its d= signing domain aligns with the visible From under the applicable DMARC policy.
• Trusted receiver results show dmarc=pass.

Relaxed alignment compares Organizational Domains; strict alignment requires exact matching identities. Use the actual domains rather than assuming matching labels or a child-domain relationship is enough. A DMARC pass obtained only through SPF does not prove intended DKIM success. For background, the EmailAuth Microsoft 365 DMARC guide explains a different sender's DMARC context; its product-specific setup is not an EviMail substitute.

Troubleshoot the failed layer

Repair SPF problems even if aligned DKIM currently makes DMARC pass. Keep the evidence for each protocol separate. Roll back only the erroneous approved change while preserving later legitimate edits and keys required for queued messages.

Preserve DMARC and control report sharing

This guide validates compatibility with existing policy; it does not prescribe creating a new DMARC record. Preserve direct and applicable inherited protection and authorized report destinations. If no applicable policy exists, agree a separate monitoring and enforcement plan. Do not insert a permissive child policy simply to bypass an inherited requirement. Current DMARC policy guidance is RFC 9989.

For aggregate reporting, compare the report destination's Organizational Domain with the policy domain's Organizational Domain. If they differ, the report-generating receiver must check DNS authorization; a destination within the same Organizational Domain is excepted. See RFC 9990 section 4. This protocol authorization does not replace the domain owner's separate privacy and data-sharing decision.