Keep sending and ticket intake separate
A support address has two jobs: accepting a customer's request and identifying the reply. Proving one does not prove the other. Start this change with the Gorelo administrator, authoritative DNS owner and current mailbox administrator together. Record the desired public address, its existing receiving route and the ticket groups that should handle it. Keep a copy of the existing DNS answers and forwarding settings before making a change.
Gorelo documents a Mailgun-based delivery service using a dedicated sending subdomain while customers continue to interact with the public-facing address. Do not treat the subdomain as a request to replace your organization's normal mailbox service. The exact records must come from the account, not a generic Mailgun example. Gorelo delivery design
Configure the domain and addresses
In Settings > Email > Settings, choose Add Domain, enter the intended domain and publish the displayed records at your DNS host. Preserve the gorelo label in the generated owners and use Verify. Adding a domain creates default help@ ticketing and accounts@ billing addresses; the latter is outbound only. Edit the ticket address to review its From/Reply-To identity and group restrictions. Custom domains
Before publishing, expand each relative DNS name to its full owner name on a worksheet. Some DNS interfaces append the zone automatically. A correctly copied value at the wrong owner is still a failed installation. If an owner already has data, establish its purpose before replacing it. Preserve a single SPF policy at each applicable owner and check its total DNS lookup cost, including nested includes.
For ticket intake, use the account's forwarding destination for the corresponding existing mailbox. Restrict any external-forwarding exception to the approved mailbox rather than opening forwarding globally. A routing change can expose incoming ticket contents, so obtain the normal internal approval before enabling it. Do not create a loop between the original mailbox and the destination.
Run a three-path acceptance test
Original test plan: first send a harmless request directly to the configured forwarding destination. Then send another to the public support address. Confirm that both reach the intended queue and that the public-address test does not create duplicate or looping tickets. Finally, reply from the ticket and send a controlled billing example if billing is in scope. Use synthetic content and controlled recipients, never a real unpaid invoice merely to test delivery.
For each outbound message, retain the trusted receiver's authentication results, visible From domain, SMTP envelope sender, DKIM signing domain and selector. Check that a passing SPF or DKIM identity aligns with From under the applicable DMARC alignment mode. A successful ticket creation and Gorelo's DNS verification are useful observations, but neither substitutes for this received-message check.
Illustrative failure: the direct forwarding-destination test works, but the public address does not. That points the next investigation toward the existing mailbox's forwarding rule or restrictions, not an immediate DKIM-key replacement. If intake works but replies fail alignment, investigate the outbound identity instead.
Recover without disrupting other mail
Pause the affected address or workflow before changing several layers at once. Restore only the last approved forwarding or DNS change that caused the failure, and check that the original mailbox remains reachable. Keep old valid signing records until queued messages and caching have been considered. Repeat the three-path test after a DNS migration, mailbox move or sender-address change.
This is a documentation-based guide reviewed on 8 November 2026. No Gorelo account, DNS zone, ticket or received message was tested; the acceptance plan and failure example are original illustrative guidance.
Assign failures to the correct mail path
Written case GO-01 stipulates that a harmless request addressed directly to the configured Gorelo forwarding destination reaches the intended group, but the same kind of request sent to help@example.com does not. A reply through the direct path has From help@example.com and trusted DKIM pass with d=example.com and s=ticket1; its SPF result is unknown. That single reply has exact DKIM alignment, but says nothing about the missing public-address intake. The existing-mailbox administrator should inspect its approved forwarding rule and destination, while the ticket owner preserves the working reply route. Do not replace DKIM keys to repair intake without evidence. All identities and results are teaching assumptions; no ticket, billing document or message was created.
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.