A message can display a familiar company name while using an entirely different email address. It can also show your company's address while the sending service authenticates only its own domain. Understanding DMARC starts by separating those identities.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It evaluates authenticated use of the domain in the message's From address and connects that result with the domain owner's published policy. It is a domain-level assessment, not a verdict about the person, request or attachment.
Find the address behind the sender name
Suppose a mail application displays this fictional sender:
Example Accounts <notices@shop.example.com>Example Accounts is the display name. notices is the part before the at sign. shop.example.com is the domain in the From address, called the Author Domain in DMARC.
The mail application's compact view might show only the display name. Open the sender details or original message to identify the actual address. A logo, a name and a recognisable subject line do not establish that domain relationship.
The examples in this guide assume an ordinary, well-formed message with one Author Domain. Malformed or ambiguous From fields require their own message-format handling; do not invent one preferred identity from whatever a mail application happens to show.
Keep the other addresses in their proper roles
An email has an SMTP delivery conversation as well as the headers and body people read. The envelope return identity supports delivery-status handling and is normally the identity evaluated by SPF for ordinary mail. It can differ from From.
A DKIM signature supplies another domain in its d= value. A message can have several signatures, each with its own domain and result. Reply-To is different again: it influences where a reply is addressed, not which Author Domain DMARC evaluates.
| Item | Question it helps answer |
|---|---|
| From domain | Which claimed author domain is being assessed? |
| Envelope identity | Which domain is being evaluated for ordinary SPF authorisation? |
| DKIM d= domain | Which domain is associated with this signature? |
| Reply-To | Where is a reply directed? |
| Display name | What name is being presented to the reader? |
These fields can legitimately differ. The task is to understand their relationships rather than require every displayed address to be identical.
Understand the relationship called alignment
SPF can pass for a sending service's envelope domain. DKIM can verify a signature from that service's signing domain. DMARC then asks whether a passing authenticated identity aligns with the Author Domain.
Strict alignment requires an exact domain match. Relaxed alignment uses the applicable organisational-domain relationship. Do not determine that boundary by simply taking the last two labels, and do not treat two similar-looking brands as aligned domains.
For a message-level DMARC pass, at least one qualifying SPF or DKIM path must both pass and align. A passing signature from an unrelated domain cannot provide that path merely because the business owns an account with the service.
Follow two fictional messages
The following is a synthetic teaching example, not a captured or redacted customer message. Assume the applicable DMARC policy is found and the stated results come from a trusted receiving system.
Both messages have From at shop.example.com. Their identities differ as follows:
| Observation | Message A | Message B |
|---|---|---|
| SPF | Pass for returns.example.net | Pass for returns.example.net |
| DKIM | Pass with d=shop.example.com | Pass with d=dispatch.example.org |
| Aligned passing path | DKIM matches From exactly | Neither passing identity aligns |
| DMARC validation | Pass | Fail |
Message A has an exact-match DKIM path. Its separate SPF identity does not need to be renamed for that message-level DMARC result to pass.
Message B authenticates domains unrelated to its From domain. Two raw passes therefore produce no aligned path. If this is an authorised sender that needs repair, follow the alignment troubleshooting guide. That investigation is different from deciding that every message with this pattern is malicious.
Separate the result from what the receiver does
A domain owner publishes DMARC policy in DNS under an applicable _dmarc name. The policy expresses the owner's assessment of failing use. It does not configure an application's signing identity or determine every receiver's final action.
Receivers also assess information outside DMARC. Consequently, a pass does not promise inbox placement, and a failure does not independently establish a blocked attack. The policy selection guide explains how a domain's actual use affects the owner's decision.
Reporting can help the owner investigate how its domain appears in observed mail. Reports are feedback from participating receivers, not a complete ledger of every message sent. Keep reported observations separate from business authorisation and final delivery outcomes.
Read a passing result without overreading it
Use authentication results produced by the relevant trusted receiving boundary. A sender can insert a header that claims a pass; the existence of that text does not make it trustworthy.
Even a genuine aligned pass has limits. A compromised authorised account can send authenticated mail. An unrelated domain can authenticate its own messages while presenting a deceptive display name. DMARC does not inspect the truth of an invoice or approve a payment instruction.
The useful explanation is specific: this received message had a passing authenticated domain that satisfied the required relationship with its From domain. That is a valuable identity signal. Keep account protection, content assessment and independent verification of sensitive requests alongside it.
For implementation, continue with creating and verifying a DMARC record. For ownership across applications, use the sender inventory. Both become easier once the actual domain being assessed is clear.
Trace a result in five lines
Use this short worksheet when a message is described as “authenticated”. Start with the address, not the company name displayed beside it.
- From: write down the domain after @ in the actual From address.
- Evidence: use the receiving system's trusted results. Record the SPF domain and each passing DKIM d= domain separately.
- Relationship: compare each passing identity with From under the applicable strict or relaxed mode. A provider account name is not a domain match.
- Result: with an applicable policy and no unresolved DNS error, one aligned passing path is enough. If there is none, the message fails DMARC. No discovered policy means DMARC does not apply; a required DNS-query error is not simply a pass or fail.
- Meaning: record the identity result separately from delivery and whether the request is safe to act on.
For Message A above, the explanation is: “DKIM passed for shop.example.com, which exactly matches From; this supplies a DMARC pass.” It is not: “The invoice is approved.”
Check the DMARC processing steps and the Authentication-Results trust boundary for these distinctions.