SMTP 550 5.7.26 and 5.7.23: unauthenticated email

What the message looks like

550-5.7.26 Unauthenticated email from beispiel.de is not accepted due to domain's DMARC policy.

Common causes

• The sending IP (newsletter tool, CRM, web shop) is missing from the SPF record.
• SPF exceeds the 10 DNS lookup limit and returns permerror.
• DKIM is not signing, or the DNS selector does not match the key.
• No alignment: SPF/DKIM pass for a different domain than the one in From:.
• Forwarding through third-party servers breaks SPF and there is no DKIM to fall back on.

Check

1. Query the sender domain's SPF record
   dig +short TXT example.com | grep spf1Copy
2. Query the DMARC policy
   dig +short TXT _dmarc.example.comCopy
3. Check the DKIM key for the selector
   dig +short TXT default._domainkey.example.comCopy
4. Test the DKIM key against DNS (OpenDKIM)
   opendkim-testkey -d example.com -s default -vvvCopy
5. In a delivered test mail, check the Authentication-Results header for spf=, dkim= and dmarc=

Fix

• Add every sending source via ip4:/include: to SPF and end it with ~all or -all.
• Keep SPF under 10 lookups: drop unused includes or replace them with IP ranges.
• Enable DKIM signing on the mail server or sending service and publish the public key at selector._domainkey.
• For external services, set up a custom return-path or DKIM domain so alignment works.
• Run DMARC with p=none and rua= reports first, review them, then tighten the policy.

FAQ

What is the difference between 5.7.26 and 5.7.23?

5.7.26 means DMARC failed or the mail is not authenticated at all. 5.7.23 means the SPF check itself hard-failed, typically with -all.

Is SPF alone enough for Gmail?

Not for bulk senders – Google requires SPF and DKIM plus DMARC. Even at low volume DKIM is the more robust base because it survives forwarding.