Email & domain security check

Press Enter to add. We already probe ~40 common selectors; add yours if your provider uses a custom one.

What this scan checks

• SPF

  SPF says which servers may send e-mail as the domain.

  • An SPF record exists
  • There is exactly one SPF record
  • The record has no errors
  • It stays within the 10 DNS lookups receivers allow, with few lookups that find nothing
  • It ends by refusing every other server (-all)
  • It does not authorize a very large range of addresses
  • The domain's own mail servers are covered
  • Every included domain has an SPF record
  • The deprecated ptr mechanism is not used
  • A domain that sends no e-mail authorizes no sender
  • The SPF records of the subdomains that send e-mail are valid and not open to everyone
• DMARC

  DMARC tells receivers what to do with e-mail that fails SPF and DKIM, and where to report it.

  • A DMARC record exists
  • There is exactly one, and it has no errors
  • The policy rejects e-mail that fails
  • The policy is not in testing mode, and the obsolete pct tag is not used
  • Subdomains are protected too, also ones that do not exist
  • Alignment is strict for SPF or for DKIM
  • Aggregate reports are asked for (rua)
  • A report address on another domain is authorized by that domain
  • A domain that sends no e-mail rejects everything, for its subdomains too
• DKIM

  DKIM signs outgoing e-mail so receivers can tell it was not altered and really comes from the domain.

  • A DKIM key is published under a common selector, or one named for the domain
  • Every selector set for the domain is found
  • Each key record is valid (an RSA key under 1024 bits is not)
  • No key is in testing mode
  • A selector a provider hosts is a CNAME, not a copied TXT record
  • A domain that sends no e-mail publishes an empty wildcard key
• Mail servers

  The servers that receive e-mail for the domain (MX), and how safely they accept it (SMTP).

  • The domain exists in DNS
  • MX records say where the domain's e-mail goes
  • A domain that takes no e-mail says so with a null MX
  • There is more than one mail server
  • Each MX is a host name with a public address
  • The mail servers of the subdomains that send e-mail have an address
  • Each mail server answers on port 25
  • No mail server relays e-mail for strangers
  • STARTTLS is offered and works
  • The certificate is trusted, for the right name and not expired
  • The certificate is not about to expire
  • The certificate key is strong, and old TLS versions are refused
  • No login is offered without encryption
  • The server gives nothing away: VRFY and EXPN are off, the banner names no version
  • MTA-STS does not keep e-mail from a mail server
  • DANE does not keep e-mail from a mail server
• Downgrade protection

  MTA-STS and DANE stop an attacker from forcing e-mail to the domain onto an unencrypted connection.

  • MTA-STS is set up
  • The MTA-STS record is valid
  • The policy file can be fetched and is valid
  • The policy is enforced, not in testing mode or switched off
  • The policy covers every mail server
  • DANE is set up: the mail servers have TLSA records
  • The TLSA records are signed with DNSSEC
  • The TLSA records match the certificate of the mail server
  • The TLSA records use the DANE usages (2 or 3), not the PKIX ones
  • At least one of the two is in place
• TLS reporting

  TLS reporting asks other mail servers to report when they could not deliver to the domain over an encrypted connection.

  • A TLS-RPT record exists
  • The record is valid
• DNSSEC

  DNSSEC signs the DNS answers of the domain, so they cannot be forged on the way.

  • The zone is signed
  • The parent zone has a DS record that matches the zone's key
  • The chain validates from the root down
  • The signatures are not about to expire
  • No deprecated algorithm is used
• DNS

  The name servers that answer for the domain, and what its zone makes public.

  • The domain has at least two name servers
  • The name servers are in more than one network
  • Each name server has a public address
  • Each name server responds and answers authoritatively
  • The name servers are in sync
  • The delegation at the parent zone matches the zone's own name server records
  • No name server answers for other domains (open resolver)
  • No name server hands out the whole zone (AXFR)
  • A CAA record says which certificate authorities may issue for the domain
• Blocklists & reputation

  Whether the domain, its mail servers or the addresses that send as it are on a blocklist that receivers use to refuse e-mail.

  • The domain is on no domain blocklist
  • No mail server address is on an address blocklist
  • Every mail server address has reverse DNS, and that name points back to it
• Domain registration

  The domain's registration at its registrar.

  • The registration has not expired and is not about to
  • A transfer lock is set
  • No transfer to another registrar is pending
  • The domain is not being deleted
  • The domain is not on hold
• BIMI

  BIMI shows the brand logo next to e-mail from the domain in inboxes that support it.

  • A BIMI record exists
  • The record has no errors
  • DMARC is enforced, which BIMI requires
  • The logo can be fetched and is in the required format (SVG Tiny PS)
  • A mark certificate (VMC or CMC) is present and valid

Open a subject to see exactly what is tested.