Define the customer-facing identity
Transactional email is part of the customer's access to a purchased product, so sender changes need an operational owner. List the relevant receipts, license or download messages and their configured From and Reply-To identities. Select a domain your organization controls and identify the DNS owner. This guide describes the Freemius workflow, not the settings of an unrelated SendGrid account.
Freemius documents SendGrid as its transactional transport. Its November 2025 sender update explains that incomplete DKIM, a sender outside the authenticated domain, or a generic mailbox provider triggers a Freemius sender fallback. Reply-To remains unchanged. When domain authentication and sender domain agree, the configured sender remains in use. Source: Freemius, Enhanced Handling of Sender Addresses for Transactional Emails.
A fallback can preserve a delivery route while changing the identity customers see. Do not call it a successful branded-domain rollout merely because the message arrived. Record the intended sender, actual sender and reply destination as separate acceptance fields. Avoid assuming that a custom reply address supplies DMARC alignment; it does not.
Configure the domain in Freemius
In the Developer Dashboard's Emails area, start Authenticate Domain with DKIM, enter the intended domain and choose Authenticate. Publish the generated CNAME records at the authoritative DNS provider, then confirm they were added and select Verify. If aliases conflict, restart the workflow and select the option indicating other DKIM records already exist to obtain different addresses. Freemius says SPF is handled automatically after this setup. Source: Freemius, Email Deliverability.
Use every account-generated value exactly, with the DNS host's owner-name convention. Do not paste the screenshots' example records into production. Before editing, check whether each owner already has a record and who depends on it. A CNAME cannot be repaired by placing competing targets at one owner. The alternate-record workflow is preferable to breaking another sender, but its final names still require inspection.
Do not add a speculative SendGrid include at your root domain to compensate for a failed CNAME check. The provider's automatic SPF statement applies to its documented integration; other legitimate senders still need their own correct authorization. Keep the root SPF policy and all unrelated services unchanged unless a separate, evidence-backed change is required.
Verify DNS and the actual transactional message
First compare authoritative answers with the generated record set. Distinguish publishing at the wrong DNS host from recursive caching: an incorrect authoritative answer is not fixed by waiting. Confirm that the domain suffix was not appended twice and that no conflicting record was overwritten. Then retain the product's verification result.
Use an approved test transaction or other controlled transactional workflow with fictitious data. Do not create a real charge or send a customer license merely to obtain test headers. Preserve the original received message, expected workflow, visible From, Reply-To, envelope identity, DKIM d=/s= and trusted receiver Authentication-Results. A product badge and a delivery log cannot establish all those identities.
Synthetic example: a transactional message has From licenses@example.com and a valid DKIM signature d=example.com. Even if SPF passes for an unrelated provider envelope, exact DKIM alignment can supply the DMARC path. Now change the configured sender to a different organizational domain without authenticating it. The previous test cannot establish authentication for that new identity, and the documented fallback may apply. Retest after any sender-domain change.
DMARC requires at least one passing aligned SPF or DKIM path under the applicable alignment mode. DKIM is a signature, not content encryption or a guarantee that the recipient sees the message. A provider-owned fallback can be valid mail for its own identity without being a branded-domain success.
Investigate customer delivery without losing evidence
Separate four questions: was the workflow triggered, was a message attempted, did a recipient system accept it, and where did it appear? Ask the operator to retain the relevant send event and exact error rather than guessing from a customer's missing-mail report. Check the recipient address, including whether it is the address associated with the intended account. Avoid repeated resends before the error is understood.
If authentication passes but placement is poor, review reputation, content and recipient handling. If the signature is missing or invalid, compare DNS, account verification and the current From domain before changing broad policies. A reply-routing problem is a different layer and requires its own test.
Keep recovery and completion honest
Save prior DNS values and sender settings. Preserve the documented fallback as an explicitly approved operational outcome where appropriate, rather than weakening DMARC across the business domain. Remove obsolete records only after confirming that no active product or delayed message depends on them.
Acceptance requires the intended sender and replies, verified DNS and a real received-message record for every in-scope transactional route. This guide used provider documentation, checked through current primary-source pages and protocol references. It contains no live tenant, purchase, DNS or delivery execution. Human SME review, independent checking and publication remain pending.
Keep the mismatch outcome separate from reply routing
Written case FM-02 assumes example.com is the authenticated domain, but a product now selects licenses@other.example as sender and support@example.com as Reply-To. The new sender domain has not been authenticated. Under the documented mismatch behavior, expect a Freemius From fallback; the actual fallback address and message authentication have not been observed here. Reply-To can remain support@example.com without making other.example an aligned From identity. The product owner must approve the intended sender, complete the matching setup if needed and inspect a controlled transactional message without issuing a real charge or license. No purchase, account change or message 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.