Confirm that custom sending is available
This guide covers Greenvelope's documented business-account premium feature for sending invitations from your own domain. It does not assume that every personal invitation account supports it. Begin with the account owner, event owner and DNS administrator. Record the invitation, desired sending address and who will approve any feature purchase or account change.
Greenvelope's guide identifies the feature as business-only and premium. Its custom-sending setup publishes a DKIM TXT record at gvdkim._domainkey, using the complete public key from the current provider instructions. The feature is enabled through the invitation's Details > Information > Advanced Options workflow. Confirm the current account entitlement before committing to a launch date. Greenvelope custom DKIM
Prepare the domain without guessing a key
Retrieve the current public-key value from the provider, not a screenshot, old internal document or this guide. Record its full intended owner name and the domain whose address guests should see. Check existing data at that selector. If the owner is occupied, find its current user before replacing anything. Preserve the old value in the approved change record.
Use the authoritative DNS service rather than assuming the domain registrar hosts the zone. Confirm whether its editor appends the zone name to the host field. For a long DKIM key, follow the DNS provider's supported TXT-string handling so the complete value remains in one TXT resource record. Accidental line breaks, omitted characters or a second contradictory key can make verification fail. Never publish private signing material.
Greenvelope encourages a DMARC record. Review the organization's existing policy and reporting configuration rather than inserting another policy or automatically downgrading enforcement. This documentation does not establish a customer-specific SPF envelope domain or a custom Return-Path procedure, so do not invent an SPF include to accompany the DKIM record. Determine the real envelope identity from a controlled received message.
Test the invitation identity before the guest send
Original acceptance worksheet: record the invitation identifier, selected custom address, feature-enabled state, public selector answer and controlled recipient. Send a harmless invitation through the same workflow intended for guests. Keep the received original privately and extract the visible From domain, DKIM d= and s= values, SPF envelope domain and trusted receiver's authentication results.
DMARC can pass through a passing DKIM signature aligned with the visible From domain, even when SPF uses another domain. Conversely, a visible company address and an inbox delivery do not prove aligned authentication. Compare the actual identities and applicable policy mode instead of treating appearance as verification.
Illustrative scenario: the public key is correct for the company domain, but the invitation was never switched to the custom-sending feature. DNS edits alone cannot change the selected invitation identity. Check the account and invitation configuration before replacing the key. A different failure, such as a missing character in the TXT key, calls for a DNS correction and another message test.
Plan recovery around the event
Do not discover authentication problems during a full guest send. Assign a person who can pause the invitation workflow, retain the previously approved sender configuration and agree on any fallback with the event owner. Do not imply that a fallback is authenticated until it has its own evidence. Keep valid prior DNS records until queued messages and dependencies have been considered.
Documentation was reviewed on 8 November 2026. No premium feature was purchased, no Greenvelope account or guest list was accessed, and no DNS or invitation delivery was tested. The worksheet and examples are proposed operational checks.
Keep entitlement and message proof on separate rows
Written case GV-01 assumes events@example.com is the approved From and the DNS administrator has published the complete current public key at gvdkim._domainkey.example.com. The invitation’s custom-sending feature is not yet enabled and its purchase entitlement is unconfirmed. No message, envelope or signature result exists. The event owner must settle entitlement and explicitly approve any purchase before activation; then use a controlled invitation, not the guest list, to verify actual identity. DNS readiness cannot authorize payment or prove custom sending. No purchase, account action, DNS change or invitation was executed.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.