Email Authentication Guide: SPF, DKIM, and DMARC

How email authentication works, why it matters, and how to check your domain's records.

What is email authentication?

Email authentication is a set of DNS-based mechanisms that let receiving mail servers verify that a message genuinely came from the domain it claims to be from. Three protocols work together to achieve this: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance).

Without these records, anyone can send email that appears to come from your domain. Phishing campaigns, business email compromise, and brand impersonation all exploit missing or misconfigured email authentication.

SPF: who is allowed to send

An SPF record is a TXT record on your domain that lists the IP addresses and hostnames authorized to send mail on your behalf. When a receiving server gets a message from user@example.com, it looks up the SPF record for example.com and checks whether the sending server's IP is permitted.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

The -all at the end means "reject anything not explicitly listed." Using ~all (soft fail) instead is a common transitional choice but provides weaker protection.

SPF lookup limit

SPF evaluation is capped at 10 DNS lookups. Every include:, a:, mx:, and redirect= mechanism counts. Exceeding this limit causes a permanent error (permerror), and many receivers treat that as a fail. Organizations using multiple SaaS providers frequently hit this limit without realizing it.

DKIM: cryptographic message signing

DKIM adds a digital signature to outgoing messages. The sending server signs a hash of the message headers and body with a private key. The corresponding public key is published in DNS as a TXT record under a selector subdomain, such as selector1._domainkey.example.com.

When the receiving server processes the message, it retrieves the public key from DNS, verifies the signature, and confirms that the message was not tampered with in transit. Unlike SPF, DKIM survives forwarding because the signature travels with the message.

DMARC: policy and reporting

DMARC ties SPF and DKIM together. It tells receiving servers what to do when neither SPF nor DKIM passes with alignment to the From: header domain. The policy is published as a TXT record at _dmarc.example.com:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s

The rua tag specifies where aggregate reports are sent. These XML reports from receiving servers show you who is sending mail as your domain and whether authentication passes or fails.

Alignment

DMARC requires alignment: the domain in the From: header must match the domain that passed SPF or DKIM. Strict alignment (adkim=s, aspf=s) requires an exact match; relaxed alignment (adkim=r) allows subdomains. If your transactional email is sent from mail.example.com but the From header says example.com, strict alignment will fail even if SPF passes.

Why it matters

Major mailbox providers (Gmail, Outlook, Yahoo) increasingly require all three protocols. As of 2024, Google and Yahoo require bulk senders to publish SPF, DKIM, and DMARC with at least p=none. Messages failing these checks may be silently dropped or routed to spam, regardless of content quality.

Beyond deliverability, email authentication protects your domain's reputation. A single phishing campaign spoofing your domain can erode customer trust and trigger blocklisting that affects your legitimate mail for weeks.

How to check your records

You can inspect all email authentication records for a domain using a DNS lookup tool. Query the following record types:

The netray.info DNS inspector's +check mode runs all of these lookups at once and applies lint rules to catch common misconfigurations.

BIMI: brand indicators in email

Brand Indicators for Message Identification (BIMI) allows organizations to display their logo next to authenticated emails in supporting email clients (Gmail, Apple Mail, Yahoo Mail, and others). BIMI builds on top of DMARC: only messages that pass DMARC authentication with a policy of p=quarantine or p=reject are eligible to display the logo.

BIMI is published as a TXT record at default._bimi.<domain>:

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

The two parameters:

BIMI is not a security mechanism -- it is a brand visibility feature that rewards domains with strong email authentication. The prerequisites (DMARC at enforcement, DKIM signing, SPF alignment) are the actual security measures. BIMI provides a visible incentive for organizations to deploy them.

SMTP TLS Reporting (TLSRPT)

SMTP TLS Reporting (RFC 8460) provides visibility into TLS failures during email delivery. When a sending mail server fails to establish a TLS connection to your MX servers -- whether due to an expired certificate, a misconfigured cipher suite, or a MTA-STS policy violation -- the sender generates a report and delivers it to the address specified in your TLSRPT record.

TLSRPT is published as a TXT record at _smtp._tls.<domain>:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

The rua tag specifies where aggregate reports are sent. Reports are JSON documents (often gzip-compressed) that include:

TLSRPT is the companion to MTA-STS and DANE. MTA-STS tells senders to require TLS; TLSRPT tells you when that requirement causes delivery failures. Without TLSRPT, you have no way to know if your MTA-STS policy is rejecting legitimate mail due to a misconfiguration on either side.

Key considerations:

Common mistakes

Check your domain's email authentication

Runs SPF, DKIM, DMARC, MTA-STS, TLSRPT, and BIMI checks on your domain.

Check your domain's email authentication with beacon