Email Security — DMARC, Advanced Threats

Email remains the primary vector for cyberattacks. According to the 2023 Verizon Data Breach Investigations Report, over 50% of breaches involve phishing or pretexting. The SY0-701 exam covers three core email authentication protocols — SPF, DKIM, and DMARC — that work together to verify the legitimacy of email senders and prevent spoofing. Additionally, you must understand advanced threats like business email compromise (BEC), spear phishing, and email account compromise, as well as technical defenses like mail gateways, sandboxing, and user training.

SPF allows a domain owner to publish a list of IP addresses authorized to send email on behalf of that domain. This list is stored as a TXT record in DNS. When a receiving mail server gets an email, it checks the envelope sender domain (the Return-Path header) against the SPF record. If the sending IP is not in the list, SPF fails.

How SPF works mechanically: 1. Domain owner (example.com) publishes an SPF record: v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all 2. Sender sends email from IP 203.0.113.5 claiming to be from user@example.com. 3. Receiver's MTA queries DNS for example.com's SPF record. 4. The record says only IPs in 192.0.2.0/24 or Google's SPF servers can send. 203.0.113.5 is not authorized. 5. SPF check fails (result: fail).

Key SPF mechanisms: - ip4: / ip6: — specific IP ranges - include: — include another domain's SPF record - a: — the domain's A record - mx: — the domain's MX servers - all — catch-all: -all (fail), ~all (softfail), ?all (neutral)

Limitations: SPF checks only the envelope sender, not the header From address. Attackers can spoof the header From while using a legitimate envelope sender, bypassing SPF. Also, SPF breaks when emails are forwarded (e.g., to a Gmail address) because the forwarding server's IP is not authorized.

DKIM provides a digital signature for each email, allowing the receiver to verify that the email was not tampered with and indeed came from the claimed domain. The signature is stored in the email headers and verified using a public key published in DNS.

How DKIM works mechanically: 1. Domain owner generates a public/private key pair. The public key is published as a TXT record in DNS (e.g., selector1._domainkey.example.com). The private key is stored on the outgoing mail server. 2. When an email is sent, the MTA signs the email headers (From, Subject, Date, etc.) and the body using the private key. The signature is added as a DKIM-Signature header. 3. The receiving MTA extracts the selector and domain from the DKIM-Signature header (e.g., s=selector1; d=example.com), retrieves the public key from DNS, and verifies the signature. 4. If verification succeeds, DKIM passes. If the email was modified in transit, the signature fails.

DKIM signature header example:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
 s=selector1; h=from:to:subject:date; bh=...; b=...

Selectors: Multiple selectors allow key rotation without breaking verification. Old keys can be kept for a grace period.

DMARC builds on SPF and DKIM by allowing domain owners to specify a policy for how receivers should handle emails that fail authentication. It also provides reporting so domain owners can see who is sending email on their behalf.

How DMARC works mechanically: 1. Domain owner publishes a DMARC record as a TXT record at _dmarc.example.com. Example: v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com 2. Receiver checks SPF and DKIM for the email. DMARC alignment requires that the domain in the From header matches the domain used in SPF (or DKIM). 3. If both SPF and DKIM fail, or if alignment fails, the receiver applies the DMARC policy: none (monitor only), quarantine (send to spam), or reject (block delivery). 4. If rua (aggregate reports) is specified, the receiver sends daily XML reports to that address.

DMARC alignment: - SPF alignment: The domain in the From header must match the domain in the envelope sender (Return-Path). If not, SPF is not aligned even if the SPF check passes. - DKIM alignment: The domain in the From header must match the d= domain in the DKIM signature. - DMARC requires at least one of these to be aligned AND pass its respective check.

DMARC policies: - p=none — Take no action; monitor only. Used for testing. - p=quarantine — Treat as suspicious; often move to spam folder. - p=reject — Reject the email (bounce).

Reporting: - rua — Aggregate reports (XML) about all authentication results. - ruf — Forensic reports (individual failure details).

Business Email Compromise (BEC): A sophisticated phishing attack targeting executives or employees with access to financial accounts. The attacker spoofs or compromises a legitimate email account (e.g., CEO) and requests wire transfers or sensitive data. BEC does not use malware; it relies on social engineering. Defenses include DMARC, user training, and verification procedures (e.g., out-of-band confirmation).

Spear Phishing: Targeted phishing emails crafted for a specific individual or organization. Often uses personal information from OSINT to appear legitimate. Defenses include email filtering, sandboxing, and user awareness.

Whaling: Spear phishing targeting senior executives (the "big fish").

Email Account Compromise (EAC): The attacker gains access to a legitimate email account (via phishing, credential theft, or brute force) and uses it to send malicious emails from within the organization. DMARC does not protect against EAC; multifactor authentication (MFA) and monitoring are key.

Phishing Kits: Pre-packaged tools that create convincing phishing pages. Often hosted on compromised websites.

Email Security Gateway (ESG): A device or cloud service that filters incoming and outgoing email for spam, malware, and phishing. It can perform SPF/DKIM/DMARC verification, sandbox attachments, and enforce policies.

Sandboxing: Suspicious attachments or links are executed in an isolated environment to detect malicious behavior. Example: Cisco AMP, FireEye.

User Training: Simulated phishing campaigns teach users to identify suspicious emails. Metrics like click rate are tracked.

MFA: Protects against credential theft for email accounts.

Check SPF record (dig):

dig TXT example.com | grep -i spf

Check DKIM record:

dig TXT selector1._domainkey.example.com

Check DMARC record:

dig TXT _dmarc.example.com

View email headers in Outlook: Open message > File > Properties > Internet headers.

View headers in Gmail: Open message > Click three dots > Show original.

Sample DMARC aggregate report (XML snippet):

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
  </report_metadata>
  <record>
    <row>
      <source_ip>203.0.113.5</source_ip>
      <count>10</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

A SOC analyst at a financial firm notices a spike in DMARC failure reports from their DMARC analyzer. The reports show thousands of emails from an unknown IP in Russia claiming to be from the company's domain. The company's DMARC policy is p=reject, so the emails were never delivered. The analyst confirms no users reported phishing. Without DMARC, those emails would have reached inboxes, likely resulting in credential theft. The analyst creates a block rule for the IP and notifies the threat intel team. The correct response is to do nothing more — DMARC already blocked them. A common mistake is to change the DMARC policy to p=none to "investigate," which would allow future attacks through.

An engineer at a manufacturing company receives an email from the CFO asking for an urgent wire transfer to a vendor. The engineer notices the email is from the correct domain and DMARC passed. Suspicious, the engineer calls the CFO, who confirms they did not send the email. The incident response team investigates and finds the CFO's account was compromised via a phishing link. The attacker set up a mailbox forwarding rule to copy all emails. The team disables the account, removes the rule, and resets credentials. The mistake would be to assume DMARC would have blocked it — DMARC only protects against spoofing, not account compromise. MFA would have prevented the initial compromise.

A company's marketing emails using Mailchimp are being blocked by recipients. The IT team checks DMARC reports and sees SPF failures. They realize the SPF record does not include Mailchimp's IPs. They update the SPF record to include include:servers.mcsv.net. They also add a DKIM signature for Mailchimp. Within 24 hours, delivery improves. The common mistake is to blame the email gateway or set DMARC to p=none, which would allow spoofing. Proper troubleshooting involves checking SPF and DKIM alignment first.