SMTP error from the remote mail server after end of data

This message is generated by the Exim mail transfer agent (and tools built on it). It means your server finished transmitting the message body and sent the closing line containing a single dot (.) — the end-of-DATA terminator defined in RFC 5321 §4.1.1.4 — and the receiving server rejected the message at that final step instead of replying 250 OK.

The phrase itself is just a wrapper. The actual diagnosis is the SMTP reply that Exim quotes immediately after it.

What does "after end of data" actually mean?

During an SMTP session the client issues DATA, the server replies 354, the client streams the message and ends it with <CRLF>.<CRLF>. Only then does the server evaluate the whole message and return a final code. A failure here is distinct from a failure at MAIL FROM or RCPT TO — by this point the recipient is already accepted, so the rejection is almost always about the message content, authentication, or your sending reputation, not a bad address. Exim classifies any error "after end of data" as a message error (the specific message fails) rather than a host error, so it does not delay other messages queued to the same host.

How do I read the real cause?

Look at the full bounce. The useful part is the code and text after the phrase, for example:

SMTP error from remote mail server after end of data:
550 5.7.1 Message rejected as spam

• 5xx = permanent rejection (the message failed and won't be retried).
• 4xx = temporary deferral (Exim will retry; often greylisting or rate limiting).
• The 3-part code (e.g. 5.7.1) is an enhanced status code from RFC 3463. 5.7.x = policy/security, 5.6.x = content/media, 5.2.x = mailbox.

How do I fix it?

Match the fix to the trailing code:

1. "spam", "high probability of spam", 5.7.1 / 5.6.0 — content or reputation. Send a multipart message (include a plain-text alternative, not HTML-only), avoid attachment types receivers distrust (macro-enabled Office files, some PDFs), and check your sending IP/domain against blocklists (Spamhaus, Barracuda).
2. Authentication failures (5.7.x, "SPF/DKIM/DMARC", "not authenticated") — publish and align SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 9989). Since February 2024, Gmail and Yahoo require authentication for bulk senders (those sending more than ~5,000 messages a day); unauthenticated mail may be marked as spam or rejected outright.
3. "Headers contain illegal BOM", malformed MIME, encoding errors — your message generator is emitting a byte-order mark (often inside a header added by a forwarder or spam filter) or invalid headers. Fix the template/library producing the message.
4. 4xx / "incoming data timeout", "rate limited" — slow down sending or wait; these clear on retry.

Note: the original advice to "edit your SPF record because it blocklists domains" is misleading. SPF authorizes your sending hosts; it does not maintain recipient blocklists. Only revisit SPF when the trailing code names an authentication failure.