Authentication
SPF, DKIM and DMARC, watched rather than assumed
The gateway checks authentication on every inbound message, and for your own domains it collects the DMARC reports the rest of the internet sends about you — then tells you what they mean in a sentence.
Included on every protected domain. There is no separate DMARC product to buy.
On the way in
Every inbound message is evaluated for SPF, DKIM and DMARC before anything else looks at it, and the result is recorded with the message rather than folded into a score you cannot take apart.
- Alignment, not just a pass
- A message can pass SPF and DKIM and still fail DMARC, because what DMARC asks is whether the domain that passed is the domain in the From header. That is the check attackers rely on people not making.
- Why a signature failed
- A DKIM failure is classified rather than reported as a flat fail: no signature at all, a signature that does not verify, a key that cannot be found. These mean very different things and only one of them is suspicious.
- Recorded per message
- Message tracking shows the authentication result for any message the gateway handled, so "did that really come from them" is a lookup rather than an argument.
Reading SPF, DKIM and DMARC results
Each mechanism answers a different question, and a result only means something once you know which question it answered.
- SPF: was this server allowed to send for the envelope domain?
- pass
means the connecting server is listed. fail means the domain says it is not
(a published
-all); softfail (~all) means probably not. neutral and none mean the domain made no claim either way. permerror means the published record is broken; temperror means DNS could not be reached. SPF checks the envelope sender, which a person never sees, so a pass on its own says nothing about the From address. - DKIM: did a domain sign this message, and is the signature intact?
- A pass
names the signing domain (
d=). That domain may be a sending service rather than the brand in the From header, which is why a DKIM pass and a DMARC fail can arrive together. - DMARC: does a passing result belong to the From domain?
- DMARC passes when SPF
or DKIM passed and aligned with the domain in the From header. Its policy
(
p=none,quarantineorreject) is what that domain's owner asks receivers to do when it fails.
How the gateway weighs them
- One fact is charged once. DMARC is decided from SPF and DKIM, so adding all three together would count the same failure up to three times. The authentication contribution is the stronger of the two readings, SPF and DKIM together or DMARC, never their sum.
- An unreachable DNS server is not a pass. If a lookup could not complete and nothing else authenticated the sender, the result is recorded as temperror. It scores nothing against the sender, because our DNS problem is not evidence against them, and it does not claim an authentication that never happened.
- A pass proves the domain, not the display name. Authenticated mail has some heuristics relaxed, because legitimate mail mentions brands constantly. A brand named in the display name is not excused: the sender types that, and DMARC never checks it.
- Behind a gateway, your platform must look past it. Microsoft 365 and Google Workspace evaluate SPF against the last server that handed them the message. Without Enhanced Filtering or the inbound gateway setting, that server is the gateway, and nearly everything fails.
The result for each mechanism is recorded per message, so any of the above can be checked against a specific delivery in message tracking. How a full score is read, stage by stage, is on the demo page.
On the way out: your own DMARC reports
Publish rua=mailto:dmarc@your-domain and the aggregate reports the
world sends about your domain arrive at the gateway, because the gateway is
already your MX. They are parsed on arrival and turned into something readable.
Related, but a separate feature: Protected Domain Reputation Monitoring watches how the outside world sees your domains (blocklists, authentication health, DNS and registration) and uses these reports as one of its inputs.
- Who is sending as you. Every source IP that claimed your domain, whether it passed, and how much volume it carried.
- New senders, flagged. A source that has never appeared before is called out rather than left in a table for you to notice.
- Unauthorized senders. Volume claiming your domain that neither SPF nor DKIM supports — which is either spoofing or a marketing tool nobody told you about.
- Alignment gaps. Sources that pass one mechanism but fail alignment, the most common reason a move to enforcement breaks legitimate mail.
- Idempotent ingestion. Reporters re-send. The same report twice does not double your traffic figures.
Getting to enforcement without breaking your mail
Almost nobody fails at publishing p=none. They fail at the step
after it, because moving to quarantine or reject without knowing which legitimate
systems are still failing alignment is how a company stops receiving its own
invoices.
The console reads your current DNS record, compares it against what your last thirty days of reports actually show, and proposes the next record as text you can paste — with the specific senders that would break if you published it today. Each suggestion carries its reason, not just its priority.
It proposes. It does not publish: nothing here writes to your DNS.
And a daily check that it is all still true
DNS drifts. A registrar migration, a well-meaning change to an SPF include, an expired DKIM selector — none of these announce themselves, and all of them end the same way: mail you sent starts landing in spam folders, or being refused outright, and nobody tells you.
Every protected domain is checked daily for its MX, SPF, DKIM and DMARC records and for the routing the gateway expects. You hear about it when something is wrong, not on a schedule that trains you to ignore the mail.