Confirm E-goi sender eligibility before DNS work
E-goi's official Authenticating my email sender guide, updated August 13, 2025, describes sender authentication and a separate domain CNAME requirement. This article covers that E-goi workflow. It does not assume that a mailbox provider's own authentication settings cover marketing mail sent through E-goi, or that a successful test for one sender domain covers another. Start with the actual account, sender address, domain and intended message route.
The guide requires a sender address on a domain the customer controls; it says personal freemail addresses cannot be authenticated through this process. It also states a public-WHOIS eligibility condition for domain authentication and the CNAME setup. Preserve that as a documented provider prerequisite requiring current-account confirmation, not as a general DNS, SPF or DKIM rule. Do not silently weaken it to an optional recommendation or infer that registration privacy makes a domain malicious.
If that condition conflicts with the organization's privacy requirements, keep implementation blocked for a provider clarification and an authorized decision. Do not expose personal registration details merely to make a checklist green. This manuscript does not change registration privacy, collect personal contact information or submit a support request. The source's broader claims about private domains and ownership risk are not used as technical conclusions here.
Choose an authorized configuration route
The documented path starts in the upper-right menu under Senders. Add the intended sender if necessary, then choose Authenticate beside it. E-goi presents three routes: provider-assisted setup, sending instructions to a technical contact, or doing the configuration yourself. These routes carry different permissions and information-sharing consequences. Choosing provider assistance or emailing instructions is an external action, not simply viewing a help page.
For a proposed self-service workflow, identify the DNS administrator and confirm access to the authoritative zone. The guide says to select the domain's hosting company so that E-goi displays the SPF, DKIM and DMARC entries to add. Use the current account's displayed instructions rather than inventing a universal record set. If another team will implement the changes, provide only the necessary public record details through an approved channel and preserve the scope of the request.
Before any change, inventory existing authentication records and other legitimate senders. Record which entries are new, which modify existing policy and which would conflict with an active dependency. Keep a copy of the approved previous configuration for rollback. An account interface can show the requested records, but that view does not establish that the public zone actually publishes them.
Keep the additional CNAME requirement visible
The E-goi guide repeatedly says authentication should be accompanied by adding its CNAME to the domain. Its troubleshooting example describes a name commonly beginning with mkt, but the exact name and target should come from the account's setup. Do not assume this CNAME is identical to a DKIM selector record or create an illustrative mkt name without checking the issued configuration. Give each record a clear purpose in the change record.
Compare the full owner and target with the DNS editor's conventions. A panel may append the zone suffix to a relative label, so an apparently complete input can produce an unintended duplicate suffix. Existing aliases also need review before replacement. Keep the sender-authentication records and the additional domain CNAME as separate acceptance items; a successful check of one does not prove the other is present or appropriate.
The guide's manual checking section names egoi as its DKIM selector example. That is useful context for the documented setup, but actual message evidence should establish the selector and signing domain used by the route being accepted. Do not treat a successful lookup at a familiar label as proof that every campaign uses that key. RFC 6376, section 3.5 defines the signature fields needed for that comparison.
Review SPF and DMARC as domain-wide decisions
The account's SPF instruction must be reconciled with the existing legitimate-sender inventory. Do not publish a second SPF policy or replace unrelated authorizations blindly. RFC 7208, sections 2.4, 3.2 and 4.6.4 define the MAIL FROM identity, multiple-record behavior and evaluated DNS-dependent term limits. Count relevant nested dependencies rather than assuming the number of visible includes is the complete cost.
The provider includes DMARC in its setup guidance, but choosing a domain-wide policy still requires review of other senders and the intended reporting arrangements. Do not overwrite a working policy with a generic sample just to satisfy one service's setup screen. Report destinations are data-sharing decisions and should not be added automatically from examples. The current protocol remains v=DMARC1; there is no need to invent a new version string for current-standard review.
RFC 9989, section 4.4 explains alignment between the visible author domain and a passing authentication identity. Passing SPF for an unrelated envelope domain does not automatically produce an aligned result. Likewise, a signature for an unrelated domain is not sufficient just because the cryptographic check succeeds. Evaluate the actual route and identities rather than equating any green badge with complete DMARC acceptance.
Interpret Verify and DNS delays carefully
After saving DNS changes, the guide directs users back to the still-open E-goi window to choose Verify. It describes SPF and DKIM indicators turning green when the checks pass and red indications when settings are wrong. Preserve the exact result and time. This is a provider configuration check, not proof of delivery to every receiver or evidence that all future messages will authenticate.
The guide suggests that a missing expected value may indicate propagation, but that should not be the only diagnosis. A wrong owner, wrong zone or omitted value can produce the same apparent absence. Compare the authoritative publication and account-issued value before assuming that waiting is sufficient. Its timing estimates are guidance rather than universal deadlines. No DNS query or verification action was performed for this manuscript.
A separately authorized acceptance exercise should use harmless message content and inspect trusted receiver results for the intended sender domain. Record the actual envelope identity, signature domain and selector, author domain and observed route. Avoid uploading real contact lists or confidential messages to third-party checkers. E-goi itself notes that authentication alone is not enough to improve delivery: engagement and other factors remain relevant. No guaranteed inbox or campaign-response outcome is claimed here.
Fictional diagnosis and blank acceptance worksheet
A fictional arts organization, Willow Stage, completes the sender authentication entries but overlooks the additional CNAME item. Its campaign owner marks setup complete from the SPF and DKIM indicators alone. The review compares the full issued checklist with the public-record evidence and finds that the extra domain dependency has not been addressed. The proposed correction is a scoped DNS review and fresh acceptance evidence, not a wholesale policy replacement. The scenario is fictional and contains no real account result, campaign or query.
- Account, sender domain and actual message route: ______
- Current eligibility confirmation, including documented WHOIS condition: ______
- Privacy decision or unresolved provider clarification: ______
- Account-issued SPF, DKIM, DMARC and separate CNAME requirements: ______
- Existing dependencies, authoritative DNS owner and approval: ______
- Verify result and public-record evidence by item: ______
- Trusted received-message identities and alignment result: ______
- Rollback owner, remaining exceptions and release decision: ______
Original implementation evidence, human subject-matter review, current applicability, production routes, visual accessibility and owner release remain open. No record, registration setting or account control was changed. The broader catalogue implementation requirement remains dependent on authorized tenant and message evidence.