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.

  • There is exactly one SPF record and it has no errors
  • It stays within the 10 DNS lookups receivers allow, with few lookups that find nothing
  • It ends with a rule for everyone else: -all, not ~all, ?all, +all or nothing
  • 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, and the old ptr mechanism is not used
  • A domain that sends no e-mail authorizes no sender
• DMARC

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

  • There is exactly one DMARC record and it has no errors
  • The policy rejects or quarantines failing e-mail: not p=none, and not in testing mode
  • Subdomains are protected too, also ones that do not exist
  • Whether alignment is strict or relaxed
  • Aggregate reports are asked for (rua), and a destination on another domain is authorized
  • The obsolete pct tag is not used
  • A domain that sends no e-mail rejects everything
  • From the DMARC reports that arrive: how much e-mail passes, and which senders fail and why
• 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 the common selectors we try and the ones you add
  • Each key record is valid and not in testing mode
  • Each key is long enough: 1024 bits is flagged, shorter is too short
  • A selector hosted by a provider 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).

  • MX records exist, there is more than one host, and each is a host name with a public address
  • A domain that takes no e-mail says so with a null MX
  • Each mail server answers on port 25 and is not an open relay
  • STARTTLS works, with a certificate that is valid, trusted, for the right name, not about to expire and has a strong key
  • Old TLS versions and weak ciphers are refused
  • No login is offered without encryption, VRFY and EXPN are off, and the banner does not reveal the software version
  • MTA-STS and DANE do not block delivery to the servers
• Downgrade protection

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

  • MTA-STS: the record and the policy exist, are valid and can be fetched
  • MTA-STS: the policy is in enforce mode, not testing or none, and covers every mail server
  • DANE: TLSA records exist, are DNSSEC-validated, match the certificate of the mail server and do not use the PKIX usages
  • 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
  • From the TLS reports that arrive: how many deliveries were encrypted, and which failed and why
• DNSSEC

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

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

  The nameservers that answer for the domain.

  • There are at least two nameservers, in more than one network
  • Each has an address, responds, answers authoritatively and is in sync with the others
  • The delegation at the parent zone matches the nameserver records of the zone
  • No nameserver has a private address, answers for other domains (open resolver) or 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 looked up on the domain blocklists
  • The address of every mail server (MX) is looked up on the address blocklists
  • Every mail server address has reverse DNS, and that name points back to the address
  • The addresses that actually send e-mail as the domain, taken from its DMARC reports, are looked up on the address blocklists once a day
• Domain registration

  The domain's registration at its registrar.

  • When the registration expires
  • Whether a transfer lock is set
  • Whether a transfer, a deletion or a hold is under way
• BIMI

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

  • A BIMI record exists and 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 check to see exactly what is tested.