Email spoofing: why your domain is a target and how to stop it
Email spoofing: why your domain is a target and how to stop it
When a trusted sender name hides a hostile messageEmail spoofing is the art of forging the sender identity so that a message appears to come from your...
When a trusted sender name hides a hostile message
Email spoofing is the art of forging the sender identity so that a message appears to come from your company, your bank or a public body. The person receiving it sees a familiar name in the inbox and lowers their guard. Behind that name, however, there may be a phishing campaign, a fraudulent invoice or a link to a credential-harvesting page. For businesses in Barcelona, Lleida, Tarragona or Girona, the damage is rarely limited to the person who clicked: it hits the reputation of the domain, the trust of clients and, in many cases, the compliance obligations under GDPR.

The root of the problem is old and structural. The SMTP protocol, which still moves most of the world's email, was designed without built-in sender verification. Any server can claim to send messages on behalf of any domain unless that domain publishes rules that receiving servers can check. That is why spoofing does not require breaking into an account or stealing a password: the attacker simply builds a message with a false sender header and hands it to a mail server that accepts it.
Two addresses, one weak point
Every email carries at least two different sender addresses, and spoofing exploits the gap between them. The envelope sender, visible in the Return-Path header, is used by mail servers to route the message and handle bounces. The From header is what the recipient actually sees in their inbox. The second is little more than a line of text, and the sending server is not obliged to prove it has the right to use it.
This separation explains a common symptom: organisations often discover their domain is being abused indirectly, through bounce messages for emails they never sent, complaints from clients about fake invoices, or a sudden drop in deliverability as the domain's reputation deteriorates. No system has been breached, yet the brand is already paying the price.
SPF, DKIM and DMARC: three layers, one goal
The defence against spoofing rests on three complementary standards that receiving servers use to decide whether a message is legitimate:
- SPF (Sender Policy Framework): a DNS record that lists which servers are authorised to send email on behalf of your domain. If a message arrives from an IP that is not on the list, the check fails.
- DKIM (DomainKeys Identified Mail): a cryptographic signature added to outgoing messages. The receiving server verifies it against a public key published in DNS, confirming that the message was not altered in transit.
- DMARC (Domain-based Message Authentication, Reporting and Conformance): the policy layer that tells receiving servers what to do when SPF or DKIM fail — monitor, quarantine or reject — and sends you aggregate reports so you can see who is sending email in your name.
Deploying all three is not a one-off task. SPF records need to be kept short and accurate, especially when you rely on external platforms for invoicing, newsletters or transactional email. DKIM keys must be rotated. DMARC should start in monitoring mode, with reports reviewed regularly, before moving to a strict rejection policy. Rushed enforcement can block legitimate mail, so a gradual rollout with careful observation is the safer path.
How to check whether a message has been forged
When a suspicious email arrives, the inbox view tells you very little. The real evidence is in the headers. In Gmail, open the message, use the three-dot menu and choose the option to show the original. In Outlook, go to File, then Properties, and open the internet headers. Look for the Authentication-Results line: if SPF, DKIM or DMARC show a failure, the sending server was not authorised by the domain in the From address. A Return-Path that differs from the visible From address is a frequent warning sign, although some legitimate bulk-sending services also produce that difference. Received headers pointing to infrastructure unrelated to the supposed sender are another strong red flag.
If your own domain is being spoofed, DMARC aggregate reports are the fastest way to confirm it and to identify which IP addresses and services are sending mail in your name. Without that visibility, you are effectively flying blind.
Beyond email: the server layer matters too
Email authentication stops forged messages from reaching inboxes, but it does not stop the infrastructure behind a campaign from probing your servers. Phishing waves are usually accompanied by scanning, brute-force attempts against mail and web services, and repeated connections from IP ranges with a poor reputation. This is where host-level protection complements DNS-based defences.
At ALMC we work with Abuse Shield, a service that centralises server protection: it blocks malicious IPs automatically, manages fail2ban across multiple machines and shares an IP reputation feed between all the servers in your fleet. For system administrators, hosting companies and SMEs with their own servers, the advantage is consistency. When one machine detects an abusive source, the rest learn about it immediately, so an attack that starts against a test server does not get a second chance against production. Combined with SPF, DKIM and DMARC, this layered approach reduces both the volume of forged mail and the exposure of the servers that send and receive it.
A practical checklist for Catalan and Spanish businesses
- Publish an SPF record that lists only the services you actually use, and review it whenever you add a new provider.
- Enable DKIM signing on every domain and subdomain that sends email, including invoicing and marketing platforms.
- Start DMARC in monitoring mode, read the reports and move to a quarantine or reject policy once legitimate traffic is confirmed.
- Monitor server logs for repeated failed authentication attempts and block abusive IP ranges at the host level.
- Train staff to check headers when a message looks unusual, and document an internal procedure for reporting suspected fraud.
- Keep a record of the measures in place: under GDPR, demonstrating technical safeguards is part of accountability.
Spoofing thrives on the gap between what an email claims to be and what can be verified. Closing that gap with authentication standards, and reinforcing it with disciplined server protection, is one of the most cost-effective security investments a small or mid-sized organisation can make.
Related
- How to Harden Your Servers with Fail2ban and IP Reputation Feeds
- Fail2ban: Your First Line of Defense Against Unauthorized Server Access
- Critical libssh2 flaw: urgent patch for SSH servers
- Desarrollo web
Put these ideas into practice
Talk to ALMC about a solution for your business. Explore your options or contact our team.
