Check SPF, DKIM and DMARC for your domain

What an SPF, DKIM and DMARC check tells you

Three DNS records decide how mail services treat a message that claims to come from your domain. SPF lists the servers allowed to send for it. DKIM adds a signature to each message, with the public key published in DNS. DMARC tells the receiving service what to do when a message fails both checks, and where to send reports.

If these records are missing or too loose, anyone can put your domain in the From line of a phishing email, and your own invoices are more likely to land in spam.

The check is part of the free external website security check. It reads public DNS records and the MTA-STS policy file only. It does not connect to your mail servers and sends no email.

What we check, record by record

Each row in the mail section of the report shows the value we saw, a short verdict and, where something is wrong, what to change.

We also flag an SPF redirect= to a name without SPF, DMARC reports sent to another domain that has not agreed to receive them, relaxed DMARC alignment, and domain addresses shown in clear text on the site.

DKIM and selectors: why “not found” is not a verdict

A DKIM key lives under a name chosen by your mail service, called a selector, for example selector1._domainkey.example.com. A receiving server learns it from the s= tag of each signed message (RFC 6376). From outside, there is no list of selectors to read.

So we try common names such as selector1 and selector2 (Microsoft 365), google, default, k1, s1, dkim and mail. If your homepage has a newsletter form from Brevo, Mailchimp, Klaviyo or Mailjet, we also try that service’s usual names. We ask DNS for a random name as well: some zones answer every name the same way, and then a match means nothing.

If we find no key, the report says the selector may have another name. To be sure, open the headers of an email you sent and look at s= in the DKIM-Signature line.

Newsletters and bulk sender rules

Google asks anyone who sends close to 5,000 or more messages a day to personal Gmail accounts for SPF, DKIM and DMARC, with the From domain aligned to SPF or DKIM; p=none is enough for this rule. Yahoo asks bulk senders for SPF, DKIM and DMARC with at least p=none. Since 5 May 2025 Microsoft requires SPF, DKIM and DMARC from domains that send more than 5,000 messages a day to Outlook.com (Outlook.com sender policies).

When the check sees a newsletter service on your homepage, the report adds a line for it: whether that service signs mail with your domain and whether DMARC is in place. It is a hint, not an audit of your sending volume.

What to fix first

• Keep exactly one SPF record, end it with ~all or -all, and remove services you no longer use.
• Publish DMARC with p=none and a rua address, read the reports for two to four weeks, then move to p=quarantine and later to p=reject.
• Turn on DKIM signing in every service that sends mail for you and publish its key.
• If the domain receives mail, add MTA-STS in testing mode with TLS-RPT, then switch to enforce.
• If the domain sends no mail at all, publish v=spf1 -all: no server may send for it.

Every finding in the report says what we saw, why it matters and what to do, in words for the person who manages your DNS.

What this check does not do

• It does not connect to your mail servers, test STARTTLS or send test messages.
• It does not see real messages, so it cannot prove that DKIM passes or that From aligns in practice. Your DMARC reports show that.
• It looks for DKIM keys on common selector names only. There is no field for your own selector yet.
• The SPF lookup count is an estimate: we follow include records one level deep.
• It does not check blocklists, sender reputation, BIMI or your DMARC reports.
• A weak record means weaker protection, not proof that your mail was forged.