Email security glossary

Three-digit SMTP replies where a 4xx code means a temporary failure the sender should retry, and a 5xx code means a permanent failure that ends delivery.

Codes such as 421 or 451 tell the sending server to keep the message queued and try again later, so mail is delayed, not lost. A 550 5.1.1 says the mailbox doesn't exist, and the sender returns a bounce. Enhanced codes like 5.7.1 add detail, often a policy or authentication rejection. A common mistake is returning 5xx during a short outage or maintenance window, which turns a recoverable delay into lost mail.

Learn more → See: Bounce (NDR) See: Greylisting See: Spooling Source ↗

DNS records that map a hostname to an IP address: an A record holds an IPv4 address and an AAAA record holds an IPv6 address.

Mail depends on them because an MX record names a host, and the sending server then looks up that host's A or AAAA record to find where to connect. If a domain has no MX record, senders fall back to the domain's own A or AAAA record. A common mistake is adding an AAAA record to a mail server that isn't reachable over IPv6, so some senders fail or delay delivery.

Learn more → See: MX record See: PTR record (reverse DNS) Source ↗

A list of senders, domains or IP addresses that a spam filter treats as trusted, so their messages skip some or all filtering checks.

Allow lists fix recurring false positives, such as invoices from a supplier whose mail server has a poor reputation. They are also risky: an entry for a whole free-mail domain, or for your own domain, lets anyone who forges that address walk straight past the filter. Prefer narrow entries, and filters that only honor an allow entry when the message passes SPF, DKIM or DMARC for that sender.

Learn more → See: Block list See: False positive See: Spoofing

Email protection that connects to a cloud mailbox platform through its API and scans messages after they arrive, without changing the domain's MX records.

Tools of this type use APIs such as Microsoft Graph or the Gmail API to read, move or remove messages in mailboxes. Because they work after delivery, they can pull back a message that turned malicious later and can see internal mail. The trade-off: the platform's own filter still accepts mail first, and there is nothing in front of your mail server to hold mail if it goes down.

Learn more → See: Secure email gateway See: Exchange Online Protection See: Spooling

An email standard that lets each server handling a message record and seal the authentication results it saw, so later servers can trust them after forwarding.

Forwarders, mailing lists and filtering services often change a message, for example by adding a footer or rewriting links, which breaks the original DKIM signature and can make DMARC fail. ARC adds ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results headers so the final receiver can see the message passed earlier. Receivers decide which ARC sealers to trust; Microsoft 365 lets admins list trusted ARC sealers.

Learn more → See: DKIM See: DMARC See: Authentication-Results header Source ↗

A message header added by a receiving mail server that records the outcome of its SPF, DKIM and DMARC checks on that message.

A typical entry reads spf=pass, dkim=pass and dmarc=pass, each with the domain that was checked. It is the quickest way to see why a message was flagged as spoofed or sent to junk. Only trust the copy added by your own mail system, identified by its server name at the start of the header; a sender can paste a fake Authentication-Results line into a message before sending it.

Learn more → See: SPF See: DKIM See: DMARC See: Received header Source ↗

Bounce messages sent to innocent people whose address was forged as the sender of spam or malware they never sent.

It happens when a mail server accepts a message first and only later decides it can't deliver it, then bounces it to the forged envelope sender. Victims see floods of delivery failure notices for mail they never wrote. Servers that create backscatter can end up on block lists. The fix is to reject unknown recipients and spam during the SMTP conversation instead of accepting and bouncing later.

Learn more → See: Bounce (NDR) See: Recipient validation See: Envelope sender (Return-Path)

A fraud where attackers use a compromised or impersonated business email account to trick staff into paying money or sending sensitive data.

BEC messages usually contain no link or attachment, just a believable request: change a supplier's bank details, pay an urgent invoice, or buy gift cards for the boss. CEO fraud is the variant where the attacker poses as a senior executive. Because the text looks ordinary, filters catch it less reliably than malware. The strongest control is a process: confirm any payment change by phone using a number you already have.

Learn more → See: Vendor email compromise See: Display-name spoofing See: Whaling Source ↗

A DNS-published standard that lets participating mailbox providers show a brand's verified logo beside authenticated messages from its domain.

You publish a TXT record at default._bimi.yourdomain pointing to an SVG logo and, for most providers, a mark certificate. BIMI only works once DMARC is at enforcement, meaning p=quarantine or p=reject, so it rewards domains that finished their DMARC rollout. Each mailbox provider decides whether to show the logo and which certificates it accepts. BIMI does not block anything by itself; it is a display feature.

See: VMC (Verified Mark Certificate) See: DMARC See: DMARC policy (none, quarantine, reject) Source ↗

A list of senders, domains or IP addresses whose messages a spam filter always rejects or quarantines, regardless of other checks.

Admins use block lists for persistent unwanted senders or domains seen in an attack. Blocking by sender address alone is weak because spammers change addresses constantly and can forge someone else's. Blocking a lookalike domain, or a domain you never correspond with, works better. Review entries now and then; a stale block on a former supplier's domain is a classic source of mysteriously missing mail.

Learn more → See: Allow list See: DNSBL (RBL) See: Lookalike domain

An automated message returned to the sender's envelope address when a mail server can't deliver a message, explaining the reason and status code.

Bounces go to the envelope sender (Return-Path), not necessarily the From address you see. A bounce with 550 5.1.1 means the recipient address doesn't exist; 5.7.x codes usually point to a policy or authentication problem such as a failed DMARC check. Read the status code and the diagnostic text from the remote server first. Bounces for mail you never sent are backscatter, not a sign your account sent them.

Learn more → See: 4xx and 5xx SMTP reply codes See: Backscatter See: Envelope sender (Return-Path) Source ↗

A domain that sends large volumes of email to consumer mailboxes, which Gmail defines as one sending close to 5,000 or more messages a day to personal Gmail accounts.

Since 2024, Gmail and Yahoo require bulk senders to authenticate with SPF and DKIM, publish a DMARC record, align the From domain, offer one-click unsubscribe on marketing mail, and keep spam complaints low. Microsoft has published similar rules for Outlook.com consumer addresses. Once a domain counts as a bulk sender, Gmail treats it as one permanently. Marketing tools sending on your domain count toward your volume too.

Learn more → See: One-click unsubscribe See: Spam complaint rate See: DMARC See: Sender reputation Source ↗

A mailbox setting that accepts mail sent to any address at a domain, including addresses that don't exist, and delivers it to one inbox.

Catch-alls were popular so typos like jhon@ wouldn't be lost. Today they mostly collect spam: spammers send to guessed names, and a catch-all accepts every one. They also make recipient validation impossible, so a filtering service can't reject nonexistent addresses at the door. A better approach is real aliases for the addresses you use, and rejecting everything else with a 550 code.

Learn more → See: Recipient validation See: Domain alias See: Backscatter

A phishing technique that lures users to a fake sign-in page so the attacker can capture their username, password and sometimes their MFA code.

The email usually imitates a shared document, a voicemail notice or a password expiry warning, and links to a page that copies the Microsoft 365 or Google sign-in screen. Some kits relay the login to the real service in real time, so they can also steal the session even when MFA is on. If someone entered their password, reset it, revoke active sessions and check for new mailbox forwarding rules.

Learn more → See: Phishing See: MFA (multi-factor authentication) See: URL rewriting

A standard that uses DNSSEC-signed TLSA records to tell sending servers which certificate a domain's mail server must present, making encrypted delivery mandatory.

For mail, you publish TLSA records at a name like _25._tcp.mail.example.com, and supporting senders refuse to deliver if TLS fails or the certificate doesn't match. DANE only works if your DNS zone is signed with DNSSEC and the sender validates DNSSEC. A common mistake is renewing or rotating the server certificate without updating the TLSA record, which blocks mail from DANE-aware senders.

Learn more → See: MTA-STS See: STARTTLS See: TLS-RPT Source ↗

A scheduled email that lists a user's recently quarantined messages, with options to release, allow or delete each one without logging in to a console.

Digests let users find a misfiled message themselves, which cuts helpdesk requests about missing mail. The schedule matters: hourly suits people waiting on time-sensitive mail, daily suits most. Attackers also send fake quarantine digests to harvest passwords, so train users to recognize your real digest's sender and layout, and to check the quarantine through the portal if a digest looks odd.

Learn more → See: Quarantine See: False positive See: Credential harvesting

An impersonation trick where the sender's visible name is set to a trusted person or brand while the actual email address belongs to the attacker.

A message may show "Jane Smith, CEO" in the inbox while the address behind it is a random free-mail account. Many mail apps, especially on phones, show only the display name, so users never see the real address. SPF, DKIM and DMARC don't stop it because the attacker's own domain authenticates correctly. Filters that compare display names against your staff list, and external-sender tags, help.

Learn more → See: Spoofing See: BEC (business email compromise) See: Header From

An email authentication method in which the sending system signs each message with a private key and receivers verify it with a public key in DNS.

The DKIM-Signature header names a signing domain (d=) and a selector (s=); receivers fetch the public key from selector._domainkey.domain and check that signed headers and body are unchanged. Unlike SPF, a valid signature usually survives plain forwarding. It breaks when a forwarder or gateway alters the message, for example by adding a footer. Every service that sends as your domain should sign with your domain.

Learn more → See: DKIM selector See: SPF See: DMARC See: DMARC alignment Source ↗

A label in a DKIM signature that tells receivers which of a domain's public keys to look up, published at selector._domainkey.domain in DNS.

Selectors let one domain run several keys at once, one per sending service, and rotate keys without downtime. Microsoft 365 uses selector1 and selector2; Google Workspace defaults to google. You can't list a domain's selectors from DNS, so a checker that doesn't find one has only learned that a guessed name is missing. The reliable way to find a selector is the s= value in a real message header.

Learn more → See: DKIM See: DMARC alignment Source ↗

A DNS policy that tells receivers what to do with mail that claims to be from your domain but fails aligned SPF and DKIM checks, and where to send reports.

You publish a TXT record at _dmarc.yourdomain, for example v=DMARC1; p=none; rua=mailto:reports@yourdomain. A message passes DMARC when SPF or DKIM passes for a domain aligned with the visible From address. Start at p=none to collect reports, fix every legitimate sender, then move to quarantine and reject. The current standard is RFC 9989, published in 2026, which replaced RFC 7489.

Learn more → See: DMARC alignment See: DMARC policy (none, quarantine, reject) See: DMARC reports (rua and ruf) See: SPF See: DKIM Source ↗

The DMARC requirement that the domain verified by SPF or DKIM matches the domain in the message's visible From header, either exactly or at organizational level.

Relaxed alignment, the default, accepts any domain sharing the same organizational domain, so mail.example.com aligns with example.com. Strict alignment (adkim=s or aspf=s) needs an exact match. Alignment is why a newsletter tool can pass SPF and DKIM for its own domain yet still fail DMARC for yours. The fix is a custom return-path domain or DKIM signing with your domain.

Learn more → See: DMARC See: SPF See: DKIM See: Header From See: Envelope sender (Return-Path) Source ↗

The p= tag in a DMARC record, telling receivers to only monitor (none), send to spam (quarantine) or refuse (reject) mail that fails DMARC.

p=none collects reports and changes nothing about delivery, so it doesn't stop spoofing. p=quarantine usually sends failing mail to junk; p=reject asks receivers to refuse it during the SMTP conversation. The sp= and np= tags set policy for subdomains and nonexistent subdomains. RFC 9989 drops the old pct= tag and adds t=y, a test flag for trialing a stricter policy before applying it fully.

Learn more → See: DMARC See: DMARC reports (rua and ruf) See: BIMI Source ↗

Reports receivers send about mail claiming your domain: rua asks for aggregate reports with daily summaries, ruf asks for per-message failure reports.

Aggregate reports are XML files listing each sending IP, its message count, and its SPF, DKIM and DMARC results; they show which services send as your domain. Few large receivers send failure reports, because they can contain personal data. If reports go to an address at another domain, that domain must publish an authorization record, or receivers won't send them. Raw XML is hard to read without a parser.

Learn more → See: DMARC See: DMARC policy (none, quarantine, reject) Source ↗

A DNS-based list of IP addresses or domains known for sending spam, which mail servers query in real time to decide whether to accept a connection.

The receiving server reverses the connecting IP's octets and looks them up under the list's DNS zone; any answer means the IP is listed. Lists differ in criteria and how quickly they delist. If your outbound IP is listed, find and fix the cause, such as a compromised account, before requesting removal. Many public lists refuse lookups that come through large public DNS resolvers, which can quietly disable the check.

Learn more → See: IP reputation See: Block list See: Spam trap Source ↗

An extra domain that delivers to the same mailboxes as a primary domain, so mail to name@alias.com reaches name@primary.com.

Businesses use aliases after a rebrand, for country domains, or to catch common misspellings of their name. Each alias still needs its own DNS: MX records, SPF, and a DMARC record, even p=reject for an alias that never sends mail. A common gap is leaving an alias's MX pointing straight at the mail server after the main domain moved behind a filter, giving spammers an unfiltered side door.

Learn more → See: MX record See: Catch-all address See: DMARC policy (none, quarantine, reject)

A Microsoft 365 setting on an inbound connector that lets Exchange Online see the original sender IP when mail first passes through another filtering service.

When your MX points to a filtering service, every message reaches Microsoft 365 from that service's IPs, so Microsoft's SPF and spoofing checks see the wrong source. Enhanced Filtering skips those known hops and evaluates the original sender, which reduces false spoof detections and DMARC failures. Microsoft says to disable rules that set SCL -1 for that connector after you turn it on, except in a few documented cases.

Learn more → See: Inbound connector See: Exchange Online Protection See: SCL (spam confidence level) See: ARC Source ↗

The sender address given in the SMTP MAIL FROM command, used for bounces and SPF checks, and recorded by the receiver in the Return-Path header.

It is often different from the From address people see. A marketing platform may use bounces.platform.com as the envelope sender while the visible From shows your domain. SPF checks the envelope domain, which is why SPF alone does not protect the visible From and DMARC alignment exists. Bounces always return to this address, so forged envelope senders are what cause backscatter.

Learn more → See: Header From See: SPF See: DMARC alignment See: Backscatter Source ↗

Microsoft's built-in cloud filtering for every Microsoft 365 organization with Exchange Online mailboxes, covering anti-spam, anti-malware and anti-spoofing.

EOP filters mail whether or not you add other products, and Microsoft Defender for Office 365 adds features such as Safe Links and Safe Attachments on top. When the MX record points to another filtering service, EOP still processes the mail after it, so configure the inbound connector and Enhanced Filtering to keep the two from fighting over spoof verdicts. Also lock down direct delivery to your tenant.

Learn more → See: Inbound connector See: Enhanced Filtering for Connectors See: SCL (spam confidence level) See: Secure email gateway Source ↗

A harmful or unwanted message that a filter wrongly lets through to the inbox, such as spam, phishing or a malicious attachment.

No filter catches everything, so false negatives are certain to happen sometimes; what matters is how fast you can act on them. Report each one through the filter's reporting option or to your admin, so the sample can be analyzed and similar messages blocked. Pushing filters very aggressive to eliminate false negatives raises false positives, which cost real business mail.

Learn more → See: False positive See: Phishing See: Block list

A legitimate message that a filter wrongly marks as spam or a threat, sending it to quarantine or junk, or rejecting it.

False positives usually trace back to the sender: broken SPF or DKIM, a listed IP, or a link to a domain with a poor reputation. Check the quarantine and the headers before adding an allow list entry, because the right fix is often the sender correcting their authentication. Report the message as not spam so the filter learns, and allow narrowly by authenticated sender, not by whole domain.

Learn more → See: False negative See: Allow list See: Quarantine See: Digest

A spam defense that temporarily rejects mail from an unfamiliar sender with a 4xx code, accepting it only when the sending server retries later.

Legitimate mail servers queue and retry after a 4xx reply, while many spam tools never come back. The cost is delay: the first message from a new sender may arrive minutes later or longer, which hurts password resets and one-time codes. Large senders also retry from a different IP each time, which can trip naive greylisting. Many filters now greylist selectively, only for suspicious connections.

Learn more → See: 4xx and 5xx SMTP reply codes See: Spooling See: SMTP Source ↗

The From header that mail apps display as the message's author, which DMARC protects by checking it against SPF and DKIM results.

It is separate from the envelope sender used during SMTP, and on its own the receiving server takes it on trust. That is why spoofing works: a message can say From: ceo@yourcompany.com while coming from anywhere. DMARC closes the gap by requiring an aligned SPF or DKIM pass for the From domain. Display names shown next to it are not authenticated at all.

Learn more → See: Envelope sender (Return-Path) See: DMARC alignment See: Spoofing See: Display-name spoofing Source ↗

A lookalike-domain trick using characters from other alphabets, such as a Cyrillic а in place of a Latin a, so a fake domain looks identical.

Internationalized domain names (IDNs) let domains contain non-Latin characters; in DNS they are stored as punycode strings that start with xn--. An attacker can register a domain that renders exactly like your bank's or your own. Some browsers and mail apps show the xn-- form for suspicious mixes of alphabets, but not all do. Filters that decode punycode and compare it with known brands catch many of these.

Learn more → See: Lookalike domain See: Phishing See: Spoofing Source ↗

A malware delivery technique where an HTML attachment or web page contains script that assembles a malicious file inside the recipient's browser.

The payload, often a ZIP, ISO or script file, is encoded in the HTML and rebuilt locally when the user opens the attachment. A gateway scanning attachments sees only an HTML file, not the executable it will produce. Treat unexpected .html and .htm attachments as high risk, and consider quarantining or blocking them from external senders. Few businesses receive legitimate HTML attachments.

Learn more → See: Malware See: Sandboxing See: Ransomware

An Exchange Online setting that tells Microsoft 365 how to accept and treat mail arriving from a specific source, such as a filtering service or on-premises server.

When your MX record points to a filtering service, you create an inbound Partner connector that identifies that service by its IP addresses or TLS certificate. With the connector restricted to that certificate or those IPs, Exchange Online rejects mail that doesn't come through the service, so attackers can't send straight to your tenant and skip the filter. A common mistake is creating the connector but leaving direct delivery open.

Learn more → See: Enhanced Filtering for Connectors See: Exchange Online Protection See: MX record Source ↗

A receiver's running assessment of a sending IP address, based on its history of spam, complaints, spam trap hits and authentication results.

Mailbox providers and filters use IP reputation to decide whether to accept, throttle or junk mail before reading it. A new IP with no history is treated cautiously, so high-volume senders warm up new IPs gradually. On shared IPs, such as a web host's server, one bad neighbor can hurt everyone. Check a listed IP against DNSBLs and fix the cause before requesting removal.

Learn more → See: Sender reputation See: DNSBL (RBL) See: Spam trap See: PTR record (reverse DNS)

A domain registered to resemble a real one, like examp1e.com or example-invoices.com, used to send convincing phishing or invoice fraud.

Because the attacker owns the lookalike, its SPF, DKIM and DMARC can all pass, so authentication does not catch it. Common patterns swap letters (rn for m), add words (-billing, -secure), or change the ending (.co instead of .com). Watch for newly registered domains contacting finance staff, and consider registering the most obvious variants of your own domain defensively.

Learn more → See: Homoglyph (IDN) attack See: Display-name spoofing See: BEC (business email compromise) See: Spoofing

Malicious code hidden in the macros of Office documents, such as Word or Excel files, that runs when the user enables content.

Attackers send a document posing as an invoice or order and ask the user to click Enable Content, which lets the macro download further malware. Microsoft now blocks VBA macros in files from the internet by default in Office on Windows, so attackers have moved to other formats, but older versions and changed settings remain exposed. Filtering or quarantining macro-enabled attachments adds another layer.

Learn more → See: Malware See: Ransomware See: HTML smuggling Source ↗

Software designed to harm a device or network or steal from it, including viruses, trojans, spyware and ransomware, often delivered through email.

Email delivers malware as attachments (archives, documents, disk images, scripts) or as links to download pages. Filters combine signature scanning, file-type rules and sandbox detonation. Blocking file types your business never receives, such as .exe or .iso, removes whole classes of risk cheaply. Keep devices patched too; many infections exploit known, fixed vulnerabilities.

Learn more → See: Ransomware See: Macro malware See: Sandboxing See: Zero-day Source ↗

A header holding a unique identifier for each email, set by the originating system, written like <unique-string@domain> and used to track and thread messages.

Mail apps use Message-ID with the In-Reply-To and References headers to group conversations. Admins use it to trace one message through logs, quarantines and message trace tools, because subjects and timestamps are not unique. A Message-ID whose domain doesn't match the sending service is a weak hint of forgery or of a misconfigured script, not proof by itself.

Learn more → See: Received header See: Authentication-Results header Source ↗

A sign-in method that requires two or more different proofs of identity, such as a password plus an app prompt or security key.

MFA is the single most effective control against stolen email passwords: a phished password alone no longer opens the mailbox. Not all MFA is equal. SMS codes and push prompts can be phished or approved by tired users, while passkeys and FIDO2 security keys resist phishing. Enforce MFA for every account, especially admins, and disable legacy sign-in protocols that skip it.

Learn more → See: Credential harvesting See: Phishing See: BEC (business email compromise) Source ↗

A standard that lets a domain require sending servers to deliver its mail over TLS to named MX hosts, using a policy published over HTTPS.

You publish a TXT record at _mta-sts.yourdomain with an id value, and a policy file at https://mta-sts.yourdomain/.well-known/mta-sts.txt listing your MX hosts and a mode: testing, enforce or none. In enforce mode, supporting senders refuse to deliver if TLS fails, which blocks downgrade attacks. A common mistake is changing MX records or the policy file without updating the id.

Learn more → See: TLS-RPT See: STARTTLS See: DANE See: MX record Source ↗

A DNS record that tells sending servers which hostnames accept email for a domain, each with a preference number where lower is tried first.

To route mail through a filtering service, you replace your MX records with the service's hosts. MX records must point to a hostname, never an IP address or a CNAME alias. Lowering the TTL a day before a change speeds up the switch. An MX lookup shows where mail is meant to go, but it can't prove mail is filtered: attackers can still send directly to the mail server unless it is locked down.

Learn more → See: A and AAAA records See: SPF See: Inbound connector Source ↗

A standard pair of email headers that lets mail apps unsubscribe a recipient with a single HTTPS POST request, with no web page or login needed.

The message carries List-Unsubscribe with an HTTPS URL and List-Unsubscribe-Post: List-Unsubscribe=One-Click. RFC 8058 requires a valid DKIM signature covering both headers. Gmail and Yahoo require one-click unsubscribe for marketing mail from bulk senders. A common mistake is pointing the URL at a page that asks for confirmation; one-click means the POST alone must unsubscribe.

Learn more → See: Bulk sender See: Spam complaint rate See: DKIM Source ↗

A mail server misconfigured to forward email from any sender to any recipient on the internet, without checking who is allowed to send.

Spammers scan for open relays and use them to push large volumes of mail, so an open relay's IP lands on block lists quickly and the owner's legitimate mail starts bouncing. Printers, scanners, old on-premises servers and web forms are typical culprits. A relay should only accept mail from authenticated users or known internal IPs, or for domains it actually hosts.

Learn more → See: Smart host See: DNSBL (RBL) See: IP reputation Source ↗

A fraudulent message that impersonates a trusted person or organization to trick the recipient into revealing credentials, paying money or running malware.

Phishing emails copy familiar brands and situations: a shared document, a missed delivery, an overdue invoice. They create urgency so people act before thinking. Layered defenses work best: filtering, DMARC on your own domain, link checking at click time, MFA, and a simple way for staff to report suspect messages. Training helps, but plan for someone clicking eventually.

Learn more → See: Spear phishing See: Credential harvesting See: BEC (business email compromise) See: Spoofing Source ↗

A DNS record that maps an IP address back to a hostname, which receiving mail servers check to judge whether a sending server is legitimate.

Receivers expect a mail server's IP to have a PTR record whose hostname resolves back to the same IP, known as forward-confirmed reverse DNS. Google requires valid forward and reverse DNS for sending IPs. PTR records are set by whoever owns the IP block, usually your hosting or internet provider, not in your own domain's DNS zone. Generic names like 203-0-113-5.dynamic.isp.net look like home connections.

Learn more → See: A and AAAA records See: IP reputation See: SMTP Source ↗

A secure holding area where a filter keeps suspicious messages instead of delivering them, so users or admins can review, release or delete them.

Quarantine is safer than the junk folder because held messages never reach the mailbox, so a user can't click a phishing link by accident. Typical setups give each user a personal quarantine for spam and keep higher-risk items, such as malware or high-confidence phishing, in an admin-only area. Messages expire after a set period, so check quarantine promptly when someone reports missing mail.

Learn more → See: Digest See: False positive See: False negative Source ↗

Malware that encrypts an organization's files or systems and demands payment for the key, often while threatening to publish stolen data.

Phishing email is one of the most common ways ransomware gets in, through a malicious attachment, a link, or stolen credentials used for remote access. Email filtering reduces exposure, but recovery depends on offline, tested backups and a response plan. CISA advises against paying, as payment doesn't guarantee recovery. Report incidents to the authorities in your country.

Learn more → See: Malware See: Macro malware See: Phishing See: Credential harvesting Source ↗

A header that each mail server adds when it accepts a message, recording where it came from, the time, and the server that received it.

Received headers stack up with the newest on top, so you read them bottom to top to follow a message's path. Delays show up as gaps between timestamps. Only headers added by servers you control are reliable; anything below them may have been forged by the sender. Header analyzers parse the chain and calculate the delay at each hop.

Learn more → See: Authentication-Results header See: Message-ID See: Envelope sender (Return-Path) Source ↗

Checking during the SMTP conversation that a recipient address really exists, and rejecting mail for unknown addresses before accepting it.

A filtering service needs a list of valid addresses, from directory sync or by asking your mail server, to reject unknown recipients with 550 5.1.1. Without it, the service accepts mail for nonexistent users and must bounce or discard it later, causing backscatter and wasted processing. The trade-off is that attackers can probe which addresses exist, so pair validation with rate limits.

Learn more → See: Catch-all address See: Backscatter See: Bounce (NDR)

Opening a suspicious attachment or link inside an isolated virtual machine to watch what it does, then deciding whether to deliver it.

Sandboxing catches malware that has no known signature, because it judges behavior: dropping files, changing settings or contacting unknown servers. It adds delay, from seconds to minutes, which some filters reduce by delivering the message body first and attaching the file once it is cleared. Some malware detects sandboxes and stays dormant, so sandboxing is a layer, not a guarantee.

Learn more → See: Malware See: Zero-day See: HTML smuggling Source ↗

A Microsoft 365 value from -1 to 9 stamped in the X-Forefront-Antispam-Report header, where 5 or higher generally means the message was judged bad.

Microsoft now says SCL no longer decides the spam verdict or action in the cloud, so read the CAT value in the header to see what filtered a message. Its main cloud use is mail flow rules: setting SCL -1 asks for most spam filtering to be bypassed, a common setup behind another filtering service. Microsoft recommends removing such rules once Enhanced Filtering for Connectors is on.

Learn more → See: Exchange Online Protection See: Enhanced Filtering for Connectors See: Inbound connector Source ↗

A filtering service placed in front of your mail server through the MX record, so every inbound message is scanned before it reaches your mailboxes.

Mail flows from the internet to the gateway, which removes spam and malware, then on to Microsoft 365, Google Workspace or your own server. Because it sits in front, a gateway can reject mail during SMTP, keep a quarantine outside the mailbox and hold mail during an outage. The weak spot is direct delivery: lock your mail platform to accept internet mail only from the gateway.

Learn more → See: API-based email security See: MX record See: Inbound connector See: Spooling

How mailbox providers rate a sender, combining the reputation of its domain and IPs with engagement, complaints and authentication history.

Domain reputation increasingly matters more than IP reputation, because a domain moves with you across sending services while IPs are often shared. Good reputation comes from consistent authentication, wanted mail and low complaint rates. Gmail's Postmaster Tools shows how Gmail sees your domain. A common mistake is sending marketing from the same domain as invoices, so a bad campaign hurts transactional mail.

Learn more → See: IP reputation See: Spam complaint rate See: Bulk sender See: Spam trap

A server that your mail server or applications send outgoing mail through, instead of delivering directly to recipients' mail servers.

Smart hosts are used to filter outbound mail, sign it with DKIM, or give devices and apps a reliable sending path with a good reputation. Copiers, CRMs and websites often relay through one. Add the relay to your domain's SPF record and sign with your own DKIM key so mail stays DMARC-aligned. Require authentication or IP restrictions, or the relay becomes an open relay.

Learn more → See: Open relay See: SPF See: DKIM See: SMTP

The internet protocol that mail servers use to send email to each other, defined in RFC 5321, normally over TCP port 25 between servers.

An SMTP session is a short conversation: the sender announces itself (EHLO), gives the envelope sender (MAIL FROM) and recipients (RCPT TO), then sends the message (DATA). The receiver answers each step with a code, and can reject at any step. Mail apps submit messages to their own server on port 587 with authentication. SMTP itself is unencrypted unless STARTTLS upgrades the connection.

Learn more → See: 4xx and 5xx SMTP reply codes See: STARTTLS See: Envelope sender (Return-Path) See: MX record Source ↗

The share of a sender's delivered messages that recipients mark as spam, which mailbox providers use as a key reputation signal.

Gmail tells senders to keep the spam rate shown in Postmaster Tools below 0.10% and never reach 0.30%. Going over can mean junk folder placement or rejection, and losing eligibility for mitigation. Rates rise when people didn't clearly opt in, can't find the unsubscribe link, or get mail more often than they expected. Clean lists and easy unsubscribing are the levers.

Learn more → See: Bulk sender See: One-click unsubscribe See: Sender reputation Source ↗

An email address operated by a mailbox provider or blocklist to catch senders with poor list practices, because no real person ever asked for mail there.

Pristine traps were never used by a person and are seeded where scrapers find them; recycled traps are old, abandoned addresses that were turned into traps. Mailing a trap signals bought, scraped or stale lists, and can get an IP or domain listed. Traps look like normal addresses, so you can't spot them. Confirmed opt-in and removing long-inactive addresses keep you clear.

Learn more → See: DNSBL (RBL) See: Sender reputation See: IP reputation

A phishing attack aimed at a specific person or small group, using researched details like names, projects or suppliers to seem genuine.

Attackers gather details from LinkedIn, company websites and earlier breaches, then write a message that references real colleagues or deals. Because volume is low and content is tailored, it resembles normal business mail and is harder to filter. Defenses include impersonation protection for key names, external-sender warnings, and staff who feel free to verify unusual requests.

Learn more → See: Phishing See: Whaling See: BEC (business email compromise) See: Display-name spoofing

A DNS TXT record listing the servers allowed to send mail using a domain in the envelope sender, so receivers can detect unauthorized senders.

An SPF record starts with v=spf1, lists senders with mechanisms such as ip4:, include: and mx, and ends with ~all (soft fail) or -all (fail). SPF checks the envelope sender, not the From address users see, and usually breaks on forwarding. A domain must have exactly one SPF record; publishing two causes a PermError. Every service sending as your domain needs to be listed.

Learn more → See: SPF include See: SPF PermError See: SPF 10-lookup limit See: DMARC See: Envelope sender (Return-Path) Source ↗

The SPF rule that evaluating a record may trigger at most 10 DNS-querying terms; going over returns a PermError.

The terms that count are include, a, mx, ptr, exists and the redirect modifier, including those nested inside included records; ip4 and ip6 cost nothing. Domains that add one sending service after another hit the limit without noticing. Fix it by removing unused services, replacing a and mx with ip4 entries where stable, and moving bulk senders to a subdomain with its own SPF record.

Learn more → See: SPF See: SPF include See: SPF PermError See: SPF void lookup Source ↗

An SPF mechanism that tells receivers to also check another domain's SPF record, used to authorize a third-party sending service.

For example, include:spf.protection.outlook.com authorizes Microsoft 365. If the included record matches the sending IP, the include matches; if not, evaluation continues with the next mechanism. Each include costs one DNS lookup, and any lookups inside it count too, so a few includes can exceed the 10-lookup limit. Including a domain that has no SPF record causes a PermError.

Learn more → See: SPF See: SPF 10-lookup limit See: SPF PermError Source ↗

An SPF result meaning the domain's SPF record can't be evaluated correctly, so receivers treat SPF as broken for every message from that domain.

Common causes are more than 10 DNS lookups, two SPF records on the same domain, a syntax typo, or too many void lookups. A PermError doesn't mean the sender is fake, but SPF then gives DMARC nothing to work with, so delivery depends on aligned DKIM alone. Check the record after every change, especially after adding a new email or marketing service.

Learn more → See: SPF See: SPF 10-lookup limit See: SPF void lookup See: SPF include Source ↗

A DNS query made during SPF evaluation that returns no answer or a nonexistent domain; RFC 7208 recommends a limit of two before a PermError.

Void lookups usually come from stale entries: an include for a service you stopped using whose SPF record has since been deleted, or an a: or mx: pointing to a retired hostname. Each one wastes a lookup, and receivers that enforce the recommended limit of two return a PermError on the third. Remove includes for services you no longer use, and re-check SPF when a vendor changes its setup.

Learn more → See: SPF 10-lookup limit See: SPF PermError See: SPF include Source ↗

Forging the sender details of an email, usually the From address, so the message appears to come from someone the recipient trusts.

SMTP doesn't verify the From address, so anyone can type yours. Exact-domain spoofing, using your real domain, is what DMARC at quarantine or reject stops. It doesn't stop display-name spoofing or lookalike domains, which need content and impersonation filtering. A spoofed message from your own domain to your own staff is a red flag that DMARC enforcement or inbound filtering is missing.

Learn more → See: Display-name spoofing See: Lookalike domain See: DMARC See: Header From Source ↗

Holding email in a queue when the destination server can't accept it, and retrying delivery until it succeeds or a time limit passes.

SMTP was built for this: when a receiving server is down or answers with a 4xx code, the sender keeps the message and retries. RFC 5321 suggests retrying no sooner than every 30 minutes and giving up after at least four to five days. A filtering service in front of your server can spool during an outage, so senders see no error and mail arrives once your server returns.

Learn more → See: 4xx and 5xx SMTP reply codes See: Greylisting See: Secure email gateway Source ↗

An SMTP command that upgrades a plain-text mail connection to an encrypted TLS connection when both servers support it.

Most mail between large providers is now encrypted this way, but STARTTLS is opportunistic: if a server doesn't offer it, or an attacker on the network strips it out, mail falls back to plain text without warning. Senders also rarely validate certificates. MTA-STS and DANE fix this by letting a domain require TLS with a valid certificate, and TLS-RPT reports failures.

Learn more → See: MTA-STS See: DANE See: TLS-RPT See: SMTP Source ↗

A standard that lets a domain receive daily reports from sending servers about failures to make encrypted TLS connections to its mail servers.

You publish a TXT record at _smtp._tls.yourdomain, for example v=TLSRPTv1; rua=mailto:tls-reports@yourdomain. Supporting senders then send JSON reports of successful and failed sessions, including certificate errors and MTA-STS or DANE policy problems. Turn it on before switching MTA-STS to enforce, so you can see what would break. Without TLS-RPT, enforced policies fail silently from your side.

Learn more → See: MTA-STS See: DANE See: STARTTLS Source ↗

A DNS record that holds free-form text, used in email to publish SPF, DKIM keys, DMARC policies, MTA-STS, TLS-RPT and BIMI settings.

Each email standard reads its TXT record from a specific name: SPF at the domain itself, DMARC at _dmarc, DKIM at selector._domainkey. Long values such as 2048-bit DKIM keys must be split into strings of 255 characters or fewer within one record. A common mistake is adding a second SPF TXT record instead of editing the first, which breaks SPF.

Learn more → See: SPF See: DKIM See: DMARC See: MTA-STS Source ↗

A protection that replaces links in incoming email with links through a checking service, so each URL is scanned again when the user clicks it.

Attackers often send a link that is harmless at delivery and turns malicious hours later; checking at click time catches that switch. The trade-offs are long, unreadable links and changes to the message body, which break the original DKIM signature for any later system checking it. Microsoft Defender for Office 365 calls its version Safe Links.

Learn more → See: Phishing See: Credential harvesting See: ARC Source ↗

A form of business email compromise where attackers take over a real supplier's mailbox and use it to send fake invoices or changed bank details.

Because the mail comes from the supplier's genuine account, it passes SPF, DKIM and DMARC and often continues an existing thread, so filters and staff both trust it. The usual tell is a request to pay a new bank account. Verify every bank-detail change by calling the supplier on a number from your own records, never one from the email.

Learn more → See: BEC (business email compromise) See: Lookalike domain

A digital certificate from an approved certificate authority that proves a domain's owner has rights to the logo it publishes for BIMI.

To get one, you typically need a registered trademark for the logo and a domain at DMARC enforcement, and you pay the issuing authority annually. The certificate's URL goes in the a= tag of your BIMI record. Some providers, Gmail and Apple among them, require a mark certificate before showing your logo. Check each provider's requirements before buying.

See: BIMI See: DMARC policy (none, quarantine, reject) Source ↗

Spear phishing aimed at senior executives or other high-value people, such as finance directors, whose access or authority makes them valuable targets.

Whaling messages often imitate lawyers, regulators, board members or major customers, and push matters that seem confidential and urgent. Executives are attractive because they can approve payments and their mailboxes hold sensitive data. Give leadership the same MFA and reporting habits as everyone else, with no exceptions for convenience, and add impersonation protection for their names.

Learn more → See: Spear phishing See: BEC (business email compromise)

An attack using a software vulnerability that the vendor hasn't yet fixed, or that defenders don't yet know about, so no patch or signature exists.

In email, zero-days usually arrive as a booby-trapped document or link that exploits a flaw in a mail app, browser or Office. Signature-based scanning can't recognize them, which is why sandboxing and behavior analysis matter. Apply emergency patches quickly once the vendor releases a fix, because exploitation often spreads widely right after disclosure.

Learn more → See: Malware See: Sandboxing See: Ransomware Source ↗