Skip to main content

Spam and Authentication Issues

Alex Panagides
Updated

Use this page when mail processed by mxHERO lands in junk or spam, shows a spoofing warning, or fails SPF, DKIM or DMARC checks. mxHERO changes messages in transit (for example, it replaces attachments with links), so the receiving system must be told to trust mxHERO.

Check these first

  1. Trust mxHERO's IP addresses. In Microsoft 365, add all eight mxHERO IPs to the connection filter IP Allow List. In Google Workspace, add them to the Inbound gateway. See Network Endpoints and IP Addresses for the list.
  2. Trust mxHERO's ARC seal (Microsoft 365). Add mxhero.com as a trusted ARC sealer. Google Workspace needs no ARC setting.
  3. Include mxHERO in SPF. Your domain's SPF record must contain include:_spf.mxhero.com whenever mxHERO delivers outbound mail directly to recipients (no Relay Server set).
  4. Set up DKIM for your domain in mxHERO if mxHERO delivers outbound mail directly. See SPF, DKIM and DMARC.
  5. Read the authentication headers of an affected message (Authentication-Results, ARC-Authentication-Results) and match them in the tables below.

Note: The Office 365 Configuration Service adds the ARC sealer and the IP allow list for you. If you configured Microsoft 365 by hand, check both.

Inbound mail goes to junk or spam

Symptom Cause Fix
Microsoft 365: compauth=fail reason=001 on messages returned by mxHERO Microsoft 365 is not honoring mxHERO's ARC seal. Check that Get-ArcConfig lists mxhero.com, that the mxHERO Tenant Connector lists all eight IPs, and that the message came from one of them.
Microsoft 365: compauth=pass reason=130 ARC was honored through the trusted sealer. No action needed.
Microsoft 365: messages marked as spoofed or junk after mxHERO mxHERO's IPs are not in the connection filter IP Allow List. In the Microsoft Defender portal, open Email & collaboration › Policies & rules › Threat policies › Anti-spam › Connection filter policy (Default) and add each mxHERO IP.
Google Workspace: inbound mail lands in spam mxHERO's IPs are not listed in the Inbound gateway, or Gmail re-evaluates spam on the returned message. In the Google Admin console, open Apps › Google Workspace › Gmail › Spam, Phishing and Malware › Inbound gateway. Add all eight IPs. For loopback, set the message-tagging regexp ^X-Gm-spam: (0|1)$ and tick Disable Gmail spam evaluation on mail from this gateway; only use header value. See Google Workspace Configuration.
Spam after mxHERO changed its IPs Your allow lists use an old IP list. Compare your lists with Network Endpoints and IP Addresses.
Border gateway (Proofpoint, Barracuda and others) flags mail from mxHERO The gateway does not trust mxHERO's IPs. Add the mxHERO IPs to the gateway's trusted or allow list. See Border Gateways.

Outbound mail fails SPF, DKIM or DMARC at recipients

Symptom Cause Fix
SPF fail or softfail at the recipient mxHERO delivered the message directly, and your SPF record does not include mxHERO. Add include:_spf.mxhero.com to your existing SPF record. Keep a single SPF record per domain, for example v=spf1 include:spf.protection.outlook.com include:_spf.mxhero.com ~all. The dashboard's SPF indicator on the Domains tab shows whether the include is present.
DKIM fail at the recipient mxHERO changed the message (for example, replaced attachments), which breaks your mail system's original DKIM signature. Set up DKIM for the domain in Settings › Organization and domains › DKIM. mxHERO then signs the messages it delivers. Alternatively, return outbound mail through your mail system (outbound loopback) so it signs the final message.
DMARC fail at the recipient Neither SPF nor DKIM aligned with the From domain. Fix SPF and DKIM as above. Recipients that support ARC can also use mxHERO's ARC seal.
DKIM key not verifying in the dashboard The TXT record is missing or its value differs. Publish the TXT record at <selector>._domainkey.<domain> exactly as shown, then click Verify. Spaces after ; are accepted. Only one unverified key per domain is allowed.

Note: mxHERO generates 1024-bit DKIM keys.

Messages show "winmail.dat" or attachments are not processed

Microsoft 365 can wrap messages in TNEF (winmail.dat). mxHERO cannot read attachments inside TNEF, so most rules skip these messages.

Symptom Cause Fix
Recipients get winmail.dat, or Email Flow Logs shows mail_content_is_tnef TNEF is enabled for the remote domain. Run Get-RemoteDomain Default | Select TNEFEnabled and, if it returns True, run Set-RemoteDomain Default -TNEFEnabled $false. See Preventing TNEF Encapsulation.

Notifications from mxHERO are filtered

mxHERO sends system email (password notices, hold and approval notices, sign-in codes, digests). If users do not receive them, allow these senders in your spam filter:

  • noreply@mxhero.com: hold, approval and block notices, bounces, digests, re-authentication and tracking notices.
  • noreply@notifications.mxhero.com: mxHERO Shares sign-in codes and malware notices.

Password notices for protected links are sent from the original sender's address when that domain is managed by mxHERO, and from noreply@mxhero.com otherwise.

Related articles

Comments

0 comments

Please sign in to leave a comment.

Powered by Zendesk