How the email and DNS check works

Your domain's DNS records are public by design: every mail server and browser reads them. This check reads the ones that protect your domain from email forgery, and looks for addresses that point to a hosting service where your account or project no longer exists.

What it reads

• The TXT records of your domain, for an SPF record.
• The TXT record at _dmarc. your domain, for a DMARC policy.
• The MX records, to note whether the domain receives email at all.
• The CNAME of the address you entered and of its www. version, and, when one points to a known hosting service, whether that target still exists.

These are DNS lookups, not requests to your website.

What it reports

• No SPF record, an SPF record that allows any sender (+all), one that gives no instruction (?all), or more than one SPF record (receivers then ignore both).
• No DMARC record, or a DMARC policy of p=none, which watches forged mail but still lets it through.
• A possibly dangling CNAME: your address points to a service such as GitHub Pages, Heroku, Azure or an S3 bucket, and the target no longer resolves. Someone else could then claim that name at the provider and serve their content on your address. This is reported as Potential, because only the provider can confirm the resource is free to claim.

What it cannot see

• DKIM. A DKIM key is published under a name your mail provider chose, and that name is not public, so it cannot be looked up without guessing. Check DKIM in your mail provider's admin panel.
• Whether your real email passes SPF and DMARC. Only the DMARC reports sent to you show that.
• Subdomains other than the address you entered and its www. version. The scanner does not guess names.

What to do with the result

The SPF and DMARC guide explains the records in plain language and the order to set them up in. A dangling CNAME should be removed in your DNS settings, or the resource re-created at the provider.