How to set up DMARC/DKIM/SPF for Gorelo
Published 1 Jul 2026
Updated 2 Nov 2026
13 min read
Summarize with
Updated on 2 Nov 2026: We clarified Gorelo DNS verification and corrected the DMARC rollout guidance.
Gorelo custom-domain email uses Mailgun for delivery through a custom sending subdomain. Add the domain in Gorelo, publish every generated SPF and DKIM record at the exact gorelo-prefixed hostname, then publish DMARC on the visible From domain. Treat Gorelo as a separate sender because ticket replies and billing emails need their own verified authentication path.
Gorelo places custom sending domains under Settings > Email > Settings. Its custom domain instructions say to keep the gorelo subdomain on every generated record. Copy the records for your domain from Gorelo instead of using a generic SPF include or guessed DKIM selector.
Add your domain
Start inside Gorelo before editing DNS. You need access to Gorelo's email settings and permission to edit the domain's authoritative DNS zone. Gorelo generates the records first; their hostnames determine which domains SPF and DKIM authenticate.
- Open settings: Sign in to Gorelo, then go to Settings > Email > Settings.
- Create domain: Click Add Domain, enter the domain users should see in the From address, then save.
- Copy records: Copy every DNS field exactly. Keep the gorelo label wherever Gorelo includes it.
- Publish DNS: Add every generated record at your DNS host using the exact record type, hostname, and value, including any MX records shown for the Gorelo subdomain.
- Verify in Gorelo: Return to Settings > Email > Settings, click Verify, and confirm the domain's required records are verified before sending production mail.
Gorelo Settings Email screen with the Add Domain dialog open
What Gorelo is checking
- Ownership: The verification record proves control of the Gorelo-specific sending subdomain.
- Signing: The DKIM records let Gorelo sign mail with keys tied to your domain.
- Bounces: The Return-Path record lets SPF pass on a subdomain that shares the visible From domain's organizational domain under relaxed alignment.
- Routing: The forwarding address connects inbound support mail to Gorelo after domain verification.
|
|
|
|---|---|---|
Verify | Gorelo host | Domain proof |
DKIM | Selector | Message signing |
SPF | Return-Path | Sender check |
Mailbox forwarding | Mailbox | Ticket intake |
Gorelo domain verification and mailbox forwarding have separate jobs.
Enter Gorelo DNS records correctly
DNS hosts differ in how they accept record names. Some append the zone name automatically. For the example.com zone, entering gorelo.example.com in a relative-name field creates gorelo.example.com.example.com and prevents domain verification. Check the saved full hostname against Gorelo's value.
|
|
|
|---|---|---|
gorelo.example.com | gorelo | Sending subdomain records |
selector._domainkey.gorelo.example.com | selector._domainkey.gorelo | Illustrative DKIM selector |
_dmarc.example.com | _dmarc | DMARC for From addresses at example.com |
Hostname examples for the example.com DNS zone only. Use Gorelo's generated names and values.
Preserve existing mail routing
Add any Gorelo MX records only at the hostname Gorelo specifies. Keep the root domain's existing MX records so normal mailbox delivery continues. Publish a CNAME only where Gorelo requests it, and check for conflicting records at that exact hostname before saving.
Configure addresses and forwarding
Adding a custom domain creates help@ as the default ticketing address and accounts@ as the default billing address. The accounts@ address is outbound only. Each custom address can have its own display name, From and Reply-to address, group restrictions, auto responses, and email templates.
- Edit the ticket address: In Settings > Email > Settings, edit help@ and set its identity and ticket behavior. Select the allowed groups because outbound sending is limited to them.
- Copy the forwarding address: Copy the Gorelo address shown for help@, such as help@gorelo.example.com.
- Configure the public mailbox: At your mailbox provider, route help@example.com to the Gorelo forwarding address. For an Outlook rule, Gorelo specifically recommends 'Redirect to'.
- Limit external forwarding: Allow external forwarding only for the mailbox that needs it, following your organization's security controls.
- Test ticket intake: First send a message from an unrelated external account directly to the Gorelo forwarding address. Then test the public help address. If only the direct test creates a ticket, check the mailbox forwarding rule.
Templates are configured per custom email address, not per group. Create separate custom addresses when different queues need different Ticket Created Email or Ticket Status Updated templates.
Set up SPF
SPF checks the envelope sender, not the visible From address. Gorelo sends through Mailgun using a subdomain such as gorelo.example.com, so publish the SPF or Return-Path record at the exact hostname Gorelo provides. Do not add a guessed Gorelo or Mailgun include to root SPF. Only one SPF policy can exist at any one hostname.
- Find SPF: In Gorelo's DNS table, look for a Return-Path, bounce, SPF, or sender verification row.
- Use the exact host: Publish the record on the gorelo-prefixed hostname shown by Gorelo, not automatically on the root domain.
- Keep one policy: If that same hostname already has an SPF TXT record, combine the authorized mechanisms into one record instead of publishing a second SPF record.
- Count lookups: SPF allows at most 10 DNS-querying mechanisms and modifiers during evaluation, including nested includes. RFC 7208 counts a, mx, ptr, exists, include, and redirect; ip4, ip6, and all do not consume this budget.
- Test the result: Send a Gorelo ticket reply and confirm SPF passes on a Return-Path domain that satisfies DMARC alignment with the visible From domain.
Illustrative SPF syntax only, do not publish this placeholderdns
v=spf1 include:<exact-value-shown-by-Gorelo> ~all
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Check the failing identifier before changing root SPF
- Duplicate SPF: Two TXT records starting with v=spf1 at the same hostname produce an SPF permerror.
- Root policy: Do not change -all to ~all by default. First confirm which SPF identity fails and whether DKIM already passes DMARC through identifier alignment.
- Rejection evidence: Inspect the bounce response and Gorelo delivery logs before changing SPF. An SPF hardfail can cause rejection before DKIM or DMARC is evaluated, even when DKIM would pass DMARC.
Gorelo custom domain verification screen showing SPF and Return-Path DNS records
Set up DKIM
DKIM should provide Gorelo's dependable DMARC path because forwarding can break SPF. Publish the DKIM records exactly as Gorelo displays them, since selector names and target values vary by account.
- Copy selectors: In Gorelo's domain verification table, find the DKIM rows and copy each selector hostname.
- Keep hostnames: If Gorelo includes a gorelo label in the hostname, publish the record at that exact hostname.
- Use the shown type: Add CNAME records as CNAME records and TXT records as TXT records. Do not convert one type into another.
- Wait for DNS: Check the saved records publicly before retrying Verify. Cached positive or negative answers persist until their TTL expires, so repeated checks do not force DNS propagation.
- Verify signing: Send a Gorelo email and check that the Authentication-Results header shows dkim=pass with a signing domain that satisfies DMARC alignment.
Illustrative DKIM CNAME syntax, not Gorelo-generated valuesdns
s1._domainkey.gorelo.example.com CNAME s1.provider.example s2._domainkey.gorelo.example.com CNAME s2.provider.example
Gorelo DKIM verification rows with selector CNAME records
Passing DKIM
- Selector found: DNS returns the exact selector Gorelo generated.
- Signature valid: The recipient can validate the body hash and signed headers.
- DMARC alignment: The DKIM signing domain shares the organizational domain in the From address under relaxed alignment.
Failing DKIM
- Wrong host: The DNS host removed a label such as gorelo or _domainkey.
- Wrong type: The record was entered as TXT when Gorelo asked for CNAME, or the reverse.
- Old cache: Gorelo checked before the DNS change reached public resolvers.
Set up DMARC
DMARC belongs on the visible From domain, usually the root domain users see, rather than on the gorelo sending subdomain alone. If the domain has no DMARC policy, start with a monitoring policy so reports can confirm Gorelo passes before enforcement. A signing or Return-Path subdomain needs relaxed alignment when the visible From domain is the root domain. Relaxed alignment is the default for adkim and aspf. If the domain already uses quarantine or reject and Gorelo passes, keep the stricter policy.
Starter DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
- Create the host: For help@example.com, add one DMARC TXT record at _dmarc.example.com (often entered as _dmarc in the DNS host's Name field). Edit an existing DMARC record instead of adding a duplicate.
- Start with p=none: If no enforcement policy already exists, use p=none until reports show Gorelo and every other legitimate sender passing. This requests monitoring; recipient spam filtering still applies.
- Set reporting: Replace the example address with a mailbox or DMARC reporting address you control. For Suped's DMARC monitoring product, use the reporting address provided for your domain and confirm external reporting authorization is in place.
- Use relaxed alignment: Omit adkim and aspf to use their relaxed defaults, or set both to r explicitly. Use strict alignment only after exact-domain tests pass.
- Protect the policy: If the domain already uses quarantine or reject, do not downgrade it for Gorelo. Fix Gorelo authentication instead.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
What counts as passing DMARC
- DKIM route: DKIM passes and its signing domain satisfies DMARC alignment with the domain in the From address.
- SPF route: SPF passes and the Return-Path domain satisfies DMARC alignment with the domain in the From address.
- Either route: DMARC passes when either SPF or DKIM passes with the required identifier alignment. DKIM should still pass for Gorelo because forwarding can break SPF.
DMARC policy staging
Move only after the previous stage is clean for Gorelo and other approved senders.
Monitor
p=none
Filter
p=quarantine
Block
p=reject
Verify and troubleshoot Gorelo email
After Gorelo verifies the DNS records, test a real outbound message. UI verification proves DNS is visible to Gorelo, but header verification proves recipient systems see SPF, DKIM, and DMARC passing on an actual message.
- Send externally: Create or reply to a Gorelo ticket and send it to an address outside your organization. Also test an accounts@ billing message and each additional custom From domain you use.
- Inspect headers: Open the raw message headers and find the Authentication-Results added by the receiving mail system. Read header.d for the DKIM signing domain, smtp.mailfrom for the SPF identity, and header.from for the visible From domain.
- Check DKIM: Confirm dkim=pass and a signing domain that satisfies DMARC alignment with the custom From domain.
- Check SPF: Confirm spf=pass and a Return-Path domain that satisfies DMARC alignment with the custom From domain.
- Check DMARC: Confirm dmarc=pass for the domain in the From address.
- Test intake: Send mail to the public support address and confirm it redirects to the Gorelo forwarding address and creates the expected ticket.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Suped's email tester checks a Gorelo message delivered to its generated test address. Review its authentication results and message headers, then test support mailbox forwarding separately. Passing SPF, DKIM, and DMARC does not guarantee inbox placement.
Problem
- Gorelo pending: DNS is missing, cached, or placed at the wrong hostname.
- DKIM fail: Selector host or record type differs from the Gorelo value.
- SPF errors: Duplicate SPF policies or excessive DNS lookups cause permerror. Missing SPF or Return-Path configuration also prevents a pass.
- DMARC fail: Neither SPF nor DKIM passes with the identifier alignment required for the visible From address.
Fix
- Recheck the host: Compare the exact DNS hostname in Gorelo with the hostname at your DNS host.
- Copy again: Replace hand-typed selector and target values with copied values from Gorelo.
- Fix the SPF error: Merge duplicate SPF policies at the failing hostname. For permerror caused by the lookup limit, remove stale mechanisms or use Suped's Hosted SPF workflow to reduce lookup use.
- Keep monitoring: Do not move to reject until aggregate reports show Gorelo passing consistently.
Gorelo ticket reply screen used for a real outbound email test
Monitor Gorelo email authentication
DNS records can drift after launch. A zone edit, selector rotation, lookup increase, or new client domain can break authentication. Suped's product provides DMARC monitoring that turns aggregate reports into source detection, pass-rate history, alerts, and fix steps.
- Watch Gorelo: Track Gorelo as a sending source and confirm its DKIM and SPF results continue to satisfy DMARC alignment.
- Configure alerts: Trigger alerts when authentication failures rise instead of waiting for users to report missing ticket mail.
- Fix precisely: Use issue detection and repair steps for DNS, DKIM, SPF, or DMARC problems.
- Scale clients: MSPs can manage many client domains in one Suped dashboard instead of checking each DNS zone manually.
- Monitor reputation: Combine DMARC with blocklist (blacklist) monitoring so sender reputation problems are visible.
Alert on these Gorelo signals
- DKIM drop: Gorelo volume continues but the DKIM pass rate for signatures meeting DMARC alignment falls.
- SPF errors: The Return-Path domain changes or SPF fails after a DNS edit.
- Unknown source: New mail appears from the domain and does not match Gorelo or another approved sender.
- Policy risk: A domain is close to reject but still has legitimate Gorelo failures.
Secure your domain with p=reject
Move to p=reject only after Gorelo and every other legitimate sender pass consistently. Suped's Hosted DMARC workflow can centralize source checks, policy edits, report review, and rollback while enforcement changes.
- Collect reports: Run p=none long enough to capture normal Gorelo ticket traffic and at least one billing cycle, plus traffic from every other approved sender. Use sending evidence rather than a fixed waiting period.
- Fix sources: Resolve every legitimate source that fails DMARC, starting with DKIM that satisfies DMARC alignment for Gorelo.
- Remove pct staging: Do not use pct=25 or other partial values. RFC 9989 marks the pct tag historic.
- Treat testing as optional: With p=quarantine; t=y, RFC 9989 receivers are asked to apply none to failing messages. Older receivers ignore t=y and apply quarantine. Use this stage only when legitimate mail is ready for quarantine.
- Reach reject: Move to reject when legitimate mail is consistently authenticated and every approved source is accounted for.
- Stay alert: Keep monitoring after reject because a future Gorelo DNS change can create delivery failures.
Successive values for one DMARC TXT recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Replace the existing DMARC TXT value at each stage; publish only one policy record at the hostname. Remove t=y to request the published quarantine policy. Receivers still apply their local handling rules.
Reject readiness
Use DMARC report data and verified sending inventory before changing enforcement.
Ready
All approved sources pass
Investigate
Intermittent failures remain
Hold
Unknown legitimate sources remain
Where Suped helps
- Policy staging: Move through none, quarantine, and reject with visible source data and rollback controls.
- Hosted SPF: Use Suped's Hosted SPF product for lookup-limit errors at the affected SPF hostname. Gorelo's separate sending subdomain does not add lookups to root SPF.
- Failure alerts: Detect a Gorelo authentication drop before an enforcement policy affects more mail.
- MSP dashboard: Manage Gorelo-sending client domains without switching between separate reporting setups.
FAQ
Yes. Add the sending domain in Gorelo, publish the SPF or Return-Path and DKIM records Gorelo generates, then publish DMARC on the visible From domain.
Use the exact SPF record or Return-Path configuration shown in Gorelo's DNS verification screen. The required hostname and record type come from that setup; do not add a guessed include to root SPF.
Gorelo sends custom-domain mail through Mailgun from a subdomain such as gorelo.example.com. The subdomain holds the generated authentication records while recipients continue to see the root domain in the From address.
Gorelo uses Mailgun for outbound delivery, so message headers and reverse DNS can identify Mailgun infrastructure even when the visible From address uses your domain.
Do not change the root SPF policy solely to add Gorelo. Check the failing envelope-sender domain and bounce response first. SPF hardfail can trigger rejection before DKIM is checked, but it does not automatically mean the root SPF record needs changing.
Only when aggregate reports already show Gorelo and every other approved sender passing. For a new setup, monitor with p=none, fix failures, enforce quarantine, then move to p=reject. Do not use the historic pct tag for partial enforcement.
