Guide · Email

DMARC + Beyond: the modern email stack.

Authentication is the floor, not the ceiling. A layered email-defence stack for 2026: SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, plus the impersonation detection that catches everything authentication cannot.

What email authentication does and doesn't do

SPF, DKIM, and DMARC together protect against one specific attack: someone sending mail with your exact domain in the From header without your authorisation. That's important — domain spoofing is cheap, scalable, and was the dominant phishing pattern through most of the 2010s. But modern attackers have largely moved on: lookalike domains (yourbrand-support.com), display-name spoofing ('Acme Support' <random@gmail.com>), compromised vendor accounts, and AI-generated personalised pretexting are all immune to your authentication posture. A complete defence layers detection on top of authentication.

SPF — the basics done right

List every IP or include: mechanism that's authorised to send mail as your domain. Common failure: 10+ include: lookups blowing the SPF flattening limit. Solutions: SPF flattening services (with monitoring for IP changes), consolidating sending platforms, or moving to ARC-aware infrastructure. Use -all (hard fail) not ~all (soft fail) once you're confident in coverage; without -all, DMARC alignment is weaker.

DKIM — rotate and align

Use 2048-bit RSA keys (1024 is deprecated for new deployments). Rotate keys every 6-12 months — automation matters here, manual rotation gets forgotten. Use a unique selector per sending platform so revoking one doesn't break others. Verify alignment between the DKIM d= domain and your DMARC org domain — relaxed alignment is the default and usually fine, strict only if your business case requires it.

DMARC rollout — the 8-week path

Week 1-2: publish p=none with rua and ruf reporting addresses pointed at a DMARC analyser (Dmarcian, Valimail, EasyDMARC, or a self-hosted parser). Week 3-6: review reports, identify every legitimate sender, fix their SPF/DKIM, and confirm alignment. Week 7: move to p=quarantine pct=10. Week 8-12: ramp pct to 100, then move to p=reject. Communicate to internal stakeholders before each step — finance, HR, marketing, and any vendor sending on your behalf.

MTA-STS — encrypt the transport

MTA-STS forces inbound mail servers to use TLS when sending to you and to verify your TLS certificate. Without it, an attacker who can intercept SMTP traffic can downgrade or MITM email between providers. Publish an MTA-STS policy at mta-sts.yourdomain.com with mode=enforce (after a brief mode=testing period), and pair it with TLS-RPT so you get reports of any TLS failures.

BIMI — the visible payoff

Once you're at DMARC p=reject (or strict quarantine), you can publish a BIMI record to display your logo next to your authenticated emails in Gmail, Yahoo, Apple Mail, and increasing-coverage providers. You need an SVG Tiny PS logo (specific format, not any SVG) and a Verified Mark Certificate from DigiCert or Entrust ($1.5-2k/year). The cert is the gate that makes BIMI valuable — it confirms the logo matches your registered trademark. BIMI is the lever that gets DMARC rollouts funded inside marketing-led organisations.

Beyond authentication — impersonation detection

Layer an inbound email-security gateway that scores messages on: display-name vs From-address mismatch; lookalike-domain detection (Levenshtein, homoglyph); freemail senders using executive names; first-time-sender flags; unusual reply-to domains; semantic anomalies (a 'CFO' email asking for gift cards). Microsoft 365 Defender, Google Workspace's advanced phishing protection, Abnormal Security, Tessian, and IronScales all play in this space; pick based on your existing platform, not feature checkboxes.

Vendor email compromise — the underrated threat

Your DMARC posture means nothing when an attacker has compromised your supplier's legitimate mailbox and sends fraudulent invoices from a real, authenticated address. Defences: behaviour-based detection (sudden change in invoice details, banking instructions, urgency cues); finance-process controls (call-back verification on any payment detail change, ideally to a number from your records not the email); and supplier risk programs that surface their email-security posture before onboarding.

Lookalike-domain monitoring as an email defence

Most modern email-based fraud now uses lookalike domains the attacker registered minutes earlier, not your real domain. Hook your DMARC platform into a domain-monitoring feed (CT logs, dnstwist, a DRP vendor) so that newly registered lookalikes auto-feed your inbound gateway's blocklist, your DLP rules, and your customer-alert workflow. This single integration prevents more harm than any further DMARC fine-tuning.

Reporting that proves value

Monthly executive view: percentage of outbound mail authenticated, percentage of inbound impersonation attempts blocked, number of brand-lookalike domains identified, MTTR on takedowns of email-borne phishing infrastructure. Quarterly board view: incidents prevented, regulatory exposure (e.g. PCI 4.0, NIS2, FCA expectations), peer-benchmark posture (free tools like DMARC SaaS dashboards expose industry averages).

Common mistakes

Staying at p=none indefinitely 'for safety' — none does nothing protective. Skipping DKIM because SPF passes — without DKIM, forwarded mail breaks DMARC alignment. Publishing BIMI without a VMC — many providers won't render it. Treating MTA-STS as optional — without it, your authentication can be downgraded in transit. Assuming DMARC alone is a phishing defence — it isn't, and treating it as one creates dangerous complacency.

Frequently asked questions

Is DMARC enforcement enough by itself?
No. DMARC at p=reject stops domain-spoofing of your authenticated domain — that's a meaningful but narrow protection. It doesn't stop lookalike domains, display-name impersonation, freemail-based impersonation, vendor email compromise, or content-based fraud. Authentication is the floor, not the ceiling — pair it with detection.
How long does it take to get to p=reject?
A clean rollout takes 8-12 weeks for a single brand with one or two sending platforms. Larger organisations with shadow-IT sending (marketing automation, HR, billing, regional offices, third-party vendors) often take 6-12 months because the dominant work is discovering and authenticating every legitimate sender, not the DNS edits themselves.
What's the order of operations?
Inventory senders → publish SPF and DKIM for each → publish DMARC at p=none with reporting → review reports for ~30 days → fix legitimate failures → move to p=quarantine pct=10 → ramp pct up over weeks → move to p=reject. After reject, add MTA-STS, TLS-RPT, BIMI, and finally pair with inbound impersonation detection.
Does BIMI improve security or is it just marketing?
Both, indirectly. BIMI itself doesn't authenticate anything new — it requires DMARC enforcement plus a Verified Mark Certificate (VMC). The security value is that it raises the cost of getting your logo into inboxes, makes phishing emails visually distinguishable to users, and creates organisational urgency to maintain DMARC at p=reject. The brand-visibility benefit is what gets it funded; the security benefit is what makes it worth the work.