Email Authentication (SPF, DKIM, DMARC, BIMI)

What it is

Email was designed in an era when nobody was thinking about spoofing. The protocol lets any server claim to send mail from any domain, and receiving servers have no built-in way to tell whether that claim is honest. Email authentication is the set of standards bolted on top of SMTP to fix that.

Four records do the work:

• SPF (Sender Policy Framework). A DNS TXT record listing which IP addresses or hostnames are allowed to send mail for your domain.
• DKIM (DomainKeys Identified Mail). A cryptographic signature applied to outbound mail. The receiving server checks the signature against a public key in your DNS.
• DMARC (Domain-based Message Authentication, Reporting and Conformance). A policy record that tells receivers what to do when SPF and DKIM fail, and where to send reports about authentication results.
• BIMI (Brand Indicators for Message Identification). A newer optional record that lets receivers display your verified logo next to authenticated mail in supporting clients.

Each one solves a specific piece of the spoofing problem. None of them works well on its own.

Why it matters

Spoofed email is still the entry point for most business email compromise (BEC) and a large share of phishing campaigns. The FBI's IC3 reports BEC losses in the billions of dollars per year, and a meaningful share of those start with a message that looks like it came from a trusted domain because the trusted domain had no enforced DMARC policy.

The business consequences are concrete:

• Wire fraud. A spoofed message from "the CFO" tells finance to redirect a payment. Without authentication enforcement, the receiving mail server has no easy way to flag it.
• Credential phishing. Login pages spoofed under a vendor's domain land in customer inboxes with no warning, because the customer's mail provider trusts the From address.
• Brand damage. When customers receive obviously fraudulent mail from your domain, they remember the brand, not the technical reason it happened.
• Deliverability drag. Legitimate mail from poorly authenticated domains gets routed to spam more often. Marketing teams sometimes notice this before security does.
• Regulatory pressure. Google and Yahoo's bulk sender rules, in force since early 2024, require authenticated mail with a DMARC policy for any sender pushing more than 5,000 messages per day to their users.

There is no shortage of cautionary examples. The 2016 attack on Mattel that nearly cost three million dollars, the long-running Snapchat W-2 incident, and a steady stream of vendor impersonation cases against finance teams all involved spoofing that proper DMARC enforcement would have stopped at the receiving server.

How attackers exploit it

The attacker's playbook against weak email authentication is short and well-rehearsed.

First, they pick a target domain and check the DNS. Tools like dig, nslookup, or any of a dozen public lookup services pull the SPF, DKIM and DMARC records in seconds. If DMARC is missing, set to p=none, or scoped only to specific subdomains, the domain is in play.

Next, they decide which technique to use:

1. Direct spoof. If DMARC is none or absent, the attacker just sets the From header to the target domain and sends. Many receivers will deliver it.
2. Subdomain abuse. Many organisations publish DMARC for the root domain only. Mail from marketing.targetcompany.com may pass authentication checks the parent domain blocks, especially if sp= (subdomain policy) is not explicitly set to reject.
3. Display name spoofing. Easier and harder to stop with DMARC alone. The attacker uses an unrelated domain but sets the display name to something like "Jane Smith, CFO". Most mobile clients show only the display name.
4. Lookalike domains paired with broken DMARC. A typosquat domain registered by the attacker has its own freshly published SPF, DKIM and DMARC. The mail authenticates cleanly, just for the wrong domain.
5. Cousin domains via authentication-friendly providers. Many bulk mail providers will configure SPF and DKIM on whatever domain the attacker controls, with no review of intent.

The attacker does not need to break cryptography. They just need a domain that does not enforce its own policy.

How to detect it

Authentication problems usually announce themselves if you know where to look.

Check your records directly. Pull the SPF, DKIM and DMARC TXT records for every active sending domain and subdomain. Confirm:

• SPF exists, has fewer than ten DNS lookups, and ends with -all (hard fail) or at minimum ~all (soft fail). A +all is open relay and bad.
• DKIM selectors exist for every legitimate sending service, and the keys are at least 1024 bits (2048 preferred).
• DMARC exists, is published at the organisational domain, and has a policy of quarantine or reject. A p=none record is monitor-only and provides no enforcement.

Read the DMARC reports. When DMARC is enabled with a rua= address, receivers send daily aggregate reports listing every IP that sent mail claiming to be your domain and whether it passed or failed. These reports are the single best detection signal for spoofing in the wild. They also reveal legitimate sources you forgot about (a marketing tool, a transactional provider, a third-party HR system) that need their own authentication.

Watch alignment, not just pass/fail. SPF and DKIM can both technically pass while DMARC still fails, because DMARC requires alignment between the authenticated domain and the visible From header. Misalignment is one of the most common reasons authentication looks healthy from the sending side and fails from the receiver's perspective.

Monitor for record drift. A vendor offboarded last quarter still in your SPF include list. A DKIM selector left active after a key rotation. A DMARC record someone weakened to p=none to debug a deliverability issue and never restored. Continuous checking catches these.

How to remediate

If you are starting from scratch or fixing a domain that has drifted, the rough sequence is:

1. Inventory every legitimate sender. Marketing platforms, transactional senders (SendGrid, Mailgun, AWS SES), HR tools, support systems, internal mail servers. Anything that sends mail in your name. The DMARC reports will help you find the ones you forgot.
2. Publish or fix SPF. Include only the legitimate sources. Watch the ten-DNS-lookup limit. Use -all once you are confident the list is complete.
3. Configure DKIM for every sender. Each sending service gets its own selector. Use 2048-bit keys. Document the rotation schedule.
4. Publish DMARC at p=none first. Add a rua= and ideally ruf= address. Collect at least two weeks of reports to see who is sending in your name.
5. Move to p=quarantine. With pct= set to a small percentage at first, then ramping up. Monitor reports for legitimate mail being caught.
6. Move to p=reject. This is the goal. Spoofed mail gets rejected at the receiver before it ever lands in an inbox. Set sp=reject too so subdomains inherit the policy.
7. Add BIMI once at p=quarantine or p=reject. A Verified Mark Certificate (VMC) is required for the major mail providers. Then publish a BIMI TXT record pointing to your logo.
8. Apply the same rules to parked and inactive domains. Domains you own but do not send from should publish a strict null SPF (v=spf1 -all) and a p=reject DMARC record. Otherwise attackers will use them.

Best practices

• Run DMARC enforcement on every domain you own, including the ones nobody sends from. Inactive domains are favourite spoofing targets precisely because they look unmonitored.
• Process DMARC reports automatically. Raw aggregate reports are unreadable XML at scale. Either pipe them into a parser or use a service that does.
• Keep an authoritative list of authorised senders. Treat it like an asset register. Review it quarterly and after any vendor change.
• Rotate DKIM keys. At least annually. Roll a new selector, leave the old one in DNS for a grace period, then retire it.
• Watch for SPF flattening as a workaround, not a strategy. Some teams flatten includes to fit under the ten-lookup limit. Done badly, this leaves stale IP ranges in DNS for years.
• Train finance and exec assistants on display name spoofing. DMARC does not stop a message from notreallytheCFO@gmail.com with a display name set to your CFO. Process and awareness do.
• Treat any change to SPF, DKIM or DMARC as a change-managed event. A wrong character in a TXT record can take all your mail dark in minutes.