Beyond SPF, DKIM, and DMARC: The Rest of the Email Security Toolbox

This is Part 4 — the final chapter — of our email security series. Part 1 covered SPF, Part 2 covered DKIM, and Part 3 covered DMARC. Together, those three are the foundation — the difference between "anyone could send email pretending to be us" and "our domain is far better protected from direct spoofing."

But they're not the whole story. There's a second tier of technologies that most businesses have never heard of, mainly because they're not required in the same way SPF, DKIM, and DMARC increasingly are. Some are about building trust and recognition once you're already authenticated. Some close smaller, quieter gaps that authentication alone doesn't cover. And one is still being developed. This post rounds up all of it in one place.

Getting your logo into the inbox

Once your domain is authenticated, the next layer is about recognition — literally getting your logo to show up next to your business's emails in the inbox.

BIMI (Brand Indicators for Message Identification) is the standard that makes this possible. When it's set up correctly, supporting inboxes may display your verified logo alongside your message. But BIMI doesn't work on its own — it requires DMARC to already be set to an enforced policy (quarantine or reject, not just monitoring) and applied to 100% of mail, plus a specific DNS record and properly formatted logo files served over HTTPS. Providers such as Gmail and Apple also require the logo to be backed by an accepted certificate.

Whether your logo actually shows up, and what it looks like when it does, depends on which certificate (if any) backs it up:

• A VMC (Verified Mark Certificate) generally requires your logo to be registered with a recognized trademark authority. It's the most widely supported option — Gmail, Apple Mail, and Yahoo Mail all recognize it, and Gmail specifically adds a blue verified checkmark next to logos backed by a VMC.
• A CMC (Common Mark Certificate) is the newer, lighter-weight alternative that can cover an unregistered logo — for a prior-use mark, you need proof the logo has been in continuous use on a domain you control for at least 12 months. Gmail added support for it in late 2024, and it will display your logo as a brand avatar, just without the blue checkmark.
• Yahoo Mail is the most permissive of the major providers — it may display your logo without any certificate at all, as long as your DMARC policy is enforced and your sending reputation is solid.
• Microsoft Outlook and Exchange Online still don't render incoming BIMI logos. Microsoft may display some logos through its own proprietary brand and profile systems instead. If a large share of the people you email use Outlook, this is worth knowing going in — BIMI simply won't reach them yet.

Separately — and often confused with BIMI-in-Apple-Mail — is Apple Branded Mail, part of Apple Business, formerly Apple Business Connect. It's Apple's own program, not tied to the BIMI standard, and it's what controls your logo and business name showing up in the Mail app on supported Apple devices and in iCloud Mail on the web. It has its own organization, brand, and domain approval process (including a TXT record Apple gives you), and it requires enforced DMARC plus DKIM authentication — SPF alone isn't enough — separate from whatever you've set up for BIMI elsewhere.

Locking down how the message actually travels

Authentication helps a receiving system verify that a message was authorized by the sending domain and, with DKIM, that the signed portions weren't altered. It doesn't say anything about whether the connection it traveled over was actually encrypted. That's a separate layer:

• MTA-STS, when set to enforcement mode, tells compatible sending mail servers, in effect, "always deliver to us over an authenticated encrypted connection, and don't fall back to plain text if something goes wrong." Without it, an opportunistic TLS connection can be tricked into silently downgrading to plain text during a man-in-the-middle attack.
• TLS-RPT is the reporting side of that same coin — it tells compatible sending mail servers where to send aggregate reports about successful and failed encrypted connections to you, so problems surface instead of failing silently.
• DANE takes a different, DNS-based approach: it uses TLSA records to specify the certificate, public key, or certificate authority your mail server is allowed to use. But DANE only works if DNSSEC — a way of cryptographically signing your DNS records so they can't be tampered with in transit — is also switched on for your domain. The two are effectively a package deal.

The pieces that still need specialized tools to check

A few closely related technologies confirm what's actually happening at the moment of connection — not just what's published in DNS, but what the mail server does in real time:

• SMTP STARTTLS — confirms your mail server actually offers an encrypted connection when another server tries to deliver mail to you.
• TLS Certificate validity — checks the certificate presented during that handshake, including its hostname, expiration, and trusted certificate chain when normal public-certificate validation is expected. A self-signed certificate isn't automatically useless for SMTP — it can still encrypt opportunistic TLS and can be explicitly authenticated through DANE — but it won't satisfy MTA-STS certificate validation by itself.
• TLS Protocol Security — checks which TLS versions and encryption settings your server still accepts, including whether old, insecure choices remain enabled.

These three don't show up as DNS records you can simply look up — checking them for real requires actually connecting to your mail server on port 25, which is exactly the kind of low-level network access that a normal browser is deliberately blocked from doing. A webpage running entirely in your browser can't perform that test itself; an online tool needs server-side SMTP testing infrastructure behind it. That's why ns19.com's Email & Domain Health tool, which can check BIMI, MTA-STS, TLS-RPT, DANE/DNSSEC, and Apple Branded Mail today, marks these as "coming soon" rather than faking a result.

Keeping authentication intact after the message leaves your server

Here's a gap that trips up a lot of otherwise well-configured domains: ordinary forwarding usually breaks SPF because the forwarding server has a different IP address, while mailing lists and some forwarding services may also modify a message slightly — adding a footer, tweaking the subject line — and that small change can break the original DKIM signature. If neither SPF nor DKIM still passes in alignment, DMARC fails, and a completely legitimate forwarded email may be quarantined or rejected.

ARC (Authenticated Received Chain) was designed to help with exactly this. When an ARC-enabled mailing list, forwarder, or security service handles your message, it can record and sign the authentication results it observed before the message was changed. The next server in line may take that history into account if it trusts the ARC sealer, even though it can no longer verify the original authentication directly. ARC doesn't replace SPF, DKIM, or DMARC, and it never guarantees that a receiving provider will accept the message.

There's an important 2026 wrinkle: ARC is still used by major mail systems, but the IETF is now working to move the ARC experiment to historic status after it fell short as a dependable Internet-wide solution. Lessons learned from ARC are helping shape DKIM2, discussed below, so ARC is better viewed as something already present in today's mail flow than as the long-term answer businesses should rush to deploy themselves.

Closing the door on domains you're not using

Most businesses own more domains than they actively email from — old brand names, defensive registrations, domains bought just to keep someone else from grabbing them. Every one of those is a potential target for spoofing if it's left with no explicit policy at all.

Null MX, defined in RFC 7505, is one part of the fix: a single DNS record that explicitly declares "this domain receives no email whatsoever." For a domain that should neither send nor receive mail, combine it with an SPF record of `v=spf1 -all` to declare that no servers are authorized to send from it, plus an enforced DMARC policy such as `p=reject` to protect the visible From domain. Null MX stops incoming delivery attempts; SPF and DMARC are the pieces that help shut down outbound spoofing.

The unsubscribe rule bundled in with deliverability

Since 2024, Gmail and Yahoo have required bulk senders to support one-click unsubscribe for marketing and subscribed messages, as defined in RFC 8058 — a technical header that lets someone unsubscribe directly from within Gmail or Yahoo's interface, rather than being routed to a webpage first. Google applies the requirement when a domain sends more than 5,000 messages per day to personal Gmail accounts; Yahoo defines bulk sending more generally and doesn't publish the same fixed numerical threshold. Gmail also requires a clearly visible unsubscribe link in the message itself. It's not framed as an authentication technology, but it's now bundled into the same sender-reputation conversation as SPF, DKIM, and DMARC, and mailbox providers do factor compliance into deliverability. Most small businesses sending day-to-day correspondence fall well under Google's threshold — but anyone running email marketing or newsletter campaigns at scale should have this on their radar.

A different kind of protection entirely

Almost everything in this series — SPF, DKIM, DMARC, ARC — works at the domain level: it helps show that the sending domain authorized the message. S/MIME works differently. It uses a certificate and private key configured for an individual user or email identity to digitally sign a message so the recipient can verify its sender and that it wasn't altered. It can also encrypt the message's actual content so only the intended recipient can read it, although doing that requires access to the recipient's public S/MIME certificate. It's much more common in law, healthcare, finance, and government, where the content of a specific email — not just the domain it came from — needs to stay private.

The quiet reputation check happening in the background

Reverse DNS, and more specifically Forward-Confirmed Reverse DNS (FCrDNS), is a check that happens without either party publishing anything dramatic. It confirms that the IP address your mail server sends from has a PTR record pointing to a hostname, and that the hostname's regular A or AAAA record points back to the same IP address. It isn't strong proof of the visible From domain, but it is an important infrastructure and reputation check that helps receiving systems distinguish established mail servers from suspicious or misconfigured ones. If you're on Microsoft 365 or Google Workspace, this is already handled for you by the provider. If you run your own mail server, it's worth confirming with whoever manages your IP allocation, since reverse DNS records are controlled by the network owner, not your domain registrar.

What's still on the horizon

One more thing worth knowing about, even though there's nothing to set up yet: DKIM2 is a proposed successor to DKIM, still an active working-group draft under discussion at the IETF as of August 2026. It's designed to close some of DKIM's known weak points — particularly around messages that get replayed or forwarded in ways the original standard didn't anticipate — and it incorporates lessons learned from the ARC experiment. It has no standardized production deployment yet and there's no timeline for when it might be ready, so there's genuinely nothing for a business to act on today. But if you hear "DKIM2" mentioned somewhere down the road, now you'll know what it's referring to.

Where does your domain actually stand?

That's a lot of ground to cover — which is exactly why most businesses have never heard of half of this. If you want to see where your own domain stands today, ns19.com's Email & Domain Health tool checks several of these — BIMI, MTA-STS, TLS-RPT, DANE/DNSSEC, and Apple Branded Mail — for free, in seconds.

And if it turns out there's work to do — whether that's getting BIMI live, tightening up transport security, or just making sense of which of these actually matter for your business — that's exactly the kind of thing we can help you sort out. Start a conversation, or give us a call at (954) 274-9020.

The bottom line

SPF, DKIM, and DMARC are the foundation, and if you've only got room to do three things, those are the three. Everything in this post is what comes after — the layer that separates "technically protected" from genuinely buttoned-up: your logo showing up where customers can see it, supported sending servers being required to deliver to you over encrypted connections, authentication surviving the trip through a mailing list, unused domains locked down instead of left wide open, and one technology still being built that's worth knowing about before it arrives.

That's the whole series. Thanks for reading — and if any of the last four posts turned up something on your own domain worth fixing, you know where to find us.

All product names, trademarks, and registered trademarks mentioned in this article — including Gmail, Yahoo Mail, Apple Mail, Apple Business, Apple Business Connect, Microsoft 365, Outlook, and Google Workspace — are the property of their respective owners and are used here for identification and informational purposes only. Timent Technologies is not affiliated with, sponsored by, or endorsed by any of the companies mentioned.