Elvanto SPF, DKIM and DMARC setup, step by step

To authenticate your own domain for native Elvanto email, obtain the three CNAME records generated for that domain in Elvanto, publish the exact records at its authoritative DNS host, and check that its Sending Domains status becomes Valid. Then send a controlled message through Elvanto and verify the intended signature and DMARC alignment at the receiving mailbox. If your domain is shared, ask Elvanto Support for a unique account-specific CNAME packet first. Do not substitute a generic SendGrid SPF record or copy another church's selectors. Elvanto: Sending Domains

This guide covers Elvanto's native church-management email route. Elvanto identifies SendGrid as its delivery service, but the documented setup starts in Elvanto, not a separately created SendGrid account. It does not configure Mailchimp integration, an Elvanto website custom domain, SMS, or every other Tithely product.

On this page: Start with the right sender and domain · Obtain the exact Elvanto CNAME packet · Publish the records without disturbing other services · What to do about SPF · Confirm domain status and approved From permissions · Validate DNS and an actual Elvanto message · Troubleshooting Elvanto-specific failures · Frequently asked questions

Start with the right sender and domain

Domain authentication and permission to use a From address are different controls. First agree which church-owned domain and addresses the organization intends to use. Record the existing DNS configuration and identify the administrator authorized to change it. Access to the website editor alone does not establish DNS authority.

Elvanto's domain list draws on its default sending address, configured From addresses, and custom sending addresses in email templates. Inspect each applicable path rather than authenticating one address and assuming every template and group leader is covered. The Sending Domains documentation references the default under Settings > Account; the separate Using Email guide describes entering and saving the default under Settings > Communication. Follow the controls actually present in your account; if these do not match, ask support instead of changing unrelated account fields. Sending Domains, Using Email

A personal gmail.com or yahoo.com address is not a domain you can authenticate through Elvanto. A church-owned domain hosted by a mailbox provider is a different case: ownership of that domain, not the mailbox provider's name, determines whether you can publish its records. Changing the display name or Reply-To does not authenticate the visible From domain.

By default, Elvanto can use the sending user's profile address. Do not assume that address belongs to the verified domain. Review existing sender permissions, approved From entries and template overrides before testing. Keep the original mailbox service and its DNS intact; adding Elvanto is not an instruction to migrate inbound email.

Obtain the exact Elvanto CNAME packet

1. Open Settings and the Sending Domains section under Communication. The Using Email guide also calls this the Sending Domain tab.
2. Find the exact domain used by the intended From address. If it is absent, review the configured default, From and template addresses with the administrator.
3. Select Get CNAME Records for a domain awaiting setup. Elvanto generates three records and provides a draft you can pass to your authorized DNS administrator.
4. Retain each record's complete owner and target, together with the account and domain it belongs to. Use the live values, not examples found in another provider's guide.
5. If the domain is shared, stop before publishing a standard packet and request the unique CNAMEs Elvanto Support specifies for your account. Check for other applications or Elvanto accounts already using the same names. Elvanto: account-issued records and shared domains

The public instructions establish the three-record authentication workflow but do not publish universal owner names, selector values, regional targets, or a guaranteed Return-Path. They also do not label the individual purposes of every generated row. Preserve the complete packet and ask support to explain any owner whose function or destination is unclear. Do not assign roles to the rows solely from their count or from another SendGrid integration.

You should not need to disclose a mailbox password or DKIM private key for this DNS setup. A support request can identify the account, intended sending domain and conflicting public DNS owners without including church-member lists, message contents, or credentials.

Publish the records without disturbing other services

Use the provider hosting the authoritative DNS zone, which may differ from the registrar or website host. Compare the proposed owners and destinations with the approved authentication and routing plan. If a packet introduces tracking or other web/bounce routing beyond the agreed scope, obtain the owner's approval before activating it. A provider-generated value is not permission to redirect an existing service.

For each issued row:

• Choose CNAME, not TXT. Preserve the complete target supplied by Elvanto.
• Translate the full owner correctly into the DNS editor's naming convention. If the editor automatically appends the zone, enter only the relative portion. Inspect the saved full name to catch a doubled domain suffix.
• If a child domain is separately delegated, edit its authoritative zone. Do not remove parent or _domainkey delegations to force a record into the wrong zone.
• Inspect existing records at the exact owner before adding anything. A CNAME cannot coexist there with unrelated A, AAAA, MX or TXT data, or another CNAME target. Do not delete a conflicting selector or route that another sender still needs. Ask Elvanto and the DNS administrator for a supported resolution.
• Keep email-authentication aliases DNS-only rather than HTTP-proxied. Where literal CNAME answers are required, make sure flattening does not hide them.

For Cloudflare, turn off the applicable per-record Flatten option when available for these aliases. A zone-wide flatten-all setting can override individual behavior; review its dependencies before an authorized change rather than disabling it blindly. Apex and same-zone target behavior may flatten automatically. If the required CNAME answer cannot be preserved, stop and coordinate a supported configuration instead of inventing a switch or changing other services. Cloudflare: CNAME flattening

This workflow does not require changing the root nameservers, inbound MX, website address, DNSSEC, or every existing DKIM selector. Preserve the direct and inherited DMARC policy, its alignment settings and authorized report recipients. Do not create a second DMARC policy or weaken enforcement merely to make a test arrive.

What to do about SPF

Use Elvanto's generated authentication packet. Its current public setup calls for CNAME records, not a universal root-domain SPF include. Do not add include:sendgrid.net just because Elvanto uses SendGrid, and do not replace your mailbox service's SPF policy.

SPF checks the SMTP MAIL FROM identity, or HELO in applicable cases, rather than automatically checking the visible From address. Determine the actual envelope identity from a trusted receiver's result. A passing SPF result for a provider-owned domain does not by itself authenticate your church's visible From domain for DMARC.

If support supplies a separate, route-specific SPF requirement, confirm the evaluated owner before editing it. Maintain one v=spf1 TXT policy per owner, preserving legitimate senders and the approved ending qualifier. Account for the limit of ten evaluated DNS-dependent terms, including nested processing, not merely ten written includes. An all mechanism causes redirect to be ignored. Do not change -all to ~all as an automatic deliverability workaround. RFC 7208: SPF

Confirm domain status and approved From permissions

Elvanto documents these statuses:

Elvanto mentions 24–48 hours for records to start working. This is an estimate, not a reason to ignore a wrong target or authoritative-zone mistake. The public instructions do not establish a separate universal Start Signing button; do not invent one. If Valid never appears despite correct authoritative answers, ask support to inspect the exact account/domain association. Elvanto: statuses

Next confirm that the sender can select the intended address. Elvanto documents From entries under Settings > Communications > Email Settings, using the plus control and Save. Under Settings > Access Permissions > Admin Area Menu > Communication, the administrator can allow communication access, permit sending from specific addresses, and select those addresses. Change these permissions only for authorized users and approved addresses; authentication is not a reason to grant everyone broader sending access. The composer then provides the permitted From choices. Using Email, From-address permissions

Validate DNS and an actual Elvanto message

Check all three issued owners against their authoritative nameserver and an independent recursive resolver. For example, replace both placeholders below with actual values from the approved packet:

dig @AUTHORITATIVE_NAMESERVER CNAME ISSUED_FULL_RECORD_OWNER
dig CNAME ISSUED_FULL_RECORD_OWNER

The required observation is the exact expected alias target, not merely an IP response or a green generic domain score. Repeat for every issued owner. DNS publication demonstrates configuration; it does not demonstrate that a particular email was signed.

After Valid status, have an authorized operator send a small, non-sensitive test through the actual native Elvanto workflow to a controlled, consenting mailbox. Use the intended From selection and test relevant template overrides separately. Do not broadcast to the congregation, enable archiving, re-subscribe anyone, or bypass suppression to create a test.

At the receiving mailbox, inspect raw headers and results generated inside the receiving service's known processing boundary. Use that service's documented handling of externally supplied Authentication-Results, or ask its administrator which results are authoritative. Header position and a familiar authserv-id string alone do not establish trust; ignore attacker-inserted or otherwise untrusted result fields. RFC 8601: Authentication-Results

Record and compare:

1. The visible From domain: it must remain the intended church identity, not an unexpected provider rewrite.
2. The intended Elvanto-route DKIM signature, its signing domain d= and selector s=, and the receiver's result for that signature. Require a passing, aligned intended signature; another unrelated signature or SPF-only DMARC pass does not prove this setup works.
3. The SPF result and evaluated MAIL FROM domain. Diagnose any failure independently, even if DKIM supplies DMARC pass.
4. The receiver's DMARC result and the currently applicable alignment modes. Require dmarc=pass for the intended From identity.

Relaxed DKIM alignment allows the signing domain and visible From domain to share an Organizational Domain; strict alignment requires an exact domain match. SPF alignment makes the corresponding comparison using MAIL FROM. A child envelope domain does not automatically meet strict SPF alignment. Preserve the approved policy and resolve the sending identity rather than silently relaxing it. RFC 9989: DMARC

For more on interpreting these two different results, see raw DKIM results versus aligned DKIM policy results. Keep minimally necessary evidence privately; no member data or message bodies need to be pasted into public testing tools.

Troubleshooting Elvanto-specific failures

Only some senders fail. Compare the actual profile From address, permitted composer selection, default address and template override. Elvanto warns that personal or unverified addresses can cause problems even when an organization's domain is configured. Authenticate and authorize the intended address, not just a similarly named domain. Elvanto delivery troubleshooting

The domain remains Incomplete. Check authoritative-zone selection, duplicate suffixes, missing rows, copied targets, CNAME conflicts, proxying and flattening before waiting longer. For a shared domain, confirm that support issued the unique packet for this account.

Valid appears, but DKIM is missing, fails or does not align. Confirm the message really traveled through native Elvanto with the intended address. Compare its selector and signing domain with the current account packet. Stop rollout and ask support about signing for that route; do not invent a public key or treat another sender's valid signature as success.

SPF fails while DKIM passes. A fail means the evaluated authorization did not pass for that sending path; investigate the actual envelope owner and sending service. A temperror indicates a temporary evaluation/DNS problem and needs investigation and retesting. A permerror points to a permanent configuration/evaluation problem such as multiple policies or excessive DNS-dependent terms. Do not dismiss any of these just because aligned DKIM yielded DMARC pass.

The message is Sent or Delivered but not in the inbox. Elvanto's troubleshooting guide distinguishes its delivery-service status from recipient filtering. The recipient profile's Activity tab can help establish whether Elvanto sent a message, but it cannot prove receiver authentication or inbox placement. Review the controlled test's delivery evidence without blanket allowlisting, removing unsubscribes or weakening spam checks. Elvanto delivery troubleshooting