The records that decide delivery
Since Google, Yahoo and Microsoft require SPF, DKIM and DMARC from senders, the DNS zone decides about the inbox. The records are set quickly and break just as quickly: an extra include blows the lookup limit, a hosting move loses the DKIM key, someone sets DMARC to none for testing and forgets.
DomainWarn checks the records in the interval of the plan, evaluates them with the same rules as the free tools and compares them with the last state. Alerts arise on errors and on changes, each with before and after.
What is monitored
- SPF: syntax, lookup count, qualifier, multiple records, changes to the mechanisms.
- DKIM: resolvability and key length of the configured selectors, revoked keys.
- DMARC: existence, policy, pct, reporting addresses, weakening of the policy.
- MX: mail servers, priority, resolvability, provider change.
- MTA-STS and TLS-RPT: policy file reachable, mode, MX hosts covered.
- Blacklists: mail server and website IPs against Spamhaus, Spamcop, Barracuda and more.
- DANE for MX: TLSA records of the mail servers, DNSSEC signing and comparison with the certificate served via STARTTLS; a certificate change without a new TLSA record is reported as critical.
- The mail servers themselves: reachability on port 25, STARTTLS, TLS version and certificate per MX host as well as reverse DNS (PTR) of the mail server IPs.
Create missing records in one click
If DMARC, SPF, TLS-RPT or CAA is missing, DomainWarn proposes the record with conservative values: DMARC with p=none and a reporting address, SPF with the include of the detected mail provider and ~all, TLS-RPT with a reporting address, CAA for the certificate authority actually in use. If the zone is hosted at Cloudflare, Hetzner DNS, IONOS, netcup, INWX or Amazon Route 53 and the account is connected as an integration, one click creates the record. Additive only: existing records are never changed, and only if all name servers of the domain point to the provider. Without an integration the values are ready to copy.
DMARC monitoring without a report service
DMARC report services parse the XML reports and show who sends on behalf of the domain. That is valuable for rolling out p=reject. DomainWarn adds the other side: it monitors the record itself. The most common damage is not an unknown sender but a policy someone rolled back, or a record lost during a DNS migration.
For MSPs and agencies with many client domains
Clients, domains and notifications are separate: every alert names client and domain, a client can get a status page and a monthly report, the morning digest sums up everything. New client domains can be imported, the monitors are created automatically. On the Agency plan a domain costs under 50 cents a month, a fraction of one hour of troubleshooting a spam problem.
Frequently asked questions
- Does DomainWarn parse DMARC reports?
- No, DomainWarn monitors the records and their changes. A report service is the right tool for parsing reports; the two complement each other.
- Which DKIM selectors are checked?
- Those detected when adding the domain and any you configure per domain. The check alerts when a selector no longer resolves or the key becomes too short.
- How fast is a weakened DMARC policy noticed?
- Within the check interval of the plan: SPF and DMARC are checked hourly on Agency and every three hours on Freelancer. The change is reported as critical.