MDaemon Technologies Blog

You've configured sender authentication. You've published the right DNS records. You're checking your logs and seeing the word fail next to messages that shouldn't have been delivered, and yet they landed in user inboxes anyway.

This is one of the most common questions we hear from MDaemon administrators, and what seems to confuse a lot of people is that failing authentication is rarely a hard block. SPF, DKIM, and DMARC produce signals, and what happens to those signals depends on how your server is configured to respond.

In this post, I’ll walk you through the nine most common reasons "failed" mail can still get delivered through MDaemon, where each setting lives, and I’ll provide a troubleshooting checklist you can run when you spot something suspicious in the logs.

A 60-second refresher

Before we dig in, here's what each of these mechanisms actually does:

• SPF (Sender Policy Framework) verifies that the sending IP is authorized to send for the domain in the SMTP envelope (MAIL FROM). It answers: Is this server allowed to send for example.com?
• DKIM (DomainKeys Identified Mail) verifies that the message body and selected headers haven't been altered, using a cryptographic signature tied to a DNS-published public key. It answers: Was this message actually signed by example.com, and is it intact?
• DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM by adding two things: alignment (the authenticated domain must match the visible From: header), and policy (what the sender wants receivers to do when alignment fails: none, quarantine, or reject).

The critical point: a DMARC failure is best understood as a signal. The sending domain requests an action via its published policy, and the receiving server applies that policy based on its own configuration. MDaemon's documented defaults honor DMARC reject and quarantine policies, but the resulting delivery outcome can be shaped by exemptions, trusted sources, downstream rules, and other settings that may have been changed from those defaults.

Nine reasons failing mail can still get delivered

1. The sender publishes a DMARC policy of p=none

This is by far the most common reason. The From: domain's DMARC record looks something like v=DMARC1; p=none; rua=mailto:reports@example.com. A policy of none means the sender is in monitoring mode. In other words, they're collecting aggregate reports but explicitly not asking receivers to quarantine or reject. MDaemon will faithfully record the DMARC failure in the log and deliver the message, because that's exactly what the sender asked for.

You can verify this yourself by running nslookup -type=TXT _dmarc.exampledomain.com.

2. The DMARC disposition settings have been changed from their defaults

MDaemon's DMARC Verification screen includes a set of behavioral settings that determine what happens when a message fails DMARC and the sending domain has published a strict policy. These settings are enabled by default, meaning MDaemon honors a sending domain's published p=reject and p=quarantine policies out of the box. If failing mail is reaching inboxes when the sender's policy says otherwise, one possibility is that those settings were turned off, or weren't re-enabled after an upgrade or migration. Verify them at:

Security → Sender Authentication → DMARC Verification

Look for "Honor p=reject when DMARC produces a FAIL result" and "Filter messages which fail the DMARC test into Junk E-Mail folders." If either has been disabled, MDaemon will still evaluate DMARC and log the result, but won't take the corresponding action on the sender's published policy.

3. DKIM Verification has its own Exempt list

Most administrators audit Trusted Domains and Trusted IPs under Security Settings, but DKIM Verification has its own "Exempt list" button that does something similar. Any IP added there is exempt from cryptographic verification specifically — DKIM is skipped, and if SPF also doesn't conclusively fail, the message can pass DMARC by default. What can confuse some people is that this list isn't visible from the global Trusted IPs view, so a clean Trusted IPs audit can give a false sense of completeness.

Check: Security → Sender Authentication → DKIM Verification → Exempt list

Audit this list periodically alongside your global Trusted IPs. Any IP listed here should have a documented reason, and stale entries should be removed.

4. The message came from a Trusted Domain or Trusted IP

Trusted Domains and Trusted IPs are treated as if they were part of your own infrastructure. Authentication checks may be bypassed for these sources by design. The assumption is that anything coming from a trusted internal source has already been vetted.

Check: Security → Security Settings → Trusted Domains and Trusted IPs

 Watch out for any legacy entries: an old smarthost domain, a decommissioned relay's hostname, or a vendor IP that was added years ago and never removed. If any of those entries are ever compromised or reused, your authentication enforcement effectively has a hole punched through it.

5. ARC may be carrying forward an upstream "pass" (in environments that use it)

This one only applies if your MDaemon is configured to trust ARC (Authenticated Received Chain) sealers. ARC (more info from the Help file) is designed to preserve authentication results through legitimate intermediaries — mailing lists, forwarders, secure email gateways — that often break SPF or DKIM by modifying messages in transit. When an upstream ARC-trusted host has vouched that the message was authenticated before it was modified, MDaemon can use that result during DMARC verification even though the message arrives at your edge looking like a failure.

If ARC isn't configured in your environment, this section likely doesn't apply. If it is, check: Security → Sender Authentication → ARC Settings

Review your list of trusted ARC sealers. An unrecognized sealer, or a trusted one that has itself been compromised, could explain failures passing when they shouldn't.

6. Verification is happening, but the configured action isn't what you think

MDaemon can verify SPF, DKIM, and DMARC and then, depending on configuration, log the result, tag the message in headers, add to its Spam Filter score, route it to a junk folder, or reject it outright during the SMTP session. Verification by itself doesn't dictate the outcome; the action does, and the action is configured separately on each Sender Authentication screen.

Check each tab under Security → Sender Authentication → SPF, DKIM Verification, and DMARC Verification. On SPF, look for the "When verification produces a FAIL result: ...send 550 error code" option. On DMARC Verification, look for "Honor p=reject when DMARC produces a FAIL result" and "Filter messages which fail the DMARC test into Junk E-Mail folders." DKIM Verification has no direct fail-action option of its own — failed DKIM influences DMARC alignment and Spam Filter scoring rather than acting on its own. But DKIM is still very important: DMARC alignment depends on a valid DKIM signature, so its enforcement happens downstream rather than on the DKIM Verification screen itself. If a screen is set to verify but the corresponding action you'd expect isn't configured, the delivery outcome may not match what the policy suggests it should be.

7. SPF or DKIM passes, but DMARC fails on alignment

This one fools a lot of people. A message can pass SPF or pass DKIM and still fail DMARC, because DMARC requires the authenticated domain to align with the From: header domain. This is what catches a lot of spoofing: a message can be cryptographically signed by mailer.attacker.com and pass DKIM, but if the visible From: says ceo@yourcompany.com, DMARC fails on alignment.

The message looks "partially authenticated" in the logs, which sometimes leads admins to assume it's safe. It isn't. The DMARC result is what matters, and a failed DMARC alignment is the signal that someone is impersonating the visible sender.

8. A Content Filter rule may be influencing the delivery outcome

Content Filter rules run after authentication results are evaluated and can influence what happens to a message — for example, a rule that delivers messages with a particular subject line, routes mail from a known sender to a specific folder, or stops further filter processing for certain conditions. Depending on how those rules are configured, they can change the outcome of a message that sender authentication would otherwise have flagged or rejected.

Check: Security → Content Filter

Review your content filter rules top to bottom and look for any rule whose action is "Deliver," "Move to," "Stop processing," or similar — especially older rules whose purpose isn't obvious from the name.

9. The message came in over an authenticated SMTP session

If a user (or a compromised account) authenticates to your server with valid SMTP credentials, MDaemon by default exempts that session from sender authentication checks. This makes sense for outbound mail from your own users, but it becomes a problem when an attacker has stolen credentials. The message can pass through with its SPF/DKIM/DMARC failures essentially uninspected, because the session is being treated as a legitimate outbound submission.

Note: You can use Dynamic Screening and Account Hijack Detection to protect against hackers with stolen credentials. 

This is the cause behind a lot of "we're sending phishing from our own domain" incidents. The session is authenticated; the user is not who they claim to be.

Check session auth bypass behavior under Security → Sender Authentication → [each tab] — most of the tabs have an explicit "Do not apply to authenticated sessions" option.