How to set up DMARC/DKIM/SPF for Highspot
Highspot can send sales outreach and digital sales room notifications using your domain. SPF, DKIM, and DMARC work when Highspot signs mail with your domain, uses a custom Return-Path under your domain, and your DMARC record receives reports before enforcement changes.
I set Highspot up in this order: add the sending domain in Highspot, publish the tenant-specific DNS values, verify the records in Highspot, send a real test message, then move DMARC toward p=reject only after report data shows Highspot passing consistently.
What you need before DNS changes
- Admin access: Use a Highspot admin account that can view domain or email authentication settings.
- DNS access: Use access to create TXT and CNAME records for the exact sending domain.
- Sender scope: Know whether Highspot sends as your root domain or a subdomain.
- Report address: Prepare a DMARC aggregate reporting address before you publish the DMARC record.
Add your domain
Add the domain that appears in the visible From address on Highspot messages. If Highspot sends as rep@example.com, authenticate example.com. If Highspot sends as rep@sales.example.com, authenticate sales.example.com.
- Open admin: Sign in to Highspot as an admin and open Admin, Settings, then Email or Domain authentication.
- Enable sending: If domain authentication is hidden, ask Highspot to enable custom email sending for your site.
- Add domain: Enter the exact From domain that Highspot users send from, not a different parent domain.
- Choose streams: Apply the domain to outreach, buyer room notifications, and system notifications that use the same From domain.
- Copy records: Save every DNS value Highspot shows for verification, Return-Path, DKIM, and any SPF include it explicitly gives you.
Highspot domain authentication page with an added sending domain.
|
|
|
|---|---|---|
Root domain | Root | Matches normal staff addresses. |
Sales subdomain | Subdomain | Keeps vendor mail separate. |
Mixed domains | Each domain | Each From domain needs its own records. |
Use the domain that appears in Highspot's visible From address.
Highspot values are tenant-specific
Do not copy a Highspot DNS value from another domain or a search result. Use the records shown in your own Highspot admin panel or implementation instructions, because DKIM selectors and Return-Path hosts are tied to the tenant.
Set up SPF
Highspot supports a custom Return-Path, so SPF can pass DMARC's same-domain check when the bounce domain sits under your sending domain. Publish the Return-Path CNAME Highspot gives you first. Add an SPF include only when Highspot explicitly provides one for your tenant.
- Find Return-Path: In Highspot domain authentication, copy the CNAME for the bounce or Return-Path host.
- Publish CNAME: Create the CNAME at the exact host Highspot shows. DNS screens often append the domain automatically.
- Merge SPF: If Highspot gives an SPF include, merge it into the existing SPF TXT record. Keep one SPF TXT record per host.
- Count lookups: Keep SPF under 10 DNS lookups. Suped's Hosted SPF and SPF flattening help when several senders share the same domain.
- Recheck later: Wait for the DNS TTL, then verify in Highspot and with a real Highspot test message.
Return-Path CNAME shapedns
bounce.example.com CNAME customer-bounce.provider.example
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Highspot SPF and Return-Path DNS records awaiting verification.
When SPF is not the main pass path
Some senders cannot use your domain in the Return-Path, so their SPF result fails DMARC even when SPF itself passes. Highspot supports a custom Return-Path, so set it up. Still make DKIM the primary pass path because forwarding often breaks SPF.
Set up DKIM
DKIM is the most important Highspot DNS step. It signs the message with a domain receivers can compare to the visible From domain, and it keeps working in cases where forwarding changes SPF.
- Copy selectors: Copy each Highspot DKIM CNAME exactly, including the selector name and the target value.
- Publish records: Create each CNAME under the same domain Highspot uses in the visible From address.
- Avoid duplication: If your DNS provider appends the domain, enter only the host label Highspot shows before the domain suffix.
- Verify in Highspot: Return to Highspot and click Verify DNS or Refresh after the DNS TTL passes.
- Keep both keys: If Highspot provides two selectors, publish both so key rotation does not break signing.
DKIM CNAME shapedns
hs1._domainkey.example.com CNAME hs1.customer.provider.example hs2._domainkey.example.com CNAME hs2.customer.provider.example
Highspot DKIM selector records verified in the admin panel.
Common DNS mistakes
- Duplicate host: The selector host ends with the domain twice.
- Wrong type: The DKIM value is published as TXT when Highspot asked for CNAME.
- Missing selector: Only one of the Highspot DKIM selectors is published.
Healthy DKIM result
- DKIM pass: The message header shows a passing DKIM result.
- Domain match: The signing domain uses the same organizational domain as the From address.
- Both selectors: Highspot can rotate keys without breaking authentication.
Set up DMARC
DMARC belongs at the domain level, not inside Highspot. Start with p=none unless your domain already enforces quarantine or reject. If it already does, keep the stronger policy and fix Highspot until it passes.
- Check existing: Look for a TXT record at _dmarc. Keep one DMARC record for that host.
- Start reporting: Use p=none and send aggregate reports to a mailbox or reporting platform.
- Set rua: Replace the example reporting address with the address you use for aggregate DMARC reports.
- Keep enforcement: If the domain already uses quarantine or reject, do not downgrade it just to add Highspot.
- Generate safely: Use the DMARC record generator to avoid malformed tags.
Starter DMARC TXT recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
After publishing, run the DMARC checker and confirm the record parses as one policy for the sending domain.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Highspot domain authentication status with DMARC monitoring ready.
Do not use reject on day one
A new Highspot setup should prove that DKIM and the custom Return-Path pass in real mail before you enforce reject. The exception is a domain already at quarantine or reject. In that case, keep the policy and fix Highspot until the authenticated mail passes.
Verify and troubleshoot
Verification has two parts: Highspot must see the DNS records, and real mail sent through Highspot must pass authentication at the receiving mailbox.
- Send real mail: Send a Highspot outreach message or digital sales room notification to a mailbox you control.
- Inspect headers: Confirm DKIM passes with your domain and SPF passes through the custom Return-Path.
- Use tester: Send a Highspot message to the email tester address and review the full authentication diagnosis.
- Fix hostnames: Check for duplicate domain suffixes, missing CNAME targets, and DNS records placed at the wrong host.
- Separate sources: If failures come from another sender, do not change Highspot DNS to fix that source.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Authentication header targetstext
dkim=pass header.d=example.com spf=pass smtp.mailfrom=bounce.example.com dmarc=pass header.from=example.com
|
|
|
|---|---|---|
Highspot unverified | Wrong host | Recreate CNAME |
DKIM pass, DMARC fail | Domain mismatch | Authenticate From domain |
SPF permerror | Too many lookups | Reduce includes |
Duplicate DMARC | Two TXT records | Keep one record |
No reports | Bad rua | Fix report address |
Use symptoms to narrow the fix before changing DNS.
Highspot verification checklist
- DKIM result: The receiving mailbox shows dkim=pass.
- SPF result: The receiving mailbox shows spf=pass for the Highspot Return-Path.
- DMARC result: The receiving mailbox shows dmarc=pass for the visible From domain.
- Report data: Aggregate reports show Highspot as a known passing source before enforcement changes.
Get alerted when it breaks
A Highspot setup that passes today can break when someone edits DNS, changes the From domain, removes a CNAME, or adds a new sender to the same domain. DMARC monitoring should stay on during setup and after verification.
- Track Highspot: Filter DMARC data by source, DKIM domain, SPF mailfrom, and visible From domain.
- Alert on drift: Send alerts when Highspot shifts from pass to fail, or when an unknown sender appears.
- Watch reputation: Use blocklist (blacklist) monitoring with authentication data so a sender issue is visible fast.
- Route owners: Send Highspot-related alerts to the team that owns Highspot and the team that controls DNS.
Where Suped fits
Suped's product is the practical overall DMARC platform when you want this to keep working after launch. It brings together DMARC, SPF, DKIM monitoring, automated issue detection, Real-Time Alerts, hosted SPF, hosted MTA-STS, blocklist monitoring, and multi-tenant workflows for teams managing many domains.
- Source visibility: Highspot appears as a monitored source instead of a raw XML row.
- Fix steps: Authentication failures produce concrete remediation steps for DNS and sender owners.
- Policy control: Hosted DMARC and hosted SPF reduce repeated DNS edits during rollout.
One-time check
- Useful once: Confirms the DNS record exists right now.
- No history: Does not show whether Highspot passed yesterday.
- No owner: Does not tell the right team when mail breaks.
Ongoing monitoring
- Source trend: Shows pass rates for Highspot over time.
- Issue alerts: Flags authentication failures as they start.
- Policy path: Shows when the domain is ready for stricter DMARC.
Secure your domain with p=reject
Move to p=reject only when Highspot and every other legitimate sender passes DMARC consistently. I use staged policy changes when the domain has several senders or a shared root domain.
Policy rollout thresholds
Operational gates before a stricter DMARC policy.
Monitor
7-14 days
Collect enough report data to identify Highspot and every legitimate sender.
Quarantine
Low failures
Use when known senders pass and remaining failures are isolated.
Reject
Known mail passes
Use when legitimate mail passes and unknown mail is separated.
Stop
New failures
Pause the rollout when Highspot or another known sender starts failing.
- Confirm Highspot: Highspot messages must show passing DKIM for your domain or passing SPF through the custom Return-Path.
- Stage policy: Move from monitoring to quarantine, then reject after report data shows legitimate mail passing.
- Use subdomains: Authenticate Highspot subdomains separately when they send with their own visible From domain.
- Keep alerts: Do not turn off alerts after reject. DNS cleanup and vendor changes can break Highspot later.
- Control changes: Use Hosted DMARC in Suped when you want policy staging without repeated DNS edits.
Enforced DMARC exampledns
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Do not skip report review
Reject is the right end state for a sending domain, but it should be based on observed mail. Highspot can be perfect while another source still fails. Review the full sender inventory before enforcing reject.
