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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
The free plan watches your home page, the SSL certificate and the domain expiry date. No card, no expiry date on the plan itself.
How we watch this day to day: Availability monitoring ›
Is my website down
Check from the outside whether the site responds, and whether the problem is on your end.
SSL certificate
Expiry date, issuer, name coverage and everything else that makes the padlock disappear.
Domain expiry
When the domain expires, who the registrar is and whether anyone can move it without your knowledge.
Security headers
Eight items you set on the server in a quarter of an hour, and every audit asks about them.