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.
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.
- 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.