Email Authentication Guide: SPF, DKIM, DMARC, MTA-STS & BIMI

Email is still one of the easiest ways to impersonate an organization. The basic SMTP protocol was designed to move messages, not to prove that the visible sender is honest. That is why modern domain owners need a layered email-authentication setup: SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and sometimes BIMI or DANE.

This guide explains what each layer does, how the records fit together, and how to roll out stronger protection without breaking legitimate mail.

Quick check: run PrivKit's Email Security Checker to audit your own domain's MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI records.

The Email Trust Problem

When a person opens an email, they usually look at the display name and the visible From address. Attackers abuse that habit. They can send messages that claim to be from a bank, payroll vendor, executive, SaaS product, or internal helpdesk. Without authentication, the receiver has little evidence that the domain in the From header really authorized the message.

Email authentication gives receiving servers a way to ask better questions:

Is this sending server allowed to use the domain?
Was the message signed by a domain-controlled key?
Does the authenticated domain align with the visible From domain?
What should the receiver do when authentication fails?
Should SMTP delivery require trusted TLS?
Where should failures be reported?

No single record answers all of those questions. SPF, DKIM and DMARC handle identity and policy. MTA-STS and DANE handle transport security. TLS-RPT provides reporting. BIMI adds a brand indicator on top of a strong DMARC posture.

SPF: Authorizing Sending Servers

Sender Policy Framework, usually called SPF, is a DNS record that lists which servers may send mail for a domain. A simple SPF record might look like this:

example.com TXT "v=spf1 include:_spf.example-mail-provider.com -all"

When a receiving server gets a message, it can check the connecting IP address against the SPF policy for the envelope sender domain. If the IP is authorized, SPF passes. If it is not authorized, SPF can fail.

SPF is useful, but it has limits:

SPF checks the envelope sender, not always the visible From address that the user sees.
SPF can break when messages are forwarded.
SPF records have DNS lookup limits.
Multiple SPF records can cause SPF evaluation to fail.

SPF best practices

Use one SPF record per domain. Include only providers that actually send mail for you. Remove old marketing platforms, helpdesk systems, CRMs, and infrastructure providers after they are no longer used. End with -all when you are confident the authorized sender list is complete; use ~all only as a softer transition state.

Avoid unnecessary a, mx, ptr, and broad include mechanisms. Keep the record readable and maintain a separate internal inventory of every service allowed to send mail.

DKIM: Signing Messages With a Domain Key

DomainKeys Identified Mail, or DKIM, adds a cryptographic signature to outgoing messages. The sending service signs selected headers and body content with a private key. The receiving server finds the public key in DNS and verifies the signature.

A DKIM record is stored under a selector:

selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_HERE"

The selector lets a domain use multiple keys for different providers or rotate keys without changing the whole domain setup.

DKIM helps prove that a message was signed by a domain-controlled system and was not modified after signing. It is especially important because DMARC can pass when either SPF or DKIM passes and aligns with the visible From domain. DKIM often survives forwarding better than SPF.

DKIM best practices

Use DKIM for every legitimate sending platform. Keep a list of selectors and providers. Rotate keys on a planned schedule. Remove old selectors after a provider is retired. Prefer long modern keys where supported, and avoid leaving empty or revoked keys as the only published selector.

DMARC: Turning Authentication Into Policy

Domain-based Message Authentication, Reporting, and Conformance, or DMARC, connects SPF and DKIM to the visible From domain. It also tells receivers what policy the domain owner wants applied when authentication fails.

A basic monitoring record looks like this:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

A stronger enforcement record might look like this:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100"

DMARC checks alignment. That means the domain authenticated by SPF or DKIM must match, or be related to, the visible From domain. This is what makes DMARC powerful against direct domain spoofing.

DMARC policies

p=none means monitor only. Receivers can send reports, but the policy does not ask them to block failed mail.

p=quarantine asks receivers to treat failing mail as suspicious, often by placing it in spam or quarantine.

p=reject asks receivers to reject failing mail. This is the strongest anti-spoofing posture.

A safe DMARC rollout path

Start with p=none and collect aggregate reports. Identify every legitimate sender. Fix SPF and DKIM alignment for each sender. Move to p=quarantine with a low pct value if needed. Increase coverage gradually. Move to p=reject once reports show legitimate mail is passing consistently.

Do not jump straight to p=reject unless you already know all legitimate mail streams are authenticated and aligned.

MTA-STS: Requiring Trusted TLS for Mail Delivery

Most people associate TLS with HTTPS websites, but SMTP also uses TLS. The problem is that SMTP TLS has historically been opportunistic: if encryption is unavailable or can be downgraded, delivery may continue in a weaker state.

SMTP MTA Strict Transport Security, or MTA-STS, lets a receiving domain publish a policy that says: senders should deliver to these MX hosts only over trusted TLS.

MTA-STS has two parts.

First, a DNS TXT record:

_mta-sts.example.com TXT "v=STSv1; id=2026051501"

Second, a policy file hosted over HTTPS:

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

The mode can be testing, enforce, or none. Start with testing, verify reports, then move to enforce when the policy is correct.

MTA-STS best practices

Make sure the HTTPS policy file is reachable at the exact required path. Use a valid TLS certificate. Ensure every mx: pattern matches your real MX hosts. Keep id= updated when the policy changes so senders know to refresh their cached policy.

TLS-RPT: Seeing Mail Transport Failures

SMTP TLS Reporting, or TLS-RPT, gives senders a place to report TLS delivery problems. It is especially valuable when MTA-STS is enabled because it shows policy mismatches, expired certificates, TLS negotiation failures, and other problems that could block or weaken mail delivery.

A TLS-RPT record looks like this:

_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Reports can generate operational noise, so send them to a mailbox or service that can parse and summarize them. The goal is not just to publish the record, but to watch the failures.

BIMI: Displaying a Brand Indicator After Authentication

Brand Indicators for Message Identification, or BIMI, lets participating mailbox providers show a brand logo next to authenticated email. BIMI is not a replacement for SPF, DKIM or DMARC. It is a layer that depends on them.

A BIMI record can look like this:

default._bimi.example.com TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"

The l= value points to the logo. The optional a= value points to an evidence certificate such as a VMC or CMC when required by the mailbox provider.

BIMI best practices

Enforce DMARC first. Use a correct SVG format. Host the logo over HTTPS. Understand mailbox-provider requirements before assuming the logo will appear everywhere. Treat BIMI as a brand-trust enhancement, not as the core security control.

Reverse DNS and Mail Server Reputation

Reverse DNS maps an IP address back to a hostname using PTR records. Many receiving mail systems expect mail-sending IPs to have sensible reverse DNS. Forward-confirmed reverse DNS means the PTR hostname also resolves back to the same IP.

For example:

203.0.113.10 has PTR mail.example.com.
mail.example.com resolves back to 203.0.113.10.

This does not prove that mail is safe, but missing or mismatched reverse DNS can make mail look suspicious, especially for self-hosted servers.

Use PrivKit's Reverse DNS Lookup to inspect PTR records for mail server IPs.

DANE and TLSA: Advanced Transport Authentication

DANE for SMTP uses DNSSEC and TLSA records to authenticate SMTP TLS certificates. It can provide strong downgrade-resistant transport security, but it depends on correct DNSSEC deployment.

A DANE/TLSA setup is more operationally demanding than MTA-STS. For many organizations, MTA-STS plus TLS-RPT is the more approachable starting point. For organizations with mature DNSSEC operations, DANE can be an important additional layer.

Practical Audit Checklist

DNS foundation

MX records exist.
MX hostnames resolve to valid A or AAAA records.
Mail-server IPs have PTR records where appropriate.
PTR records are forward-confirmed.

SPF

Exactly one SPF record exists.
The SPF record includes all legitimate senders.
Old providers are removed.
DNS lookup count is below the limit.
The record ends with a deliberate ~all or -all policy.

DKIM

Every provider signs outgoing mail.
Selectors are documented.
Old selectors are removed after migration.
Keys are rotated on a planned schedule.

DMARC

DMARC record exists at _dmarc.example.com.
Aggregate reporting is enabled with rua=.
Legitimate senders pass SPF or DKIM alignment.
Policy moves from p=none to p=quarantine to p=reject when ready.
Subdomain policy is set when subdomains matter.

Transport security

MTA-STS TXT exists if the domain wants TLS enforcement.
MTA-STS policy file is reachable over HTTPS.
Policy mode is testing during rollout and enforce after validation.
TLS-RPT is published and reports are monitored.

Brand layer

BIMI is added only after DMARC enforcement.
Logo URL is HTTPS.
Evidence certificate is present when required.

A Safe 30-Day Rollout Plan

Days 1-3: Inventory

List every service that sends email for the domain: corporate mail, helpdesk, CRM, marketing automation, billing, product notifications, monitoring alerts, and cloud infrastructure.

Days 4-7: SPF and DKIM cleanup

Remove old SPF includes. Add missing providers. Enable DKIM in every sending platform. Document selectors.

Days 8-14: DMARC monitoring

Publish p=none with aggregate reports. Review which sources pass, fail, and align. Fix legitimate failures.

Days 15-21: Begin enforcement

Move to p=quarantine at a low percentage if needed. Watch reports. Increase coverage as legitimate mail stays clean.

Days 22-30: Strong policy and transport security

Move toward p=reject. Add MTA-STS in testing mode. Add TLS-RPT. When reports are clean, move MTA-STS to enforce.

This schedule is only a model. High-volume or complex domains may need more time. The important part is to use reports, not guesswork.

Common Mistakes to Avoid

Treating SPF as enough

SPF alone does not protect the visible From address in every scenario. Use DMARC to connect SPF and DKIM results to the domain users actually see.

Publishing DMARC without reading reports

DMARC reports are the feedback loop. If nobody monitors them, you can miss broken senders, spoofing attempts, and readiness problems.

Forgetting subdomains

Attackers may spoof subdomains if policy is weak or ambiguous. Use the sp= tag when subdomain handling should differ from the organizational domain.

Breaking mail with strict policy too early

A strict policy is good only after legitimate senders are aligned. Move carefully and verify each step.

Publishing MTA-STS incorrectly

MTA-STS fails if the TXT record and HTTPS policy file do not agree. The policy file must be reachable, correctly formatted, and served with a valid certificate.

Frequently Asked Questions

What is the difference between SPF, DKIM and DMARC?

SPF authorizes sending servers. DKIM signs messages with a domain key. DMARC checks whether SPF or DKIM aligns with the visible From domain and tells receivers what to do when authentication fails.

Which DMARC policy should I use?

Start with p=none for monitoring. Move to p=quarantine after legitimate mail is aligned. Move to p=reject when reports show that real mail is passing consistently.

Does DMARC stop all phishing?

No. DMARC helps stop direct spoofing of your domain. It does not stop lookalike domains, compromised legitimate accounts, or malicious messages sent from authenticated systems.

Do I need MTA-STS if I already have DMARC?

DMARC and MTA-STS solve different problems. DMARC handles sender authentication and policy. MTA-STS handles encrypted SMTP transport to your receiving mail servers.

What does TLS-RPT add?

TLS-RPT gives you reports about TLS delivery failures. It helps you detect certificate errors, policy mismatches, and delivery problems that might otherwise stay hidden.

Why is BIMI not showing my logo?

Common reasons include weak DMARC policy, missing or invalid BIMI record, unsupported logo format, missing evidence certificate where required, low sender reputation, or mailbox-provider-specific requirements.

How often should I check my email authentication setup?

Check after every mail-provider change, DNS migration, DKIM key rotation, DMARC policy change, or MX change. For business domains, run a monthly audit even when nothing appears to have changed.

Check Your Domain

Run the free PrivKit Email Security Checker to test your MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI records in one place.

You can also inspect raw DNS records with Forward DNS Lookup, check mail server PTR records with Reverse DNS Lookup, review ownership with RDAP / WHOIS Lookup, and inspect certificate issuance with Certificate Transparency Monitor.

Check email security