What are common RFC compliance issues that break deliverability?

Most senders never think about RFCs until something breaks. Then they're staring at a bounce message wondering why a perfectly normal email got rejected before it even reached a spam filter. The answer is usually a structural problem, something in how the email was built that violates the rules servers expect.

Here are the most common RFC compliance issues, ranked roughly by how badly they hurt you.

1. Bad HELO/EHLO identification (RFC 5321)

When your mail server introduces itself at the start of an SMTP connection, it uses a HELO or EHLO command followed by a hostname. That hostname is supposed to be a real, fully qualified domain name (FQDN) that resolves in DNS. If your server sends a bare IP address, a made-up name, or something that doesn't resolve, receiving servers flag it immediately. Some reject the connection outright. This is one of the most common self-hosted server misconfigurations and one of the easiest to fix.

2. Missing or mismatched reverse DNS (RFC 5321)

Every sending IP should have a PTR record that matches its forward DNS. If your IP's reverse lookup returns nothing, or returns a hostname that doesn't match your sending domain, that's a red flag for most receiving servers. It doesn't automatically block you, but it contributes to a poor reputation signal and can tip borderline emails into the spam folder.

3. Malformed message headers (RFC 5322)

RFC 5322 defines exactly how headers must be structured. The most common violations are missing or duplicate From headers, incorrect date format, lines that exceed 998 characters without being folded properly, and invalid characters in header values. Some email clients will try to render around these problems. Receiving servers and spam filters are less forgiving, and they treat structural irregularities as a sign that something automated and low-quality generated the message.

4. Authentication misconfigurations (RFCs 7208, 6376, 7489)

SPF, DKIM, and DMARC each have their own RFC specifications. Misconfiguring them doesn't just cause authentication failures. It can actively signal to mailbox providers that the email may not be legitimate. A DKIM signature that doesn't verify, or an SPF record with more than ten DNS lookups, both count as failures even if everything else about your email looks fine. DMARC failures on top of that can result in messages being rejected or quarantined entirely.

5. MIME boundary and encoding errors (RFCs 2045-2049)

Now if your email has multiple parts (plain text and HTML, or an attachment), MIME boundaries define where each part starts and ends. Malformed boundaries, missing content-type declarations, or incorrect base64 encoding can cause parts to display incorrectly or not render at all. Some security gateways will block messages with encoding anomalies because they're a known vector for obfuscating malicious content.

6. Ignoring bounce handling requirements (RFC 5321)

RFC 5321 requires that the return-path address (the envelope sender) actually accepts bounce messages. If you use a no-reply address or a non-existent mailbox as your bounce address and never process what comes back, you're not just ignoring bad signals. You're building a reputation for ignoring them. Mailbox providers notice high bounce rates and factor that into sender reputation scoring.

What to actually do about this

Start with authentication. SPF, DKIM, and DMARC violations cause the most direct, measurable damage to deliverability. You can check your SPF record right now with our free SPF checker, and your email headers (including HELO identification and MIME structure) with the Email Header Analyzer. Both are free, no signup needed.

If something is actively broken and you're not sure where to start, our SOS hotline is free. We'll help you figure out what's actually causing the issue rather than guessing.