‹ All tools

SPF, DKIM and DMARC check

Three DNS records decide whether your email is delivered and whether a stranger can send a message signed with your domain. We check them together, because they only work as a set: SPF says who may send, DKIM signs the message, and DMARC decides what to do with mail that fails the checks.

The domain on its own is enough. An address pasted from the browser works too.

What exactly we check

  • Mail servers (MX)
  • SPF: presence, number of records, final qualifier and the ten DNS lookup limit
  • DMARC: policy, subdomain policy and the reporting address
  • DKIM: the selectors most commonly used by large email providers
  • MTA-STS as an extra for demanding setups

DKIM cannot be listed: the record sits under a selector name that only the sender knows. We ask for a dozen or so of the most common ones, so an empty result is not proof that a signature is missing.

How to read the result

No SPF

Receiving servers have no way to tell whether a message really came from you. The effect cuts both ways: your mail goes to spam, while messages spoofing your domain arrive unopposed.

Two SPF records

This is the most common fault after changing email providers: the old record stays, the new one is added next to it. Under the standard, two records invalidate SPF entirely. The fix is to merge them into one.

SPF ends with "~all" instead of "-all"

Mail from outside the list is then marked but still delivered. That is a reasonable interim step while you sort out your senders, but it is not the destination.

The ten lookup limit is exceeded

Every "include" entry costs a DNS lookup, and the standard allows ten. Above that limit SPF stops working entirely, even though the record looks perfectly fine.

DMARC in observation mode

A "p=none" policy blocks nothing: it is a reporting mode. Many domains stay there for years, convinced they are protected. The policy should eventually quarantine or reject failing mail.

Most common causes

A new sending tool missing from SPF

A newsletter system, an invoicing tool or a shop starts sending from your domain, but nobody added it to the record. Mail from that one source starts landing in spam.

A change of email provider

A migration leaves the old SPF record and old DKIM entries behind while new ones are added. The result is both a duplicated SPF and an exceeded lookup limit.

Someone impersonating your finance team

Without a DMARC policy that rejects, anyone can send a message carrying your company address in the sender field. That is how most changed-bank-account frauds begin.

Questions and answers

Where do I start?

With a single correct SPF record listing every sender, then DKIM at your email provider, and DMARC last. The DMARC policy is raised gradually, once the reports show that nothing legitimate is being rejected.

Will DMARC block my own email?

It can, if you switch to rejection before all of your senders pass the checks. That is why you start in observation mode with reports and raise the policy after reading them.

Why can you not see my DKIM?

Because we ask for the most common selector names and your provider may use its own. You will find the selector in the headers of any message you have sent, in the DKIM signature field.

Does this really affect deliverability?

Yes. The largest email providers now require authentication from bulk senders, and missing SPF and DMARC records are among the first reasons a message is treated as spam.

You checked once. We check every five minutes.

The free plan watches your home page, the SSL certificate and the domain expiry date. No card, no expiry date on the plan itself.

  • A pulse check every 5 minutes, with a second check confirming an outage
  • A warning before the certificate and the domain expire
  • Email notifications with no limit
  • Seven days of statistics, one account
Start free monitoring

How we watch this day to day: Availability monitoring ›