SenderCompass

Email authentication glossary: SPF, DKIM and DMARC terms

Use this glossary when you meet an unfamiliar term in a message header, a DNS setting or a delivery report. Authentication identifies authorised use of your domains; it does not by itself tell you whether a message is wanted. Read the terms in sequence and the short header example at the end to see them working together. If a definition points to a live problem, the related guides at the end of each group show what to check next.

By Alex Calder · Reviewed 15 September 2026

Worn leather-bound books arranged upright on a wooden library shelf.

Addresses and transport: the identities a recipient sees

  • From: the message-header address identifying the author, normally displayed to the recipient. Its domain is the reference identity for DMARC. Internet Message Format: RFC 5322 DMARC: RFC 9989
  • Envelope sender: the SMTP MAIL FROM identity, also called the reverse-path. It is used for delivery-error handling and may differ from the visible From address. Some messages use a null reverse-path. SMTP: RFC 5321
  • Return-Path: a header added on final SMTP delivery that preserves the reverse-path. It helps investigate the envelope identity but is not interchangeable with From. SMTP: RFC 5321
  • Reply-To: the address suggested for replies when present. It does not replace the From domain for DMARC alignment. Internet Message Format: RFC 5322 DMARC: RFC 9989
  • SMTP: Simple Mail Transfer Protocol, used to transfer mail between systems. A successful acceptance response is a transport event, not a guarantee of inbox placement. SMTP: RFC 5321 Email sender guidelines

Why these matter in practice. Most confusion in email authentication starts here: the address a person sees in From is not the same as the route identity used behind the scenes. When a supplier sends on your behalf, the envelope sender is often theirs while the visible From is yours: which is exactly why DMARC connects these identities rather than taking the From address at face value.

Authentication and alignment: the checks behind the results

  • SPF: Sender Policy Framework. A domain publishes which hosts may use its SMTP identity. SPF usually evaluates MAIL FROM, with HELO handling relevant to null reverse-path messages; it does not authenticate the visible From address by itself. SPF: RFC 7208
  • DKIM: DomainKeys Identified Mail. A signing system uses a private key; the receiver retrieves a public key and verifies the signature over selected headers and body content. The d= value identifies the signing domain. DKIM is not message encryption. DKIM: RFC 6376
  • DKIM selector: the s= value identifying a key under a signing domain. Together s=mail1 and d=example.com point to mail1._domainkey.example.com. Different selectors allow different keys to coexist. DKIM: RFC 6376
  • DMARC: Domain-based Message Authentication, Reporting, and Conformance. It connects the From domain to SPF or DKIM and publishes policy and reporting preferences. A pass requires at least one passing, aligned mechanism, not necessarily both. DMARC: RFC 9989
  • Alignment: the relationship between an authenticated domain and the From domain. Strict alignment requires an exact match. Relaxed alignment compares organisational domains, allowing qualifying subdomains to align. An authentication pass and an alignment match are separate checks. DMARC: RFC 9989
  • DMARC policy: p=none requests no DMARC-specific handling change; p=quarantine requests suspicious treatment; p=reject requests rejection for failures. Receivers can apply local policy, so these are not universal delivery guarantees. DMARC: RFC 9989

Why these matter in practice. SPF, DKIM and DMARC are complementary, not interchangeable: SPF approves a route, DKIM signs content, and DMARC decides whether either one relates to the domain a recipient sees. That relationship: alignment: is the reason a check can pass yet DMARC still fail. The SPF vs DKIM guide walks through how the checks differ, and the alignment guide explains the comparison in depth.

Evidence and delivery: reading the language of a report

  • Authentication-Results: a header carrying a checking system’s authentication conclusions. Trust results added by your receiving system, not arbitrary copies inserted by a sender. Authentication-Results: RFC 8601
  • DMARC aggregate reports: machine-readable summaries of observed sending sources, counts and authentication outcomes, requested using rua. They are not inbox-placement reports or a complete list of applications. DMARC aggregate reporting: RFC 9990
  • DMARC failure reports: per-message failure information requested using ruf. Support and disclosure vary, and privacy considerations matter. Do not expect every receiver to send them. DMARC failure reporting: RFC 9991
  • Reputation: a receiving service’s assessment of sending domains or IPs. Complaint behaviour and other sending signals can influence filtering even when authentication passes. Email sender guidelines
  • Inbox placement: whether accepted mail reaches an inbox rather than spam or another destination. “Delivered” in a sending log should not automatically be read as “in the inbox”. Provider authentication and reputation data answer different questions. Get started with Postmaster Tools Email sender guidelines

Why these matter in practice. Report and delivery language often gets misread as proof of good health. Aggregate reports describe observed sources and counts, not trusted inbox placement. If you are learning to read what your sending looks like to receivers, the headers guide and the deliverability overview give the fuller picture.

Read a short practical header example

Fictional, shortened fields for explanation, not a complete signed message:

From: Billing <billing@example.com>

Return-Path: <bounce@bounce.example.com>

DKIM-Signature: v=1; d=example.com; s=mail1; ...

Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

Assuming mx.example.net represents the trusted receiving system and these are its genuine results, DKIM passes with an exact From-domain match. That is enough for DMARC. SPF’s bounce.example.com identity would align in relaxed mode but not strict mode. Merely seeing a DKIM-Signature header would not establish a pass without verification. DMARC: RFC 9989 Authentication-Results: RFC 8601

Use a real received message to identify its actual domains before looking up DNS or changing policy.

To find these fields in a real message without exposing private data, use the safe email-header reading guide as the practical companion.

Sources and further reading

Current analytics choice: Not chosen

Withdrawing consent stops future Analytics collection and removes accessible Analytics cookies. Data already transmitted before withdrawal cannot be retrieved through this browser control.

Read our privacy and cookie information