Cybersecurity glossary

What is Email Header Injection?

Learn what email header injection is, how newlines in mail fields forge BCC recipients or custom headers, what abuse follows, and how to build SMTP messages safely.

Application securityUpdated August 11, 2026
Also known asSMTP header injectionMail header injectionEmail CRLF injection

Definition

Email Header Injection is a vulnerability in which untrusted input containing newline or header-delimiting characters is inserted into email headers, allowing attackers to add recipients (Bcc/Cc), alter subjects, or inject additional MIME headers that change how messages are routed or rendered.

Why email header injection matters

Contact forms, “share this,” and notification features often build outbound mail from user text. Email headers are line-oriented: one bad newline turns a subject into an extra Bcc. Email Header Injection lets attackers ride your mail infrastructure—burning domain reputation, spamming third parties, or silently copying sensitive notifications.

Because messages leave through your authenticated MTA, recipients may trust them more than obvious spam. That makes this class disproportionately useful for phishing.

How email header injection works

1

User input enters a header field

Name, subject, or reply-to is copied into the message header block.

2

Newlines forge additional headers

CR/LF sequences terminate the field and start Bcc, Cc, or Content-Type lines.

3

MTA accepts the crafted message

Your mail server sends to attacker-added recipients using your identity.

4

Abuse and reputation damage

Spam, phishing, or data leakage follows—often until blocklists notice.

Common abuse outcomes

Silent BCC

Attackers receive copies of password resets or support conversations.

Spam relay

Your domain sends bulk mail to victims and lands on blocklists.

Header spoofing

Injected From/Reply-To values confuse users and ticket systems.

MIME confusion

Extra Content-Type headers can alter rendering in some clients.

Prevention that works

ControlNotes
Structured mail APIsSet To/Subject/Reply-To via library fields, never raw header strings
Reject CR/LFValidate header values after decoding; block control characters
Body-only user contentKeep free text in the message body whenever possible
Strict address validationAllowlist a single RFC-compliant address for Reply-To
Fixed envelope senderDo not let users choose SMTP MAIL FROM
Rate limits & monitoringDetect sudden spikes in outbound recipients from form endpoints
  • Find every code path that builds outbound email from request input.
  • Replace string-built headers with typed mail library calls.
  • Reject CR, LF, and other controls in name, subject, and reply-to.
  • Place free-form comments only in the message body.
  • Test with %0aBcc: and %0d%0aCc: payloads and inspect raw MIME.
  • Monitor MTA logs for unexpected recipient counts on form mail.
  • Authenticate mail with SPF, DKIM, and DMARC—and watch for abuse signals.
  • Treat successful recipient injection as high severity.

The practical takeaway

Email header injection uses newlines to rewrite SMTP/message headers. Build mail with structured APIs, keep user prose in the body, and never trust a form field as a raw header line.

If your contact form can add a BCC, attackers will use your domain as their mail gun.

Related security terms

Frequently asked questions

What is email header injection in simple terms?

A contact form asks for your name or subject and puts that text into the email’s headers. If you include a new line and 'Bcc: attacker@evil.com', the server may send a copy to the attacker or spam targets.

Which fields are usually vulnerable?

Name, subject, reply-to, and any custom header built from form input. Body injection is different; header injection specifically breaks header structure.

What can attackers do with it?

Silent BCC copies, spam relay through your domain, phishing that inherits your SPF/DKIM reputation, and MIME tricks that change how clients display content.

Is this still relevant with modern mail APIs?

Higher-level APIs reduce risk by treating headers as structured fields, but string-built messages, legacy mail() wrappers, and custom SMTP code remain common failure points.

How do you prevent email header injection?

Never concatenate user input into raw header blocks. Use mail libraries that set headers via typed fields, and reject CR/LF in any value that still must appear in a header.

Should user input ever appear in headers?

Prefer placing user content only in the body. If Reply-To must be user-controlled, validate it as a single email address and reject control characters.

How do you test for it?

Submit %0aBcc: or \r\nCc: payloads in name/subject fields and inspect the raw message your MTA queues.

References

Explore authoritative guidance and frameworks related to email header injection.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary