Email Security

Overview

SMTP — the protocol that transfers email between servers — was designed in a more trusted era and contains almost no built-in authentication. Any server on the internet can claim to be any sender. This makes email spoofing trivially easy: the “From:” header on any email is a free-text field that the sending server can set to anything. Spam folders are full of emails purporting to come from trusted contacts or organizations that were sent by completely unrelated servers. The fix is not in the protocol itself but in supplementary DNS-based records that receiving systems can check.

Why Email Spoofing Is So Common

SMTP does not verify that the server sending an email is actually authorized by the domain in the From address. When a mail server receives a message claiming to be from james@professormesser.com, nothing in the SMTP protocol requires that the sending server prove it is operated by professormesser.com. The receiving server just accepts it. This weakness enables:

• Phishing — emails impersonating banks, executives, or trusted vendors to trick users into revealing credentials or authorizing transfers
• Business Email Compromise (BEC) — impersonating a company executive to authorize fraudulent wire transfers or payments
• Malware distribution — sending malicious attachments under a trusted sender name to increase open rates
• Credential theft — directing users to fake login pages by spoofing a legitimate service notification email

The only check in the original SMTP protocol is a reverse-DNS lookup on the sending server’s IP — which is easy to pass with any legitimately provisioned mail server regardless of what domain it claims to send for.

The Mail Gateway

A mail gateway is the organizational gatekeeper for all inbound (and often outbound) email. It sits between the internet and the internal mail server, inspecting every message before it reaches end users. If the gateway decides a message is illegitimate, it can:

• Block — discard the message silently
• Quarantine — hold the message in a spam/quarantine folder the user can review
• Flag — deliver the message but add a warning header or banner

Mail gateways may be deployed on-premises (a physical or virtual appliance in the organization’s network, typically placed in a screened subnet because it must accept connections from the internet) or in the cloud (a third-party filtering service that processes mail before forwarding it to the organization’s mail server). Modern gateways integrate:

• SPF, DKIM, and DMARC validation
• Anti-malware scanning of attachments
• URL filtering and link rewriting
• Attachment sandboxing
• Spam and reputation filtering

Key Terms

• Email spoofing — forging the From address to impersonate a trusted sender; enabled by SMTP’s lack of sender authentication
• Mail gateway — the organizational gatekeeper that validates and filters inbound email before delivery to users
• Business Email Compromise (BEC) — a targeted spoofing attack impersonating executives or vendors to authorize fraudulent transactions
• Screened subnet — the network zone where an on-premises mail gateway should be placed, given that it must accept internet connections

Overview

The three email authentication technologies — SPF, DKIM, and DMARC — are all published as DNS TXT records by the sending domain and checked by the receiving mail server. They form a layered defense: SPF verifies the sending server is authorized; DKIM verifies the message was digitally signed by the domain; DMARC specifies what to do when either check fails and collects compliance reports. A domain that configures all three makes email spoofing detectable by any receiving server that checks.

Sender Policy Framework (SPF)

SPF answers the question: Is this server authorized to send email for this domain?

The domain owner publishes a DNS TXT record listing all servers (by IP, hostname, or include-reference) that are permitted to send mail on behalf of the domain. When a receiving mail server receives a message claiming to be from @example.com, it performs a DNS lookup for the example.com SPF record and checks whether the sending server’s IP appears on the authorized list.

• Pass: the sending server is in the SPF list — the email is from an authorized source
• Fail: the sending server is not in the list — the email is not from an authorized source; the receiving server applies its policy (flag, quarantine, or reject)

Limitation: SPF validates the server IP, not the message content. A server can be on the SPF list and still send spoofed content. SPF alone is insufficient.

DomainKeys Identified Mail (DKIM)

DKIM answers the question: Was this message authorized by and unmodified since leaving the sending domain?

The sending mail server uses a private key to compute a digital signature over selected message headers and the message body. This signature is added to the message’s email headers. The corresponding public key is published as a DNS TXT record by the domain. The receiving server:

DKIM verification happens automatically between mail servers; end users do not see the process. The exam detail: this is a server-level digital signature on the email transport, not a user-level signature on the message body (that would be S/MIME or PGP).

Domain-Based Message Authentication, Reporting, and Conformance (DMARC)

DMARC answers the question: What should a receiving server do when SPF or DKIM fails — and how should the domain owner be informed?

DMARC is an extension of SPF and DKIM. It does not replace them; it uses their results and adds two things:

• Policy enforcement: the domain owner specifies the action for failing messages: none (accept, monitor only), quarantine (send to spam), or reject (discard the message entirely)
• Compliance reporting: receiving servers send aggregate reports back to a reporting address the domain owner specifies; these reports show how many emails passed and failed validation across all receiving servers worldwide

The DMARC record is published as a DNS TXT record at the _dmarc.example.com subdomain. A typical record specifies the policy (p=quarantine), the SPF/DKIM alignment mode, and a reporting URI. The reporting capability allows a domain owner to detect if their domain is being actively spoofed — they see the volume of emails claiming to be from their domain that failed authentication.

How SPF, DKIM, and DMARC Work Together

A receiving server checks SPF (is the sending IP authorized?), then DKIM (is the signature valid?), then applies DMARC policy (what to do with the result). All three records are added to the sender’s DNS by the domain administrator — any organization can query them.

Key Terms

• SPF — Sender Policy Framework; DNS TXT record listing authorized sending servers for a domain
• DKIM — DomainKeys Identified Mail; server-level digital signature on outgoing mail; public key in DNS TXT record
• DMARC — Domain-based Message Authentication, Reporting, and Conformance; policy (none/quarantine/reject) + reporting for SPF/DKIM failures
• DNS TXT record — the record type used for SPF, DKIM, and DMARC; publicly queryable by any mail server
• DMARC policy options — none (monitor only), quarantine (spam folder), reject (discard)

Overview

SPF, DKIM, and DMARC all depend on DNS as their public key infrastructure. The domain owner writes the records; any receiving mail server on the internet reads them. This public-queryable design means that the strength of email authentication is tied directly to the correctness and security of DNS configurations. Misconfiguration is one of the most common causes of both failed email delivery and weakened email security.

DNS as the Shared Public Infrastructure

Because all three records are DNS TXT entries, any receiving server in the world can validate email from any domain that publishes them — without any prior relationship or shared secret. The validation process is fully decentralized:

• Domain owner configures records on their DNS server
• Any receiving mail server performs a DNS lookup at validation time
• No enrollment, no certificate authority, no bilateral agreement required

This design scales globally but means that the domain owner bears full responsibility for record accuracy. If the SPF record is missing an authorized sending server (e.g., a newly added third-party marketing platform), legitimate emails from that platform will fail SPF checks and may be quarantined or rejected by receiving servers.

Common Operational Problems

• Missing authorized senders in SPF: When an organization adds a new cloud email service, marketing platform, or CRM that sends email on their behalf, that service must be added to the SPF TXT record. Failing to do so means emails from that service fail SPF and may be rejected.
• DKIM key rotation not updated: If the sending server’s private signing key is rotated but the new public key is not published in DNS, DKIM signatures from the new key will fail validation.
• Overly strict DMARC policy during initial deployment: Setting p=reject immediately without first running p=none to review compliance reports can accidentally block legitimate email during the transition period.
• SPF record exceeding DNS lookup limit: SPF has a 10 DNS lookup limit; complex SPF records that chain many include-references can exceed this limit and cause validation failures.

DMARC Reporting in Practice

One of the most operationally valuable features of DMARC is its aggregate reporting. Receiving servers send XML reports to the reporting address specified in the DMARC record. These reports show:

• How many emails were received claiming to be from the domain
• Which sending IPs passed or failed SPF
• Which messages passed or failed DKIM
• The DMARC disposition applied (none/quarantine/reject)

This allows the domain owner to discover if their domain is being actively impersonated. If reports show high volumes of authentication failures from IP ranges the domain does not own, those are likely spoofing or phishing campaigns abusing the domain name. The owner can also use these reports to discover legitimate services sending on their behalf that are not yet in the SPF record.

Recommended Deployment Order

Skipping step 3 and deploying p=reject directly is a common mistake that causes legitimate email to be discarded before all sending sources have been identified and added to SPF.

Key Terms

• DMARC aggregate report — XML report sent by receiving servers to domain owner; shows pass/fail counts, sending IPs, and dispositions
• SPF soft-fail (~all) — marks non-matching email as suspicious but does not reject; used during initial deployment
• SPF hard-fail (-all) — instructs receiving servers to reject mail from unlisted servers; stricter enforcement
• DKIM key rotation — periodic replacement of the signing key pair; requires updating the DNS TXT record to match
• p=none / p=quarantine / p=reject — the three DMARC policy levels, progressing from monitor-only to strict enforcement