MyRecon OSINTEmail Authentication Explained: SPF, DKIM and DMARC
Email was designed in a more trusting era, when anyone could put any name in the "From" field. SPF, DKIM, and DMARC are the three DNS records that fixed that — they let the world verify that an email really came from the domain it claims. Understanding them helps you protect your own domain and judge whether someone else's is trustworthy.
The problem: anyone can forge "From"
By default, nothing stops a spammer from sending an email that says it came from billing@yourbank.com. This is called spoofing, and it is the engine behind most phishing. The three email-authentication standards work together to make spoofing detectable, so receiving mail servers can reject or quarantine fakes.
SPF — who is allowed to send
SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers permitted to send email for a domain. When a message arrives, the receiving server checks whether the sending server's IP is on that list. A typical SPF record looks like v=spf1 include:_spf.google.com ~all, which says "Google's servers may send for us; treat anything else as suspicious." SPF answers one question: is this server authorised?
DKIM — proof the message wasn't tampered with
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message. The domain publishes a public key in DNS, and the sending server signs messages with the matching private key. The receiver uses the public key to verify the signature, proving two things: the message genuinely came from the domain, and its key contents were not altered in transit. DKIM answers: is this message authentic and intact?
DMARC — the policy that ties it together
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the record that tells receivers what to do when SPF or DKIM fail, and asks them to send reports. A DMARC record such as v=DMARC1; p=reject; rua=mailto:reports@domain.com means "if a message claiming to be from us fails authentication, reject it, and send me reports." The policy can be none (monitor only), quarantine (send to spam), or reject (block outright).
How they combine: SPF checks the sending server, DKIM checks the message signature, and DMARC decides what happens if either fails — and alignment rules ensure the checks actually match the visible "From" domain. All three are needed for strong protection.
How to read a domain's email security
Because these are all public DNS records, you can inspect any domain's email posture. Look at its TXT records for an SPF entry, its DMARC record at _dmarc.<domain>, and DKIM selectors where known. MyRecon's DNS tool surfaces the TXT records where SPF and DMARC live — our guide to DNS records explains the surrounding record types. A domain with no SPF and no DMARC is trivially spoofable; a domain with p=reject is well protected.
Why it matters for investigation and trust
For a defender, weak or missing authentication on your own domain is an open door for attackers to impersonate you to your customers. For an investigator assessing whether a message is legitimate, the sending domain's authentication posture is a useful signal — although remember that attackers frequently register their own look-alike domains and configure valid SPF/DKIM on them, so good authentication proves the domain sent the mail, not that the domain is honest.
Quick checklist for your own domain
- Publish an SPF record listing every service that sends mail for you.
- Enable DKIM signing in your mail provider and publish the key.
- Start DMARC at p=none with reporting, review the reports, then move to quarantine and finally reject.