Fixing findings in one click
On the domain overview the card "Fix findings in one click" appears as soon as a current finding (at most 30 days old, monitor active, last run without error) misses one of the records below or shows a fixable error; the same proposals also appear where the finding is shown (E-Mail → SPF and TLS-RPT, area pages). Every proposal shows type, name and content with a copy button; with a matching integration and name servers at the provider there is the button "Create at {provider}" or "Change at {provider}" with a confirmation dialog. Afterwards the change is in the audit log and the timeline, and the check runs again after about two minutes.
DomainWarn changes an existing record only after explicit confirmation: the card shows the current and the new value side by side, and the change fails if the record at the provider no longer looks like the preview. Nothing is ever deleted.
- DMARC: TXT
_dmarc.<domain>withv=DMARC1; p=none; rua=mailto:<address>. You enter the reporting address (suggestiondmarc@<domain>); if it is on a foreign domain, DomainWarn checks its authorization record. - SPF: TXT on the domain with
v=spf1 <include of the detected mail provider> <further senders> ~all. Detected are Microsoft 365, Google Workspace, IONOS, STRATO, ALL-INKL, Hetzner, mailbox.org, Posteo, Proton, Zoho, Fastmail and iCloud; an unknown provider yieldsmx. Further senders you enter asinclude:,ip4:,ip6:,aormx, up to eight; the finished record is resolved beforehand and rejected above ten lookups. - TLS-RPT: TXT
_smtp._tls.<domain>withv=TLSRPTv1; rua=mailto:<address>. With a report mailbox, DomainWarn's report address for this domain is prefilled (the reports then show up under E-Mail → Reports), otherwise the suggestion istls-reports@<domain>. - SPF too permissive (
+all,?allor noall): the same record with~all, optionally with further senders in front. This changes the existing record, so only with confirmation; DomainWarn does not propose-all, because a forgotten sender would then be rejected. Only with exactly one SPF record without syntax errors. - CAA:
0 issue "<ca>"for the certificate authority that actually issues according to certificates and CT logs, only if exactly one CA is involved (e.g. Let's Encrypt, Sectigo/ZeroSSL, DigiCert, GlobalSign, Google Trust Services, Amazon, GoDaddy, Buypass, SSL.com, HARICA). - CAA locks out the issuing CA: an additional
issuerecord (for wildcard certificatesissuewildif the set has issuewild records) for exactly this CA; the existing records stay. Not forissue ";"(deliberately locked), an unknown CA or a set outside the zone. Route 53 keeps only one CAA set per name and refuses the addition; add the value by hand there. - Only as a recommendation on the finding, not in one click: multiple SPF records (merging would mean deleting), too many SPF lookups (a decision about the services), DNSSEC (the DS record lives at the registrar) and the DMARC policy.
- Safety: before writing, the name servers are freshly resolved and the zone is looked up in the account; if a matching record already exists, DomainWarn aborts. Per zone, type and name only one write runs at a time. Owners, admins and members may create and change, 20 times per minute; client accounts do not see the proposals.
See also: Email monitoring