errno

Cloudflare Email Routing rejects mail with 550 5.7.26 "not authenticated"

· tested on Cloudflare Email Routing, route1.mx.cloudflare.net, Python smtplib, Gmail as destination

Symptom

A freshly created routing rule (contact@example.com → a Gmail mailbox) looked configured. Sending a test message straight to the MX from a host with no outbound mail authentication failed at the DATA stage:

smtplib.SMTPDataError: (550, b'5.7.26 Cannot forward emails that are not authenticated.
Refer to https://developers.cloudflare.com/email-routing/postmaster/ for more information..')

Note where it failed: MAIL FROM and RCPT TO were both accepted, so it is not an unknown-recipient or configuration problem.

First: prove the alias exists (without sending anything)

An SMTP conversation that stops before DATA tells you whether the rule is live, and costs nothing:

import smtplib
s = smtplib.SMTP("route1.mx.cloudflare.net", 25, timeout=15)
s.ehlo()
s.mail("postmaster@example.org")
print(s.rcpt("contact@example.com"))            # (250, b'2.1.0 Ok')       <- rule exists
print(s.rcpt("nonexistent-probe-8f21@example.com"))  # (550, b'5.1.1 Address does not exist.')
s.quit()

The contrast is the useful part: a live alias answers 250 while a random local part answers 550 5.1.1. If both answer 250 you have a catch-all; if your alias answers 550 the rule is not active and no amount of sending will help.

If the connection times out from your workstation, your ISP is blocking outbound port 25 — run the probe from a host that has it open.

What the 550 5.7.26 actually means

Cloudflare Email Routing forwards mail, and a forwarded message inherits your domain’s reputation with the destination. To avoid becoming an open relay for spoofed mail, it refuses messages that do not pass sender authentication — no SPF pass, no DKIM signature, no delivery.

Consequences worth knowing before you publish such an address:

What it looks like when it works

Sending the same message through an authenticated relay and inspecting the headers at the destination:

X-Forwarded-For: contact@example.com destination@gmail.com
Return-Path: <SRS0=huRD=5g=gmail.com=sender@example.com>
Authentication-Results: mx.google.com;
   dkim=pass header.i=@cloudflare-email.net;
   dkim=pass header.i=@example.com header.s=cf2024-1;
   dkim=pass header.i=@gmail.com;
   arc=pass (i=1 spf=pass dkim=pass dmarc=pass);
   spf=pass (…srs0=…@example.com designates 104.30.10.36 as permitted sender);
   dmarc=pass

Three things to read out of that:

  1. SRS rewriting. The envelope sender becomes SRS0=…@yourdomain, encoding the original sender. Without it the destination would see mail “from gmail.com” arriving from Cloudflare IPs and fail SPF.
  2. Cloudflare signs with your domain. dkim=pass header.i=@example.com header.s=cf2024-1 — the selector is published for you; cf2024-1._domainkey.yourdomain resolves even though you never created that record.
  3. ARC. Cloudflare adds an ARC seal preserving the original authentication result, which is what keeps the forwarded message out of spam.

Practical checklist for a published contact alias

email cloudflare smtp spf