In today’s world, email remains one of the most widely used communication channels, both for personal and professional purposes. Yet that very popularity also makes email a prime target for cybercriminals looking to exploit it for profit. One of the most common techniques for deceiving email recipients is SMTP spoofing — a tactic that lets attackers send messages that appear to come from a trusted source. This method enables phishing and fraud, making it hard for recipients to verify a message’s authenticity.
In this blog I responsibly disclose a flaw enabling SMTP spoofing, discovered in the popular Polish email service Interia.pl. I would like to shed light on the topic and raise awareness among the people responsible for these systems, so that the flaw can be effectively remediated.
I would like to sincerely thank the Interia team and CERT Polska for their cooperation in fixing the reported flaw.
TL;DR - Key takeaways
- Analysis of the SPF Bypass / DMARC Misconfiguration
- Envelope vs. Header
- The Vulnerability: SPF Bypass
- Where Is DMARC?
Analysis of the SPF Bypass / DMARC Misconfiguration
To understand why, in 2025, it is still possible to impersonate a large Polish mail provider or a bank, we have to go back to the 1980s. The SMTP protocol (Simple Mail Transfer Protocol), on which the entire global email system rests, was designed at a time when everyone on the internet trusted one another. It has no built-in mechanism for verifying the sender’s identity.
Modern protections are, to a large extent, "patches" laid over this old system. The biggest hole that attackers exploit stems from a fundamental distinction between two concepts in the structure of an email.
1. Envelope vs. Header
This is the crucial point where the manipulation happens. Every email consists of two addressing layers that do not have to match each other:
Envelope From (RFC 5321): This is the address on the "envelope." It is used by mail servers for routing (e.g. delivery errors come back to it). This is the address we supply in the SMTP MAIL FROM command.
Header From (RFC 5322): This is the address in the "letter" inside the envelope. This is the address the user sees in their Outlook, Gmail, or webmail in the "From:" field.
The Core Problem
These two addresses do not have to match — and that is precisely the source of the vulnerability. Mail servers verify the address on the envelope, but the user sees the address from the header.
2. The Vulnerability: SPF Bypass
Most administrators believe that deploying an SPF (Sender Policy Framework) record protects their domain. Unfortunately, SPF only checks the envelope address (Envelope From).
An attacker exploits this as follows (so-called SPF Misalignment):
What does the recipient’s server see? The server checks SPF for the envelope domain (attacker-domain.com). The IP address of the attacker’s server matches the SPF record of the attacker’s domain. Result: SPF PASS.
What does the victim see? The victim opens the email and sees the header: From: security@big-polish-provider.pl. Because SPF passed (for the technical domain), the email lands in the inbox rather than in spam.
- The attacker sets up their own mail server and attaches a domain they control to it (e.g. attacker-domain.com).
- In the DNS configuration for attacker-domain.com they set a valid SPF record authorizing their server to send.
- As the Envelope From they set admin@attacker-domain.com.
- As the Header From (what the victim sees) they set security@big-polish-provider.pl.
3. Where Is DMARC?
Here we get to the heart of the problem at many Polish providers. The DMARC protocol was created precisely to tie these two layers together. It enforces so-called Alignment: the domain in the "From" header must match the domain verified by SPF (or DKIM).
So why does the attack work?
Because DMARC is only effective when its policy is set to p=reject or p=quarantine.
4. Attack Simulation (SMTP Flow)
If we looked "under the hood" and connected to the mail server via telnet/netcat, the attack would look like this:
In the example below, the Interia server queries DNS for the SPF record of attacker-domain.com. Everything will check out. If interia.pl has no strict DMARC, the mail client will show the employee a forged sender without any warnings.
Analysis Summary
The vulnerability does not stem from a software bug, but from a configuration and protocol-logic flaw. It is a classic example of technical debt, where the absence of a p=reject policy in the DMARC record at large providers opens the door to trivial impersonation of their domains.
Conclusions
Below is the original response from the Interia team dated 29 September 2024, summarizing the whole matter and reporting the changes made. It serves as an excellent summary of the entire blog post.
Information about the report and the start of work
On 30 April 2024, an independent researcher reported by email potential security flaws concerning the handling of the SMTP protocol and the DMARC policy in the Interia.pl mail service. The report was accepted for analysis, and work on assessment and developing appropriate fixes began in May 2024. The team responsible for the mail infrastructure, together with the security team, took action aimed at securing the reported areas while preserving functionality for users.
Reported issues
The independent researcher identified two potential security issues:
- DMARC Policy is set to "none," which means there is no strict verification of the authenticity of email senders. This state of affairs may allow the sending of messages impersonating other email addresses, without the restrictions imposed by a more restrictive DMARC policy.
- There is a possibility of email spoofing — impersonating other email addresses by manually altering the FROM header (RFC5322.From) when using the SMTP protocol. This issue may lead to malicious activity, such as sending messages suggesting they were sent by a different sender.
Fixes implemented
After a thorough analysis of the report and internal verification, the following changes were introduced to add extra safeguards in the reported areas:
- The ability to impersonate other email addresses was blocked when using the SMTP protocol. Verification mechanisms were applied on the mail server side that prevent manual manipulation of the FROM header, thereby preventing spoofing.
- Security was strengthened in the web mail client, blocking attempts to impersonate other email addresses. As a result, users of the webmail service can no longer attempt to impersonate other accounts, whether within the interia.pl domain and its subdomains or external email addresses.
In addition, work is underway on visual improvements that will make it easier for users to identify spoofing, phishing, and scam messages by presenting the envelope sender address to the user in the web panel. The planned rollout is scheduled for November.
Elements not implemented
Despite implementing many safeguards, the DMARC Policy remains set to "none." The decision to keep this setting stems from concern for our users. Implementing a more restrictive DMARC policy could result in the rejection of important messages in cases where recipients’ servers are misconfigured. CERT Polska likewise treats the "none" policy not as an error, but merely as a warning (https://bezpiecznapoczta.cert.pl/).
Summary
With regard to the report concerning the RFC5322.From header, which may lead to certain security implications, we want to emphasize that this was not a direct flaw in the Interia.pl mail service, but in the widely used, though sometimes controversial, internet message standard. The handling of these headers complied with the SMTP protocol and the RFCs and was required by all popular mail clients.
The team responsible for the mail infrastructure and the security team made every effort to eliminate the possibility of spoofing in Interia.pl mail, thereby providing a high level of protection for users against potential threats, while striving to maintain the greatest possible compliance with the RFC standards and the operating principles of commonly used mail protocols.
Summary
The vulnerability does not stem from a software bug, but from a configuration and protocol-logic flaw. It is a classic example of technical debt, where the absence of a p=reject policy in the DMARC record at large providers opens the door to trivial impersonation of their domains. Cooperation with the Interia team and CERT Polska led to the deployment of fixes that protect users.
Timeline
First contact
The first message notifying the Interia.pl team of the possibility of spoofing the SMTP sender.
Request for vulnerability details
A point of contact was designated for further correspondence.
Report sent
A detailed report was sent allowing the vulnerability to be reproduced step by step.
Responsible disclosure
A question about the Interia team’s approach to the responsible disclosure process.
It's not a bug, it's a feature :)
Feedback received that, after a thorough analysis by the Interia team, the reported flaw was not deemed significant. Arguments and conclusions from the analysis were presented.
I object!
Objection to the Interia team’s analysis and reaffirmation that the security flaw exists. Additional details were sent as a counterargument for the Interia team.
Objection upheld
The security report was accepted again, with a statement of further analysis.
Request for a status update
"Implementation work is in progress"
Vulnerability reported to CERT Polska
Confirmation of receipt
A statement that an attempt would be made to contact the Interia team.
They’ll fix it, they will
Information that the Interia team plans to roll out improvements by early September.
Update, please
A request to CERT Polska for a status update. Information about the planned disclosure in the coming week.
Any minute now…
Contact with the Interia team. Information from the Interia team that fixes are still being rolled out. A request to postpone the responsible disclosure.
Postponing!
Agreement to postpone the responsible disclosure until 1 November 2024.
Roger that, over
Confirmation of receipt and forwarding of the message to the Interia team.
Changes, people, changes!
A summary of the whole matter. Information about the changes made by the Interia team.
Summary
A summary of the whole matter (a forward of the message from the Interia team).
Responsible disclosure
Public disclosure of the vulnerability details after the fixes were deployed by the Interia team.
Bibliography
The SMTP protocol specification defining the Envelope From (MAIL FROM) mechanism used in email routing.
The email message format standard defining the Header From, which is displayed to the end user in the mail client.
The specification of the SPF mechanism that allows verifying whether a given server is authorized to send mail on behalf of a domain. It defines the limit of 10 DNS lookups.
The specification of the DMARC protocol combining SPF and DKIM with an alignment mechanism that enforces consistency between the domains in the envelope and the message header.
A CERT Polska tool for verifying the email security configuration of Polish domains (SPF, DKIM, DMARC).
One of the largest Polish email services, in which the described SMTP spoofing vulnerability was found.
A step-by-step guide demonstrating how to identify a vulnerable domain, set up the infrastructure, and successfully spoof an email address, bypassing gaps in protections such as SPF and DMARC.
A section of the article explaining how cybercriminals bypass SPF protections, exploiting the absence of a strict DMARC policy to successfully forge the email sender.
A practical guide describing email spoofing techniques and the mechanisms that protect mail against this phenomenon.