WEBVTT

1
00:00:00.720 --> 00:00:06.132
A familiar sender feels like proof. It isn’t. This urgent note claims to be billing at example dot com.

2
00:00:06.722 --> 00:00:08.689
Follow the evidence before acting.

3
00:00:08.779 --> 00:00:12.894
The From line is only a display label; a sender can type a trusted-looking address there.

4
00:00:13.484 --> 00:00:17.707
Open the original headers. In Gmail: three-dot menu, then Show original.

5
00:00:17.797 --> 00:00:22.492
Trust Authentication Results added by your receiving service, not text typed into the message.

6
00:00:22.582 --> 00:00:28.299
Here, S P F and D K I M pass for example dot org; D M A R C fails for example dot com.

7
00:00:28.889 --> 00:00:34.816
S P F checks whether this server may send for the hidden envelope domain. Here, that is example dot org: pass.

8
00:00:35.406 --> 00:00:41.001
D K I M uses a public key to verify a domain’s digital seal. This one is valid for example dot org.

9
00:00:41.591 --> 00:00:46.667
D M A R C asks whether a passing S P F or D K I M domain aligns with the visible From domain.

10
00:00:46.757 --> 00:00:50.668
Example dot org and example dot com do not align, so this fails.

11
00:00:50.758 --> 00:00:54.848
Domain owners can request handling and reports; the receiver decides delivery.

12
00:00:55.438 --> 00:01:00.230
A pass does not prove content is safe or honest. Attackers can authenticate their own domains.

13
00:01:00.320 --> 00:01:04.673
A failure does not prove fraud. Forwarding and mailing lists can break legitimate checks.

14
00:01:04.763 --> 00:01:07.729
Look-alike domains and display-name tricks still need attention.

15
00:01:08.319 --> 00:01:12.880
Pause at urgency, passwords, or money. Inspect the actual address and original.

16
00:01:12.970 --> 00:01:16.337
Verify through a known app or phone number, not the message’s links.

17
00:01:16.427 --> 00:01:20.344
Check evidence. Verify requests. A familiar name is not enough.