The words, and what each one actually proves

Which servers may send for a domain.

The domain owner publishes a DNS record listing the servers allowed to send mail using that domain in the envelope sender. The receiving server checks the connecting IP against that list. SPF says nothing about the address a person actually sees.

In the analyzer: Reported with the result the receiving server recorded, plus whether the checked domain aligns with the visible From.

A cryptographic signature over parts of the message.

The sender signs selected headers and the body with a private key; the public key sits in DNS. If the signature verifies, those parts arrived unchanged and the signing domain vouches for them. A message may carry several signatures.

In the analyzer: Every signature is listed separately with its domain, selector, result and whether it aligns — because DMARC needs only one that both passes and aligns.

What the receiver should do when SPF and DKIM do not back the visible From.

The domain publishes a policy — none, quarantine or reject — and DMARC passes when SPF or DKIM passes and its domain aligns with the visible From. It is the mechanism that finally connects authentication to the address the reader sees.

In the analyzer: Reported with the published policy and the alignment mode it declares, rather than against an assumed default.

Whether the authenticated domain matches the visible From.

Relaxed alignment accepts a subdomain of the same organisational domain; strict alignment demands an exact match. Which one applies is declared by the domain itself in its DMARC record, through the aspf and adkim tags.

In the analyzer: Not just yes or no — the relationship is labelled: exact match, subdomain of the same organisation, sibling, or unrelated.

The revision that replaced the original DMARC specification.

Records still begin v=DMARC1 and nothing breaks, but the tag set changed: pct, rf and ri were removed, np and psd were added. np is the useful one — it sets the policy for subdomains that do not exist at all, which is where a great deal of spoofing is aimed. Determining the organisational domain also moved from the Public Suffix List to a DNS tree walk.

In the analyzer: The new tags are read and explained; the removed ones are still shown when a record carries them, marked obsolete, because leaving them out would hide what the record actually says.

A record of what an intermediate server saw.

Forwarding often breaks SPF and can break DKIM. ARC lets each hop seal what it observed, so a later receiver can see that authentication passed before the message was forwarded.

In the analyzer: The chain is listed with each seal and its instance number.

A superseded SPF variant, formally deprecated.

Sender ID checked a derived “purported responsible address” instead of the envelope sender. M3AAWG deprecated it in August 2026. Almost nobody publishes the records it needs, so Exchange falls back to the SPF record — which means a Sender ID failure usually just restates the SPF result.

In the analyzer: Shown when a server stamps it, marked as deprecated, and deliberately left out of the score so the same failure is not counted twice.

The server that moves mail.

A Mail Transfer Agent hands messages between systems. The sending MTA is the one the sender operates; the receiving MTA belongs to the mailbox provider. Each hop a message takes is one MTA passing it to the next.

In the analyzer: Every hop is listed in the delivery path with its timing and whether TLS was used.

A permanent delivery failure.

The receiving MTA says delivery can never succeed — the address does not exist, or the domain does not. Resending the same message will not help, and the address should come off the list.

In the analyzer: The SMTP explainer separates permanent from temporary and says which server refused.

A temporary delivery failure.

A full mailbox, a connection problem, or the provider deliberately slowing the connecting IP down. The sending system is expected to retry.

In the analyzer: Reported as temporary, with the retry implication stated.

The message that comes back when delivery fails.

A Non-Delivery Report carries structured fields — the failing address, the status code, and the diagnostic text the remote server actually returned. M3AAWG notes that senders often see only an aggregated hard/soft label and may need the real report to troubleshoot.

In the analyzer: The SMTP explainer parses the report itself rather than asking you to read it.

The provider sends you a copy when someone marks your mail as spam.

A mailbox provider forwards complaints to qualified senders so they can suppress those recipients. The models differ: Yahoo’s is domain-based and needs DKIM-signed mail, Microsoft’s is IP-based so on a shared IP the reports reach the IP owner, Gmail runs none at all, and Apple states outright that it has none.

In the analyzer: Complaint readiness is measured from the message, and Yahoo enrolment eligibility is checked against the DKIM requirement.

A published list of addresses or domains with poor reputation.

Queried over DNS. The important subtlety: a list can also refuse to answer — a public resolver may be blocked rather than the address being listed. A refused query is an error, not a verdict.

In the analyzer: Refused queries are reported as refused. Several competing tools read them as “clean” or as a listing; both are wrong.

Whether the sending IP is yours alone.

A dedicated IP sends for one brand, which owns its reputation entirely. A shared IP carries many senders at once and is usually identified with the ESP rather than any one brand — so someone else’s behaviour can affect your delivery.

How consent was obtained.

Opt-in is the recipient indicating they want your mail. Confirmed — or double — opt-in adds a step: they must click a link in a confirmation message before anything else is sent, which prevents someone being subscribed without consent. M3AAWG ranks the tiers good, better, best.

Sending from a subdomain of your brand, versus a separate lookalike domain.

M3AAWG recommends a distinct subdomain per sending purpose, so each builds its own reputation with a clear link to the brand. A separate but similar domain — a cousin domain — is discouraged: it confuses recipients and receiving systems, and it is what phishing looks like. Sending from a subdomain does not require the visible From to use it, as long as the organisational domains match.

In the analyzer: The relationship between the sending and visible domains is labelled rather than judged as pass or fail.

Raising volume gradually on a new IP or domain.

A new sending identity has no reputation. Providers treat sudden volume from an unknown source with suspicion, so volume is raised in steps. M3AAWG warns that lapses and large swings in volume damage reputation as much as a bad start.

Where bounces go — the envelope sender.

Set during the SMTP conversation and usually different from the visible From, especially for bulk mail. SPF checks this domain, not the one the reader sees, which is why alignment exists as a separate question.

In the analyzer: Shown alongside the From domain with the alignment relationship between them.

Unsubscribing from the client, without hunting for a link.

RFC 2369 defines the header; RFC 8058 adds one-click, where the client POSTs to an HTTPS endpoint and the recipient is done. Google requires it for marketing mail and Yahoo strongly recommends it.

In the analyzer: Both headers are checked, and each provider’s stated level — required or recommended — is shown next to the result.

A header that asks for complaint reports directly.

Instead of enrolling with each provider separately, the sender names an address in the message itself. It only counts if the header is covered by the DKIM signature — otherwise anyone could redirect the reports.

In the analyzer: Presence is checked, and so is whether the DKIM signature actually covers it.