kant.au
Get Started
← All insights

Email Authentication Monitoring: SPF, DKIM, and DMARC Explained

Email Security
How-To
DKIM
DMARC
SPF
Your Emails Are Landing in Spam. You Found Out From a Client.

A client emails to say their invoices have been going to spam for two weeks. You check the domain. The SPF record looks fine on the surface, but a third-party tool was added three months ago and nobody updated the policy to include it. Every email sent from that tool has been failing authentication checks, quietly, since the day it was connected.

Two weeks of missed invoices. One configuration nobody thought to check. That’s what email authentication monitoring is built to catch before the invoice call happens.

What SPF, DKIM, and DMARC actually do

These three standards work together to prove that email from your domain is legitimate. Each one does a different job.

SPF (Sender Policy Framework) your authorised sender list. It publishes the servers permitted to send email on behalf of your domain, and receiving servers check every inbound message against it. RFC 7208 defines the standard. A record ending in `~all` soft-fails unauthorised senders; `-all` rejects them outright. Many domains ship with `~all` and never tighten it.

DKIM (DomainKeys Identified Mail) your cryptographic signature. It attaches a signature to outgoing emails, verified against a public key published in DNS. If the DKIM key is removed from DNS, or the selector a sending tool uses no longer exists, signatures fail to verify and the email loses a key trust signal.

DMARC (Domain-based Message Authentication, Reporting and Conformance) your enforcement policy. It ties SPF and DKIM together and tells receiving servers what to do when checks fail: monitor only (`none`), route to spam (`quarantine`), or reject entirely (`reject`). RFC 7489 covers the specification.

The three work as a system. A gap in any one of them weakens the whole.

How email authentication breaks without anyone noticing

Most email authentication problems aren’t caused by attackers. They’re caused by ordinary business activity that nobody thought had email implications.

Adding a new sending tool. A marketing platform, a CRM, a transactional email service, a helpdesk, each one sends email on behalf of your domain and typically requires you to add its servers to your SPF record. Dozens of integrations are set up this way. Few are ever removed from SPF when the tool is retired.

The SPF lookup limit. SPF records resolve includes recursively, and the specification caps this at 10 DNS lookups. A domain with multiple sending services can exceed this without anyone realising. When it does, SPF evaluation fails permanently for that domain, regardless of whether the sending server is actually authorised.

Rotating DKIM keys. Email platforms occasionally rotate the cryptographic keys they use for DKIM signing. If the new key isn’t published in DNS, or if the old key is removed before the transition completes, signatures stop verifying. This can happen during a platform migration or a routine key rotation that the sending tool handles on its end without notifying you.

A DMARC policy set to `none` and forgotten. `none` is the monitoring-only policy. It’s often where DMARC deployment starts, as a way to observe traffic before enforcing anything. It’s also where it stays for years, meaning failed authentication is logged but never acted on. Your domain can be spoofed and DMARC will watch without intervening.

Subdomain policies weaker than the main domain. DMARC lets you set a separate policy for subdomains. A common mistake is enforcing `reject` on the main domain while leaving subdomains at `none`, which gives spoofing a clear path in through any subdomain.

Why receiving servers aren’t a substitute for email authentication monitoring

Not in a way that reaches you.

When an email fails authentication checks, the rejection or spam classification happens at the receiving server. The sender gets a bounce if the message is rejected outright, but soft failures, quarantines, and silent spam folder placements produce nothing. The email appears to send successfully from your side.

DMARC does include a reporting mechanism. Aggregate reports (`rua`) and forensic reports (`ruf`) can be sent to an address you specify in the record. But parsing these reports requires either dedicated tooling or a service that processes them. Most teams that set up a DMARC record never configure reporting, or configure it and never look at the results.

Email authentication monitoring closes this gap by watching the records themselves. A change to your SPF, DKIM, or DMARC configuration is caught the moment it appears in DNS, before you find out about it through a client complaint.

—

What email authentication monitoring covers

SPF record changes. Any modification to your SPF policy is flagged, including new includes being added, the `all` mechanism changing from `-all` to `~all`, and records that have grown past the 10-lookup limit.

DKIM key tracking. Existing selectors are monitored for changes. If a key is removed or replaced, the change is detected immediately rather than days later when a client reports delivery issues.

DMARC policy monitoring. Changes to the enforcement policy are tracked, including a policy weakening from `quarantine` to `none`, a subdomain policy that’s less strict than the main domain, and a `pct` value below 100 that means only some emails are subject to enforcement.

Parse errors. All three record types are validated on each check. A malformed SPF record that technically exists but fails to parse correctly is flagged, not silently ignored.

What to check across the domains you manage

Before a client sends you a screenshot of their spam folder:

  • Is your SPF record under the 10-lookup limit?
  • Does SPF include every service currently sending email on your behalf?
  • Are there DKIM selectors in DNS for all active sending platforms?
  • Is your DMARC policy `quarantine` or `reject`, or still sitting at `none`?
  • If DMARC has a subdomain policy, is it as strict as the main domain policy?
  • Have any of these records changed in the last 90 days?

If answering any of those requires manually running DNS lookups, you’re checking point-in-time rather than monitoring continuously. The next change will be just as invisible as the last one.

Email authentication records shift more often than most people expect, and the consequences take time to surface. kant.au tracks SPF, DKIM, and DMARC across every domain you add, with alerts on any change and validation on every check. Want to check a single domain right now? Check it for free, or start a free 14-day trial to monitor it continuously.