What the email module tests on your sender identity: SPF, DKIM, DMARC (RFC 9989), BIMI, MTA-STS and TLS-RPT – why each record matters and how it is scored.
Check your domain →
Need to create one of these records? Use the free Record Studio for SPF, DKIM, DMARC, BIMI, MTA-STS and TLS-RPT.
Last updated: July 2026 · 23 checks documented
Evaluated domain (www → apex) #
E-mail authentication (MX, SPF, DKIM, DMARC, MTA-STS) is configured at the domain itself; www. is merely the website alias and practically never sends or receives mail. Checking www directly would mostly produce meaningless "missing" findings.
RatingInformational only (weight 0): when the input starts with www., exactly that label is stripped and the parent domain is evaluated. Other subdomains are NOT rewritten – they can legitimately run their own mail identity and get the host-specific evaluation instead.
How to fix itNothing to fix – this is a transparency note about which domain the e-mail results refer to.
SPF record present #
SPF (Sender Policy Framework) defines which servers may send on behalf of the domain and is one of the foundations against email spoofing.
Ratingpass if exactly one v=spf1 record exists; otherwise fail (weight 2). Exception: a hostname without MX (e.g. www.) gets only a warn (weight 1) – the sending policy lives at the organizational domain; v=spf1 -all on the host is optional HELO hardening.
How to fix itPublish an SPF TXT record that lists all legitimate sending hosts, e.g. v=spf1 include:… ~all (softfail, recommended with DMARC) or -all.
SPF default behavior (all) #
The final all mechanism determines how unauthorized senders are handled. +all is dangerous; for sending domains, ~all (softfail) is often more robust than -all (forwarding), while parked domains should use -all.
Ratingpass with -all or ~all (context-dependent); warn with ?all/missing all; +all → fail + Cap C (SPF allows any sender). Weight 2.
How to fix itSending domain: ~all or -all (with DMARC). Parked domain: -all. Never +all.
Exactly one SPF record #
Multiple v=spf1 records cause a PermError per RFC 7208 – SPF then fails completely.
Ratingfail + Cap C with more than one SPF record (PermError – no effective SPF policy). Weight 2.
How to fix itMerge all SPF records into a single one.
Deprecated ptr mechanism #
The ptr mechanism is slow, unreliable, and explicitly discouraged by RFC 7208.
Ratingwarn if ptr is used. Weight 1.
How to fix itRemove the ptr mechanism from the SPF record.
SPF DNS lookups (limit 10) #
SPF allows a maximum of 10 DNS lookups (include, a, mx, exists, redirect). If more are needed, a PermError occurs and SPF is considered not passed.
Ratingpass ≤ 10 lookups; fail above that. Weight 1.
How to fix itReduce/consolidate includes. Avoid SPF flattening – it leads to outdated IPs.
SPF include/redirect targets valid #
An include: or redirect= pointing at a domain that publishes no SPF record causes a PermError per RFC 7208 – receivers then treat the entire SPF policy as broken. This typically happens when a former mail provider is cancelled but its include remains in the record.
Ratingfail when at least one include/redirect target has no SPF record (weight 2). Targets with %-macros cannot be checked and are skipped.
How to fix itRemove stale includes from the SPF record, or restore the SPF record at the target domain.
DMARC record present #
DMARC ties SPF and DKIM to a policy and tells receiving servers what to do with spoofed mail – plus reporting. Without DMARC, spoofing protection is incomplete.
Ratingpass if a v=DMARC1 record exists under _dmarc; otherwise fail. Weight 3. When the scanned name has no record itself, receivers walk up to eight successively shorter names down to the TLD (DNS Tree Walk, RFC 9989 §4.10; psd= tags steer where the organizational domain sits) and an inherited policy counts. The v value is case sensitive – a record such as v=dmarc1 is ignored entirely and is reported here as broken.
How to fix itPublish DMARC, starting with v=DMARC1; p=none; rua=mailto:…, then gradually tighten it.
DMARC policy (p=) #
p=none only observes but does not protect (RFC 9989 calls this "monitoring mode"). Only p=quarantine (spam) or p=reject (rejection) reach enforcement and prevent spoofing. A missing p counts as p=none (implicit default); a record with an invalid p/sp/np value survives only as p=none if a valid rua URI exists – without one, receivers apply no DMARC at all (RFC 9989 §4.10.1).
Ratingpass with reject; warn with quarantine; none (explicit, implicit, or as §4.10.1 fallback) → fail + Cap C; an inoperative record (invalid values, no rua) → fail + Cap C. Weight 3.
How to fix itEscalate in stages per RFC 9989 §7.4: about a month of p=none with reports, a similar period of p=quarantine, then p=reject. Domains at p=reject must not rely on SPF alone – sign outgoing mail with DKIM (§7.4/§8); domains whose users post to mailing lists should weigh p=reject carefully.
DMARC test mode (t=) #
RFC 9989 introduced the t=y tag as the successor of pct=0: receivers apply the published policy one level lower – reject acts as quarantine, quarantine as none; reporting is unaffected and a policy of none does not change. Useful during rollout, but as long as it is set, p=reject does not fully protect against spoofing.
Ratingwarn (weight 2) when t=y weakens a quarantine/reject policy; info (weight 0) when the policy is none, where the tag has no effect.
How to fix itOnce the aggregate reports look clean, remove t=y so the policy takes full effect.
DMARC coverage (pct=) #
With pct<100, legacy receivers apply the policy to only a portion of the mail. The tag was removed in RFC 9989 (DMARCbis) – current receivers ignore it entirely, so it only creates inconsistent behavior between old and new receivers.
RatingOnly evaluated when the tag is present: pass at 100 %; otherwise warn. Weight 1.
How to fix itRaise pct to 100, then remove the tag (obsolete since RFC 9989). A deliberate pct=0 should become t=y instead – RFC 9989 (App. A.6) designates that as its successor.
DMARC aggregate reports (rua) #
Without a rua address, you receive no analysis of who is sending on behalf of the domain – the basis for safely moving to p=reject. Email is the only defined report transport: a rua list without any mailto: URI never delivers anything (RFC 9990 §3.5).
Ratingpass if rua is set and contains a mailto: address; warn when it is missing or mailto-less. Weight 1. Exception: on a no-mail domain (Null MX + SPF without permitted senders) a missing rua is only info (weight 0) – nobody can deliver legitimate mail there, reports would at most show spoofing attempts.
How to fix itAdd a rua=mailto:… address (e.g. a DMARC reporting service).
External report recipients authorized #
If rua/ruf points to a domain in a different organizational domain (determined via tree walk – sibling subdomains under the same organizational domain do not count as external), that destination must authorize acceptance via a <domain>._report._dmarc.<target> TXT record – otherwise receivers discard the reports. Failure reports (ruf) require the same authorization (RFC 9991 §5).
Ratingpass if every external rua/ruf destination is authorized; warn when the authorization record is missing, when the verification name exceeds DNS length limits (verification then can never succeed), or when the destination overrides rua/ruf with a foreign host (receivers then deliver to neither address). DNS errors during verification are reported as not testable, not as missing. Weight 1.
How to fix itPublish a TXT record <your-domain>._report._dmarc.<target> with v=DMARC1 at the target domain.
Subdomain policy (sp=/np=) #
A weak sp (e.g. none) undermines a strong p: subdomains can then still be spoofed. RFC 9989 additionally defines np= for non-existent subdomains – valuable because spoofers like to invent hosts such as invoice.example.com that have no DNS records at all. Both tags only work in the record at the organizational domain: policy discovery never reads them from records published further down (RFC 9989 §4.7).
Ratingwarn if p is strict but sp=none or np=none; otherwise info. Weight 0–1. sp/np in a record below the organizational domain are flagged as ineffective (info).
How to fix itRemove sp/np (they then inherit p) or set them to at least quarantine/reject – and publish them in the organizational domain’s record.
DMARC record syntax #
Beyond the policy itself, RFC 9989 tightened the record format: duplicate tags make receiver behavior undefined (strict receivers discard the whole record, RFC 6376 §3.2), fo= has hard constraints (0 and 1 are mutually exclusive, d/s at most once, ignored entirely without ruf), invalid tag values silently fall back to their defaults, and the tags ri=/rf= plus the !size URI suffix were removed from the standard (historic).
RatingOnly appears when something is off: warn for duplicate tags or broken fo= values, info for removed/ignored legacy tags and values that fall back to defaults. Weight 0–1.
How to fix itClean up the record: remove obsolete (ri, rf, pct, !size) and duplicate tags, fix invalid values.
DKIM key discoverable #
DKIM cryptographically signs outgoing mail so that recipients can verify authenticity and integrity. Common selectors are checked.
Ratingpass if a key is found via known selectors; otherwise warn (the selector may differ). Weight 2. On a hostname without MX, absent selectors are skipped (not graded) – the mail identity lives at the organizational domain. Likewise skipped on a no-mail domain (Null MX + SPF without permitted senders): a domain that never sends needs no signing keys.
How to fix itEnable DKIM at the mail provider and add the published selector in DNS.
DKIM key length #
DKIM keys that are too short (RSA < 1024) are breakable. Recommended: RSA ≥ 2048 or Ed25519.
Ratingpass > 1024 (2048 recommended); warn at 1024; fail < 1024. Weight 1.
How to fix itRenew the DKIM key to RSA-2048 (or Ed25519). On Microsoft 365 / Exchange Online DKIM keys are still created with 1024 bits by default, so existing selectors (selector1/selector2) usually have to be upgraded manually: in Exchange Online PowerShell run Rotate-DkimSigningConfig -Identity yourdomain.com -KeySize 2048 (the -Identity is the domain name, not a GUID). The new key only starts signing after ~4 days (96 h) – until then the old 1024-bit key keeps signing – so re-test after that. Verify with Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1KeySize,Selector2KeySize,RotateOnDate. The Defender portal's Rotate DKIM keys button keeps the current bit depth, so the upgrade to 2048-bit needs PowerShell.
DKIM key attributes #
t=y marks a test key (recipients ignore errors → no protection); h=sha1 is cryptographically weak.
Ratingwarn with a test flag or SHA-1. Weight 1.
How to fix itRemove the test flag t=y and use SHA-256 (a=rsa-sha256).
BIMI (brand logo) #
BIMI displays the brand logo (and, with VMC, a verified badge) in the inbox – a trust signal that only works with an enforced DMARC policy (p=quarantine/reject, pct=100, sp not none). With p=none, the logo is never displayed. When a record with a logo exists, the check validates it the way a mailbox provider does: the SVG is fetched (SVG Tiny PS profile, no active content), the mark certificate (a=) is verified – BIMI marking, validity window, and a certificate chain ending at a BIMI-authorized CA (DigiCert, GlobalSign, SSL.com) – and the served logo must match the image the CA bound into the certificate (RFC 3709 logotype). Via avp=personal, a record can also ask providers to prefer the sender's personal avatar over the logo – the check shows this preference. Only shown when a BIMI record exists.
Ratinggood only when the logo and mark certificate fully verify; warn when the logo is not SVG Tiny PS, the VMC is missing/expired/not from an authorized CA, or the served logo does not match the certificate; warn (weight 1) if BIMI is set but DMARC is not enforced – the record is then ineffective. Otherwise informational (weight 0).
How to fix itPublish a BIMI record default._bimi with an SVG Tiny PS logo (l=) and a VMC/CMC from a BIMI-authorized CA (a=); serve exactly the certified logo file, and first bring DMARC to quarantine/reject with pct=100.
Null MX (RFC 7505) #
An MX 0 . explicitly signals that the domain receives no email – correct for web-only/parked domains and prevents delivery attempts.
Ratingpass if Null MX is set correctly. Weight 1.
How to fix itFor non-receiving domains, set MX 0 . plus v=spf1 -all and DMARC p=reject.
Mail provider #
The MX records reveal which platform receives the domain's mail. For a hosted mailbox provider (Google Workspace, Microsoft 365, Zoho …) the same platform usually sends the domain's mail too, so the recognised provider is a strong hint – but only a hint – for the outbound sender. Inbound security gateways (Mimecast, Proofpoint …) sit in front of the mailbox and do not reveal the sender, so they are not treated as such.
RatingInformational only – never affects the grade. When a hosted provider is recognised and its documented sending include: is absent from a published SPF record, a note suggests adding it.
How to fix itIf the recognised provider sends mail for the domain, make sure its documented SPF include: is in your v=spf1 record. Other senders (newsletters, CRM, transactional/ESP) are not visible in MX and must be added to SPF separately.
MTA-STS #
MTA-STS enforces TLS for mail delivery and protects against downgrade/MITM attacks. The TXT record (incl. the mandatory id= field per RFC 8461 §3.1), policy file, mode, max_age (1 week … max. 1 year per §3.2), and whether the mx entries match the actual MX are checked.
Ratingpass with mode: enforce with matching MX and a sufficient max_age; warn with testing/none, MX mismatch, missing id=, max_age outside 604800–31557600, or a policy host that is reachable over IPv6 only (IPv4-only senders cannot fetch the policy). An unreachable policy file is warn and names the cause: a policy host resolving only to private/internal addresses, missing A/AAAA records, an HTTP status other than 200, or a redirect (RFC 8461 §3.3 allows only 200 and forbids redirects). Missing → warn. Weight 2.
How to fix itTXT _mta-sts + a policy at https://mta-sts.<domain>/.well-known/mta-sts.txt with mode: enforce, correct mx lines, and max_age ≥ 604800.
TLS-RPT (SMTP TLS Reporting) #
TLS-RPT provides daily reports about failed TLS deliveries – important for noticing MTA-STS/DANE problems.
Ratingpass if a _smtp._tls TXT record with v=TLSRPTv1 exists; otherwise warn. Weight 1.
How to fix itPublish a TXT record _smtp._tls with v=TLSRPTv1; rua=mailto:….