E-mail has remained both one of the oldest and most exposed channels of business communication for years. The SMTP protocol was created in a time when the internet assumed trust between the sender and the recipient. Today the reality is different. Attackers use email messages to take over accounts, extort payments, steal data and manipulate employees. According to many analyses, more than 90 percent of successful attacks start with an email message. Email has become a convenient tool for business email compromise attacks where an attacker impersonates an employee, a manager or a business partner.

The biggest problem is that most users see only the padlock icon and the information about an encrypted connection. TLS is interpreted as full security, which is a fundamental misunderstanding. Transport encryption does not indicate who actually sent the message, whether the content remained intact or whether the sender is who they claim to be. TLS operates only in the transport layer. Every spoofed email will still be delivered over TLS, so the user believes it is safe.

To understand why email protection requires several independent layers, it is necessary to distinguish between domain authorization, user authenticity and message confidentiality. DKIM and DMARC protect the domain but not the user. S/MIME protects the user but not the domain. TLS protects the transmission between servers but does not protect the sender or the content against forgery. Only the combination of these technologies forms a system resistant to phishing and both internal and external spoofing.

1. Technical differences: how do DKIM, DMARC and S/MIME work?

DKIM (DomainKeys Identified Mail): domain-level signature.

DKIM adds a cryptographic signature to selected headers and parts of the message body. The private key is held by the sending server and the public key is published in DNS. The recipient verifies the signature and checks whether the message was sent by a server authorized by the domain owner. DKIM does not confirm the identity of the individual sending the message. It protects the domain’s reputation and ensures that the message was not altered in transit.

DKIM does not inform the user in any visible way about the validation result. The process works in the background. When DKIM fails or is misaligned, most systems still deliver the message and only lower its deliverability score. This is why DKIM without DMARC changes very little.

DMARC (Domain-based Message Authentication, Reporting and Conformance): domain policy.

DMARC publishes the domain’s policy and defines what the receiver should do when a message fails authentication. DMARC requires that the From: header aligns with the authentication domain. If DKIM or SPF do not align, DMARC allows the message to be rejected or placed in quarantine. In practice, DMARC protects an organization against spoofing of its domain.

The biggest issue in practice is the policy p=none. Companies often hesitate to use p=reject because they fear losing deliverability. This is a mistake. As long as DMARC is set to none, attackers can impersonate the domain and send messages that appear partially legitimate to receivers.

S/MIME (Secure/Multipurpose Internet Mail Extensions): user-level signature and message encryption.

S/MIME works very differently from DKIM and DMARC. It signs the message with the sender’s private key and allows the recipient to verify the identity of the sender. The S/MIME signature is something that the user can actually see in the interface. Outlook, Apple Mail and even Gmail display the digital signature as an icon or a notice. This allows the recipient to distinguish genuine correspondence from fraudulent messages.

S/MIME also enables message encryption. If both parties have certificates, their messages can be encrypted so that even mail server administrators cannot read them. This is important in regulated environments where personal or sensitive data must be protected.

2. Technical implementation in corporate environments.

Postfix

DKIM configuration:

smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891
milter_default_action = accept
milter_protocol = 2

OpenDKIM:

Domain example.com
KeyFile /etc/opendkim/keys/example.com/default.private
Selector default
Socket inet:8891@localhost

DMARC DNS:

v=DMARC1; p=reject; rua=mailto:[email protected]

S/MIME on clients:

• import the PFX certificate into Thunderbird or Outlook
• enforce signing of every message in the client settings

Exchange Online / Microsoft 365

DKIM:

Set-DkimSigningConfig -Identity example.com -Enabled $true

DMARC is configured only via DNS.

S/MIME:

• certificates installed locally or published via GPO
• Outlook policy:
  User Configuration -> Outlook -> Security -> S/MIME Settings
• rules for automatic signing of messages

Google Workspace

DKIM:

Admin Panel → Gmail → Authenticate email

DMARC:

v=DMARC1; p=reject; rua=mailto:[email protected]

S/MIME (Enhanced):

• administrator imports user certificates
• Gmail automatically recognizes signatures and encrypts content
• signing can be enforced for all users

3. Case studies from real-world corporate scenarios.

Case 1: SaaS company (200 employees).

The company operates a B2B platform. Their problem was fraudulent invoices and registration messages sent by attackers impersonating their domain. Clients reported these incidents as fraud committed by the company.

Analysis:

• DKIM configured but DMARC set to p=none
• no S/MIME in internal communication
• billing system forwarding broke SPF

After implementation:

• DMARC p=reject
• DKIM key rotation
• SPF flattening
• S/MIME for the finance team

Effect:

• spoofing incidents dropped to zero
• clients receive only authenticated messages
• internal financial confirmations are digitally signed

Case 2: Local bank (450 employees).

The bank was a target of CEO fraud attacks. Attackers sent emails appearing to come from the CEO, requesting urgent transfers.

Analysis:

• DMARC was set to quarantine
• no S/MIME
• attackers used another domain with the CEO’s display name

After implementing S/MIME:

• all management emails must be signed
• every employee sees the signature status
• fake CEO emails became immediately recognisable

The bank recorded a drop in attack attempts of more than 95 percent.

Case 3: Accounting firm (50 employees).

The main issue was invoice interception. Attackers modified PDF invoices and sent new ones with altered bank account numbers. Employees could not tell authentic documents from fraudulent ones.

Implementation:

• full S/MIME deployment for signing all invoices
• automatic signature validation on the recipient side
• DMARC p=reject

Result:

• all fraudulent invoices rejected before reaching inboxes
• accountants see signature validity immediately
• clients also started requiring signed documents

Case 4: Medical facility (regional hospital, 1200 employees).

The hospital exchanges sensitive data between doctors, laboratories, registration desks and external partners. After an incident where an attacker impersonated a radiologist and sent a falsified medical result, the management decided to implement S/MIME.

Analysis:

• DMARC set to none, enabling domain spoofing
• no S/MIME user signatures
• some messages contained sensitive data
• HIS system forwarding caused SPF misalignment
• doctors used multiple devices including mobile phones

Solution:

• mandatory S/MIME signatures for doctors, nurses, labs and administration
• DMARC set to p=reject
• certificate integration with MDM for mobile devices
• certificate rotation every 12 months

Effects:

• all medical documents are digitally signed
• risk of falsified medical results eliminated
• patients receive authentic referrals and confirmations
• IT can revoke certificates automatically when an employee leaves

This shows that in the medical sector S/MIME is not a luxury but a necessity. Medical data is highly sensitive and carries significant legal and reputational risk.

Case 5: IT outsourcing company (300 employees, multiple clients).

The company manages servers, provides helpdesk and supports cloud environments. The highest risk involved email communication about access credentials, temporary passwords and operational instructions.

Incident:

An attacker impersonated an employee and sent a message to a client urging access changes. The client followed the instructions, which resulted in unauthorized access to a production system.

Analysis:

• DKIM configured but DMARC soft-fail
• no S/MIME, so the client could not distinguish genuine messages
• company operates multiple domains depending on projects
• no centralized certificate management

Implementation:

• full S/MIME for all technical staff
• mandatory signatures in communication with clients
• DMARC p=reject
• internal CA for internal communication between teams
• S/MIME integrated into helpdesk systems such as Freshdesk and Jira SM

Results:

• clients can instantly verify sender identity
• false instructions never pass validation
• company gained competitive advantage through enforced signatures
• phishing attempts reduced by more than 90 percent

This confirms that in outsourcing environments digital signatures are not an add-on but the foundation of trust.

4. FAQ.

Does TLS alone secure email?
No. TLS only encrypts the transport. It does not protect sender identity or message integrity.

Does DKIM ensure that a message comes from a specific employee?
No. DKIM signs the domain, not the user. S/MIME signs the user.

Does S/MIME work with Gmail and Outlook?
Yes. Gmail supports Enhanced S/MIME and Outlook fully supports S/MIME.

Can DMARC harm deliverability?
Yes, if the domain is misconfigured. With correct configuration p=reject improves both security and deliverability.

Can S/MIME be automated?
Yes. It can be centrally managed via Azure AD, MDM or internal PKI.

Does DMARC protect against internal spoofing?
No. This requires S/MIME.

Is message encryption needed or is signature enough?
In most companies signature is enough. In regulated industries encryption is recommended.

Is S/MIME difficult for end users?
No. After deployment the signing process is automatic.

5. Most common organizational mistakes.

1. Treating TLS as full email protection.

TLS does not protect the sender or the content. It encrypts only the transport layer. Any spoofed email is still sent over TLS.

2. Using DKIM without DMARC or DMARC set to p=none.

DKIM is ineffective without DMARC enforcing policy. p=none provides only reporting and blocks nothing.

3. Relying on SPF as the only protection.

SPF is vulnerable to forwarding and does not provide From: alignment. SPF alone does not stop spoofing.

4. No S/MIME in internal communication.

More than half of serious business email compromise incidents occur internally. Without S/MIME employees cannot recognise forged messages.

5. S/MIME certificates without centralized management.

Without rotation, revocation and MDM/AD integration organizations quickly lose control over identity.

6. Ignoring DMARC reports.

DMARC reports highlight unauthorized senders, SPF alignment issues and domain abuse.

7. No penetration testing on email layer.

Companies often test web apps but ignore email spoofing scenarios that can be executed in minutes.

8. Partial S/MIME deployment.

Attackers target the weakest link. S/MIME should be deployed company-wide.

9. Incorrect handling of forwarding and mailing lists.

Forwarding and mailing lists often break SPF and DKIM, causing DMARC rejections.

10. No DKIM key rotation and outdated key lengths.

1024 bit DKIM keys are outdated and risky.

11. No S/MIME encryption in regulated industries.

Medical, financial and legal sectors require encryption for sensitive messages.

6. Conclusions.

Business email security is not a single mechanism but a layered architecture. TLS protects transport but not sender identity. DKIM signs the domain but not the user. DMARC defines domain-level policy and blocks spoofing, but only S/MIME ensures that the sender is authentic and the content remains intact. In practice each layer solves a different problem and their importance becomes clear only when a real incident occurs. Companies that implement only part of the mechanisms discover quickly that attackers can leverage the remaining gaps. Incidents with internal spoofing, invoice manipulation or compromised financial communication show that without S/MIME not even experienced administrators can reliably distinguish real messages from fraudulent ones.

When deployed together, these layers form a predictable and resilient communication system. The sender signs the message with S/MIME, the server adds DKIM, the transport is encrypted via TLS and the receiving server enforces DMARC. The recipient can validate both the user and the domain. Each layer strengthens the next, resulting in communication that is consistent, verifiable and resistant to manipulation.

Email is often treated as a simple operational tool, yet a single mistake can result in reputational damage, financial loss or regulatory exposure. Organizations that implement full email protection gain stability, trust and resilience. Combining DMARC, DKIM, SPF, TLS and
S/MIME is the most practical and measurable way to protect a critical communication system used every day.

Check our S/MIME certificates: S/MIME Certificates

Do you have questions about which solution is best for your company? Contact our sales team.