Skip to content
SenderProbe
Guide

How a receiving server decides a message really came from you

A receiving mail server never sees who sent a message. It sees an IP address, an envelope, a set of headers, and whatever your DNS says about them. Email authentication is the small set of published records that turn those signals into an answer it can act on.

Updated 5 August 2026 9 minute read

Two sender identities, and only one of them is visible

Every message carries at least two claims about who sent it, and nothing requires them to agree. The envelope sender — the address given in MAIL FROM during the SMTP conversation, defined by RFC 5321 — is where bounces are returned. The header From, the field defined by RFC 5322, is the address a mail client displays beside the subject line.

Legitimate mail routinely uses different domains in the two places. A mailing list, a bounce processor and most bulk sending platforms put their own domain in the envelope so that failures come back to them, while leaving your domain in the header From so the recipient sees you. That is normal, and it is also exactly the gap that domain spoofing exploits: a sender who wants to impersonate you does not need to touch your servers, because the header From is a line of text they write themselves.

The envelope sender is example.org and the address the recipient will see is example.com. SMTP permits this, which is why a receiver needs more than one check.
220 mx1.example.net ESMTP ready
EHLO relay.example.org
250-mx1.example.net
250 STARTTLS
MAIL FROM:<[email protected]>
250 2.1.0 Ok
RCPT TO:<[email protected]>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: Billing <[email protected]>
Subject: Your invoice

SPF: which hosts may put your domain in the envelope

SPF, defined by RFC 7208, is a TXT record listing the hosts authorised to send mail with your domain in the envelope sender. A receiver takes the connecting IP address and the domain from MAIL FROM, evaluates your record, and arrives at one of seven results: pass, fail, softfail, neutral, none, temperror or permerror.

What that proves is narrow but useful — the machine currently connected is one you published. What it does not prove is anything at all about the header From, or about the body of the message. It is also fragile in transit: when a recipient forwards a message, the forwarding server relays it with the original envelope sender from an IP address your record has no reason to list, and SPF fails through no fault of yours.

DKIM: a signature that travels with the message

DKIM, defined by RFC 6376, works on the message rather than the connection. The sending system hashes the body and a chosen list of headers, signs the result with a private key, and adds a DKIM-Signature header naming the signing domain in its d= tag and the key in its s= tag. The receiver fetches the matching public key from DNS and verifies.

A valid signature proves two things: the domain in d= took responsibility for the message, and the parts that were signed have not changed since. Because the proof travels inside the message, it survives forwarding — as long as no hop rewrites something that was signed. What DKIM does not prove on its own is that the signing domain has anything to do with the address the recipient reads, since anyone may sign their own mail with their own key.

DMARC: attaching a result to the address people read

DMARC, defined by RFC 7489, is the piece that connects the other two to the visible identity. It is published as a TXT record at the _dmarc label of your domain, and it does three things: it requires that a passing mechanism refer to the same domain as the header From, it states what a receiver should do when nothing does, and it asks for reports.

The requirement that the two identities match is what DMARC alignment means. A message passes DMARC when SPF passes and the envelope domain aligns with the header From domain, or when DKIM passes and the d= domain aligns. Only one aligned pass is needed. A message can carry an SPF pass for a bounce domain the recipient never sees and still fail DMARC outright, because that pass was never about the address on screen.

A starting DMARC record: no enforcement yet, aggregate reports requested, relaxed alignment on both mechanisms.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r"

Why all three are needed

The three records are often described as alternatives, or as a checklist where two out of three is close enough. They are neither. Each one covers a failure the others do not, and DMARC has nothing to evaluate unless at least one of the other two is deployed and aligned.

  • SPF authenticates an identity the recipient never sees, so on its own it does nothing about a forged header From.
  • SPF fails on ordinary forwarding, because the forwarding host is not in your record.
  • DKIM survives forwarding, but breaks when a hop modifies a signed header or the body.
  • DKIM alone says a domain signed the message, not that the signing domain is the one on display.
  • DMARC supplies both the alignment requirement and the policy, but it can only report none when neither mechanism is present.
  • Because either aligned pass satisfies DMARC, running SPF and DKIM together gives every message two chances to survive a path that damages one of them.

What the receiver writes down

A receiver that runs these checks records the outcome in an Authentication-Results header, defined by RFC 8601, before the message reaches the mailbox. It is the closest thing to a receipt you will get, and reading one is the fastest way to find out which identity actually failed.

Each result names the identity it applies to: smtp.mailfrom for SPF, header.d or header.i for DKIM, header.from for DMARC. Comparing those three values is usually enough to explain a surprising DMARC failure, because in most cases the mechanism passed and the domain simply did not match.

An Authentication-Results header in which all three identities refer to example.com, which is what an aligned pass looks like.
Authentication-Results: mx1.example.net;
    spf=pass (example.net: domain of [email protected] designates
        192.0.2.25 as permitted sender) smtp.mailfrom=example.com;
    dkim=pass header.d=example.com header.s=s2026a header.b=Lk3Qm9tA;
    dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Deploying the three in order

The order matters, because DMARC enforcement applied before the inventory work is finished is how an organisation loses its own invoices. Each step below is safe to sit on for as long as the reports say you should.

  • List every system that sends with your domain: the mail platform, the marketing tool, the invoicing system, the monitoring alerts, the CRM, and anything a department signed up for without telling you.
  • Publish an SPF record covering those sources and ending in ~all while you are still finding them.
  • Enable DKIM signing on each source, with a distinct selector per platform so that one provider's key rotation never touches another's.
  • Publish DMARC with p=none and a rua address, and change nothing else for a few weeks.
  • Read the aggregate reports until every legitimate source shows an aligned pass on SPF, DKIM, or both.
  • Tighten to p=quarantine, then to p=reject, keeping rua in place permanently — the reports are the only view you have of what is being sent in your name.

What authentication does not do

Email authentication answers one question: is this message genuinely from the domain it claims. It says nothing about whether the message is wanted. A message that passes SPF, DKIM and DMARC can still be filtered, because a spammer can publish exactly the same three records for a domain they registered this morning and pass every one of them.

Placement is decided after authentication, by the reputation of the sending IP address and domain, by whether recipients engage with the mail, by the content of the message, and by whether the sending IP appears on a blocklist. Authentication is the entry condition, not the verdict.

Check this on your own domain. The spf record checker reads the live records and reports what a receiver would see.

Open the spf record checker

Common questions

If DMARC only needs one mechanism to pass, why publish both SPF and DKIM?
Because they fail in different places. SPF breaks whenever a message is forwarded, since the forwarding host is not in your record. DKIM breaks whenever a hop alters a signed header or the body, which mailing lists do routinely. Publishing both means a message that loses one still has an aligned pass and still satisfies DMARC.
Does email authentication stop someone spoofing my display name?
No. Display-name spoofing puts your name or brand beside an address at a domain the attacker controls, and DMARC only governs messages whose header From domain is yours. The records make your own domain unusable by an impersonator; they cannot stop somebody registering a lookalike domain and authenticating it correctly.
Will publishing DMARC with p=none change how my mail is delivered?
No. A policy of none asks receivers to take no special action on failures and to send you aggregate reports about what they saw. It is the observation phase, and it is the only safe way to discover the sending sources nobody remembers signing up for before enforcement starts rejecting them.
What should a domain that never sends mail publish?
Publish an SPF record of v=spf1 -all, a DMARC record with p=reject, and a null MX record if the domain also receives no mail. Parked and internal-only domains are a common vehicle for spoofing precisely because nobody thought they needed records, and the three above cost nothing to maintain.
Which record should I publish first?
SPF, because it is the one you can complete from an inventory of your sending systems without touching any of them. DKIM comes next and needs work on each sending platform in turn. DMARC comes last, since a DMARC record is only meaningful once at least one of the other two produces an aligned pass.

Keep reading

Related checks, definitions and guides.