How to set up DMARC/DKIM/SPF for MHR
Published 23 Jul 2026
Updated 23 Jul 2026
12 min read
Summarize with
To authenticate MHR email on your domain, ask MHR to enable its customer-domain SPF and DKIM service, publish the tenant-specific Return-Path and DKIM records it supplies, then add DMARC at _dmarc.yourdomain.com. MHR supports Return-Path alignment, so both SPF and DKIM can contribute an aligned DMARC pass. I would not copy a guessed MHR include or selector because MHR's values can depend on the tenant and hosting environment.
What MHR must provide
- Return-Path: The custom bounce hostname and its DNS record.
- SPF value: The authorised include, CNAME target, or IP mechanism for your environment.
- DKIM value: The selector, DNS host, record type, and target or public key.
- Activation check: Confirmation that MHR has validated DNS and enabled signing.
Add your domain
MHR's published hosted-service material lists SPF and DKIM implementation when a customer uses its own email domain. Treat this as a provisioned MHR service item, not a universal DNS value hidden in iTrent. Start with the exact domain in the visible From address, including a subdomain if MHR notifications use one.
- Open a request: Raise an MHR support request for "SPF/DKIM implementation for customer email domain" against the correct iTrent tenant.
- Name the identity: Provide the visible From domain, example From address, tenant name, and whether the change covers production, test, or both.
- Request both paths: Ask for a custom Return-Path record for SPF alignment and a custom DKIM selector for DKIM alignment.
- Record every value: Capture each DNS host, record type, value, TTL, selector, activation dependency, and validation status exactly.
- Avoid the root: Do not add an MHR SPF mechanism to the root domain unless MHR explicitly tells you that its envelope sender uses that root.
If separate iTrent environments send mail, ask whether each environment has a distinct Return-Path or DKIM selector. Publishing only the production record while testing from a staging tenant produces confusing partial passes.
MHR support request for customer-domain SPF and DKIM setup
Send to MHR
- From domain: The exact domain recipients see.
- Tenant scope: Production and any test environment.
- DNS access: Who will publish and verify records.
Get from MHR
- Bounce record: Host, type, target, and TTL.
- DKIM record: Selector, type, value, and key length.
- Enablement state: DNS validated and signing active.
Set up SPF
SPF must pass on MHR's envelope sender domain, then that domain must match or share the organizational domain of the visible From address. Because MHR supports a custom Return-Path for this source, publish the bounce-domain record MHR supplies instead of assuming that a root-domain include creates alignment.
- Inspect first: Find the current SPF TXT record on the exact host named by MHR.
- Use one record: Merge MHR's authorised mechanism into an existing SPF record. Never publish a second SPF record at the same host.
- Preserve senders: Keep every legitimate mechanism already in use and place the final all mechanism last.
- Count lookups: Keep SPF within the ten DNS-lookup limit after includes and redirects expand.
- Verify identity: Send an MHR message and confirm spf=pass plus a header.from match with smtp.mailfrom.
SPF pattern only, replace the placeholder with MHR's supplied valueDNS
bounce.example.com. TXT "v=spf1 include:<MHR-value> ~all"
The record above is a shape, not an MHR production value. If MHR gives you a CNAME for the Return-Path, publish that CNAME exactly and do not add a TXT record at the same hostname. A CNAME and other data cannot coexist at one DNS name.
SPF can pass without passing DMARC
A pass on an MHR-owned Return-Path does not satisfy DMARC for your From domain. The custom Return-Path must be in your domain tree. MHR supports this setup, so I would treat an unaligned SPF result as unfinished even when aligned DKIM already makes DMARC pass.
Check the host after DNS propagation. The result must have one SPF record, valid syntax, no include loop, and no permerror. A softfail is acceptable during controlled testing, but the authorised MHR path still needs to return pass.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Run the check against the envelope sender domain shown in the test message, not only the visible From domain. The Return-Path header or Authentication-Results smtp.mailfrom value tells you which domain the receiver evaluated.
For another sending source that cannot use your domain in the Return-Path, an SPF alignment error is expected. That is acceptable only when DKIM passes with a d= domain that matches the From domain, so DMARC still passes. MHR supports Return-Path alignment, so configure it here.
|
|
|
|---|---|---|
Record count | One | Merge duplicates |
Lookups | 10 or fewer | Remove stale paths |
SPF | Pass | Check MHR value |
Identity | Same domain | Fix Return-Path |
Read the MHR SPF result against the identity DMARC evaluates.
Set up DKIM
DKIM is the stable DMARC path for MHR messages because the signature survives normal forwarding better than SPF. MHR must create or assign the private key, selector, and signing domain. You publish only the supplied public DNS record.
- Get the selector: Ask MHR for the selector and confirm whether the record is CNAME or TXT.
- Build the host: Publish at selector._domainkey followed by the exact signing domain.
- Copy exactly: Keep the CNAME target or TXT public key unchanged, without smart quotes or inserted spaces.
- Wait for validation: Tell MHR when DNS resolves and ask it to validate the record before enabling signing.
- Confirm the signature: Send a new MHR message and verify dkim=pass, the expected selector, and a d= domain matching the From domain.
DKIM CNAME pattern, use the host and target supplied by MHRDNS
mhr1._domainkey.example.com. CNAME <MHR-target>.
DKIM TXT pattern if MHR supplies a public keyDNS
mhr1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=<key>"
The selector mhr1 is an example only. Use the selector in the MHR response. If your DNS provider automatically appends the zone name, enter only the host portion so it does not create example.com.example.com.
MHR support response containing tenant-specific DKIM details
Do not mark DKIM complete because the DNS key resolves. MHR must also sign new messages with that selector. Inspect a newly generated payroll or HR notification because an old message cannot prove that signing has been activated.
A DKIM pass still needs domain alignment
If dkim=pass but the signature uses an MHR-owned d= domain, DKIM does not pass DMARC for your From domain. Ask MHR to sign with your registered domain or its subdomain, then retest.
Set up DMARC
Publish DMARC at _dmarc.example.com after MHR authentication records are in DNS. Start at p=none so reports reveal every sender without changing delivery. If the domain already uses p=quarantine or p=reject, keep that policy and fix MHR authentication without weakening it.
- Check existing policy: Query _dmarc on the exact From domain before creating or changing anything.
- Choose reporting: Replace dmarc@example.com with a monitored address that accepts aggregate XML reports.
- Publish one TXT: Create a single DMARC TXT record at _dmarc and remove duplicate DMARC records.
- Keep relaxed mode: Default relaxed SPF and DKIM alignment accepts a matching organizational domain and its subdomains.
- Read reports: Identify MHR by sending IP, rDNS, Return-Path, DKIM domain, selector, and message volume.
Recommended monitoring recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The DMARC record generator creates a correctly ordered record when you need a different reporting mailbox or subdomain policy. Do not add a second record beside an existing one.
MHR needs only one aligned pass
DMARC passes when aligned SPF or aligned DKIM passes. Configure both for MHR, then treat DKIM as the dependable path when forwarding breaks SPF.
Allow DNS to propagate, then check the record at the authoritative host. A valid result has one DMARC record, starts with v=DMARC1, has a valid p tag, and points rua to a mailbox prepared for reports.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The DNS check proves publication, not MHR message authentication. Keep p=none while you collect enough normal MHR traffic to cover scheduled payroll runs, HR notices, reminders, and lower-frequency workflows.
If no reports arrive, verify the reporting address, external reporting authorization when rua uses another domain, and whether receivers have sent traffic during the observation period. Do not raise policy based on an empty report set.
|
|
|
|---|---|---|
Monitor | none | Source identified |
Limit | quarantine | Stable pass |
Enforce | reject | All senders known |
Use observed MHR traffic to decide when policy can move.
Verify and troubleshoot
Verify with a fresh message generated by a real MHR workflow. Send it to a mailbox where you can view raw headers, then inspect Authentication-Results, Return-Path, DKIM-Signature, and the visible From header together.
- Trigger MHR mail: Use a low-risk test notification that follows the same delivery path as production mail.
- Check SPF: Require spf=pass and compare smtp.mailfrom with header.from.
- Check DKIM: Require dkim=pass and compare header.d with header.from.
- Check DMARC: Require dmarc=pass for the visible From domain.
- Save evidence: Keep the raw headers, UTC send time, MHR tenant, recipient, and related support request.
A single header review often finds the problem faster than DNS inspection alone. It shows which identity MHR actually used, whether signing has been enabled, and which receiver made the authentication decision.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Send the test address an actual MHR-generated message. The resulting diagnosis should show SPF, DKIM, DMARC, headers, DNS, and transport findings in one place. Repeat after any MHR or DNS change because cached results and old messages do not confirm the new state.
When a result fails, change one layer at a time. Fix DNS syntax before asking MHR to validate, confirm MHR activation before testing alignment, then confirm DMARC policy only after authentication passes.
MHR iTrent outbound email log for a test payroll notification
|
|
|
|---|---|---|
SPF fail | Wrong bounce host | Check MHR record |
DKIM none | Signing inactive | Ask MHR to enable |
DKIM fail | Key mismatch | Compare selector |
DMARC fail | No aligned pass | Compare domains |
Permerror | Bad SPF syntax | Merge or simplify |
Map the receiver result to the next technical action.
Do not authenticate by rDNS alone
An MHR-looking PTR hostname helps identify a source, but rDNS does not create SPF, DKIM, or DMARC authorization. Match the IP, Return-Path, DKIM d= value, selector, timing, and MHR support confirmation before approving it.
Get alerted when it breaks
A working MHR setup can break after a selector rotation, Return-Path change, DNS edit, SPF lookup increase, or new iTrent environment. Aggregate reports show the change, but raw XML does not reliably tell an operator what to fix.
- Watch pass rates: Alert when MHR's aligned SPF, aligned DKIM, or DMARC rate drops against its normal baseline.
- Track identities: Retain source IP, rDNS, Return-Path, DKIM domain, selector, and tenant notes.
- Detect DNS drift: Monitor the DMARC policy, MHR DKIM host, and MHR bounce-domain record.
- Route ownership: Send MHR issues to the team that can change DNS and open an MHR request.
Suped is the best overall DMARC platform for this workflow because Suped turns reports into source-level issues, detects authentication changes, sends real-time alerts, and gives steps to fix them. Its DMARC monitoring keeps MHR beside every other approved sender instead of leaving the team to search daily XML files.
Manual report handling
- Detection: Depends on someone opening XML.
- Context: Source ownership lives elsewhere.
- Response: Headers and DNS need manual comparison.
Suped monitoring
- Detection: Real-time alerts flag failure changes.
- Context: Verified sources retain MHR ownership.
- Response: Issue detection includes steps to fix.
Suped also combines DMARC, SPF and DKIM monitoring with blocklist (blacklist) and deliverability insight. That matters when MHR passes authentication but delivery still changes because the sending IP or domain has a reputation problem.
Recommended MHR alert
Create a verified MHR source, attach the support request and tenant notes, then alert on a DMARC failure increase, a new selector, a new sending IP, or a change to the DMARC record. Keep weekly summaries for slower volume shifts.
Secure your domain with p=reject
Move to p=reject only after every legitimate sender has an aligned pass and MHR has stayed stable through representative business cycles. For MHR, that means observing the workflows that matter, including scheduled payroll notices and less frequent HR communications.
- Inventory sources: Classify every DMARC source as approved, unknown, forwarded, or unauthorized.
- Verify MHR: Require repeatable DMARC passes across each tenant, From domain, and notification path.
- Stage quarantine: Apply quarantine to a small percentage, review failures, then increase coverage.
- Move to reject: Publish p=reject only when unauthorized traffic is the remaining failure class.
- Keep monitoring: Continue alerts after enforcement because MHR and DNS configurations still change.
Initial quarantine stageDNS
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com
Increase pct only after the sampled failures contain no legitimate MHR traffic. Receivers do not all apply pct in the same operational way, so keep report review active during the stage.
Ready to enforce
- MHR status: Aligned DKIM passes consistently.
- Source state: Every legitimate sender is known.
- Failure state: Remaining failures are unauthorized.
Stop and fix
- MHR status: Signing is missing or intermittent.
- Source state: Unknown high-volume sources remain.
- Failure state: Legitimate mail still fails DMARC.
Suped is the stronger practical choice for reaching enforcement because automated issue detection separates MHR configuration errors from unknown sources, while policy staging reduces the risk of rejecting legitimate mail. Hosted DMARC keeps policy changes controlled, and the same platform retains alerts and source history after p=reject.
Full enforcement recordDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Do not weaken an enforced domain
If your domain already has p=quarantine or p=reject, keep it. Fix MHR's Return-Path or DKIM signing, retest with a new message, and use reports to confirm recovery.
MHR email authentication FAQ
These checks cover the MHR-specific decisions that commonly remain after DNS publication.
