Envoke SPF, DKIM and DMARC setup, step by step

To authenticate email sent from your Envoke account, verify your From domain with the account-generated DKIM instructions and retain an appropriate DMARC policy. Envoke manages SPF for its own envelope domain, lists.bettermail.ca. Adding the optional include:spf.envoke.com to your domain does not change that envelope or create SPF alignment. For your custom From domain, the practical DMARC path is a passing, aligned DKIM signature. Envoke DKIM setup and SPF behavior.

This guide covers outbound communications you manage and send through Envoke using your organization's domain. It does not configure Envoke's own login or billing emails, a personal mailbox, or an unrelated SMTP service. No customer account, DNS zone or delivered message was tested.

What Envoke manages and what you must configure

Envoke's current technical-settings page lists DKIM and DMARC as required, while customer-domain SPF changes depend on internal configuration. Authenticate the domain before treating it as ready to send. Do not rely on an old volume threshold as permission to skip the current setup requirements. Envoke technical settings.

Envoke explicitly says its envelope sender uses lists.bettermail.ca and that a custom envelope header is not available. A branded From or Reply-To does not remove that underlying identity. Envoke internal-delivery explanation.

Gather the account and DNS details first

Have the following ready:

• Access to Envoke Account Settings and the Email Sending configuration.
• The exact sender address and domain, including any subdomain.
• The DNS administrator for that domain and a copy of its current records.
• An approved reporting destination and the owner of the existing DMARC policy.
• A controlled recipient mailbox for an authorized test and someone who can inspect its raw headers.

Envoke requires a sender domain you control. You cannot authenticate gmail.com, yahoo.com or another organization's domain just because you own an individual mailbox there. Sender names and addresses are managed in the Email sending group of Account Settings. Envoke sender-address requirements.

For example, updates@comms.example.com uses the sender domain comms.example.com. Record that exact name. A verification for example.com should not be treated as proof that Envoke is signing with comms.example.com; inspect the issued instructions and the received signature.

Keep a change record containing the account, From domain, issued DNS owner and responsible administrator. If separate accounts or additional domains are involved, obtain and compare their instructions rather than assuming keys or selectors are reusable.

Set up and verify Envoke DKIM

1. In Account Settings > Email Sending, enter the domain you intend to send from.
2. Select Start domain verification.
3. Retain the generated key and use the instructions-copy control to obtain the associated DNS directions.
4. Have your DNS administrator publish the supplied configuration. Copy the specified record type, owner and full value, not just a key fragment.
5. Return to the settings page and select Verify. A successful result completes Envoke's documented verification flow; a failure requires reviewing the DNS setup.

The public procedure does not provide a universal selector or public key for every account. Use the values generated for your domain. Envoke's DKIM procedure.

After verification, confirm that the message's selected From address belongs to the intended domain. Adding an address, configuring Reply-To and authenticating a domain are different tasks. Reply-To affects replies; DMARC evaluates the actual From domain. Envoke sender management and DMARC identifier alignment.

Avoid DNS naming and key-length mistakes

Treat the issued hostname as an exact DNS owner. If an account instruction gives an owner such as issued-selector._domainkey.comms.example.com, the relative name depends on the zone:

This selector is illustrative, not an Envoke default. Some DNS forms require the full hostname instead. Check the resulting public name to ensure the zone was not appended twice.

If the instructions call for TXT, retain the complete key value. A long TXT record can contain multiple quoted character strings in one resource record. The strings are concatenated without inserted spaces during DKIM verification. Do not create multiple independent TXT records containing different pieces of a single key. DKIM key-record storage.

Envoke warns that a DNS interface can truncate a long key. Its help text describes splitting the key; implement that using your DNS provider's supported single-record string format. A shorter value is not an acceptable substitute for the issued key. Envoke key-length troubleshooting.

Do not overwrite another service's selector. If the exact owner already contains a record, identify its purpose and coordinate the change. A CNAME cannot ordinarily share an owner with TXT data, so stop and resolve such a conflict rather than adding both. DNS CNAME restrictions.

Only if a supported managed-DKIM arrangement uses a CNAME: in Cloudflare, preserve the issued target, choose DNS only, keep the record-level Flatten option off where available, and check that zone-wide CNAME flattening for all CNAME records is off. A zone-wide flatten-all setting cannot be overridden per record. These controls concern CNAMEs, not the native TXT record. Cloudflare CNAME verification and flattening controls.

If mandatory apex flattening or a same-zone-target exception prevents the required literal CNAME answer, stop and obtain a provider-supported, owner-approved hostname or DNS design. Do not declare a synthesized A/AAAA answer equivalent to the required alias or blindly change a shared zone setting.

Coordinate any shared setting change with the DNS owner and affected services first. Preserve legitimate child-zone and _domainkey delegations; publish at their authoritative DNS provider rather than removing or repointing NS records just to make one sender verify. Follow the actual supported account instructions.

Decide whether your SPF record needs a change

SPF authorizes a connecting server for an SMTP envelope identity. Envoke documents that it manages SPF for lists.bettermail.ca, the domain used in its Return-Path. It also publishes this optional mechanism for customers whose internal policy requires Envoke authorization in their own SPF record:

include:spf.envoke.com

That is a mechanism, not a complete TXT record. It does not configure DKIM or a custom envelope. Envoke SPF documentation.

If your DNS owner approves the optional include

Inspect the existing policy at the intended domain first. For a sender domain comms.example.com, the relative owner in an example.com zone is comms; in a delegated comms.example.com zone it is the zone apex, commonly represented by @. For example.com itself, it is the apex of that zone. Follow the DNS host's input format.

Merge the mechanism into the existing v=spf1 TXT policy before its terminal all, retaining legitimate senders and the existing reviewed qualifier. Do not publish a second SPF policy at the same owner. If the policy uses redirect=, have its owner review how the proposed change affects evaluation instead of appending terms mechanically.

Check the complete policy, including nested includes, against SPF's ten DNS-lookup-causing-term limit. Preserve unrelated TXT verification records and avoid authorizing an IP merely because it appeared in an old example. SPF publication and processing limits.

Any all mechanism causes SPF to ignore redirect, regardless of its position. Preserve the authorized qualifier and redirected authorization design; do not insert all casually when merging. A qualifier determines an SPF result, not a guaranteed delivery or rejection decision. SPF all/redirect rule.

SPF can also evaluate HELO; for a null reverse-path (MAIL FROM:<>), the HELO identity supplies the SPF identity used in the applicable DMARC SPF evaluation. Record the actual receiver-evaluated identity rather than assuming every message has the normal envelope sender. SPF identities.

Why SPF can pass while remaining unaligned

Consider an email with From: updates@comms.example.com and an envelope sender under lists.bettermail.ca. SPF can authenticate the Envoke domain, but it does not match the customer's domain. Adding Envoke to comms.example.com does not change which domain the receiving server evaluates.

The correct acceptance target for this route is therefore aligned DKIM plus the expected DMARC result, not a customer-domain SPF alignment result that the documented envelope cannot provide. SPF failures in a real direct-delivery sample still deserve investigation; the existence of a DKIM pass does not explain every transport problem.

Add DMARC without weakening an existing policy

Start by checking whether your domain already has an applicable policy. Envoke's DMARC page instructs customers to inspect the current configuration before adding a record. Its example is not permission to replace stronger protection. Envoke DMARC guidance.

If comms.example.com is a delegated DNS zone, use _dmarc there. Absence at the child's direct owner does not prove that no policy applies. Review the inherited policy and the current standard's DNS tree-walk discovery before adding an override. Preserve the organization's p, sp, np, alignment and reporting choices. RFC 9989 policy discovery.

Do not add duplicate DMARC policies at one owner, replace quarantine or reject with none, or change strict alignment simply to make an incorrectly configured sender appear healthy.

If there is genuinely no applicable policy and the domain owner approves monitoring, publish one TXT at the appropriate DMARC owner mapped above; this illustrates its value:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use an authorized, monitored reporting destination, not the example address. p=none requests no DMARC enforcement; it does not make authentication pass. Enforcement changes should follow an inventory of legitimate senders and representative report evidence, not a single Envoke test.

When the report destination has a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check external-destination DNS authorization. A destination within the same Organizational Domain is excepted even when the hostnames differ; this protocol rule is separate from the owner’s report-recipient/data-sharing approval. For a policy at comms.example.com and destination reports@collector.example.net, the authorization owner is comms.example.com._report._dmarc.collector.example.net, normally managed by the collector. Obtain its actual instructions and approval to receive your reports. Aggregate reports disclose sending domains, IP addresses and message counts, so review the collector's access and retention arrangements. RFC 9990 external-report authorization.

For DKIM alignment, compare the signing d= domain with the visible From domain. Strict mode requires an exact match; relaxed mode requires the same Organizational Domain. A valid signature for an unrelated provider domain does not satisfy DMARC for yours. RFC 9989 alignment rules.

For a hypothetical passing signature with d=news.example.com and visible From sender@example.com, DKIM aligns in relaxed mode but not strict mode. A passing d=example.com signature with that same From aligns in both modes. These examples illustrate comparison rules, not measured provider signing identities. DKIM alignment.

Verify the result in three separate places

1. Public DNS

Replace these illustrative domain and selector values with your own. The provider SPF lookup is diagnostic, not an instruction to edit Envoke's DNS.

dig +short TXT issued-selector._domainkey.comms.example.com
dig +short TXT _dmarc.comms.example.com
dig +short TXT _dmarc.example.com
dig +short TXT lists.bettermail.ca

Compare the DKIM value with the issued instructions. Check authoritative DNS and at least one public resolver, especially after a change. If your account supplies a different record type, query that type and follow its target as applicable. Use the actual record type, not a guessed TXT/CNAME conversion.

If you changed your own SPF policy, query its exact owner too. A successful lookup at example.com does not validate a policy at comms.example.com.

2. Envoke verification status

Confirm that Verify succeeded for the intended domain in the correct account. A published DNS value and a saved sender address are not substitutes for that result. Retain the date and domain with your change record.

3. A new message received through the intended route

After approval to send, deliver a fresh message to a controlled recipient using the intended From address. Start with direct delivery; inspect internal and forwarded paths separately if they matter to your communications.

Open the raw message and use Authentication-Results from the receiving system you trust. A copied result line or a header supplied by an unknown sender is not reliable proof. Have the receiving-domain administrator identify the trusted authentication service and confirm that externally supplied Authentication-Results are stripped or clearly distinguished. If that cannot be established, use receiver-controlled authentication logs or message-trace diagnostics instead. A familiar service name or header position alone does not establish trust. RFC 8601 authentication-result trust.

This is an illustrative result, not a captured Envoke test:

From: Community Updates <updates@comms.example.com>
Return-Path: <message-token@lists.bettermail.ca>
Authentication-Results: mx.receiver.example;
 spf=pass smtp.mailfrom=message-token@lists.bettermail.ca;
 dkim=pass header.d=comms.example.com;
 dmarc=pass header.from=comms.example.com

In that example, DKIM supplies the aligned path. SPF authenticates the separate Envoke identity. Record the real DKIM-Signature d= and s= values and verify the corresponding s._domainkey.d DNS name. Do not accept a generic “DKIM pass” without checking which signing domain passed.

Complete the check only when the intended branded DKIM signature has dkim=pass, its signing domain aligns with the actual From domain under the effective adkim mode, and the trusted receiving system reports dmarc=pass. A verified DNS key, an unrelated passing signature or the sample above does not satisfy this requirement. Neither an SPF-only DMARC pass nor rewriting From to an unrelated fallback domain completes the intended branded-DKIM setup.

Investigate SPF errors independently: fail or softfail requires checking the evaluated identity and connecting IP; permerror requires checking invalid/duplicate policies and lookup limits; temperror points to a temporary evaluation problem such as DNS failure. Compare direct and forwarded paths. An unaligned spf=pass for lists.bettermail.ca is not one of those errors. Do not dismiss an actual failure because DKIM supplies DMARC success, or try to repair Envoke's envelope policy with a blind edit to your own root SPF. SPF result meanings.

Keep the DNS result, Envoke status and receiver result as distinct evidence. None alone establishes that every communication reaches an inbox.

Troubleshoot Envoke authentication and delivery

For internal delivery, Envoke recommends checking technical settings and involving your IT team before escalating to support. A local rule that dislikes different From and envelope domains is not proof of an SPF error. Prefer a narrowly reviewed mail-flow fix based on authenticated traffic rather than disabling anti-spoofing or broadly allowing every message from a provider. Envoke internal-delivery troubleshooting.

For a missing external message, check Email sending history on the contact details page and inspect the detailed event or bounce reason. Envoke may exclude contacts because of repeated bounces, revoked/expired consent or unverified double opt-in status. DNS edits do not remove those causes. Do not relabel optional communications as mandatory merely to bypass an exclusion. Envoke delivery troubleshooting.

No recorded bounce is not proof of inbox placement. The recipient may accept a message and then quarantine it, place it in spam or apply other local handling. Preserve the account, timestamp, sender domain and relevant authentication or bounce details for an approved support request.