Email authentication monitoring (SPF, DKIM, DMARC)
If your domain's email authentication records are missing or too permissive, anyone can send mail that appears to come from you — phishing your customers with your own domain. CompleteStatus's Email security monitor checks the three DNS records that prevent this and alerts you if they disappear.
Email security monitors are available on every plan, including Free.
What CompleteStatus checks
On each run, the monitor queries your domain's DNS and parses:
- SPF — the TXT record at your domain starting with
v=spf1. CompleteStatus extracts theallqualifier at the end of the record (-allstrict fail,~allsoftfail,?allneutral,+allwide open), which determines how strictly receivers should treat unauthorized senders. - DMARC — the TXT record at
_dmarc.yourdomain.comstarting withv=DMARC1. CompleteStatus parses the policy (p=none|quarantine|reject), thepctpercentage, and theruaaggregate-report address. - DKIM — TXT records at
{selector}._domainkey.yourdomain.comstarting withv=DKIM1. By default CompleteStatus probes six common selectors:default,google,selector1,selector2,k1andmail. You can supply your own selector list in the monitor's configuration (dkim_selectors) if your provider uses a different one.
Setting it up
- Go to /monitors/create and choose the Email Security monitor type.
- Enter your bare domain (for example
example.com— not a URL) as the target. - Tick the ownership attestation and save. A daily interval is typical, and is what the whole-site quick-add at /monitors/site uses when it creates this monitor for you.
Repeat per domain: each Email security monitor watches one domain. If you send mail from several domains, create a monitor for each.
Note: If your DKIM selector isn't one of the six defaults, the check will report DKIM as missing even though signing works. Set your real selector(s) in the monitor's config so the right
_domainkeyrecord is queried. You can find your selector in your mail provider's DKIM setup page or in thes=tag of a sent message'sDKIM-Signatureheader.
Pass or fail
A check passes when both an SPF record and a DMARC record exist. If either is missing, the check fails; after two consecutive failed checks CompleteStatus opens an incident and sends down alerts to the monitor's channels — so if a DNS migration silently drops your _dmarc record, you find out from CompleteStatus, not from a spoofing campaign.
A weak-but-present configuration (for example p=none) still passes while being flagged as a finding, so you aren't paged for policy you're intentionally ramping up.
The findings CompleteStatus flags
Findings appear on the monitor's page, sorted by severity, each with a recommendation and, where applicable, a ready-to-publish record:
| Finding | Severity | What it means |
|---|---|---|
| No SPF record | High | Receivers can't tell which servers may send for your domain. Publish e.g. v=spf1 include:_spf.your-provider.com -all. |
| SPF is permissive | Medium | The record ends in +all (authorizes any sender) or has no all mechanism at all. End it with -all or at least ~all. |
| No DMARC record | High | Nothing tells receivers what to do with unauthenticated mail. Publish e.g. v=DMARC1; p=quarantine; rua=mailto:dmarc@your-domain.com at _dmarc. |
DMARC policy is p=none |
Medium | Monitoring-only: reports are generated but spoofed mail is still delivered. Move to p=quarantine, then p=reject once your reports look clean. |
| No DKIM record found | Medium | None of the checked selectors returned a v=DKIM1 record. Enable DKIM signing at your provider and publish the selector record (or configure the correct selector, above). |
Reading the results panel
Open the monitor from /monitors. The Email security panel shows three cards:
- SPF — Present/Missing badge, the
allqualifier, and the full record text. - DMARC — Present/Missing, the policy (
p=), thepctvalue, and the record. - DKIM — which of the checked selectors returned a valid record.
Below the cards, findings are listed critical → info with the recommendation and suggested record for each.
A sensible hardening path
- Publish SPF listing only your real senders, ending in
~all. - Enable DKIM at your mail provider(s) and confirm CompleteStatus finds the selector.
- Publish DMARC with
p=noneand arua=address, and watch the aggregate reports for a couple of weeks. CompleteStatus will flagp=noneas a medium finding the whole time — that's your reminder that the job isn't done. - Tighten SPF to
-alland move DMARC top=quarantine, thenp=reject. - Keep the monitor running: if any record is ever dropped during a DNS change, the check fails and you get an incident.
Warning: Moving straight to
p=rejectbefore DKIM and SPF are correct for every legitimate sender (marketing platform, helpdesk, billing system…) will cause real mail to be discarded. Ramp throughp=none→p=quarantine→p=reject.
What this check does not do
The Email security check verifies presence and policy strength on each run. It does not diff record contents between runs — a record that changes but remains present and parseable won't trigger an alert by itself. To be alerted on any change to specific DNS records (including TXT), add a DNS monitor for the same domain — see SSL, DNS and domain-expiry monitors.
Related guides
- Security-posture scans — header and TLS grading.
- Getting started — alert channels and rules.
- SPF, DKIM and DMARC explained — how the three records work together, on the blog.
- Moving DMARC from p=none to p=reject — the safe migration path in detail.