How to set up DMARC/DKIM/SPF for Highspot
Updated on 1 Nov 2026: We clarified Highspot sending routes, DNS record placement, and DMARC reporting checks so you can verify authentication before changing enforcement.
Highspot supports direct sending and corporate email client sending. The correct SPF, DKIM, and DMARC setup depends on which system actually sends the message, which domain signs it, and which domain appears in the Return-Path.
Set Highspot up in this order: identify the sending path, add the visible From domain when direct sending requires it, publish only the tenant-specific DNS values supplied for that path, send a real test message, then choose a DMARC policy after report data shows all legitimate mail passing consistently.
What you need before DNS changes
- Admin access: Use a Highspot admin account and access to the corporate email system when sellers send through their mailbox.
- DNS access: Use access to create the exact TXT and CNAME records supplied for the sending domain.
- Sending path: Confirm whether mail leaves Highspot directly or leaves through the seller's corporate mailbox.
- Sender scope: Know whether the visible From address uses the root domain or a sending subdomain.
- Report address: Prepare a DMARC aggregate reporting address before publishing or changing the policy record.
Choose the Highspot sending path
Send one controlled Highspot message before changing DNS and inspect its full headers. The Authentication-Results, DKIM-Signature, and Return-Path fields show whether Highspot or the corporate mailbox system owns authentication for that message.
Direct Highspot sending
- Get records: Request the DKIM, Return-Path, verification, and SPF values supplied for your tenant.
- Publish exactly: Create only the records included in the implementation instructions.
- Verify headers: Expect a Highspot-related path with aligned DKIM, SPF, or both.
- Track source: Group the observed source and authenticated domains in DMARC reports.
Corporate email client sending
- Use mailbox controls: The corporate email system handles SPF and DKIM for the outbound message.
- Avoid extra records: Do not add Highspot SPF or DKIM records unless Highspot also sends directly.
- Test the mailbox: Confirm the corporate signing domain and envelope sender satisfy DMARC alignment with the From domain.
- Separate results: Attribute authentication failures to the outbound system shown in the headers.
Do not authorize an assumed sender
An SPF include authorizes sending infrastructure, so an unverified value expands who can send for the domain without proving DMARC alignment. Use only records supplied for your tenant and confirmed by a real message. Ask Highspot for a supported sending route if neither SPF nor DKIM can satisfy DMARC alignment with your From domain.
Verify your Highspot sending domain
For direct Highspot sending, authenticate the domain that appears in the visible From address. If Highspot sends as rep@example.com, authenticate example.com. If it sends as rep@sales.example.com, authenticate sales.example.com. Corporate email client sending normally uses the domain authentication already configured for that mailbox system.
- Confirm direct sending: Use a test header to verify that Highspot, rather than the corporate mailbox, sends the message.
- Request tenant values: Ask Highspot support or your implementation contact for the authentication records for your site.
- Add the From domain: Enter the exact domain used in the visible From address when your tenant provides a domain setup control.
- Map message streams: Document which outreach, digital sales room, and notification messages use that domain and route.
- Copy records: Save every verification, Return-Path, DKIM, and SPF value Highspot explicitly supplies for the tenant.
Illustration of Highspot sending domain verification for email authentication.
|
|
|
|---|---|---|
Root domain | Root | Matches normal staff addresses. |
Sales subdomain | Subdomain | Keeps direct vendor mail separate. |
Mixed domains | Each domain | Each From domain needs a valid authentication path. |
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. Confirm which custom-domain authentication options your tenant supports, then use only the supplied records. Highspot is part of Seismic, but its customer guidance says existing logins, workflows, and support contacts continue. Use your current Highspot contact for DNS instructions.
Set up SPF
Sender Policy Framework (SPF) checks whether the sending IP is authorized for the envelope sender domain. For direct sending, publish the custom Return-Path or SPF values Highspot supplies. With DMARC's default relaxed SPF alignment, a Return-Path domain such as bounce.example.com can satisfy relaxed alignment with a From domain of example.com. A policy using aspf=s requires an exact domain match.
- Find the envelope sender: Inspect a test message and compare its Return-Path with the value supplied for the direct sending route.
- Publish the supplied record: Use the exact record type and hostname supplied for the Return-Path. If the record is a CNAME, disable DNS proxying and do not publish a TXT record at the same hostname.
- Merge SPF only when instructed: If Highspot supplies an SPF include, add it before the all mechanism in the SPF TXT record at the envelope sender hostname Highspot specifies. Keep one SPF record at that hostname; an include at the root does not authenticate a different Return-Path domain.
- Check alignment mode: Confirm whether the DMARC record uses relaxed alignment or aspf=s.
- Count lookups: Count DNS-querying mechanisms and modifiers across the full SPF evaluation, including nested includes. RFC 7208 limits these to 10; exceeding the limit returns permerror. Suped's Hosted SPF workflow can manage lookup pressure when several authorized senders share a domain.
- Wait for propagation: Allow the DNS TTL to pass, then confirm the published answer and send another real message.
Illustrative Return-Path CNAME, replace with supplied valuesdns
bounce.example.com CNAME customer-bounce.provider.example
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Illustration of SPF and custom Return-Path DNS setup for Highspot email.
When SPF is not the DMARC pass path
SPF can pass for an envelope sender that does not satisfy alignment with the visible From domain. In that case, SPF does not produce a DMARC pass. Use aligned DKIM as the primary path because forwarding also changes the route checked by SPF.
Set up DKIM
DomainKeys Identified Mail (DKIM) adds a digital signature that receivers verify using a public key in DNS. For direct Highspot sending, request the tenant's DKIM records and publish every supplied selector. Under relaxed alignment, the passing DKIM signing domain and visible From domain need the same organizational domain. A policy using adkim=s requires the domains to match exactly.
- Copy selectors: Copy each tenant-specific DKIM host and target exactly.
- Publish records: Create each record at the exact selector hostname supplied for the DKIM signing domain, which must satisfy the active DMARC alignment rules. Disable DNS proxying for CNAME records.
- Avoid duplication: If the DNS provider appends the domain, enter only the required host label.
- Check alignment mode: Compare the signing domain with the From domain under relaxed or strict adkim rules.
- Verify after TTL: After DNS propagation, ask Highspot to confirm custom-domain DKIM signing is active, then verify the signature on a new message. Publishing the DNS record alone does not activate signing.
- Keep every key: If Highspot supplies multiple selectors, publish all of them so key rotation does not break signing.
Illustrative DKIM CNAMEs, replace every selector and targetdns
hs1._domainkey.example.com CNAME hs1.customer.provider.example hs2._domainkey.example.com CNAME hs2.customer.provider.example
Illustration of Highspot DKIM authentication with two example CNAME selectors.
Common DNS mistakes
- Duplicate host: The selector host ends with the domain twice.
- Wrong type: The DKIM value uses TXT when the supplied record requires CNAME.
- Missing selector: Only one of the supplied DKIM selectors is published.
- Proxied CNAME: A DNS proxy prevents receivers from resolving the supplied target.
Healthy DKIM result
- DKIM pass: The receiving system records a passing DKIM result.
- Aligned domain: The signing domain satisfies the active relaxed or strict alignment mode.
- Every selector: Highspot can rotate keys without breaking authentication.
- Correct route: The signer matches the direct or corporate sending path being tested.
Set up DMARC
DMARC belongs in DNS for the visible From domain. It passes when either SPF or DKIM passes with a domain that satisfies DMARC alignment. RFC 9989 defines DMARC policy and DNS Tree Walk discovery for applicable parent policies. Start with p=none when the domain has no enforcement policy. If an applicable parent or exact-domain record already uses quarantine or reject, keep it and fix the sending path until mail passes.
- Check the exact domain: For example.com, publish one DMARC TXT record at _dmarc.example.com. For an explicit policy on sales.example.com, use _dmarc.sales.example.com.
- Check inherited policy: Without an exact-domain record, check the policy discovered by DNS Tree Walk under RFC 9989 and its sp value, or p if sp is absent. Older receivers use organizational-domain discovery under RFC 7489; an explicit subdomain record reduces policy-discovery differences.
- Start reporting: Use p=none only when no enforcement policy already applies. Add an aggregate reporting address to an existing policy without weakening it.
- Set rua: Replace the example reporting address with the address used for aggregate DMARC reports.
- Avoid historic tags: RFC 9989 classifies pct, ri, and rf as historic; omit them from new records.
- Keep enforcement: Do not downgrade an existing quarantine or reject policy 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 exact From domain resolves to one applicable policy. For a rua destination in a different organizational domain, confirm that the report receiver publishes authorization in its DNS, as RFC 9990 requires. Setting rua alone does not authorize an external destination.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Illustration of Highspot email authentication checks with a p=none DMARC policy.
Do not use reject on day one
A new setup needs real mail and aggregate report evidence before enforcement changes. For a general-purpose domain used by people, RFC 9989 recommends at least one month at none and another month at quarantine before considering reject because mailing lists and forwarding can disrupt legitimate mail.
Verify and troubleshoot
Verification has two parts: the responsible sending system must see its DNS records, and a receiving mailbox must show DMARC passing on real mail. Header evidence takes priority over a green state in an admin screen because it identifies the route actually used. A DMARC pass does not guarantee inbox placement; recipient filtering and sender reputation still affect delivery.
- Send both routes: If sellers use direct and corporate client sending, send one controlled message through each route.
- Inspect headers: Use the receiving system's Authentication-Results header. Record the DKIM signing domain and selector (d= and s= in DKIM-Signature), SPF envelope sender, visible From domain, and DMARC result. Look up the key at selector._domainkey.signing-domain using those actual values.
- Use tester: Send a message through the target route to the email tester address and review the full authentication diagnosis.
- Fix hostnames: Check for duplicate domain suffixes, proxied CNAMEs, missing targets, and records placed at the wrong host.
- Separate sources: Attribute the failure to the sender and authenticated domains shown in the message, then change only that route.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Example passing headers with relaxed DMARC alignmenttext
dkim=pass header.d=example.com spf=pass smtp.mailfrom=bounce.example.com dmarc=pass header.from=example.com
|
|
|
|---|---|---|
Tenant unverified | Wrong host or propagation | Check the authoritative DNS answer |
DKIM pass, DMARC fail | No passing mechanism satisfies DMARC alignment | Check both DKIM and SPF against the From domain and active alignment modes |
SPF permerror | Duplicate SPF records, excess lookups, or invalid syntax | Keep one SPF record at the checked hostname; check lookup count and syntax |
Unexpected signer | Different sending route | Test direct and corporate routes separately |
Duplicate DMARC | Two TXT records at one name | Keep one valid record |
No reports | Reporting delay, invalid rua, or missing external authorization | Allow a reporting cycle, then check the destination and receiver-side authorization |
Use symptoms to narrow the fix before changing DNS.
Highspot verification checklist
- DKIM result: The receiving mailbox shows dkim=pass with a domain aligned to the visible From domain.
- SPF result: The receiving mailbox shows the expected envelope sender and whether SPF alignment passes.
- DMARC result: The receiving mailbox shows dmarc=pass for the visible From domain.
- Report data: Aggregate reports show the expected sending sources passing; use message headers and sending logs to identify application traffic that shares a corporate outbound system.
Monitor Highspot authentication failures
A setup that passes today can break when someone edits DNS, changes the From domain, removes a CNAME, or changes the outbound route. DMARC monitoring should stay on during setup and after verification. Aggregate feedback is usually daily, as described in RFC 9990, so report-based alerts follow receiver reporting schedules.
- Track each route: Filter DMARC data by source, DKIM domain, SPF envelope sender, and visible From domain.
- Alert on drift: Send alerts when a known route shifts from pass to fail or an unknown sender appears.
- Watch reputation: Use blocklist (blacklist) monitoring with authentication data so a sender issue is visible quickly.
- Route owners: Send alerts to the team that owns Highspot and the team responsible for the failing outbound route.
Where Suped fits
Suped's DMARC reporting product parses aggregate reports, groups traffic by sending source and authenticated domain, and alerts owners when incoming reports show failures. Identify Highspot traffic with controlled test messages before tracking it in Suped. Hosted DMARC supports controlled policy changes, while Hosted SPF helps manage authorized senders when lookup pressure grows.
- Source visibility: Compare direct sending sources with corporate mailbox sources; shared infrastructure still needs headers or sending logs for attribution.
- Failure history: Compare current alignment failures with earlier passing periods.
- Fix steps: Send the DNS or sender owner the values that failed alignment.
- Policy control: Manage policy changes after reports confirm the impact on legitimate mail.
Choose an enforcement policy
A p=reject policy is not the automatic end state for every domain. RFC 9989 advises against reject on general-purpose domains whose users participate in mailing lists because indirect mail can fail DMARC. A dedicated sending subdomain has a narrower risk profile, but every legitimate sender still needs a passing path.
Policy rollout thresholds
Operational gates before a stricter DMARC policy.
Monitor
30+ days
Identify every legitimate route and assess indirect mail before enforcement.
Quarantine
30+ days
Observe another full reporting period on a general-purpose domain.
Reject
Assessed domain
Consider only after legitimate mail passes and indirect mail risks are accepted.
Stop
New failures
Pause the rollout when a known route starts failing.
- Confirm each route: Before choosing p=reject, verify an aligned DKIM pass on direct and corporate client messages. RFC 9989 requires reject domains to apply valid DKIM signatures and avoid relying solely on SPF because forwarding can break SPF.
- Assess domain use: Determine whether people use the domain for mailing lists, aliases, and forwarded mail before choosing reject.
- Stage policy: Use report evidence at none, then quarantine, before making a reject decision.
- Do not rely on pct: RFC 9989 makes percentage sampling historic. Stage policy changes with report review instead of assuming receivers support percentage-based enforcement.
- Use subdomains deliberately: A dedicated From subdomain can separate direct Highspot mail from employee mail.
- Keep alerts: DNS changes and route changes can break authentication after enforcement.
- Control changes: Use Hosted DMARC in Suped when policy changes need an auditable workflow without repeated DNS edits.
Reject policy exampledns
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Do not skip report review
A direct Highspot route can pass while a corporate route or another authorized sender fails. Review the full sender inventory and the domain's indirect mail behavior before enforcement, especially before reject.
FAQ
Configure SPF and DKIM on the system that sends the message, then publish or retain DMARC for the visible From domain. For direct sending, get the tenant's supported authentication options from Highspot; corporate email client sending uses the mailbox system's setup. There is no single DNS record set for every sending route.
Get them from Highspot support, your implementation contact, or the tenant controls provided for direct sending. Do not copy an include, selector, or CNAME target from a search result because the required values can be tenant-specific.
Yes. DKIM can produce the DMARC pass when the signature passes and its signing domain satisfies DMARC alignment with the visible From domain. Relaxed alignment compares organizational domains, while adkim=s requires an exact match. Configure SPF alignment too when the direct sending route supplies a custom Return-Path.
No separate Highspot records are needed when the message leaves only through the corporate mailbox system. Verify this in the message headers. Add Highspot-specific records only if the tenant also sends messages directly.
Use p=none when the domain has no existing enforcement policy. RFC 9989 recommends at least one month of monitoring and another month at quarantine before a general-purpose domain considers reject. Keep an existing stronger policy and repair any failing Highspot route instead of downgrading it.
Send controlled messages through direct Highspot sending and the corporate email client. Compare the source IP, DKIM signing domain, SPF envelope sender, visible From domain, and DMARC result with aggregate report data. Use headers and sending logs to distinguish Highspot messages from other applications using the same corporate outbound system.
