Know the Moment Your SPF, DKIM or DMARC Record Changes

It is the continuous checking of the three DNS records that authorise and authenticate your outbound email. Domainyze watches your SPF record, your DKIM public keys and your DMARC policy around the clock, grades how well protected your domain is, compares each check against your known records, and alerts you with the exact before and after values when one of them changes. The point is that email authentication fails silently: nothing bounces visibly and no dashboard turns red, so without monitoring the usual way you discover a broken record is a customer telling you weeks later that they never received your email.

SPF is a TXT record at your domain listing which mail servers are allowed to send on your behalf. DKIM publishes a public key at selector._domainkey so receiving servers can verify a cryptographic signature and confirm the message was not altered in transit. DMARC, published at _dmarc.yourdomain.com, tells receiving servers what to do when SPF or DKIM fails, typically to quarantine or reject the message, and is what actually stops your domain being used to spoof your customers.

No. Domainyze monitors the records themselves rather than parsing the aggregate (rua) or forensic (ruf) reports that receiving servers send back. The two are complementary: report analysis tells you how mail claiming to be from you performed across the internet over the past day, while record monitoring tells you the moment your own configuration changes. Record monitoring catches the edit that breaks authentication on the day it happens, rather than surfacing it in the following report cycle.

DKIM records live at a name that cannot be enumerated from DNS, which is why most tools require you to type the selector in yourself. Domainyze infers it instead. Your MX records identify who handles your mail, and each major provider uses predictable selector names, so a Google Workspace domain has google checked, a Microsoft 365 domain has selector1 and selector2, and the same applies across Postmark, SendGrid, Mailgun, Amazon SES, Zoho, Fastmail, Mailchimp and Proofpoint. A list of selectors common to hosted mail generally is swept as well. Every selector queried is recorded on the check, so an empty DKIM result always means we looked and found nothing rather than that we never looked.

As part of DNS monitoring on portfolio domains held by an account on a paid plan, on a tiered schedule: twice a day on Business, daily on Pro. Authentication records are edited rarely, so a genuine change stands out, and every detected change is confirmed against a second independent resolver before you are alerted.

The alert names the record type that changed and carries both the removed and the added values, which is usually enough to decide whether to revert without opening your DNS panel. It can be delivered to email, a Slack channel, a Discord channel or an HMAC-signed webhook, and each destination has its own filter, so you can route authentication changes to the team that owns email while general DNS changes go elsewhere.

Yes, to a point. Alongside change alerts, Domainyze grades your email-authentication posture (strong, adequate, weak or absent) and surfaces specific findings against your published records: a DMARC policy left on monitor-only (p=none), an SPF record that exceeds the ten DNS-lookup limit, a revoked or weak DKIM key, a missing record. What it does not do is parse your DMARC aggregate reports or score the deliverability of your actual mail flow; it reads the records you publish, not the mail you send. So it will both catch a regression in a configuration you had right and point out a standing weakness you have not fixed yet.

Use the free email deliverability checker. It reads a domain’s MX, SPF, DKIM and DMARC records once and gives a verdict on each, with no account. Monitoring is what keeps reading them afterwards and tells you when one changes.