How to set up DMARC/DKIM/SPF for Enreach
Published 10 Jul 2026
Updated 10 Jul 2026
10 min read
Summarize with
Enreach can send authenticated email for your domain when the domain is verified in Enreach, SPF authorizes the Enreach return-path host, DKIM signs with a selector under your domain, and DMARC checks the visible From domain. I start with monitoring at p=none unless the domain already has p=quarantine or p=reject, then I verify real Enreach messages before tightening policy.
What has to pass
- SPF: The Enreach bounce or return-path domain must be authorized by SPF, preferably under your own domain.
- DKIM: Enreach must sign messages with a selector that uses your domain or a subdomain you control.
- DMARC: DMARC passes when SPF or DKIM passes and the authenticated domain matches the visible From domain.
- Reports: Aggregate reports show which Enreach traffic passes, fails, or uses a domain you have not approved.
Add your domain
I start inside Enreach because the DNS records are generated per tenant and per sending domain. Use the exact hostnames and values Enreach shows in its admin panel or provides through support. Do not publish guessed Enreach records.
- Open admin: Sign in to Enreach with administrator access and open the settings area for email, notifications, sender domains, or outbound mail.
- Add domain: Enter the organizational domain used in the visible From address, such as example.com.
- Pick sender: Use a branded mailbox or subdomain, such as no-reply@example.com or notifications.example.com.
- Copy records: Copy every DNS hostname and value Enreach shows for domain verification, DKIM, SPF, and return-path.
- Verify later: Publish the DNS records, wait for TTL, then return to Enreach and press the verify action.
Enreach email domain settings with DNS verification records.
Do not guess vendor records
Enreach records can vary by tenant, region, and product configuration. I treat any SPF include, DKIM selector, verification token, and return-path hostname as tenant-specific until Enreach confirms it.
DNS values to expectDNS
example.com. TXT "enreach-verification=REPLACE_WITH_ENREACH_TOKEN" bounce.example.com. CNAME enreach-return-path-host.example selector1._domainkey.example.com. CNAME enreach-dkim-host.example
Set up SPF
SPF for Enreach is about the envelope sender, not the visible From address. Because Enreach supports custom return-path matching, I publish the return-path CNAME or SPF include Enreach gives me, then confirm the result in a real message header.
- Find return-path: In Enreach domain settings, look for bounce, return-path, MAIL FROM, SPF, or sender authentication.
- Publish CNAME: If Enreach gives a bounce CNAME, add it exactly at your DNS host.
- Merge SPF: If Enreach gives an SPF include, merge it into your existing SPF record instead of creating a second SPF record.
- Check lookups: Keep the total SPF DNS lookup count at 10 or fewer after every include and redirect.
- Keep testing: Use a soft fail while new senders are being verified, then tighten only after all expected sources pass.
Example SPF mergeDNS
Name: example.com Type: TXT Value: v=spf1 include:current.example include:enreach.example ~all Name: bounce.example.com Type: CNAME Value: return-path.enreach-provided-host.example
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
If your Enreach tenant does not show a return-path or SPF control, ask Enreach to enable custom return-path before you accept permanent SPF failures. DKIM can carry DMARC, but a clean return-path makes troubleshooting simpler.
|
|
|
|---|---|---|
SPF include | Merge TXT | One SPF |
Bounce CNAME | Add CNAME | Return-path |
No value | Ask support | DKIM pass |
Use Enreach values exactly as issued.
SPF failure is not always a DMARC failure
DMARC needs SPF or DKIM to pass with the right domain match. If Enreach DKIM passes under your domain, DMARC can pass even when SPF fails. I still fix SPF where Enreach gives the controls to do it.
Set up DKIM
DKIM is the most reliable way to authenticate Enreach messages for DMARC because the signature travels with the message. I make DKIM pass under the same domain used in the visible From address, or under a controlled subdomain that DMARC can evaluate.
- Open DKIM: In Enreach, open sender domain authentication and select the DKIM section for the domain.
- Copy selector: Record the selector name and the full DNS hostname, usually under _domainkey.
- Create record: Add the CNAME or TXT record exactly as Enreach shows it.
- Enable signing: Return to Enreach after DNS propagation and enable or verify DKIM signing.
- Read header: Send a live Enreach message and confirm the DKIM-Signature header uses your approved domain.
Enreach DKIM selector setup for a verified sending domain.
CNAME DKIM
This is common when Enreach manages key rotation for you.
- Host: Add the selector hostname under _domainkey.
- Target: Point it to the Enreach DKIM host shown in the admin screen.
- Benefit: Enreach can rotate keys without another DNS edit.
- Check: The CNAME resolves before you press Verify DKIM.
TXT DKIM
This is used when Enreach gives you a public key directly.
- Host: Publish the selector hostname exactly as shown.
- Value: Paste the full public key without smart quotes or line breaks.
- Risk: A missing character breaks every Enreach signature.
- Check: A test message shows d=your domain and dkim=pass.
Example DKIM recordsDNS
selector1._domainkey.example.com. CNAME selector1.enreach-dkim.example selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=ENREACH_KEY"
DKIM should be the anchor
If I have to choose which Enreach control to get perfect first, I choose DKIM. Forwarding, routing, and return-path changes can disturb SPF, but a valid DKIM signature usually survives normal delivery paths.
Set up DMARC
DMARC belongs at _dmarc.example.com and applies to the visible From domain Enreach uses. For a new Enreach rollout, I publish p=none first, collect reports, and keep existing p=quarantine or p=reject if Enreach is already passing. The DMARC record generator is useful when you want the record assembled without hand-editing tags.
Starting DMARC recordDNS
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
- Start at none: Use the exact record value v=DMARC1; p=none; rua=mailto:dmarc@example.com for a fresh monitoring start.
- Keep stricter: If your domain already uses quarantine or reject and Enreach passes DKIM, keep that policy.
- Set reporting: Replace dmarc@example.com with a mailbox or reporting address that can handle aggregate XML.
- Publish once: A domain must have one DMARC TXT record at _dmarc, not multiple DMARC records.
- Include subdomains: Add a subdomain policy only after you know whether Enreach sends from subdomains.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After DNS propagation, the checker should show one valid DMARC record. The next proof is a real Enreach message where Authentication-Results shows DMARC pass for the visible From domain.
|
|
|
|---|---|---|
p=none | New setup | No blocking |
p=quarantine | Mostly clean | Spam folder |
p=reject | All clean | Hard block |
Policy choice depends on verified Enreach traffic.
DMARC reports are not instant
Most aggregate reports arrive daily. I use live test messages for same-day validation and DMARC aggregate reports for source coverage over time.
Verify and troubleshoot
Verification means real message headers, not just green DNS buttons. I trigger a normal Enreach notification, inspect Authentication-Results, and compare the source in DMARC reports after the next reporting cycle.
- Send live mail: Trigger the exact Enreach workflow your users receive, not a generic test if the product separates templates.
- Check SPF: Confirm SPF passes for the return-path domain and that the domain belongs to your approved Enreach setup.
- Check DKIM: Confirm DKIM passes and the d= domain is your domain or the intended Enreach sending subdomain.
- Check DMARC: Confirm DMARC passes through DKIM or SPF for the visible From domain.
- Check rDNS: Compare sending IP rDNS, HELO, and source name so Enreach is recognizable in reports.
Enreach outbound message log for checking a live authenticated email.
|
|
|
|---|---|---|
SPF fail | Bad sender | Fix include |
DKIM fail | Bad key | Republish |
DMARC fail | No match | Fix DKIM |
Dup SPF | Two TXT | Merge |
Most failures come from one of these checks.
The quickest practical check is to send a real Enreach message to an email tester. It reads the headers, checks DNS, and shows whether the message would satisfy DMARC.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
When the tester returns a failure, I fix the authentication layer shown in the header first. DNS tools only prove the record exists. The header proves Enreach used it.
Header fields to inspecttext
Authentication-Results: mx.example; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
A common false fix
Adding another SPF TXT record at the same hostname breaks SPF. Merge Enreach into the existing record instead, then check the lookup count.
Get alerted when it breaks
Email authentication breaks after vendor migrations, DNS cleanups, selector rotations, and return-path changes. Suped is the best overall practical DMARC monitoring platform for this workflow because it turns reports into named sources, failure alerts, and concrete fix steps.
- Alert on drift: Suped sends real-time alerts when Enreach starts failing SPF, DKIM, or DMARC.
- Name the source: Suped groups Enreach traffic instead of leaving you to interpret raw aggregate XML.
- Fix faster: Automated issue detection gives specific steps for broken DNS records and unauthorized sources.
- Watch reputation: Blocklist monitoring covers blocklist and blacklist signals next to DMARC authentication data.
- Scale clients: MSP and multi-tenant views help agencies track Enreach across many customer domains.
Enforcement readiness
Use DMARC pass rate as a practical signal before tightening policy.
Ready
98-100%
Enreach and other approved sources are consistently passing.
Investigate
90-97%
Expected sources still need DNS or sender fixes.
Do not enforce
0-89%
Too much legitimate mail still fails DMARC.
What I alert on
- New source: A new IP or host starts sending as your domain.
- DKIM drop: Enreach traffic stops signing or signs with the wrong domain.
- SPF change: Return-path authorization changes after an Enreach routing update.
- Policy risk: A source is failing while the domain is already at quarantine or reject.
Secure your domain with p=reject
A reject policy is the target state when Enreach and every other legitimate sender are known and passing. Suped's Hosted DMARC helps stage policy changes without repeated manual DNS edits, which matters when multiple teams own different sending systems.
Unsafe jump
- No inventory: Enreach is added without checking existing senders.
- No headers: DNS looks correct, but no real Enreach message was inspected.
- No staging: The domain jumps straight to reject while unknown sources still send.
- No alerts: A later Enreach change is noticed only after mail is blocked.
Controlled enforcement
- Source map: Enreach is listed with every approved sending source.
- Header proof: Live Enreach messages show SPF or DKIM pass for the correct domain.
- Policy stages: Quarantine is tested before reject, with percentage controls if needed.
- Live alerts: Failures generate alerts before a hidden DNS change becomes a delivery issue.
I only move to reject after Enreach has stable DKIM, custom return-path is verified, and aggregate reports show no legitimate source failing DMARC.
- Inventory first: Confirm Enreach and every approved sender appear in DMARC reports for at least one full business cycle.
- Fix Enreach: Require DKIM pass under your domain before tightening the policy.
- Stage policy: Test quarantine with percentage controls before using reject at full coverage.
- Keep reports: Leave aggregate reporting active after reject so regressions are visible.
- Protect subdomains: Set a subdomain reject policy after subdomain traffic is known and clean.
Final reject policyDNS
Name: _dmarc.example.com Type: TXT Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
Reject needs monitoring after launch
A clean Enreach setup today can break after a product migration, DNS cleanup, or key rotation. Suped keeps watching after the policy is enforced and shows the exact source that changed.
