Blog · Dmarc

What Email Security Grading Tools Actually Check: The Checklist Behind Your Domain Score

You ran your domain through a security grading tool. You got a C or lower. The tool told you to improve your email authentication but did not tell you which specific misconfiguration is costing you points or in what order to fix them.

The single most common reason for a below-average grade is not a missing SPF record. It is a DMARC policy set to p=none. More than half of all domains that have any authentication configured at all are running in monitor mode, and grading tools penalize that choice heavily.

This post explains exactly what these tools measure, why the grading scale punishes p=none even when SPF and DKIM are correct, and what a configuration that scores an A actually looks like.

What Email Security Grading Tools Evaluate

Most grading tools assess four to six categories. The underlying components are consistent across most tools, even if the weighting differs.

SPF Configuration

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain. Grading tools check:

  • Whether an SPF record exists at all
  • Whether the record uses ~all (softfail) or -all (hard fail) as its mechanism
  • Whether the record exceeds the 10-DNS-lookup limit, which is the most common silent failure in SPF configuration
  • Whether deprecated or fragile includes are creating unnecessary risk

A missing SPF record earns an automatic failing grade in this category. An SPF record that exists but silently exceeds the lookup limit is actually worse: the record looks correct in DNS, but SPF validation is not performed at all when the limit is exceeded.

DKIM Configuration

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound email. Receiving servers use the public key published in your DNS to verify that the message was not altered in transit and that it originated from your authorized infrastructure.

Grading tools check:

  • Whether a DKIM record exists in your DNS
  • Whether the selector in the DNS record matches the selector your mail server is actually using when signing
  • Whether the DKIM key length meets current standards (2048-bit minimum; 1024-bit is legacy and a liability)
  • Whether all outbound message streams are signed, including automated transactional mail

A DKIM record that exists in DNS but is not actually signing outbound mail is a common post-migration failure. The record looks correct. The signing does not happen. Grading tools catch this from authentication data in aggregate reports.

DMARC Configuration

DMARC (Domain-based Message Authentication, Reporting and Conformance) adds alignment checking and a reporting layer on top of SPF and DKIM. This is where grading tools apply the most scrutiny, because DMARC is where your email security policy lives.

Grading tools evaluate:

  • Whether a DMARC record exists at all
  • The policy tag: p=none, p=quarantine, or p=reject
  • Whether the rua (aggregate reporting) or ruf (forensic reporting) addresses are configured
  • Whether the pct tag is set below 100, which means enforcement is partial
  • Whether the sp= subdomain policy tag is present and intentional

The p=none penalty deserves specific attention. p=none means you are collecting reports but instructing receivers to take no action on mail that fails authentication. From a grading tool's perspective, this signals that your domain has the infrastructure for email authentication but the owner has not committed to enforcing it. An attacker spoofing your domain would still have their mail delivered. Grading tools reward the transition from p=none to p=quarantine or p=reject with a substantial score increase.

DNS and Broader Configuration

Some grading tools go beyond email authentication and assess:

  • Whether MX records point to servers that advertise STARTTLS (TLS support is now baseline)
  • Whether BIMI (Brand Indicators for Message Identification) is published (primarily a deliverability feature, not a security feature, but some tools award bonus points)
  • Whether the DNS zone has a CAA record restricting which certificate authorities can issue certificates for your domain

This category is tool-dependent. Check your specific tool's documentation to understand whether these bonus categories affect your score.

Why p=none Domains Rarely Score Above a C

This is the most common point of confusion in domain grading. You have SPF. You have DKIM. You have DMARC. Yet your grade is a C.

The issue is almost always p=none.

Here is the grading logic that tools apply: p=none means you are monitoring but not enforcing. You have done the minimum viable deployment of email authentication, which is better than nothing. But you have not committed to protecting your domain from being impersonated. Grading tools interpret this as a partial investment rather than a full one, and they score accordingly.

In practice, p=none is the correct starting point. You need weeks or months of aggregate report data before you can safely move to p=quarantine, because moving too early without knowing your aligned sender landscape will cause legitimate mail to bounce. But from a grading tool's perspective, that cautious deployment has a score ceiling.

The standard safe progression:

1. Deploy SPF and DKIM fully
2. Add DMARC at p=none and collect aggregate reports for a minimum of two to four weeks
3. Analyze the reports to identify which legitimate senders are not yet aligned
4. Fix those senders
5. Move to p=quarantine
6. After another observation period, move to p=reject

Each policy step up produces a measurable grade improvement, assuming SPF and DKIM are correctly configured.

Why Subdomains Often Score Worse Than Apex Domains

Subdomains present a common failure mode that grading tools catch explicitly.

A DMARC record on example.com does not automatically protect subdomains. If your marketing automation platform sends from marketing.example.com, that subdomain needs its own DMARC record or a wildcard record that uses the sp= tag to set a subdomain policy.

Failing to protect subdomains means:

  • Marketing, transactional, and notification emails are sent with no DMARC enforcement
  • Attackers can spoof those subdomains and the spoofed mail will be delivered because receivers have no policy instruction for that subdomain
  • Grading tools that evaluate subdomains separately will assign them lower scores

If your apex domain scores a B but your subdomains are receiving Fs, you need an sp= tag in your DMARC record with a policy set to match your main domain's intent.

What a Perfect Score Configuration Looks Like

Different tools use different scales, but the configuration that scores at the top across all of them has these elements:

  • SPF record with fewer than 10 DNS lookups, using -all (hard fail) or a redirect mechanism
  • DKIM signing with 2048-bit keys, applied to all authorized outbound message streams
  • DMARC record at p=quarantine or p=reject, with rua aggregate reporting configured
  • Subdomain policy aligned via sp= tag (or separate subdomain records where custom treatment is needed)
  • BIMI record with a valid VMC certificate for Gmail, Yahoo, and Apple Mail
  • MX records pointing exclusively to servers that advertise STARTTLS support
  • CAA record restricting certificate issuance to your chosen certificate authorities

Most organizations do not hit all of these on the first deployment. The grading scale rewards incremental progress.

The Configuration Problems That Appear Most Frequently

These are the issues I see repeatedly in domain assessments:

SPF exceeding the 10-lookup limit. Every include:, redirect=, and ip4:/ip6: mechanism counts as one lookup toward the limit. Adding a new email vendor, a new cloud platform, or a new marketing tool can silently push you over the threshold. When the limit is exceeded, SPF returns a permanent error and no validation is performed.

DKIM keys below 2048 bits. Keys below 2048 bits are considered deprecated. Some tools apply a specific penalty for this. After a DNS migration, DKIM records are sometimes regenerated at the old 1024-bit length if migration tooling does not enforce current standards.

DMARC record with no rua address. Aggregate reports are the only practical way to monitor your authentication health across all receivers. Without an rua address, you are making configuration changes without visibility into whether those changes are working.

p=none with pct below 100. Setting pct=50 at p=none means half of your failing mail is being silently ignored. This is not full enforcement, and it is a clear signal to grading tools that the domain is not committed to the policy.

How to Use DMARC Aggregate Reports to Raise Your Grade

The most actionable data for improving your domain grade lives in your DMARC aggregate reports. These reports arrive from participating receivers and tell you which IPs are sending mail as your domain, which are passing or failing authentication, and which receivers are processing your mail.

The problem is that raw DMARC aggregate reports arrive as XML. Parsing them manually is time-consuming and error-prone. The data is there, but accessing it requires tooling.

This is where DMARCFlow fits. DMARCFlow ingests your aggregate reports and presents the data as a breakdown of authentication pass/fail rates by sender IP, by receiver domain, and over time. When you can see that a specific email vendor is generating 40% of your DKIM failures because they are using the wrong selector in their DNS, you have a specific fix rather than a vague instruction to improve DKIM.

The workflow for using reports to raise your grade:

1. Confirm aggregate reports are flowing into DMARCFlow
2. Identify which IPs are generating the most authentication failures
3. Determine whether those failures are from legitimate senders (misaligned) or unauthorized sources (spoofing)
4. Fix the legitimate senders first: bring them into SPF or DKIM alignment
5. For unauthorized sources, confirm your p= policy will block them once you move off p=none
6. Repeat until your failure rate from known legitimate senders drops to near-zero

This is the difference between knowing your grade and knowing why your grade is what it is.

FAQ

Does a DMARC p=none record still help my security grade?
Yes, but marginally. p=none tells grading tools you have deployed DMARC, which is better than no record. However, it does not instruct receivers to take action on unauthenticated mail, so it does not score as well as p=quarantine or p=reject.

I have SPF and DKIM configured. Why is my grade still a C?
The most common cause is a p=none DMARC policy. If your SPF and DKIM are correct but your grade is a C, switching from p=none to p=quarantine (after analyzing your baseline reports) is the highest-impact change you can make.

Does BIMI affect my security grade?
BIMI is primarily a deliverability and brand trust feature. It does not improve SPF, DKIM, or DMARC scores directly. Some tools include it as a bonus category, so it can contribute a few points, but it is not a substitute for getting your authentication records right.

How often should I check my domain security grade?
Email authentication configuration changes when you add vendors, migrate platforms, or modify DNS. A quarterly check is the minimum; monthly is better. If you have recently changed your email infrastructure, check immediately.

My subdomain is failing DMARC but my apex domain passes. What do I do?
You need a subdomain policy. Add the sp= tag to your apex DMARC record to set a policy for subdomains, or publish a separate _dmarc.subdomain.example.com record for subdomains that need custom treatment.

How long does it take to improve a poor domain grade?
The fastest improvements come from changing your DMARC policy from p=none to p=quarantine, once you have confirmed your legitimate senders are aligned. DNS propagation for SPF and DKIM changes typically takes minutes to a few hours. DKIM key rotation may require coordination with your email vendor to avoid a signing gap.

Bottom Line

Domain security grading tools evaluate SPF, DKIM, DMARC configuration, and broader DNS settings to assign letter grades. The most common cause of a below-average grade is a p=none DMARC policy, followed by missing DKIM configuration and SPF records that silently exceed the 10-lookup limit.

Improving your grade follows a specific order: get SPF right, add DKIM, deploy DMARC with aggregate reporting, move from p=none to p=quarantine once you have enough baseline data, and tighten to p=reject when your aligned sender landscape is fully mapped.

If your aggregate reports are sitting unread because the XML is too difficult to parse, that is where DMARCFlow helps most. Turn the raw data into a breakdown of which IPs are failing, which receivers are seeing the failures, and which specific fixes will move the needle.