SMTP error 5.7.26 Multiple authentication checks failed

What SMTP error 5.7.26 means

More than one authentication check failed on the same message and the receiver treated the combination as grounds for rejection. In working practice this is the DMARC code: neither SPF nor DKIM produced a result that lines up with the domain in the From header, and that domain publishes p=reject. It comes back as 550 5.7.26, and it very often appears the day after somebody tightened a DMARC record.

Security or policy status
Sent by The receiving mail server, applying the DMARC policy published by the From domain
Common

What SMTP error 5.7.26 Multiple authentication checks failed actually means

DMARC does not add a third check. It requires that one of the existing two both passes and aligns, meaning the domain that passed SPF, or the d= domain that produced a valid DKIM signature, has to match the domain your recipient sees in the From line. Relaxed alignment accepts a subdomain of it; strict alignment demands an exact match. This is how a message passes SPF cleanly and is still refused: the envelope sender belonged to a mailing platform, so SPF passed for the platform and not for you. The code deliberately does not name which mechanisms failed, so the detail lives in the receiver's Authentication-Results header or in your aggregate reports. Only the permanent form is registered, so there is no second attempt.

This status code is returned when a message failed more than one message authentication check, contrary to local policy requirements. The particular mechanisms that failed are not specified.
— RFC 7372

How 5.7.26 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists 550 5.7.26 as the pairing for this status.

The leading 5 is the server's verdict rather than part of the code's identity: it marks this as a permanent failure, which means the sending server has given up and returned the message.

What causes SMTP error 5.7.26 on a business phone system

A third-party sender authorised for neither mechanismStatements, quotes, booking confirmations and payroll notifications sent by a platform that signs with its own domain and bounces to its own domain. Both checks technically succeed, both succeed for the wrong domain, and the message is rejected.
The policy was moved to reject before the estate was mappedA supplier questionnaire or a Cyber Essentials review prompts someone to set p=reject in an afternoon. The change is global and instant, and the systems nobody remembered stop delivering the same evening.
SPF passes but does not alignBulk platforms use their own bounce domain in the envelope by default, so SPF authorises them rather than you. The fix is a custom Return-Path on a subdomain of yours, which most platforms offer as a CNAME and most customers never enable.
Forwarding and a mailing list in the same pathForwarding breaks SPF because the IP changes, and a list that appends a footer breaks DKIM because the hashes change. Both fail together, which is precisely the condition this code names.
The message genuinely was not yoursIf this shows up on messages nobody at your business sent, the mechanism is doing its job and somebody is attempting to spoof your domain. That is a security finding rather than a configuration fault.

How to fix SMTP error 5.7.26

Read the Authentication-Results header on a rejected copyIt states spf=, dkim= and dmarc= results with the domains each was evaluated against. Comparing those domains with the From domain answers the alignment question in about ten seconds, which no amount of guessing will.
Switch on aggregate reporting and read a fortnight of itAdd a rua address to the DMARC record and let the XML come in. It lists every source sending as your domain with pass and fail counts, and routinely surfaces legitimate senders the business had forgotten about.
Fix alignment at each platform rather than widening the policyEnable branded DKIM so the platform signs with d= set to your domain, and set a custom bounce domain so the envelope aligns too. Either one passing is enough; getting both is better.
Walk the policy up in stagesSit at p=none until the reports are clean, move to p=quarantine with a percentage, then to reject. Going straight to reject from nothing is the single most common way a business breaks its own invoicing.
Give awkward senders their own subdomainWhere a supplier cannot sign as your domain at all, publish a subdomain with its own DMARC policy. Failures are then contained to that subdomain and your primary domain stays at reject.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 5.7.26

Our SPF record is correct and we still get rejected. What are we missing?

Almost certainly alignment. SPF passing for the sending platform does nothing for you if the From line shows your domain and the envelope shows theirs. Check which domain SPF was evaluated against in the Authentication-Results header, and if it is not yours, set a custom bounce domain at the platform.

Do we need both SPF and DKIM to pass?

No. DMARC is satisfied by either one passing in alignment. DKIM is the more valuable of the two to get right, because a DKIM signature survives forwarding whereas SPF does not, so mail that is forwarded on still authenticates.

Which two checks failed? The bounce does not say.

By design. The specification states that the mechanisms which failed are not identified, so the code alone will never tell you. Ask the recipient for the full headers of one rejected message, or wait for the next aggregate report.

Related SMTP status codes

Source. SMTP error 5.7.26 Multiple authentication checks failed is defined in RFC 7372 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes