How to set up DMARC/DKIM/SPF for Gorelo
Published 1 Jul 2026
Updated 1 Jul 2026
9 min read
Summarize with

Gorelo custom-domain email needs three layers: add the domain in Gorelo, publish the SPF and DKIM records Gorelo gives you, then put DMARC on the visible From domain. I treat Gorelo as its own sender because ticket replies and billing emails need the same authentication discipline as mailbox mail.
Gorelo places custom sending domains under Settings > Email. Its public docs say the DNS records verify the domain through the sending provider, and they specifically warn to keep the gorelo subdomain wherever Gorelo shows it. Since the values are account-specific, copy them from Gorelo instead of using a generic SPF include or guessed DKIM selector.
Add your domain
Start inside Gorelo before editing DNS. Gorelo needs to generate the records first, and those hostnames decide whether SPF, DKIM, and Return-Path matching work cleanly.
- Open settings: Sign in to Gorelo, then go to Settings > Email.
- Create domain: Click Add Domain, enter the domain you want users to see in the From address, then save.
- Copy records: Copy every hostname, type, and value exactly. Do not remove the gorelo label if Gorelo includes it.
- Publish DNS: Add the records at your DNS host. Use CNAME where Gorelo shows CNAME and TXT where it shows TXT.
- Verify in Gorelo: Return to Settings > Email, click Verify, and wait for all rows to show as verified before sending production mail.

Gorelo Settings Email screen with the Add Domain dialog open
What Gorelo is checking
- Ownership: The verification record proves you control the domain or the Gorelo-specific subdomain.
- Signing: The DKIM records give Gorelo permission to sign mail with keys tied to your domain.
- Bounces: The Return-Path record lets SPF pass on a domain that matches your visible From domain.
- Routing: The forwarding address connects inbound ticket mail back into Gorelo after the domain is verified.
|
|
|
|---|---|---|
Verify | Gorelo host | Domain proof |
DKIM | Selector | Message signing |
SPF | Return-Path | Sender check |
Forward | Mailbox | Ticket intake |
Gorelo DNS records usually cover these jobs.
Set up SPF
SPF checks the envelope sender, not the visible From address. For Gorelo, that means the Return-Path DNS record matters more than adding another root-domain SPF string. Gorelo supports Return-Path matching, so publish the bounce or SPF record it gives you and avoid duplicate SPF TXT records.
- Find SPF: In Gorelo's DNS table, look for a Return-Path, bounce, SPF, or sender verification row.
- Use one SPF: If the root or sending domain already has an SPF TXT record, edit that one record instead of creating a second one.
- Merge includes: Add Gorelo's include only if Gorelo provides one. Keep the final mechanism at the end, usually ~all while you verify mail flow.
- Count lookups: SPF has a 10 DNS lookup limit. If the domain is already crowded, use hosted SPF or remove old senders before adding more includes.
- Test result: Send a Gorelo ticket reply and confirm SPF passes on a Return-Path domain related to your custom domain.
SPF merge patterndns
v=spf1 include:mail.example include:gorelo-value.example ~all
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Do not create two SPF records
- Duplicate SPF: Two TXT records starting with v=spf1 make SPF fail.
- Hard fail: Gorelo's docs warn that -all can cause forwarded or on-behalf mail to be rejected.
- Soft fail: Use ~all while verifying Gorelo, then tighten only after reports show clean results.

Gorelo custom domain verification screen showing SPF and Return-Path DNS records
Set up DKIM
DKIM is the main authentication path I expect Gorelo to pass with. Publish the DKIM records exactly as Gorelo displays them, because selector names and target values change 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 shown type: Add CNAME records as CNAME records and TXT records as TXT records. Do not convert one type into another.
- Wait for DNS: Most DNS changes appear in minutes, but cached negative answers can delay Gorelo verification.
- Verify signing: Send a Gorelo email and check that the Authentication-Results header shows dkim=pass.
DKIM CNAME patterndns
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 headers.
- Domain match: The DKIM signing domain belongs to the same organizational domain as the From address.
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, not inside Gorelo. For a new Gorelo setup, start with a monitoring policy so you can see whether Gorelo passes before enforcing quarantine or reject. If your domain already has quarantine or reject and Gorelo is passing, keep the stricter policy.
Starter DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
- Create host: Add a TXT record at _dmarc for the domain used in the Gorelo From address.
- Start p=none: Use p=none until reports show Gorelo and every other legitimate sender passing.
- Set reports: Replace the example reporting address with a mailbox or DMARC reporting address you control.
- Keep defaults: Do not add strict adkim or aspf tags unless you have already confirmed every sender passes with them.
- Protect policy: If the domain already uses quarantine or reject, do not downgrade it just 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 the signing domain matches the organizational domain in the From address.
- SPF route: SPF passes and the Return-Path domain matches the organizational domain in the From address.
- Either route: DMARC needs one of those two routes to pass, although I still want DKIM passing for Gorelo because forwarded mail can break SPF.
DMARC policy staging
Move only after the previous stage is clean for Gorelo and other real senders.
Monitor
p=none
Filter
p=quarantine
Block
p=reject
Verify and troubleshoot
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.
- Inspect headers: Open the raw message headers and find Authentication-Results.
- Check DKIM: Confirm dkim=pass and a signing domain tied to your custom domain.
- Check SPF: Confirm spf=pass and a Return-Path domain tied to your custom domain.
- Check DMARC: Confirm dmarc=pass for the domain in the From address.
- Test intake: Send mail to your 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 opens the report when the test is ready.
?/43tests passed
Preparing test address...
The email tester is the quickest way to validate the whole path. Send a Gorelo message to the generated test address, then review SPF, DKIM, DMARC, DNS, and headers in one report.
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 fail: Duplicate SPF exists or Return-Path DNS was not published.
- DMARC fail: Neither SPF nor DKIM passes with a domain matching the visible From address.
Fix
- Recheck 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.
- Flatten SPF: If SPF has too many DNS lookups, remove stale senders or move SPF management to a hosted record.
- Keep monitoring: Do not move to reject until real reports show Gorelo passing consistently.

Gorelo ticket reply screen used for a real outbound email test
Get alerted when it breaks
DNS records drift after launch. Someone changes a zone, a selector rotates, SPF reaches the lookup limit, or a new client domain starts sending through Gorelo without reports being checked. Suped's product is the strongest practical choice for most teams because its DMARC monitoring turns raw aggregate reports into source detection, issue lists, alerts, and fix steps.
- Watch Gorelo: Track Gorelo as a sending source and confirm its DKIM and SPF results stay clean over time.
- Alert fast: Use real-time alerts when failures spike instead of waiting for a user to report missing ticket mail.
- Fix precisely: Use automated issue detection and steps to fix 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 not missed.
Alert on these Gorelo signals
- DKIM drop: Gorelo volume continues but DKIM pass rate 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 is useful here because policy staging, reporting, and rollback controls stay in one place through Hosted DMARC.
- Collect reports: Run p=none long enough to see normal Gorelo ticket and billing traffic.
- Fix sources: Resolve every legitimate source that fails DMARC, starting with DKIM for Gorelo.
- Stage quarantine: Move to partial quarantine first if the domain has meaningful traffic.
- Reach reject: Move to reject when legitimate mail is consistently authenticated and unknown sources have been removed.
- Stay alert: Keep monitoring after reject because a future Gorelo DNS change can create real delivery failures.
DMARC policy staging recordsdns
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Reject readiness
Use DMARC report data before changing enforcement.
Ready
98-100% pass
Investigate
90-97% pass
Hold
Below 90%
Where Suped helps
- Policy staging: Move through none, quarantine, and reject with visible source data instead of guesswork.
- Hosted SPF: Keep SPF below lookup limits when Gorelo is one of many approved senders.
- Hosted MTA-STS: Enforce TLS for mail delivery with two CNAME records and no web hosting work.
- MSP dashboard: Manage Gorelo-sending client domains without switching between separate reporting setups.

