Home / Knowledge hub / Email header injection
Knowledge hub
Email header injection
Input that adds extra recipients or headers to an email your app sends.
What it means
Email header injection happens when user input is placed into the header of an email your app sends, such as the subject or reply-to address, without removing line breaks. In an email, a new line starts a new header, so a line break lets the sender add headers of their own.
A contact form is the textbook case. The visitor types a subject followed by a line break and a Bcc: line, and the app then sends a copy of its message to whoever they like. The fault is simple, and so is the abuse.
Why it matters
Your mail server becomes a free relay for spam and phishing, sent from your own domain with your own reputation. That can get the domain blocked or filtered, which stops real emails such as password resets from arriving. It also damages trust, since the messages appear to come from you.
It can leak information too, by copying private messages to an outside address. It is a close relative of CRLF injection and header injection, applied to mail rather than web responses. Both are good reasons to fix it early. Treat mail headers like any other output that must be cleaned.
How it shows up
You meet it in contact forms, invite and share features, password reset requests and any page where a visitor's text or address ends up in a header. The classic mistake is building the mail by joining strings by hand. Each of those fields is a place to check.
Use a mail library that takes recipients and subject as separate fields and rejects line breaks, rather than assembling raw headers. Also refuse carriage returns and line feeds in anything that enters a header, fix the sender address yourself, and limit how many messages one visitor can trigger. Test with a line break in each field.
Questions people ask
Email header injection, answered
What makes a line break dangerous in an email?
Email headers are separated by line breaks, using carriage return and line feed. A break inside a field value starts a new header, so the attacker can add Bcc, Cc or extra content.
Libraries that validate fields block it.
Is this the same as spam through a contact form?
Related, not identical. Ordinary form spam sends messages to you. Header injection makes your form send messages to other people.
It is the second kind that harms your domain.
Do modern frameworks protect us?
Many mail libraries reject line breaks in headers, so the risk is lower when you use one properly. Older code and hand-built messages are where it still turns up.
Check what your code actually does.
Should the visitor's address be the From address?
Safer to send from your own address and put theirs in Reply-To, after validating it. Letting visitors set From can break your email authentication and enables spoofing.
SPF and DMARC will usually reject it anyway.
How do we test for it?
Submit a harmless line break followed by a header such as a Bcc to a test mailbox you own in the name and subject fields, then see whether the mail arrives there.
Only test addresses you control.
Sources
Where this comes from
Related
Terms that sit next to this one
CRLF injection
Using carriage return and line feed characters to split a response or a log line.
HTTP header injection
Slipping line breaks into input so an attacker adds headers to your response.
DMARC
A DNS policy telling receivers what to do with email that fails SPF and DKIM.
Email spoofing
Sending email that appears to come from your domain when it does not.
Rate limiting
Capping how often something can be attempted, per user or per address.
Can a form send mail to anyone?
We try line breaks and extra headers in every field that feeds an email, using mailboxes we control, and show the request that proved it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.