Identify the integration before editing DNS
Record the Gorgias email address, integration type, intended From domain and DNS owner. A customer-support mailbox can remain readable while outgoing replies use an unexpected identity. Include one reply from the actual helpdesk in the acceptance plan rather than relying only on an incoming test.
Gorgias requires domain verification before sending through automatic forwarding. Its documentation strongly recommends verification for custom domains on direct integrations too. An administrator can obtain the records through Settings > Channels > Email, select the address and open Verify Domain. Verification workflow
Follow the account’s record family
The current documented workflow supplies two DKIM CNAMEs and a custom Return-Path CNAME. Publish all three with their own account-provided destinations, then use Check Status. Some accounts instead display legacy TXT values for SPF and DKIM; use the matching branch rather than combining instructions from both. The provider allows up to 72 hours for verification. Required records and legacy branch
Make a record-by-record comparison before saving: intended fully qualified owner, record type, target or value, existing data and reason for change. If the DNS editor appends your domain, enter the relative label that produces the intended full name. Do not paste a second complete domain onto an already completed owner. Check CNAME conflicts before replacing a TXT record at a DKIM selector.
A legacy SPF value must be reconciled with the existing single SPF policy, not installed as a second policy at the same name. Preserve authorized mailbox and other application senders. Assess nested DNS lookups against the protocol limit. For CNAME-only accounts, do not add an unrelated root SPF include just because an old tutorial shows one.
Keep DMARC a domain-owner decision
Review the domain's existing DMARC policy and reporting destination with its owner. A provider's example is not permission to replace an established policy or route reports to an unowned mailbox. Inventory other legitimate senders before changing enforcement. SPF authenticates the envelope identity and DKIM authenticates its signing domain; DMARC passes when at least one passing identity aligns with the visible From domain. It does not require both methods to align, although a receiving service can impose additional sender requirements.
Verify a complete support exchange
Original acceptance worksheet: record the inbound ticket, outbound reply and any automated reply actually used by this inbox. For each outbound case, capture the trusted receiver's SPF result and envelope domain, DKIM result with d= and s=, visible From domain and DMARC result. Compare the custom Return-Path with the planned bounce identity rather than assuming the visible address is also the envelope sender.
Illustrative scenario: the two DKIM records verify, but the Return-Path owner was entered with the zone name twice. Treat that as an incomplete configuration, even if one message passes DMARC through DKIM. Correct the owner and retest the intended route; do not weaken the domain policy to hide the missing record.
Resolve failures in a controlled order
Compare authoritative DNS answers with Gorgias values first. Then distinguish caching from a wrong owner or missing record. Finally compare the actual sender selected for the reply. Preserve the last working configuration and pause only the affected workflow if customers are receiving errors. Do not delete old selectors until their dependencies and in-flight mail are understood.
Documentation was reviewed on 8 November 2026. No Gorgias tenant, DNS change or delivered support message was tested. The worksheet and scenario are proposed operational checks, not observed customer results.
Inspect a partial configuration without hiding it
Written case GO-01 assumes From help@example.com and a trusted passing DKIM signature d=example.com, s=gor. The intended account-generated Return-Path owner is represented as em123.example.com, but the fictional zone inventory instead lists em123.example.com.example.com. The label is illustrative, not an account value to publish; the actual target and SPF result are unknown. DKIM supplies an aligned path for this hypothetical message, while the DNS owner still needs to fix the specified Return-Path record using real account values and retest the route. Do not call all configuration complete from that DKIM pass or invent a complete SPF verdict. No Gorgias account, DNS change or delivery was used here.
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.