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, alerts you if your SPF or DMARC record disappears, and flags weak or missing settings.

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 the all qualifier at the end of the record (-all strict fail, ~all softfail, ?all neutral, +all wide open), which determines how strictly receivers should treat unauthorized senders.
• DMARC — the TXT record at _dmarc.yourdomain.com starting with v=DMARC1. CompleteStatus parses the policy (p=none|quarantine|reject), the pct percentage, and the rua aggregate-report address.
• DKIM — TXT records at {selector}._domainkey.yourdomain.com. A record counts as a DKIM key when it has a non-empty p= tag; v=DKIM1 is optional. Selectors can't be listed from DNS, so when you haven't named your own, CompleteStatus probes 20 common ones: default, google, selector1, selector2, k1, mail, s1, s2, k2, k3, fm1, fm2, fm3, protonmail, protonmail2, protonmail3, zoho, smtp, mx and dkim. You can supply your own selector list in the monitor's configuration (dkim_selectors) if your provider uses a different one. A monitor with no selectors, or with only the four rows the form prefills, counts as not configured and gets the 20 common ones.

Setting it up

1. Go to /monitors/create and choose the Email Security monitor type.
2. Enter your bare domain (for example example.com — not a URL) as the target.
3. 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 20 common ones, the check can't find your key and reports DKIM not verified (an info finding, not a missing record) even though signing works. Set your real selector(s) in the monitor's config so the right _domainkey record is queried; a selector you configure yourself that has no key is reported as missing. You can find your selector in your mail provider's DKIM setup page or in the s= tag of a sent message's DKIM-Signature header.

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:

Reading the results panel

Open the monitor from /monitors. The Email security panel shows three cards:

• SPF — Present/Missing badge, the all qualifier, and the full record text.
• DMARC — Present/Missing, the policy (p=), the pct value, 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

1. Publish SPF listing only your real senders, ending in ~all.
2. Enable DKIM at your mail provider(s) and confirm CompleteStatus finds the selector.
3. Publish DMARC with p=none and a rua= address, and watch the aggregate reports for a couple of weeks. CompleteStatus will flag p=none as a medium finding the whole time — that's your reminder that the job isn't done.
4. Tighten SPF to -all and move DMARC to p=quarantine, then p=reject.
5. 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=reject before DKIM and SPF are correct for every legitimate sender (marketing platform, helpdesk, billing system…) will cause real mail to be discarded. Ramp through p=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 your SPF record, add a DNS monitor on your domain's TXT records — see SSL, DNS and domain-expiry monitors. DMARC and DKIM records live on underscore names (_dmarc.…, selector._domainkey.…), which a DNS monitor can't target today: a DMARC policy weakened to p=none shows up as a finding on this monitor rather than as an alert, and an edit to a DKIM key that stays valid isn't tracked.

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.