$ guides
How email authentication works
Three standards, one verdict, and a sequence that explains why a message can satisfy two of them and still be filtered. This page is the map. Every term in it has a page of its own, and the last section says what order to read them in.
Three standards, and they are not peers. SPF authorises the sending machine. DKIM signs the message. DMARC compares whichever of those passed against the From address on screen, and publishes what a receiver should do when neither matches. Only the DMARC verdict changes what happens to the mail.
What a receiving server checks, and in what order
The checks do not run together. They happen at different points in the SMTP conversation, against different things, and an early one can end the conversation before a later one is reached. The order is the part most explanations leave out, and it is what makes the failures legible.
- 01
At connection, against the IP
Before your server has said who the mail is from or what it contains, the receiver has the connecting address and can look it up. Forward-confirmed reverse DNS is evaluated here, along with whether the IP is on a blocklist. A few receivers will not continue the conversation at all when this goes badly.
- 02
At the envelope, against MAIL FROM
SPF compares the connecting IP against the record published by the envelope domain. This happens during the SMTP exchange, before the message itself has been transmitted, which is why nothing in the body or the headers can change the result.
- 03
After the message arrives, against the signature
DKIM verification needs the signed headers and the body in hand, so it cannot happen any earlier. The receiver fetches a public key from DNS and checks the signature against what it received.
- 04
Last, over the results of the other two
DMARC is not a fourth test of the message. It reads the two verdicts already produced, compares the domains those checks authenticated against the From header, and applies the policy that domain published. It is the only one of the three that tells a receiver what to do.
Reputation is not a step in that list. It runs alongside all of it, attached to the sending IP and to your domain, assembled from what you have sent before and how people reacted to it. Authentication settles whether you are who you claim to be. Reputation settles how much that is worth. The case for treating the second as an engineering concern rather than a support queue is on the deliverability page; this one stays with the mechanism.
The three standards
They arrived in this order, about a decade apart end to end, and each exists because the one before it left a gap that could be walked through.
SPF: which machines may send
SPF is a single DNS record naming the servers allowed to send for a domain. It answers one question about the connecting machine and asks nothing about the message. Two things make it brittle: it breaks on forwarding, because a forwarder connects from an address that was never in your record, and its evaluation is capped at ten DNS lookups, past which the record stops working while still looking correct. The syntax, the qualifiers and that limit are on the SPF page.
DKIM: who took responsibility
DKIM attaches a signature covering the body and a named set of headers, and publishes the verifying key in DNS under a selector. A valid signature proves that a domain holding that key authorised the message and that the signed parts arrived unaltered. It proves nothing about which machine delivered it, which is precisely why a signature survives relaying and forwarding where SPF does not. The tags, and what a signature leaves unprotected, are on the DKIM page.
DMARC: the policy over both
DMARC is a record that does three jobs: it requires one of the other two to match the visible From domain, it states what a receiver should do when neither does, and it asks for daily aggregate reports on everything sent under your name. The reports pay for themselves immediately. Publishing a monitoring-only policy changes no delivery outcome and returns an inventory of every system sending as your domain, which is reliably longer than the list you would have written from memory. The policies and the route to enforcement are on the DMARC page.
Why alignment is the one that fails
A message can pass SPF, pass DKIM, and still fail DMARC. That is not an edge case, and at most providers it is not a mistake anyone made.
SPF and DKIM take their identities from different parts of the transaction — one from the SMTP envelope, one from a signature over the message — and neither of those places is where the recipient looks. Closing that gap is DMARC's entire contribution: it requires one of the two authenticated domains to match the From header a mail client shows, and either one matching is enough. That comparison is alignment, and the glossary page sets out which identity each check actually takes.
The common failure is structural rather than accidental. A provider that returns your bounces to its own domain and signs with its own key hands you two passes and no alignment, and it does that because giving every customer an aligned return path means maintaining DNS per customer while one shared bounce domain does not.
There are two ways out, and neither is yours to take unilaterally. Aligning DKIM means getting the provider to sign as your domain, with a selector it issues and you publish — the easier of the two, and the one that survives forwarding. Aligning SPF means moving the envelope sender onto a host under your own domain, which the provider has to be willing to accept bounces at. Both end in a record you control. Both begin with whether the provider offers it at all. Either one alone passes DMARC, so the first move is the question rather than the DNS change.
The same failure read out of a real message, header by header, with the three verdicts on one line, is in why your password reset emails land in spam.
What the infrastructure has to look like
Authentication proves things about a domain. Receivers also form a view of the machine, and they form it first.
A sending IP needs a PTR record naming a host, and that host needs to resolve back to the same IP. Both halves, or the claim is worth nothing: whoever controls an IP block can publish a PTR saying anything at all, and the forward lookup is what makes the hostname's owner agree to it. The full definition, and the four ways the pair stops agreeing, are on forward-confirmed reverse DNS. It belongs on a schedule rather than in a provisioning checklist, for the reason reverse DNS rots quietly sets out: when it breaks, nothing anywhere reports an error.
TLS on the connection is the other expectation, and it is no longer negotiated as a courtesy. Both appear on the list Gmail and Yahoo published for senders above 5,000 messages a day, alongside authentication, alignment and a ceiling on spam complaints — the bulk sender requirements. A transactional sender usually sits well under that threshold and should still read the list, minus the one-click unsubscribe line, which is a rule about promotional mail.
How your application hands the message over — an SMTP relay or an HTTP API — changes none of this. What it changes is who owns the sending IP, and therefore whose behaviour the reputation on that IP records.
What to do with what comes back
Every send produces a result, and the results are an input to the next send. Ignoring them is how a sender with correct DNS still ends up filtered.
A rejection is either permanent or temporary, and the SMTP response code says which. Permanent means the address will not take mail from you again — it does not exist, the domain does not, or a policy decided it. Retrying a permanent rejection is not persistence. It is one of the clearest negative signals available to a receiver, and it is nearly always a queue with no memory rather than a decision someone made. How to read the codes, including the family that is about you rather than about the address, is on hard bounce.
The thing that stops the retry is a suppression list: the set of addresses checked before every message leaves, holding permanent failures, spam complaints and unsubscribes. Its value is in being part of the sending path. A list that gets consulted when someone remembers is a report.
None of this is special handling for transactional email. Receivers have no flag for it and no header grants an exemption, so a password reset is filtered by the same systems as a newsletter. What differs is the cost of being wrong. A filtered newsletter loses an open. A filtered password reset produces a person locked out of an account and a support conversation that never once uses the word email.
Read in this order
Thirteen pages. The first two establish what is being sent and how it leaves. The middle is the authentication itself, in the order a receiver applies it. The last four are what happens after a message is accepted or refused. Every glossary entry is written to be correct for any sender, not only for a Pharos account.
- 01 Transactional email
What kind of mail this is about, and why the filtering is identical to bulk mail while the cost of failure is not.
- 02 SMTP relay
How an application hands a message over, what the four connection settings mean, and why port 25 times out.
- 03 SPF
The record, the qualifier on all that actually expresses a policy, and the ten-lookup limit that silently disables it.
- 04 DKIM
The signature, the selector, and which headers a signature does and does not protect.
- 05 DMARC
The record that ties the first two to the visible address, the three policies, and how to reach enforcement without breaking live mail.
- 06 DMARC alignment
The question that decides the verdict, and the reason two passing checks can still add up to a failure.
- 07 Why your password reset emails land in spam
The same failure in a real message, read out of the Authentication-Results header line by line.
- 08 Forward-confirmed reverse DNS
What the sending machine looks like from the outside, checked before a word of your message has been transmitted.
- 09 Reverse DNS rots quietly, and your mail goes with it
Why that check is the one most likely to be true on the day you set it and false a year later.
- 10 Hard bounce
Reading the response code, and the 5.7.x family that is about you rather than about the address.
- 11 Suppression list
What belongs on one, what does not, and why it has to sit in the sending path rather than in a weekly cleanup.
- 12 Bulk sender requirements
The conditions Gmail and Yahoo attach to accepting mail, and which of them apply below the stated threshold.
- 13 Sending email from an n8n workflow without wrecking your domain
All of it applied to an unattended sender, where nobody is watching when a send at three in the morning is filtered.