Authenticate an E-goi sender from the upper-right menu’s Senders page: select the sender, choose Authenticate and retrieve its DNS instructions. Publish the issued SPF and DKIM records safely, retain your domain’s existing DMARC policy, and complete the separate CNAME workflow. Run Verify in E-goi, then inspect a delivered campaign for aligned authentication. Green DNS indicators alone do not prove DMARC alignment.
This guide covers E-goi campaign senders using a domain you control. It keeps sender authentication, branded link CNAMEs and transactional delivery separate. Authenticating your mailbox provider or another marketing platform does not authenticate E-goi’s sending path.
Check eligibility before making DNS changes
Have the intended sender address, E-goi account access, DNS administrator and authority to change the relevant zone ready. E-goi’s sender guide excludes personal freemail addresses from domain authentication. Use an address on a domain your organization controls. The reviewed instructions do not establish a special paid-plan requirement; confirm account-specific availability instead of assuming an upgrade is necessary. E-goi sender authentication
The same official page states that public WHOIS records are required for its authentication and CNAME workflows. Treat this as E-goi’s documented eligibility rule, not an SPF, DKIM or DMARC protocol requirement. If your registration is privacy-protected or publicly redacted, ask E-goi support whether the rule applies to your account and what approved verification options exist. Do not disable registration privacy or disclose personal contact details merely because a setup article says to. The documentation’s broad privacy and reputation claims are not needed to configure authentication safely.
Retain existing SPF, DKIM, DMARC and CNAME records before proposing changes. Record the desired From domain, DNS zone, account, record owners and administrator. Keep a separate entry for branded links so they are not confused with the message’s signing identity.
Choose a supported setup route
For a new sender, open Senders, select the email category and choose Add. Enter the display name and email address, then enter the confirmation code E-goi sends to that mailbox. Mailbox confirmation comes before domain authentication and does not prove DNS setup. Next choose Authenticate alongside the confirmed sender. Add and confirm a sender
E-goi also documents a freemail fallback: it replaces a personal address with a temporary business sender when sending the campaign and forwards replies to the original address. That is a changed visible sending identity, not permission to authenticate Gmail’s DNS or proof of authentication for your own domain. Choose a controlled branded address for the workflow in this guide. Temporary sender behavior
E-goi documents three authentication routes:
- Set it up for me: provider-assisted setup using information submitted through its form.
- Send a techie the how-to: instructions for your hosting company or technical administrator.
- I’ll do it myself: choose the domain’s hosting provider and obtain the account’s SPF, DKIM and DMARC instructions.
These routes differ in who implements the DNS changes; they are not different authentication standards. Review proposed changes even when an administrator or E-goi carries them out. Do not send account passwords or private keys in ordinary support messages. Official authentication options
For the manual route, capture the full record names, types and values before leaving the configuration window. Keep the window available for Verify after publication. Do not replace an established DMARC policy with a generated starter example, and do not infer the DNS host from where the website is built: nameserver delegation identifies the authoritative DNS service.
Add SPF without creating a second policy
Use the exact SPF authorization displayed in the sender’s configuration, at the owner E-goi specifies. A third-party example is not a substitute for the account’s current record. If that owner already publishes SPF, incorporate the new authorization into the existing policy while preserving all other legitimate senders.
Each owner can have only one SPF TXT policy beginning v=spf1. A domain may have unrelated TXT verification records without creating duplicate SPF. Evaluate the full lookup tree after merging: SPF limits evaluation to ten DNS-querying terms, including nested includes and redirects. If the proposed addition exceeds that limit, review obsolete senders and simplify the authorization set before publishing. SPF publishing and evaluation, RFC 7208
SPF uses the envelope MAIL FROM identity, not the visible From address; for a null reverse-path, the applicable identity is HELO. Record that evaluated identity rather than assuming the visible From domain. SPF identities, RFC 7208 §2. Record the actual smtp.mailfrom from delivery evidence. A valid SPF policy at the root does not establish that E-goi uses the root as its envelope domain, and a branded tracking CNAME does not establish SPF alignment.
An all mechanism matches every remaining sender, so later mechanisms cannot be reached; a redirect= modifier is ignored whenever all is present. A redirect-only design must remain intentional, not accidentally disabled while merging an include. SPF all and redirect, RFC 7208 §5.1.
Do not arbitrarily replace an existing -all with ~all, remove another service or flatten dynamic infrastructure into a static IP list. Those are domain-wide operational decisions, not routine E-goi setup steps.
Publish the sender’s DKIM public record
Copy the issued DKIM owner and public value without substituting a sample key. E-goi’s documentation uses egoi in its selector-checking example, but the actual account-issued owner remains the implementation authority. If your sender’s instructions differ, resolve that difference before publication rather than assuming every account must use the example. E-goi DKIM verification instructions
For a TXT-based key, preserve the complete public data. Long TXT data can be split into quoted strings inside one logical DNS TXT record; concatenate the strings without inserted spaces and do not publish them as separate competing records. DKIM TXT syntax, RFC 6376 §3.6.2.2. If your account issues a different record type, follow its current instructions rather than forcing a TXT recipe.
Check whether the DNS editor expects a relative name or a complete hostname. For illustration, egoi._domainkey.example.com belongs to the example.com zone; an editor that appends that zone may need only egoi._domainkey. For signing domain mail.example.com, full owner egoi._domainkey.mail.example.com is egoi._domainkey.mail in the parent example.com zone, or egoi._domainkey in an independently delegated mail.example.com zone. If _domainkey.mail.example.com itself is delegated, the owner inside that zone is egoi. Check the actual authoritative delegation and editor suffix before saving; these are illustrations, not domains or keys to publish.
DKIM verification locates the key using the delivered signature’s selector s= and signing domain d=. A valid key at a different owner does not validate that signature. Never publish credentials or private keys in DNS. DKIM key discovery, RFC 6376
Complete the separate branded CNAME workflow
E-goi documents a CNAME for branded tracked links in addition to sender authentication. From Senders, find the domain and choose Add CNAME; alternatively use Settings → Domains and CNAME → Add. Enter the intended hostname, choose the documented shared SSL option unless your organization requires its own certificate, and use Generate config to retrieve the records. Publish the account-issued CNAME target and run Verify after DNS is visible. E-goi CNAME setup
Use an unused hostname approved by the administrator, never your website root or an occupied service. A CNAME cannot coexist with ordinary TXT, A, AAAA or MX data at that owner. Save the exact issued owner and target; the authentication page’s mkt example is not a universal requirement. DNS aliases, RFC 1034 §3.6.2.
For Cloudflare, set the verification/link CNAME to DNS only, not Proxied. Turn off that record’s Flatten option if offered, and check DNS settings for whole-zone flattening: flatten-all must not suppress the required literal CNAME. Coordinate services affected by any whole-zone change before turning that behavior off. Per-record controls cannot override whole-zone flatten-all. Apex flattening is mandatory, and a target in the same zone can be flattened regardless of the selected setting. If the required literal alias cannot safely remain visible, stop and ask E-goi for a supported alternate hostname/configuration; do not delete unrelated DNS or move nameservers as a workaround. Cloudflare flattening controls, verification CNAME behavior.
A working branded-link domain is not evidence of DKIM signing or DMARC alignment. It also needs an HTTPS check: open a controlled campaign’s tracked link and confirm that the expected hostname serves a valid certificate and reaches the intended destination without a security warning. Do not bypass a certificate warning.
E-goi documents a separate transactional CNAME option. A campaign’s working link domain should not be assumed to configure transactional messages. Confirm that route’s own settings and test it separately. The article’s certificate guidance also discusses HSTS; if a tracking hostname conflicts with your organization’s HSTS policy, investigate certificate coverage and provider support with the security owner. Do not broadly disable subdomain HTTPS protection as a default deliverability fix. Likewise, the native article’s Wix/DNSSEC discussion is not authorization to migrate nameservers or disable DNSSEC. Those require separate routing/security planning and approval. If using your own SSL certificate instead of E-goi’s shared option, have the authorized security administrator handle any required private-key transfer through an approved secure workflow, not email or this guide.
Retain DMARC policy and plan reporting safely
DMARC evaluates the visible From domain against passing SPF or DKIM identities. An aligned pass from either mechanism is enough; passing both without alignment is not enough. Relaxed alignment permits the same organizational domain, while strict alignment requires exact matching. DMARC, RFC 9989
For example, a message with visible From offers@example.com and a passing intended E-goi signature d=mail.example.com aligns under relaxed adkim=r when both share the same Organizational Domain, but not under strict adkim=s. Passing d=example.com aligns in both modes. The intended signature must actually pass; an unrelated passing signature or a rewritten From is not proof of your branded route. DKIM alignment, RFC 9989 §4.4.
Inspect the existing record and any policy inherited by a sending subdomain. Keep established quarantine or reject policy. Do not create a second DMARC record or paste a new reporting address without approval. A monitored p=none phase may suit a domain with no established policy after sender inventory, but it does not enforce protection. Do not rely on obsolete pct for phased enforcement.
Only if there is no existing or inherited policy and the domain owner approves a first monitoring policy, an illustrative TXT record is owner _dmarc.example.com, value v=DMARC1; p=none. In the example.com zone its relative owner is _dmarc. For a child From domain mail.example.com, the full owner is _dmarc.mail.example.com: use _dmarc.mail in the parent zone or _dmarc in the delegated child zone. Do not create a child exception to an inherited policy merely to use this example. Add an approved rua destination only after establishing the reporting workflow. DMARC publication, RFC 9989.
Obtain the domain owner’s approval for the aggregate-report recipient and data shared, separately from protocol DNS authorization, and ensure the destination can receive reports. A report destination in a different Organizational Domain from the policy domain normally requires external-destination authorization; destinations within the same Organizational Domain are the exception. The receiving report generator must check that DNS authorization before sending reports. An rua address alone does not authorize external transmission, and a public suffix or last-two-label guess is not a reliable Organizational Domain determination. External reporting authorization, RFC 9990 §4. Review trends across all legitimate senders before tightening policy. Failure-reporting data can expose message information and needs a separate privacy decision. Aggregate reporting, RFC 9990
Verify DNS, E-goi status and a real campaign
Use complete account-issued owners in these read-only queries. Replace every uppercase placeholder; skip queries for record types the account did not issue.
dig TXT SPF-OWNER
dig TXT SELECTOR._domainkey.SIGNING-DOMAIN
dig CNAME TRACKING-HOSTNAME
dig TXT _dmarc.VISIBLE-FROM-DOMAIN
Compare authoritative responses with a recursive resolver and the saved configuration. Inspect response status if an answer is empty. Check for duplicated suffixes, wrong zones, incomplete keys and a CNAME that points to the wrong target. DNS caches can retain earlier answers until their TTL expires; repeated edits do not make them expire sooner.
E-goi’s manual workflow uses Verify and displays SPF/DKIM green on successful verification, with failures in red. The CNAME workflow has its own verification. E-goi describes propagation as taking a few hours, with a short-TTL case potentially taking about an hour; these are estimates, not deadlines. These are separate checkpoints, not a guarantee of instantaneous worldwide visibility. Sender verification, CNAME verification
After authorized setup, send a representative campaign to controlled receiving mailboxes using the intended sender. Inspect trusted receiver-added Authentication-Results. Record From, smtp.mailfrom, SPF result, DKIM d=/s=, DKIM result and DMARC result. Establish which receiving service or gateway added the result using that service’s documented trust boundary or administrator-confirmed mail path. The authserv-id string and topmost header position alone do not prove provenance; sender-supplied or untrusted earlier-hop results can be forged. Establish from receiver documentation or its administrator whether externally supplied Authentication-Results fields are stripped or isolated/distinguished, and ignore those untrusted fields. If this handling or the trusted result cannot be established, use receiver-controlled logs or message traces and obtain receiver-administrator confirmation before accepting the test. Authentication result trust, RFC 8601
Accept the campaign only when the intended From address is retained, branded DKIM passes and aligns with the visible From domain under the actual adkim setting, SPF has no unexplained error, and DMARC passes through an identified aligned mechanism. Also check tracked-link HTTPS behavior. Test automations and transactional routes separately when they select different identities or link domains. Investigate actual SPF fail, permerror or temperror even if aligned DKIM supplies the DMARC pass; distinguish those errors from an authenticated but nonaligned SPF identity. An SPF fail means the evaluated policy did not authorize that sender; permerror points to a permanent policy/evaluation problem such as duplicate SPF or excess lookups; temperror is a transient DNS/processing failure. Diagnose the evaluated identity and its dependencies rather than adding another root policy. SPF results, RFC 7208 §2.6. A successful sample is evidence for that route at that time, not an inbox guarantee.
Troubleshooting and a diagnostic example
SPF or DKIM stays red
Compare the displayed record against authoritative DNS, not just the hosting editor. Confirm the selected sender, record owner and type. If correct data is publicly visible but Verify still fails, preserve the error and ask E-goi support to check account validation. Do not keep switching between conflicting tutorial values.
Sender checks are green but links fail
Inspect the separate CNAME configuration and certificate. Broken links or images can be a branded-domain problem even when DKIM works. Escalate certificate or HSTS conflicts without weakening the domain’s security policy.
DMARC fails despite SPF passing
Compare smtp.mailfrom with the visible From domain under aspf, and the passing DKIM d= under adkim. An unrelated envelope domain cannot align merely because SPF passes. Correct the signing identity or supported sender configuration rather than weakening DMARC.
A fictional diagnosis: E-goi reports green DNS, but a campaign from offers@example.com arrives with passing SPF for an unrelated domain and no aligned DKIM signature. The next step is to check the selected sender and its actual signing configuration. Adding another root SPF record or verifying the tracking CNAME again does not establish message alignment. This is an illustrative failure, not a tested E-goi outcome.
For interpreting a passing signature that still fails policy alignment, see raw DKIM results versus aligned DKIM policy results.
Domain privacy blocks authentication
Ask E-goi to clarify its documented WHOIS eligibility for the exact domain. Do not assume publicly redacted registration is a technical SPF failure. Keep privacy changes under the domain owner’s control.
Review scope and maintenance
No customer account, DNS change, sending test or delivery result was inspected. Revalidate after changing senders, domains, certificates or sending routes.