Summary and conclusion - 9/9

Summary and conclusion#

Securing email is not the business of a single protocol, but rests on a defense-in-depth strategy. Combining the FCrDNS, SPF, DKIM and DMARC protocols makes it possible to create a robust chain of trust, making technical identity spoofing almost impossible, provided the chain is not broken.

To guarantee this security, two conditions are imperative:

1. A strict configuration on the sender side: Domain administrators must aim for excellence:

• SPF locked down with -all (Hard Fail).
• DMARC set to the p=reject policy (simply rejecting failures).

2. Rigorous validation on the receiver side: Receiving servers must perform the cryptographic and DNS checks in real time. This is today the standard among the industry giants (Gmail, Microsoft, Yahoo, Proton, etc.).

While these protocols close the door to technical spoofing (sending an email as president@whitehouse.gov), they cannot prevent social engineering. Once the technical barrier is raised, the user’s vigilance remains the last line of defense against attacks that bypass the protocols:

• Typosquatting (Homoglyphs): The attacker buys a legitimate-looking domain that visually resembles the target (e.g. bance-postale.fr instead of banque-postale.fr). DMARC will validate this email because it legitimately comes from the attacker’s domain.
• Display Name Spoofing: The attacker uses a generic address (e.g. jean.pirate@gmail.com) but changes the display name so that it appears as “Technical Support” or “Your CEO”.

In summary, while DMARC guarantees that the sender really is who they technically claim to be, it does not guarantee that their intentions are benign. Educating users to systematically verify the domain in the From field remains essential and complementary to the technical measures.

The following diagram summarizes the email security stack:

graph TD
  %% --- Styles ---
  classDef network fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#000
  classDef auth fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#000
  classDef policy fill:#c8e6c9,stroke:#1b5e20,stroke-width:2px,color:#000
  classDef human fill:#f8bbd0,stroke:#c2185b,stroke-width:2px,color:#000
  classDef outcome fill:#e0e0e0,stroke:#757575,stroke-width:1px,color:#000
  %% --- Input ---
  Mail["📧 Incoming email"]
  %% --- Layers ---
  subgraph "Layer 1: Network"
      L1["FCrDNS<br/>IP/Domain validation"]:::network
  end
  subgraph "Layer 2: Technical Auth"
      L2_SPF["SPF<br/>IP authorization"]:::auth
      L2_DKIM["DKIM<br/>Signature & Integrity"]:::auth
  end
  subgraph "Layer 3: Policy"
      L3["DMARC<br/>Alignment & Rules"]:::policy
  end
  subgraph "Layer 4: Human"
      L4["User<br/>Typosquatting vigilance"]:::human
  end
  %% --- Outputs ---
  Inbox["📥 Inbox"]:::outcome
  Spam["🚫 Spam / Rejection"]:::outcome
  %% --- Flow ---
  Mail --> L1
  
  %% From the network to auth
  L1 --> L2_SPF
  Mail --> L2_DKIM
  %% From auth to DMARC
  L2_SPF --> L3
  L2_DKIM --> L3
  L1 -.->|PTR info| L3
  %% DMARC decision
  L3 -->|Success| L4
  L3 -->|Failure| Spam
  %% Human decision
  L4 -->|Legitimate| Inbox
  L4 -->|Phishing detected| Spam

Finally, if FCrDNS, SPF, DKIM and DMARC are the “anti-spoofing defenses”, the standard aliases are the “eyes and ears” of that defense (to receive FBL complaints and error reports).

A few useful URLs#

• https://postmaster.google.com : The legacy version of Google’s website that provides feedback on the emails coming from your domain and bound for gmail.com
• https://postmaster.google.com/v2/ : The new version of Google’s website that provides feedback on the emails coming from your domain and bound for gmail.com
• https://www.mail-tester.com
• https://dmarc.postmarkapp.com
• https://easydmarc.com/tools/spf-lookup : Checks the SPF syntax, counts the number of DNS lookups, and details the SPF recursively.
• https://easydmarc.com/tools/dmarc-lookup : Checks the DMARC syntax and provides information about the DMARC of the checked domain.