5.2Email/DNS security and authentication protocols

Both email spoofing and DNS cache poisoning ultimately come down to failing to recognize "a fake pretending to be the real thing." CSIRT members and architects must be able to accurately judge which countermeasure is effective against which threat. SPF, DKIM, and DMARC have similar names and their roles are easily confused, so understanding what each one verifies and how it uses the verification result is the core of this section.

5.2.1Sender domain authentication (SPF, DKIM, DMARC)

• SPF (Sender Policy Framework) verifies whether the sending mail server's IP address is included in the list of legitimate sending IPs that the sending domain publishes in DNS. It verifies the domain of the envelope From (the SMTP-level sender), which is why SPF verification tends to fail when the envelope From changes during mail forwarding.
• DKIM (DomainKeys Identified Mail) has the sender attach a digital signature to the mail header/body using a private key, which the recipient verifies with the public key published in DNS. It provides both legitimacy of the header From domain and tamper detection of the mail content; since the signature survives as long as the content is unchanged during forwarding, DKIM is more forward-resilient than SPF.
• DMARC (Domain-based Message Authentication, Reporting & Conformance) is the higher-level framework that, based on the results of SPF and DKIM (at least one must pass, and it must align with the header-From domain — "alignment"), lets the sending domain declare a policy for how to handle failing mail (none/quarantine/reject) and has the receiving side enforce it. It also includes a reporting mechanism that returns authentication results to the sending domain. Critically, DMARC does not perform its own signature verification—it "consumes" the results of SPF/DKIM.

5.2.2Protecting mail-sending infrastructure (SMTP-AUTH, OP25B/IP25B)

• SMTP-AUTH is an extension that authenticates the sender with a user ID/password when sending mail (SMTP). It prevents an open relay (a server that anyone can use to relay mail) and ensures only legitimate subscribers can send mail.
• OP25B (Outbound Port 25 Blocking) is a countermeasure where an ISP blocks direct outbound mail on port 25 from users assigned a dynamic IP address, preventing bot-infected user devices from sending spam directly. Legitimate sending is instead routed through the submission port (587) with SMTP-AUTH.
• IP25B (Inbound Port 25 Blocking) is the inbound counterpart to OP25B: it blocks incoming connections to port 25 originating from dynamic IP addresses, suppressing the acceptance of spam sent from dynamically assigned IP ranges.

5.2.3DNS security, OAuth, and authentication protocols

• DNSSEC (DNS Security Extensions) attaches digital signatures to DNS responses, providing source authentication and tamper detection for those responses. It is the most directly effective countermeasure against DNS cache poisoning, where an attacker injects a forged name-resolution result. Note, however, that it does not encrypt the DNS traffic itself (it does not provide confidentiality).
• DNSBL (DNS-based Blackhole List) is a list (blacklist) of IP addresses known as spam sources, queryable in DNS format. A receiving mail server queries the sender IP against a DNSBL and rejects or quarantines the mail if it matches.
• OAuth is the standard protocol by which one service (a client) obtains limited authorization to access a resource on another service (the resource server) on the user's behalf. It differs from identity authentication in that it issues an access token rather than passing the password itself—the most commonly confused point is that OAuth is a standard for "authorization," not "authentication."
• EAP (Extensible Authentication Protocol) is an authentication framework that can carry a variety of authentication methods in an extensible way. EAP-TLS is the strongest, using mutual authentication with both client and server certificates, but has a high operational burden for certificate distribution. PEAP authenticates only the server side with a certificate to establish a TLS tunnel, and then performs client-side authentication (ID/password, etc.) inside that tunnel—protecting the client's credentials from eavesdropping while keeping operational overhead lower.
• RADIUS (Remote Authentication Dial In User Service) centrally manages user authentication, authorization, and accounting (AAA). Wireless access points and VPN devices are configured to query a central authentication server (the RADIUS server), avoiding the need to manage credentials separately on every device. PSK (Pre-Shared Key) authenticates using a fixed key shared in advance, suiting small sites where running a dedicated RADIUS server is not justified—but carries the operational risk that if the key leaks or is over-shared, authentication becomes meaningless for all users.

Suppose a CSIRT member receives a report that a spoofed email (BEC) impersonating the company's own domain reached a business partner. Investigating, the attacker sent mail with a From address forging the company domain, but the actual sending server's IP address differed from the company's legitimate mail servers. If the receiving mail server verifies the SPF record, it would find that the attacker's IP is not in the legitimate sending-IP list published for the envelope-From domain, yielding an SPF failure. However, since SPF tends to fail with mail forwarding, relying on SPF alone risks wrongly rejecting legitimate forwarded mail too. If DKIM signing is also configured, the header-From's legitimacy and whether the content was tampered with can be verified independently, and the logic "DMARC passes if either SPF or DKIM passes and aligns with the header-From" applies. Since this spoofed email fails both SPF and DKIM, setting the company's DMARC policy to reject ensures the receiving side rejects it outright—progressively raising the DMARC policy strength (none for observation only, to quarantine, to reject) is the practical standard for combating email spoofing. On another day, a report suggests the internal DNS server is returning suspicious resolution results, indicating possible DNS cache poisoning. Here, SPF/DKIM/DMARC are irrelevant, and deploying DNSSEC with response-signature verification enabled is the direct countermeasure (note that DNSBL is a sender reputation lookup, not a defense against cache poisoning itself).

5.2.4Section summary

• SPF verifies the sending IP (envelope From); DKIM verifies the header-From and content via signature; DMARC is the higher-level framework applying a policy (none/quarantine/reject) based on both results and alignment
• OP25B blocks outbound mail from dynamic IPs to prevent bot-originated spam; DNSSEC is directly effective against DNS cache poisoning (signature verification, not encryption)
• OAuth is a standard for authorization, not authentication. EAP-TLS is strongest via mutual certificate authentication; PEAP tunnels with only a server certificate to keep operational overhead lower