Email Authentication: A Practical Guide

Email authentication uses three complementary protocols. Each addresses a different part of the problem, and they work together to provide comprehensive protection against spoofing.

MTA-STS and TLS-RPT address the transport layer. MTA-STS publishes a policy requiring encrypted TLS connections to your mail servers, preventing STARTTLS downgrade attacks where an attacker forces a connection to fall back to unencrypted plaintext. TLS-RPT provides reporting on TLS delivery failures so you can identify and fix encryption gaps.

Email authentication projects fail for predictable reasons. The most common is treating it as a one-time configuration task rather than an ongoing operational program.

Each of these failures is fixable, but they require intentional inventory work and staged enforcement rather than a single configuration change.

Spoofing attacks cost real money. When an attacker sends a "CEO requests a wire transfer" email from your domain, it damages relationships with customers and vendors, can lead to direct financial loss, and erodes trust in your organization's communications. Email authentication makes these attacks harder to execute and gives you visibility when someone is trying.

DMARC reporting provides investigative signal. If someone is spoofing your domain, the aggregate reports show which IP addresses are sending mail as you, what volume they're sending, and whether those messages pass or fail authentication. This helps you identify patterns, block sources, and in some cases work with law enforcement or the hosting providers involved.

Deliverability protection is a longer-term benefit. When authentication is consistent, receiving mail servers develop more confidence in your mail. Over time, this means your legitimate communications are more likely to reach inboxes rather than spam folders. The inverse is also true: domains with poor authentication reputation often see their mail silently filtered, and senders may not realize it's happening.

Where you send from matters. Your choice of domain affects brand trust, operational complexity, and risk containment. The right strategy depends on your workflows, governance capacity, and risk tolerance.

Why branded sending usually beats vendor-owned domains

Sending from your own domain (main or subdomain) creates more trust with recipients than sending from a vendor-owned domain like randomaddress@salesforce.com. Recipients recognize your brand, and the email appears more legitimate. Vendor-owned sending may be fast to set up, but it creates trust issues and gives you no control over reputation.

When subdomains make sense

Branded subdomains are often a strong operational choice for third-party sending and high-risk workflows. Use mail.example.com for marketing tools, billing.example.com for invoicing platforms, or notifications.example.com for automated alerts. This provides containment: if a vendor's configuration breaks or gets abused, the impact is limited to that subdomain rather than affecting your core domain reputation.

The tradeoffs

Subdomains improve clarity and governance. It's easier to track "who sends what" when each workflow has its own subdomain with its own SPF/DKIM/DMARC configuration. You can apply stricter policies to core domains and tailored policies to vendor subdomains based on risk. The caveat is that subdomains still need governance. Moving the problem to a subdomain without managing it just relocates the failure mode.

Email authentication works best as a staged rollout. The goal is to reduce spoofing risk without breaking legitimate mail. Start with inventory and monitoring, then tighten policy gradually as you validate senders.

The staged approach prevents the most common mistake: breaking legitimate mail by enforcing too early. Teams often get more value from a disciplined first phase than from rushing to enforcement.

BIMI (Brand Indicators for Message Identification) is a later-stage enhancement that displays your brand logo in supported email clients when your DMARC policy is at enforcement. It is not a foundational control and should only be considered after DMARC is properly enforced and stable.

What BIMI actually does

BIMI allows you to publish a brand logo that appears in supported email clients next to authenticated messages. The logo is displayed only when the message passes DMARC enforcement, providing visual confirmation that the email is legitimate. This can improve brand recognition and trust, especially for customer-facing communications.

Requirements and tradeoffs

BIMI requires a VMC from a certificate authority, which adds cost and administrative overhead. Not all email clients support BIMI, so the benefit varies by recipient. The logo must meet specific technical requirements, and you must maintain the certificate and DNS records. For most organizations, BIMI is worth considering only after DMARC enforcement is mature and stable.

When to consider BIMI

Consider BIMI if you have strong brand recognition, send high volumes of customer-facing email, and have achieved stable DMARC enforcement. BIMI is most valuable for organizations where brand trust is a competitive differentiator and where email is a primary customer communication channel. If you are still working on DMARC enforcement or have a smaller sender volume, focus on the fundamentals first.

We take an operational-first approach. We start with your real senders and business workflows rather than a generic policy target. DMARC reporting is noisy without tooling, so we implement monitoring with an owner and a review cadence so the reports actually get used. We pair email authentication with DNS hygiene, including registrar security, change control, and monitoring.

For clients, we provide DMARC monitoring through a white-labeled portal powered by our PowerDMARC partner. This gives you visibility into authentication results, sender patterns, and policy enforcement without managing the reporting infrastructure yourself. The goal is a system that protects your domain and keeps working as your sender landscape changes over time.

Email authentication connects to several related security areas. Business email compromise is the attack that email authentication directly mitigates. Our Microsoft 365 security basics guide covers the platform-level mail security features that work alongside DNS-based authentication. DNS and registrar security is the foundation: if someone can modify your DNS records, they can disable your email authentication entirely.

MFA protects the accounts that manage your email and DNS configuration. If an admin account is compromised, the attacker can change SPF, DKIM, and DMARC records to enable spoofing. These controls work as layers: email authentication makes spoofing harder, DNS security prevents authentication bypass, and MFA protects the accounts that control both.