Email Authentication & Domain Trust

Email runs on SMTP (Simple Mail Transfer Protocol, RFC 5321), designed in 1982 for a small, trusting research network. Its original sin, from a security standpoint, is that SMTP does not verify who a sender claims to be. A sending server simply asserts the sender address, and the receiver historically took it on faith.

Worse, there are two different "from" addresses, which is the root of endless confusion and abuse:

• The envelope sender (the SMTP MAIL FROM, also called the Return-Path) — used for routing and bounces, invisible to the reader.
• The header From (RFC 5322) — the human-visible "From:" line your mail client displays.

Nothing in base SMTP forces these to match, or forces either to be truthful. An attacker can put ceo@yourcompany.com in the visible From while sending from an entirely unrelated server. This is email spoofing, and it underlies most phishing.

SPF (Sender Policy Framework, RFC 7208) answers one question: is this sending server authorized to send mail for this domain? A domain owner publishes a DNS TXT record listing the IP addresses and servers permitted to send on its behalf. The receiving server looks up that record and checks whether the connecting server's IP is on the list.

Two important limitations define SPF's reach:

• It checks the envelope sender domain (the Return-Path), not the visible header From. So SPF alone can pass while the address the human sees is still spoofed — a gap DMARC later closes.
• It breaks on forwarding. When a message is forwarded, the forwarding server's IP is not in the original domain's SPF record, so SPF fails even for legitimate mail. This is a constant operational headache.

SPF also caps DNS lookups at 10; exceed that (easy with many third-party senders) and it errors out. SPF is necessary but, by itself, weak — it authorizes servers, not the message, and guards the wrong "from."

DKIM (DomainKeys Identified Mail, RFC 6376) takes a cryptographic approach. The sending server signs selected headers and the body of each message with a private key, attaching a DKIM-Signature header. The domain publishes the matching public key in DNS (at selector._domainkey.example.com). The receiver fetches that public key and verifies the signature.

A valid DKIM signature proves two things: the message genuinely came from a party holding the domain's private key, and the signed content was not altered in transit. Crucially — and unlike SPF — DKIM survives forwarding, because the signature travels with the message and does not depend on the connecting IP.

Using selectors (the label before ._domainkey) lets a domain publish multiple keys at once — for different providers or for key rotation — which is how large senders manage many mail streams cleanly.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is the standard that finally protects the address the human actually sees. It does two things SPF and DKIM cannot do alone.

First, alignment. DMARC requires that a passing SPF or DKIM result be for a domain that matches the visible header From domain. This is the linchpin: it forces the authenticated identity to line up with what the recipient reads, closing the gap that let SPF and DKIM pass while the From was spoofed.

Second, policy and reporting. The domain owner publishes a DMARC TXT record stating what receivers should do with mail that fails alignment:

• p=none — monitor only; take no action (a starting point, not protection).
• p=quarantine — send failing mail to spam/junk.
• p=reject — refuse failing mail outright. This is true enforcement.

DMARC also sends aggregate reports (the rua address) back to the domain owner, revealing who is sending as their domain — invaluable for finding both spoofers and forgotten legitimate senders before you tighten policy. Finally, BIMI (Brand Indicators for Message Identification) lets a brand display its verified logo beside authenticated mail — but only for domains already at DMARC enforcement, making a strong logo a reward for doing DMARC right.

The costliest email attacks are not mass spam — they are targeted, low-tech, and lucrative. Business Email Compromise (BEC) tricks an employee into making a payment or handing over data by impersonating a trusted party: the CEO demanding an urgent wire, a vendor sending "updated" bank details, a lawyer pressing for confidentiality. The FBI's IC3 has for years ranked BEC among the very costliest categories of cybercrime, with cumulative reported losses in the tens of billions of dollars.

BEC often uses no malware at all — just a convincing message from a look-alike domain (rn instead of m), a compromised partner's real account, or a spoofed From that unenforced DMARC failed to block.

When an attacker does take over a real mailbox (usually via phishing or password reuse), a signature move is malicious mailbox rules. They create inbox rules that auto-forward copies to an external address, or silently move and mark-as-read any reply containing words like "invoice," "wire," or "fraud" — hiding their activity from the real owner while they run an invoice scam from inside a trusted account.

Layered on top of authentication are Secure Email Gateways (SEGs) — services like Proofpoint, Mimecast, and the built-in protections of Microsoft 365 and Google Workspace — that inspect mail for threats before it reaches the inbox. Two of their most valuable techniques:

• Attachment detonation: suspicious attachments are opened in an isolated sandbox and watched for malicious behavior (dropping files, calling out to a server) before delivery — catching malware that static signatures miss.
• URL detonation / time-of-click protection: links are rewritten to route through the gateway, which re-checks the destination at the moment the user clicks — defeating attackers who send a benign link and weaponize it after delivery.

Yet the single highest-impact fix remains the one most organizations never finish: moving DMARC to enforcement. Vast numbers of domains publish DMARC at p=none — monitoring, feeling protected, but blocking nothing. Spoofed mail using their exact domain still sails through, because none takes no action.