Email Security

Email Security: The Complete Guide for Enterprise Email Protection

This page brings together everything you need to know about corporate email security: email threats, authentication protocols (SPF, DKIM, DMARC), transport security (MTA-STS, TLS-RPT), encryption (S/MIME, PGP), architecture options and the Check Point product family. After scanning hundreds of domains in the field, the pattern we keep seeing is this: most organisations buy a product but never build a layer stack. That is the argument of this guide — email security is not one product but a four-layer architecture, and if one layer is missing the other three will not save you.

What is email security?

Email security is the combination of technology, process and training used to protect corporate email accounts, messages and attachments against unauthorised access, impersonation, data loss and malicious content. Its scope runs in three directions: inbound traffic (phishing, malware, ransomware), outbound traffic (data leakage, impersonation of your domain) and internal traffic (attacks spreading from a compromised account to colleagues).

A common misconception: "We use Microsoft 365, so our email is secured." The built-in filters of Microsoft 365 and Google Workspace are good at mass spam and known malware; by design they are weak against targeted business email compromise (BEC), account takeover (ATO) and internal traffic. We covered this in depth here: API-based vs gateway email security · Why Microsoft 365 built-in email security falls short.

Why is email still the number one attack surface?

SMTP does not verify that a sender is who they claim to be. That design gap has not closed since the 1980s; SPF, DKIM and DMARC are patches layered on top of it. The consequence: an attacker does not need a zero-day to knock on your door — a well-timed message written in the right tone is enough.

Three factors make it worse in the field:

• AI-written text. Spelling mistakes and clumsy grammar are no longer diagnostic. The reflex "we can spot a badly written email" has stopped working.
• Authentication can pass and the attack still lands. A message sent from a genuinely compromised account passes SPF, DKIM and DMARC. Authentication tells you the identity is real; it says nothing about intent.
• Supply chain risk. Even with strong infrastructure of your own, your supplier's compromised mailbox arrives in your inbox as a legitimate message.

The four layers of email security

This is the framework to use when evaluating a proposal or auditing your current setup. Each layer asks a different question.

1. Identity layer — "Did this message really come from that domain?"

SPF, DKIM, DMARC, BIMI and ARC live here. The goal is to stop others impersonating your domain and to verify the origin of messages you receive. This layer is built in DNS, needs no licence and costs close to nothing — which is exactly why it is the most neglected one. Setup guide: SPF, DKIM, DMARC and BIMI setup guide.

2. Transport layer — "Can the message be intercepted in transit?"

In SMTP, TLS is opportunistic: servers encrypt if they can negotiate it and fall back to plaintext if they cannot. An attacker in the middle can break that negotiation (downgrade) and expose the traffic. MTA-STS makes TLS mandatory; TLS-RPT reports failed attempts. DANE and DNSSEC offer a stricter alternative. Detail: MTA-STS and TLS-RPT for email transport security.

3. Content and behaviour layer — "What is this message trying to do?"

Phishing, quishing, malicious attachments, ransomware, fraudulent payment instructions and account takeover are caught here. Authentication is blind to most of these; this layer needs AI-based content analysis, sandboxing, click-time URL inspection and behavioural anomaly detection. The case that best captures this whole layer is account takeover; the full analysis is here: Account takeover (ATO) and email security.

4. Outbound and human layer — "What is leaving, and who is clicking?"

The most neglected direction of email is outbound: wrong recipient, forwarding to a personal address, a departing employee taking data, silent exfiltration from a compromised account. DLP, archiving and security awareness training (SAT) build this layer. Related: DLP, KVKK and email data loss prevention · Phishing simulation and security awareness training.

Email threat glossary

• Phishing: A deceptive message designed to send the user to a fake page and steal credentials or payment details.
• Spear phishing: Phishing personalised to a specific person, their role and their current work.
• Whaling: Spear phishing aimed at senior executives.
• BEC (business email compromise): A request for a payment or a bank account change, impersonating an executive, a supplier or finance. The most financially damaging email attack type. → BEC and CEO fraud
• ATO (account takeover): Mailbox access using a stolen password or session cookie. The attack no longer comes from "outside" but from "inside".
• Quishing (QR code phishing): The malicious link hidden inside a QR code; the user scans it on a phone rather than a managed device, bypassing controls. → Quishing guide
• Smishing / vishing: Social engineering over SMS and phone, usually the second leg of an email attack.
• Spoofing: Faking the sender address. Largely closed by DMARC at p=reject.
• Look-alike domains: Variants such as kinetikbilisim.co instead of kinetikbilisim.com — one character short, and the eye skips over it. Registering your own extensions (.com, .com.tr, .net) and redirecting the unused ones to your primary domain closes most of this risk.
• Ransomware: In most incidents the initial entry point is an email attachment or a phishing link.
• Malicious attachments and zero-days: Files no signature-based engine recognises; sandboxing is required.
• Spam: No longer the real risk, just the noise — although false positives in spam filtering do cost business.

Email security technology glossary

• SPF (Sender Policy Framework) — RFC 7208, 2014: Declares in a DNS TXT record which servers may send mail on behalf of your domain. Forwarding always breaks SPF; watch the ten DNS lookup limit — a Mailskop scan shows your current lookup count directly.
• DKIM (DomainKeys Identified Mail) — RFC 6376, 2011: Signs the message with a private key; the recipient verifies it against the public key in DNS. Proves the content was not altered in transit.
• DMARC — RFC 9989 (core), RFC 9990 (aggregate reporting), RFC 9991 (failure reporting), May 2026: Reads SPF and DKIM results, requires alignment, and states what to do on failure: p=none → p=quarantine → p=reject. Aggregate reporting (rua) shows who is sending mail as your domain. Critical point: a DMARC record left at p=none provides observation, not protection.
  2026 update: RFC 7489 (2015, Informational), the specification for eleven years, was replaced in May 2026 by three new RFCs, and DMARC was promoted to Proposed Standard for the first time. Most of your record stays valid — v=, p=, sp=, rua=, adkim= and aspf= keep their meaning. But pct=, rf= and ri= are deprecated; remove them at your next DNS edit. Organizational domain boundaries are now determined by a DNS tree walk instead of the Public Suffix List.
• BIMI — not an RFC yet, still an IETF draft: Displays your brand logo in the inbox; it requires DMARC at reject. Its value is trust and brand rather than security.
• ARC (Authenticated Received Chain) — RFC 8617, 2019: Seals and carries authentication results that forwarding would otherwise break. It provides a trail, not trust. → ARC and forwarding authentication
• MTA-STS — RFC 8461, 2018: Enforces TLS through a .well-known/mta-sts.txt policy file and an _mta-sts TXT record. Start in testing, then move to enforce.
• TLS-RPT — RFC 8460, 2018: Collects daily reports of failed TLS negotiations via the _smtp._tls TXT record.
• DANE and DNSSEC — DANE: RFC 6698 (2012) with the SMTP profile in RFC 7672 (2015); DNSSEC: RFC 4033–4035 (2005): Bind the server certificate to DNS by signing DNS responses. Stricter than MTA-STS, and more work to deploy.
• S/MIME — RFC 8551, 2019: Certificate-based end-to-end signing and encryption. TLS protects the road; S/MIME seals the envelope. → S/MIME and PGP encryption guide
• PGP / OpenPGP — RFC 9580, 2024: The web-of-trust alternative to S/MIME, without a central authority.
• KEP: Turkey's registered electronic delivery channel for legal notices — not an encryption technology. Do not conflate the two.
• MFA: The single highest-return control against ATO. Modern kits that steal session cookies can bypass it, which is why behavioural detection is still needed.
• Sandboxing: Detonates the attachment in an isolated environment and judges it by behaviour, catching threats with no known signature.
• Click-time URL protection: The link is scanned on arrival as usual; the difference here is that it is checked again at the moment the user clicks — defeating the "clean first, malicious later" tactic.
• DLP (data loss prevention): Identifies sensitive data in outbound messages and blocks or encrypts it.
• Archiving: Immutable records for compliance audits and legal proof.
• SAT and phishing simulation: Measurement of the human layer. The right metric is not the click rate but the report rate and reporting speed.

Where does your own domain stand? Scan it with Mailskop

Reading a list like the one above raises one immediate question: "Which of these do we actually have?" For years we answered it by moving between MXToolbox, separate DMARC lookups and report parsers. Eventually we built our own tool.

Mailskop is the free email security scanner developed by Kinetik Bilişim. Enter a domain and you get:

• SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, DNSSEC and DANE records on a single screen
• Every finding with what it means and how to fix it, not just a present/absent flag
• A measurable configuration hygiene score, so you can re-scan quarterly and track progress
• Bulk lookup for tens or hundreds of domains at once — group companies, suppliers, acquired brands. No need to reformat your list into a template, tidy columns or clean it up first: paste it however it already looks and Mailskop handles the rest

In practice, the day 0–15 inventory step of the 90-day plan on this page starts with a single Mailskop scan. You do not need to talk to us to run it; we are here if you want help interpreting the result.

Three architectures: gateway, built-in and API-based

• Secure Email Gateway (SEG): The MX record points at the gateway and traffic is filtered there first. The classic model. Its weakness: it only sees inbound traffic. A message sent from a compromised internal account to a colleague never reaches the gateway.
• Built-in protection (Microsoft 365 / Google Workspace): No extra cost and effective against mass threats. It falls short on targeted BEC, ATO and internal spread — and attackers know these filters better than anyone, testing directly against them.
• API-based protection: The MX record stays untouched; the solution connects to the mail platform through its API. It sees inbound, outbound and internal traffic, can scan historical mail, and can pull an already delivered message back out of the inbox. Deployment takes minutes and puts no mail flow at risk.

Our recommendation is clear: for an organisation on Microsoft 365 or Google Workspace, the right architecture is API-based. Consider a gateway only where a specific constraint such as on-premise Exchange demands it.

Email security solutions with Check Point

Kinetik Bilişim is a Check Point Advanced Partner holding Solution Specializations in Email, Endpoint & Browser, Mobile and SASE. The products we position for email security:

Check Point Email Security (formerly Harmony Email & Collaboration, originally Avanan)

Our lead product. It is API-based: the MX record does not change and deployment never interrupts mail flow. It runs more than 50 AI engines backed by ThreatCloud AI threat intelligence, with published detection rates of 99.9% for malware and 99.7% for phishing. More than 65,000 organisations use it, and the solution is a Leader in the 2025 Gartner Magic Quadrant for Email Security.

• Full visibility of inbound, outbound and internal email traffic
• Look-alike domain detection and brand impersonation analysis
• Sandboxing, click-time URL protection, attachment sanitisation
• DMARC Management module that turns raw reports into something readable
• SAT (awareness training and phishing simulation), Archiving, Leaked Credentials, SSPM and Incident Response modules
• Covers collaboration apps such as Teams, SharePoint, OneDrive, Google Drive and Slack
• Processes metadata only — an architecture you can defend under KVKK and GDPR

Gartner, Magic Quadrant for Email Security, Max Taggett, Nikul Patel, 1 December 2025. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. GARTNER and MAGIC QUADRANT are registered trademarks of Gartner, Inc. and/or its affiliates.

Product detail: Check Point Email Security · Why Microsoft 365 built-in email security falls short

Check Point Mobile Security (formerly Harmony Mobile)

Most corporate email is now read on a phone. A small screen, shortened URLs and divided attention make mobile phishing more convincing than its desktop equivalent. Mobile Security protects four vectors: apps, files, network and operating system. The key distinction: MDM manages, Mobile Security protects — they are layers, not competitors. Detail: Check Point Mobile Security

Complementary products

• Harmony Endpoint: EPP, EDR and XDR in a single client — the last stop for a threat that made it past email.
• Harmony Browse: Where protection extends beyond the corporate mailbox. A malicious link that lands in an employee's personal email account is invisible to your email security, yet it opens on the same device — Browse catches it at the browser layer. Its second function is identity: it detects and blocks reuse of a corporate password on an external site, breaking the account takeover chain at its very first link.
• Harmony SASE: Secure access and an enterprise browser for remote workers.
• Quantum firewalls: The network layer, sharing threat intelligence with email security. We cover this side under our network security service.
• ThreatCloud AI: The shared intelligence engine behind every product. A new phishing campaign seen at one customer is blocked across all deployments within minutes.

How to choose the best email security software: a ten-question checklist

• Does the solution see internal email traffic, or only what arrives from outside?
• Does deployment require an MX change? If so, what is the rollback plan?
• Can it claw back a message that has already been delivered?
• Does it detect account takeover behaviourally, or does it only read authentication results?
• Is there a module that makes DMARC reports readable?
• Are outbound DLP and archiving included, or separately licensed?
• Are collaboration apps such as Teams, SharePoint and OneDrive covered?
• What data does it process and where is it stored? Is that defensible under KVKK and GDPR?
• What is the false positive rate? Can users manage their own quarantine?
• Is there local technical and deployment support in your country?

Ask these ten questions of every proposal. If half the answers come back as "add-on module", the prices you are comparing do not describe the same thing.

Email security best practices

• Start DMARC at p=none, read the reports, and reach p=reject within 90 days. Staying at none is not protection.
• Consolidate SPF into a single record and stay under the ten DNS lookup limit. Do not guess where you stand: a Mailskop scan reports your current lookup count. A record that exceeds the limit silently returns permerror and SPF behaves as if it were never there.
• Use a separate DKIM selector per sending service and keep keys at 2048 bits or above.
• Publish v=spf1 -all and p=reject for non-sending and parked domains too — they are the easiest impersonation targets you own.
• Publish MTA-STS in testing first, feed TLS-RPT reports into a system, then switch to enforce.
• Enforce MFA for all users and hardware keys for administrators.
• Disable legacy authentication protocols (POP3, IMAP basic auth).
• Make out-of-band verification of payment and bank detail changes a written policy — by phone, using the number on record, never the one in the email.
• Monitor mailbox forwarding rules; the first sign of ATO is usually a rule added quietly.
• Review the last 30 days of outbound traffic for every departing employee.
• In phishing simulations, target high and fast reporting rather than low clicks.
• Re-scan your domain hygiene quarterly; DNS records decay silently.

A 90-day email security maturity plan

• Days 0–15 — Inventory. List every domain and subdomain, scan current SPF/DKIM/DMARC/MTA-STS status, and enumerate every service that sends mail as you (ERP, CRM, invoicing, marketing tools). Publish DMARC at p=none with rua.
• Days 16–45 — Clean-up. Align the legitimate senders in your reports, shut down unauthorised sources, simplify SPF, enable DKIM for every service. If the same fixes have to land across several domains, use our bulk DNS update tool Specula instead of editing records one by one — it saves hours on group companies and parked domains. In parallel, start a pilot of API-based email security — there is no risk because the MX record does not change.
• Days 46–75 — Hardening. Move DMARC to quarantine, then reject. Publish MTA-STS in testing. Enforce MFA and disable legacy protocols.
• Days 76–90 — People and process. Run the first phishing simulation, write down the out-of-band verification policy, enable DLP rules, move MTA-STS to enforce. Then institutionalise measurement: a monthly DMARC review and a quarterly re-scan.

Compliance: KVKK and GDPR

A data leak over email creates three separate obligations under Turkey's KVKK, closely mirrored by GDPR: notification (to the authority and to the data subject), technical and organisational measures (which must already have been in place) and the burden of proof (being able to demonstrate that they were). In practice the third is hardest: without logs and archives you cannot evidence the measure you took.

That is why we position DLP and archiving as compliance items rather than "nice to have later". Detail: DLP, KVKK and email data loss prevention · our KVKK compliance service. The information on this page is general and does not constitute legal advice.

Email security by industry

Every sector has its own attack script: fake proforma invoices in manufacturing, time-zone gaps in maritime, "the global brand asked for it" pressure in textiles. Our sector analyses:

• Manufacturing · Automotive · Machinery · Iron & steel · Aluminium
• Construction · Logistics · Maritime · Energy
• Food & FMCG · Textile & apparel · Insurance & finance · Holding structures

Everything we have written on email security in one place: Email Security blog category.

Frequently asked questions

What is email security, in one sentence?

Protecting the inbound, outbound and internal directions of corporate email traffic through layers of authentication, transport encryption, content analysis and data loss prevention.

Is Microsoft 365 email security enough?

For mass spam and known malware, yes. For targeted BEC, account takeover and internal traffic, no — it cannot see those scenarios by design. An additional layer is required.

What is the difference between SPF, DKIM and DMARC?

SPF says which server is authorised, DKIM proves with a signature that the message was not altered, and DMARC reads both results, requires alignment and declares what to do on failure. They only make sense together.

I have a DMARC record but an attack still got through — why?

Most likely one of two reasons: your policy is still at p=none, or the attack is not impersonating your domain at all — it comes from a look-alike domain or from a genuinely compromised account. In both cases DMARC is not designed to intervene.

Gateway or API-based solution?

If you are on a cloud mail platform, API-based. A gateway cannot see internal traffic and an MX change carries operational risk.

Is email encryption the same as TLS?

No. TLS protects the message in transit and ends between servers. S/MIME or PGP seals the message itself all the way to the recipient. For sensitive attachments TLS alone is not enough.

How do we spot AI-written phishing?

Not from the text — language is no longer a clue. The distinguishing signal is context: the sender's real history, the age of the relationship, the urgency of the request and anomalies in account behaviour. That analysis is done by a behavioural engine, not the human eye.

Do phishing simulations upset employees?

They do if you frame them as punishment. The right framing rewards the reporter rather than penalising the clicker; the metric you track should be report rate and reporting time.

Is a spam filter the same as email security?

No. A spam filter removes noise; email security addresses targeted deception, account takeover and data loss. The most expensive attacks never reach the spam folder — they look legitimate in the inbox.

How long does an email security project take?

The DNS side (SPF, DKIM, DMARC) can be published within days; hardening the policy takes 60–90 days. An API-based solution deploys in minutes and two weeks is usually enough for a pilot.

We are a small company — do we need this?

Especially so. BEC attackers look at payment flows, not headcount; a 20-person exporter can be a more attractive target than a 2,000-person enterprise because the control layer is thinner.

What is Mailskop and how is it different from MXToolbox?

Mailskop is the free email security scanner built by Kinetik Bilişim. Classic lookup tools show you the raw record; Mailskop also tells you what it means, what risk it creates and how to fix it. It brings the identity, transport and DNS layers onto one screen and supports bulk domain scanning.

Where should I start?

By scanning your domain to see where you stand. Run a free scan on Mailskop — it covers SPF, DKIM, DMARC and the whole transport layer in seconds. If you would like to interpret the result together, let us book an introductory call.

Continue with Kinetik Bilişim

Start by scanning your domain on Mailskop — free, and it requires no contact with us. Then, as a Check Point Advanced Partner, we walk through the findings with you in a 30-minute call and set the priority order. After that — if you want — we run a pilot deployment without touching your MX record.

Book an introductory meeting →

Author

Kemal Özleyen — Cybersecurity Engineer · Check Point Workspace Security Expert. Founder and CTO of Kinetik Bilişim. Works on email security, authentication infrastructure and Check Point solutions for manufacturing and automotive organisations across the Marmara region. LinkedIn