Email security check: SPF, DMARC, DKIM and MTA-STS

Find out whether someone could easily send email that looks like it comes from your domain, and whether mail to you can be forced onto an unencrypted connection.

Runs the full free check, including website checks. The email results are in the "Email authentication" area.

DKIM selector (optional)

Open an email you sent, view the original message, and find s= in the DKIM-Signature header.

What this check tells you

It reads your domain's public mail records (MX, SPF, DMARC, DKIM for a selector you give, MTA-STS and TLS reporting) and flags anything that makes it easier to send mail pretending to be you, or to intercept mail sent to you.

Who it's for

Anyone who sends email from their own domain: businesses setting up a mailbox provider, newsletter or CRM, and administrators checking that a DNS change didn't break SPF or DMARC.

What you enter, and what happens

Your domain, plus an optional DKIM selector. The check queries public DNS through Cloudflare's resolver, follows SPF include and redirect chains (up to 10 lookups and 4 levels), and, if MTA-STS is announced, fetches your policy file without following redirects, as the standard requires. A leading www. is removed for the email checks. Nothing is sent to your mail servers, and nothing is stored.

What each record does

  • SPF lists the servers allowed to send mail for your domain. There must be exactly one record, and evaluating it must take no more than 10 DNS lookups, or receivers treat it as an error.
  • DMARC tells receivers what to do with mail that fails SPF and DKIM: monitor (p=none), quarantine or reject. It also sends you reports.
  • DKIM signs your messages with a key published in DNS. We can only check a key if you tell us its selector.
  • MTA-STS and TLS reporting protect and monitor encryption for mail sent to you.

Change email DNS records carefully

Before tightening SPF or moving DMARC to quarantine or reject, list every service that sends mail as your domain: your mailbox provider, newsletter tool, CRM, invoicing and website forms. Leaving one out can get its legitimate mail rejected. Start DMARC at p=none with reports, review them, and tighten in steps.

How to read the result

  • High: for example an SPF record ending in +all (anyone may send as you), two SPF or DMARC records (receivers treat both as errors), or SPF over the 10-lookup limit, which makes SPF fail for all your mail.
  • Medium: no DMARC record.
  • Low and info: DMARC at p=none, no reporting address, or no MTA-STS. These are worth doing, but not urgent.
  • Not tested: DKIM without a selector. Selectors can't be listed through DNS, so this never means DKIM is missing.

Limits

The check reads published records. It can't see whether your mail actually passes SPF, DKIM and DMARC when it's delivered: DMARC reports (the rua address) show that. SPF macros aren't expanded. For subdomains, DMARC falls back to the parent domain's record, an approximation that doesn't use the Public Suffix List.

Questions

Should I set DMARC to reject straight away?

No. Start at p=none with a reporting address, read the reports for a few weeks to find every service that sends as you, fix their SPF and DKIM, then move to quarantine and finally reject.

Why does SPF fail with "too many DNS lookups"?

Each include, a, mx, exists and redirect costs a lookup, including those inside included records. Over 10, receivers return a permanent error. Remove services you no longer use, or replace includes with the provider's narrower record.

My domain doesn't send email. What should it publish?

A null MX record (0 .), SPF v=spf1 -all and DMARC p=reject. That tells receivers to reject any mail claiming to be from it. The check recognises null MX.

Related: all email checks in detail · all tools.

References: RFC 7208 (SPF), RFC 7489 (DMARC), RFC 6376 (DKIM), RFC 8461 (MTA-STS).