Cloudflare Email Routing rejects mail with 550 5.7.26 "not authenticated"
Symptom
A freshly created routing rule ([email protected] → 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("[email protected]")
print(s.rcpt("[email protected]")) # (250, b'2.1.0 Ok') <- rule exists
print(s.rcpt("[email protected]")) # (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:
- Mail from Gmail, Outlook, corporate Exchange and any correctly configured server arrives normally.
- Mail from a hobby server without SPF/DKIM never reaches you, and the sender gets a hard bounce.
- Your own scripted test must go through an authenticated relay, otherwise you are testing the rejection path, not the forwarding path.
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: [email protected] [email protected]
Return-Path: <[email protected]>
Authentication-Results: mx.google.com;
dkim=pass [email protected];
dkim=pass [email protected] header.s=cf2024-1;
dkim=pass [email protected];
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:
- 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. - Cloudflare signs with your domain.
dkim=pass [email protected] header.s=cf2024-1— the selector is published for you;cf2024-1._domainkey.yourdomainresolves even though you never created that record. - 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
- MX records point at
route1/2/3.mx.cloudflare.net, SPF containsinclude:_spf.mx.cloudflare.net. - Add a DMARC record even in monitoring mode:
v=DMARC1; p=none; rua=mailto:[email protected]. Receiving works without it, but it makes spoofing your domain measurably harder to do unnoticed. - Remember Email Routing is receive-only. To send from the alias you need a separate SMTP relay and a “send mail as” configuration in your mailbox.