1 Introduction
Email was designed in the 1980s on trust: the From address of a message is just text, and anyone can write [email protected] in it, exactly like anyone can write any sender address on the back of a paper envelope. That is how most email spoofing and invoice fraud works.
Three DNS records let you, the domain owner, tell every receiving mail server how to recognise your real mail: SPF lists the servers allowed to send for you, DKIM signs your messages, and DMARC ties the two to the visible From address and says what to do with mail that fails. When a domain scan flags your mail authentication, this is the protection it is talking about.
3
DNS records (SPF, DKIM, DMARC) that decide whether your domain can be impersonated
2024
Gmail and Yahoo start requiring SPF, DKIM and DMARC from bulk senders
10
Maximum DNS lookups an SPF record may trigger before it breaks (RFC 7208)
2 How It Works
When a message claiming to come from your domain arrives, the receiving server (Gmail, Outlook, a corporate gateway) runs three checks, all by reading public DNS records you publish. Nothing has to be installed on the receiving side: publishing the records is enough.
SPF
Is the IP that delivered this message on the list of senders the domain published?
DKIM
Does the cryptographic signature in the headers verify against the public key in DNS, so the message was not altered?
DMARC
Did SPF or DKIM pass for the domain shown in From? If not, apply the owner's policy: deliver, quarantine or reject.
Why DMARC is the one that matters
SPF and DKIM on their own only validate some domain: SPF checks the hidden envelope sender (Return-Path), DKIM checks whatever
domain signed the message. An attacker can pass both with their own domain while still displaying yours in the From line.
DMARC closes that gap with alignment: the domain that passed SPF or DKIM must match the From domain.
Without a DMARC policy that acts (quarantine or
reject), receivers make their own call, and spoofed mail often lands in the inbox.
3 Detailed Analysis
SPF: who may send
A single TXT record on the domain itself:
example.com. TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"The ending: -all, ~all, ?all, +all
-all means "nothing else may send" (hard fail), ~all "probably not" (soft fail, fine while DMARC enforces). ?all says nothing at all, and +all authorises the whole internet: a scan rightly flags it as high severity.
Only one SPF record
Two TXT records starting with v=spf1 make SPF return a permanent error, which receivers treat as a failure. Merge them into one.
The 10-lookup limit
Every include:, a, mx and redirect costs a DNS lookup, nested includes included. Past ten, SPF breaks for everyone. Remove providers you no longer use rather than reaching for "SPF flattening" services.
DKIM: proof the message is yours
Your mail provider signs each outgoing message with a private key; the public key lives under a selector:
google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...""No DKIM found" does not always mean no DKIM
DNS cannot list selectors, so a scanner tries the common ones (google, selector1, selector2, k1, default...). A custom selector is invisible from outside. To check for sure, open a message you sent and look for DKIM-Signature: ... d=example.com; s=<selector> in its headers.
Key length
Use 2048-bit RSA keys. 1024-bit keys are still accepted but considered weak; rotate them from your provider's admin console.
Enable it for every sender
Your CRM, newsletter tool and helpdesk send as you too. Each one should sign with your domain (d=example.com), usually by adding a CNAME or TXT they give you.
DMARC: the policy
A TXT record on _dmarc. in front of your domain:
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"p=none: monitoring, not protection
Receivers send you reports but deliver spoofed mail as usual. It is the right first step and the wrong place to stay; a scan flags it because the domain is still spoofable.
p=quarantine and p=reject
Quarantine sends failing mail to spam, reject refuses it outright. Both count as enforced. sp= sets the policy for subdomains (it inherits p= when absent), and pct= applies the policy to only part of the traffic while you ramp up.
rua=: your visibility
Aggregate reports (XML, daily) list every IP sending as your domain and whether it passed. Without them you are enforcing blind. Point them at a mailbox or a free DMARC report parser.
Getting to p=reject without losing mail
Publish SPF and enable DKIM for your main mail provider. Publish p=none with a rua= address.
Read two to four weeks of reports. Every legitimate source that fails (newsletter, invoicing, ticketing) gets SPF or DKIM fixed. Unknown sources are either forgotten tools or spoofing.
Move to p=quarantine (optionally with pct=25, then 100), watch the reports, then p=reject.
Domains that never send email
Parked domains, old brands and defensive registrations are favourite spoofing targets precisely because nobody watches them. If a domain or subdomain sends no mail, say so explicitly with three records:
old-brand.com. MX 0 . ; null MX (RFC 7505): accepts no mail
old-brand.com. TXT "v=spf1 -all" ; no server may send
_dmarc.old-brand.com. TXT "v=DMARC1; p=reject"A scan's "spoofing protection" check looks at exactly this: domains and subdomains with no mail activity that still accept being impersonated.
Microsoft 365 and Direct Send
If your MX points to *.mail.protection.outlook.com, Exchange Online accepts unauthenticated SMTP on that host for your own domains. This "Direct Send" feature exists for printers and scanners, and attackers abuse it to drop internal-looking phishing into your users' inboxes. Two things stop it: an enforced DMARC policy, and turning the feature off if nothing uses it (Set-OrganizationConfig -RejectDirectSend $true in Exchange Online PowerShell).
Check your domain on mlab.sh
A domain scan reads your SPF, DKIM and DMARC records, flags what is missing or weak, and checks your subdomains for spoofing protection.
Scan your domain on mlab.sh4 Red Flags
No DMARC record, or p=none for months
Your domain can be used in a From line by anyone, and receivers have no instruction to stop it. This is the single most impactful thing to fix.
SPF ending in +all or ?all
+all authorises every server on earth. ?all is neutral and protects nothing. End with -all or ~all.
Two SPF records, or more than 10 lookups
Both make SPF fail with a permanent error, so your own legitimate mail stops passing. It often appears after adding a new provider.
Includes for providers you no longer use
Every include widens who may send as you and eats into the lookup budget. Remove a provider's include the day you stop using it.
Parked domains without SPF -all and DMARC reject
A domain you own but do not use for mail is still yours in the eyes of the recipient. Lock it down with null MX, v=spf1 -all and p=reject.
Related Modules
Source: mlab Academy — Cybersecurity Awareness Platform
URL: https://academy.mlab.sh//page/email-authentication
Module: SPF, DKIM and DMARC for your domain — Secure your domain
Disclaimer: This content is for awareness purposes only.