How to read your Email Security Check report

What does the Email Security Check look at?

The check combines two kinds of evidence. The first is how our receiving mail server evaluated the one message you sent: whether SPF, DKIM and DMARC passed, whether the message proved it came from your own domain, and whether it arrived encrypted. The second is your sending domain's current public configuration in DNS: the DMARC policy, the SPF record, the DKIM key, MTA-STS, TLS reporting, your mail servers, DNSSEC and BIMI.

Only the authentication headers and public DNS are analysed. The message body is never retained, and the raw message is deleted as soon as it has been parsed.

Because the check sees one message from one sending path, evaluated by one receiver, it cannot show every service that sends mail as your domain, or how the configuration changes over time. A newsletter tool or a billing system that sends as you may be set up quite differently from the mailbox you tested with.

What do the posture grade and the summary tell me?

At the top, the report names the domain it covers and shows a Posture grade, a letter from A to F with a score out of 100. The score starts at 100 and goes down for every check that is marked Fail or Needs attention, and a serious problem costs far more points than a minor one. A score of 90 or more is an A; below 40 is an F. Checks marked Not determined do not change the score, which is why the grade and the list of unfinished checks belong together.

The Executive summary then gives one of three plain verdicts:

• "Someone could send email pretending to be you." At least one check failed. That is the case for any Fail, whatever its section.
• "You have some protection, but there are gaps worth closing." Nothing failed, but at least one check needs attention.
• "This message was well protected." No problems were found in the checks that could be completed for this message.

Below the summary, Highest-priority actions lists up to three problems, most serious first, each with what to do. If you only have time for a few changes, start there.

What do Pass, Needs attention, Fail, Not in use and Not determined mean?

Every check is a card with a plain question as its heading, such as "Is there a list of who may send email as you?", and one of five labels:

• Pass: the check found no problem.
• Needs attention: the setting works, but it is weaker than it should be or could cause trouble later.
• Fail: something is broken or missing in a way that weakens your protection or can stop your mail.
• Not in use: an optional feature you have not set up, or context the check cannot measure from one message. It is informational and does not lower the grade.
• Not determined: the check could not be completed, for example because a DNS lookup did not answer in time. It is neither a pass nor a failure.

Under the heading, "What this means" explains the result in plain words. Cards marked Fail or Needs attention also say what to do. The checks are grouped under five questions, in the order the report shows them, and a group with nothing to show is left out.

Can someone send email pretending to be you?

This group protects your name. It decides whether a stranger can put your domain in the From line and have the message delivered. It covers your DMARC policy, whether the message you sent was tied to your own domain, the receiving server's overall verdict, and your SPF record.

• "Are mail systems told to stop fakes?" is a Fail when there is no DMARC record, and Needs attention at p=none, because forged mail is still delivered normally. A policy that covers only part of failing mail (pct below 100), or leaves subdomains out with sp=none, also needs attention. p=quarantine and p=reject both pass; p=reject is the end goal. Move to enforcement in stages, as the guide on DMARC enforcement describes.
• "Did the message you sent prove it was really yours?" fails when SPF or DKIM passed, but for the sending service's domain rather than yours. Once you enforce DMARC, mail sent that way is rejected, including your real mail. The fix is usually to have the service sign with your own domain, often called custom DKIM.
• "Is there a list of who may send email as you?" is your SPF record. -all is the goal. ~all is marked Needs attention, because it is loose about senders the list does not recognise. +all, or more than one SPF record, is a Fail.
• "Is that list short enough to actually be read?" fails when the record needs more DNS lookups than receivers allow. Receivers then stop reading and treat SPF as failed, even for genuine mail. The guide on the SPF lookup limit explains how to trim it.

Is your mail signed in a way others can trust?

DKIM is the digital signature that lets your mail survive forwarding and still prove it came from you. A signature can be present and still be weak, so the report checks it in several parts and puts "Overall signing health" at the top of the group.

• No signature at all is a Fail. Protection then depends entirely on the sending server's address, which breaks as soon as someone forwards the message. Ask your email provider to switch on signing for your domain.
• A missing, revoked or mismatched key means nobody can verify the signature. Ask your provider for the correct key and publish it in DNS.
• A signature using SHA-1, or one that does not protect the From address, fails. One that covers only part of the message body needs attention, because text added at the end would still appear signed.
• "Can the signing key be replaced safely?" is informational. DNS does not let anyone list your keys, so one message cannot show whether a spare key is ready. Confirm with your provider that keys are rotated.

The guide on DKIM goes through these settings in more detail.

Do you know who is sending email as you?

This group has one check: whether your DMARC record asks receivers to send aggregate reports to an address you control. Without reports you are working blind. You cannot know which of your own services send mail, so you cannot safely switch on blocking.

If this check fails, add a reporting address (rua) to your DMARC record and read the reports for a few weeks before you tighten the policy. The guide on DMARC explains what the reports contain.

Is your email protected while it travels?

Encryption between mail servers stops messages being read or altered on the way. It is separate from proving who sent them. This group covers both the message you sent and how your domain receives mail.

• "Was this message encrypted on the way?" looks at the final delivery hop. Not determined here means the receiving server did not record it, which is not the same as the message being unencrypted.
• "Did our spam filter flag this message?" appears only when our filter classified your test message as spam. The message is still analysed. A missing subject line is a common cause, so send an ordinary email with a subject.
• "Is encryption required, or merely offered?" is MTA-STS. Without a policy, or with the policy in testing mode, it needs attention: senders may still deliver unencrypted. A policy in enforce mode that leaves out one of your mail servers fails, because mail to that server is refused. The guide on MTA-STS covers a safe rollout.
• "Are you told when encryption fails?" is TLS-RPT. Without it, failed encrypted deliveries to you go unnoticed.
• "Where does your incoming mail go?" checks your MX records. A domain that only sends should say so explicitly with a null MX record, as the guide on domains that send no email explains.
• "Extra certificate protection (optional)" is DANE. Not in use is fine here; most senders do not require it.

What is under Foundations and extras?

These are supporting items: useful to fix eventually, but not what an attacker would use first.

• "Are your DNS settings protected from tampering?" is DNSSEC. Every setting in the report lives in DNS, so without DNSSEC an attacker who can interfere with DNS answers can replace them. Without it the card says Needs attention. Ask your DNS provider to enable it and publish the matching DS record at your registrar. The guide on DNSSEC explains how.
• "Your logo in recipients' inboxes (optional)" is BIMI. It is a brand feature, not a security control, and it only displays once DMARC is enforced. Leave it until everything above is resolved.

What about checks we could not complete and the technical details?

If any check came back Not determined, the report lists it under "Checks we could not complete". These checks did not return an answer, so they are neither a pass nor a failure. A common reason is that one of the domain's nameservers was slow or did not answer. Run the check again if you need them covered.

Each card also has a collapsed "Technical details" section, and the report ends with "Technical evidence". Both are written in English for whoever manages your DNS: the records that were found, the receiver's verdicts and the exact recommendation. Pass these on together with the plain-language actions when you ask someone to make a change.