Plain-English definitions for every term in your domain score report — with good vs. bad configuration examples and direct links to check your own domain.
A DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. Receiving mail servers check SPF to verify that inbound email claiming to be from your domain actually originated from an authorized source.
Without SPF, anyone can send email that appears to come from your domain. SPF is one of the three core authentication standards required by Google and Yahoo for bulk senders as of February 2024.
v=spf1 include:_spf.google.com -all — lists all authorized senders and ends with -all (hard fail) to reject unauthorized senders.
Missing SPF record, ~all (soft fail) instead of -all, or too many DNS lookups (exceeds the 10-lookup limit, causing PermError).
A cryptographic email authentication method that adds a digital signature to outgoing messages. The signature is verified against a public key published in DNS, confirming the email was not altered in transit and was authorized by the sending domain.
DKIM proves message integrity and sender authorization. Without DKIM, DMARC alignment cannot be achieved through the DKIM path, weakening your overall authentication posture. Required by Google and Yahoo for bulk senders.
2048-bit RSA key (preferred over 1024-bit), selector published in DNS, signing configured on all outbound mail streams including transactional and marketing.
No DKIM record, 1024-bit key (considered weak), DKIM configured for one sending stream but not others, or key not rotated in years.
A DNS policy record that ties SPF and DKIM together and tells receiving mail servers what to do when authentication checks fail. DMARC also enables aggregate (rua) and forensic (ruf) reporting so domain owners can see who is sending email on their behalf.
DMARC is the enforcement layer of email authentication. Without it, SPF and DKIM provide no protection against domain spoofing. p=reject is the gold standard — it tells receivers to discard emails that fail authentication. Required by Google and Yahoo for bulk senders.
v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s — enforced policy with aggregate reporting enabled.
p=none (monitoring only, no enforcement), missing DMARC record, or rua pointing to an unmonitored address.
A DNS standard that allows brands to display their logo in the inbox beside authenticated emails. BIMI requires DMARC at p=quarantine or p=reject, a Verified Mark Certificate (VMC) for Gmail, and an SVG logo published at a DNS-specified URL.
BIMI increases brand visibility and trust in the inbox. Emails with brand logos see higher open rates. It also signals to receivers that your domain has strong authentication in place.
v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem — with DMARC p=reject and a valid VMC from DigiCert or Entrust.
BIMI record present but DMARC not at p=reject, SVG not in correct format, or VMC expired/missing.
A protocol that preserves email authentication results across mail forwarding and mailing list scenarios. When an intermediary server modifies a message (breaking DKIM), ARC provides a chain of custody so the final receiver can still evaluate the original authentication.
ARC solves the forwarding problem — emails forwarded through mailing lists or third-party services often fail DKIM because the message is modified. ARC allows receivers to trust the original authentication even after forwarding.
ARC is implemented by mail servers and intermediaries, not by domain owners. Ensure your ESP supports ARC signing.
No action needed from domain owners unless running your own mail infrastructure.
The requirement that the domain in the From: header matches the domain used in SPF (Return-Path) or DKIM (d= tag) authentication. Strict alignment requires an exact match; relaxed alignment allows subdomain matches.
DMARC only provides protection when alignment passes. A domain can have valid SPF and DKIM but still fail DMARC if the authenticated domains don't align with the From: header — which is what recipients actually see.
From: header domain matches the DKIM d= tag or SPF Return-Path domain. Use strict alignment (adkim=s; aspf=s) where possible.
ESP sends from a different domain in the Return-Path or uses a DKIM key signed for a different domain, causing alignment failure.
A standard that allows domain owners to declare that their mail servers support TLS encryption and that sending servers should refuse to deliver email if TLS cannot be established. Implemented via a DNS TXT record and a policy file hosted at a well-known HTTPS URL.
Without MTA-STS, email can be downgraded from encrypted TLS to plaintext SMTP by a man-in-the-middle attacker. MTA-STS enforces encryption for inbound mail delivery.
_mta-sts DNS TXT record + policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with mode: enforce.
No MTA-STS record, mode: testing (not enforced), or policy file unreachable over HTTPS.
A DNS TXT record at _smtp._tls.yourdomain.com that specifies where sending mail servers should send reports about TLS connectivity failures when delivering to your domain. Complements MTA-STS.
TLS-RPT provides visibility into TLS negotiation failures, certificate errors, and MTA-STS policy violations. Without it, you have no insight into whether your inbound mail encryption is actually working.
v=TLSRPTv1; rua=mailto:[email protected] — pointing to a monitored address.
Missing TLS-RPT record, or rua pointing to an unmonitored address.
A protocol that uses DNSSEC-signed TLSA records to publish the expected TLS certificate for a mail server, allowing sending servers to verify the certificate without relying on a certificate authority.
DANE provides a stronger guarantee of TLS certificate authenticity than the CA system. It prevents certificate substitution attacks. Requires DNSSEC to be enabled.
TLSA record published at _25._tcp.mail.yourdomain.com, DNSSEC enabled, certificate matches the published hash.
TLSA record present but DNSSEC not enabled (DANE is invalid without DNSSEC), or certificate mismatch.
A suite of extensions that adds cryptographic signatures to DNS records, allowing resolvers to verify that DNS responses have not been tampered with in transit.
Without DNSSEC, DNS responses can be forged by attackers (DNS cache poisoning). DNSSEC protects the integrity of your SPF, DKIM, DMARC, and MX records. Required for DANE.
DNSSEC enabled at registrar, DS records published, DNSKEY records signed and valid.
DNSSEC not enabled, expired signatures, or DS records missing at the parent zone.
An HTTP response header that instructs browsers to only connect to your site over HTTPS for a specified duration. Once a browser sees the HSTS header, it will refuse to connect over HTTP for the declared max-age period.
HSTS prevents SSL stripping attacks where an attacker downgrades your HTTPS connection to HTTP. It also protects users who accidentally type http:// instead of https://.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload — one year, all subdomains, submitted to browser preload list.
Missing HSTS header, max-age too short (under 6 months), or HSTS sent over HTTP (invalid — must only be sent over HTTPS).
An HTTP response header that controls which resources (scripts, styles, images, fonts) a browser is allowed to load for your page. CSP is a primary defense against cross-site scripting (XSS) attacks.
XSS attacks can steal session cookies, redirect users to phishing pages, or inject malicious content. A well-configured CSP significantly reduces the attack surface.
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; — restrictive policy with nonce-based script allowlisting.
Missing CSP header, or CSP with unsafe-inline or unsafe-eval which defeats most XSS protections.
A DNS record that specifies which certificate authorities (CAs) are authorized to issue SSL/TLS certificates for your domain. Prevents unauthorized certificate issuance.
Without CAA records, any CA can issue a certificate for your domain. CAA records reduce the risk of certificate misissuance by rogue or compromised CAs.
0 issue "letsencrypt.org" — or whichever CA you use. Add 0 iodef "mailto:[email protected]" for violation reporting.
No CAA record (any CA can issue), or CAA record listing a CA you no longer use.
The configuration that automatically redirects all HTTP traffic to HTTPS, ensuring users always connect over an encrypted connection regardless of which protocol they use to access your site.
Without an HTTP→HTTPS redirect, users who access your site over HTTP are exposed to eavesdropping and man-in-the-middle attacks. It also affects trust signals evaluated by email security filters.
HTTP 301 redirect from http://yourdomain.com to https://yourdomain.com, enforced at the web server or CDN level.
HTTP returns 200 (no redirect), or redirect is a 302 (temporary) instead of 301 (permanent).
A digital certificate that authenticates a website's identity and enables encrypted HTTPS connections. Certificates are issued by trusted Certificate Authorities (CAs) and have an expiration date.
An expired or invalid certificate causes browser warnings that destroy user trust and can affect email deliverability — receiving servers may check your web presence as part of reputation evaluation.
Valid certificate, not expiring within 30 days, issued by a trusted CA, covering the correct domain names.
Expired certificate, self-signed certificate, certificate for wrong domain, or expiring within 14 days.
A DNS record that specifies the mail servers responsible for accepting email for a domain. MX records include a priority value — lower numbers indicate higher priority.
Without valid MX records, email cannot be delivered to your domain. Misconfigured MX records (pointing to non-existent hosts, wrong priority) cause delivery failures.
MX records pointing to valid, resolvable hostnames with correct priority values. Primary and backup MX servers configured.
No MX record, MX pointing to an IP address (invalid — must be a hostname), or MX pointing to a CNAME (also invalid).
A DNS record that maps an IP address back to a hostname. For email, the PTR record of the sending IP should resolve to a hostname that forward-resolves back to the same IP (FCrDNS — Forward-Confirmed Reverse DNS).
Many receiving mail servers check PTR records as a spam signal. A sending IP without a valid PTR record, or with a PTR that doesn't match the HELO/EHLO hostname, increases spam filter scores.
PTR record for sending IP resolves to a hostname that forward-resolves back to the same IP. Hostname matches the HELO/EHLO name used by the mail server.
No PTR record, PTR resolves to a generic hostname (e.g., dynamic-ip-1.2.3.4.isp.com), or forward/reverse DNS mismatch.
The length of time a domain has been registered. Spam filters and inbox providers use domain age as one signal in sender reputation scoring — newer domains are treated with more suspicion.
Newly registered domains have no sending history and no established reputation. Sending high volumes from a new domain without a warmup plan results in poor inbox placement.
Domain registered for 12+ months with consistent, low-volume sending history before scaling up.
Domain registered within the last 3 months, or domain with a gap in sending history followed by sudden high volume.
The spam and abuse reputation associated with a top-level domain (TLD). Some TLDs (.tk, .ml, .ga, .cf, .xyz, .top) are heavily associated with spam and phishing, causing inbox providers to apply stricter filtering to all domains on those TLDs.
Authentication records alone cannot overcome TLD-level reputation penalties. A domain on a high-abuse TLD will face elevated spam filter scores regardless of how well-configured its SPF, DKIM, and DMARC are.
.com, .org, .net, .edu, .gov, or established country-code TLDs (.co.uk, .com.au, .de, etc.).
.tk, .ml, .ga, .cf, .gq, .xyz, .top, .click, .loan, .win, .bid — TLDs with documented high abuse rates.
The date on which a domain registration expires. If not renewed, the domain becomes available for registration by anyone — including attackers who could use it to impersonate your brand or intercept email.
An expired domain means your website goes offline, email stops working, and your brand identity becomes available to squatters. Domains expiring within 30 days are an active risk.
Domain renewed at least 1 year in advance, auto-renewal enabled, registrar contact email actively monitored.
Domain expiring within 30 days, auto-renewal disabled, or registrar contact email is a defunct address.
The percentage of sent emails that land in the recipient's primary inbox (as opposed to spam, promotions, or being blocked entirely). Distinct from delivery rate — an email can be delivered but still land in spam.
Inbox placement is the metric that actually determines whether your email program is working. A 99% delivery rate with 30% inbox placement means 30% of your emails are reaching the inbox — the rest are in spam.
85%+ inbox placement rate across major inbox providers (Gmail, Microsoft, Yahoo). Monitored via inbox placement testing tools.
Below 70% inbox placement, or significant variation across providers (high at Gmail, low at Microsoft, or vice versa).
A score assigned by inbox providers to sending domains and IP addresses based on historical sending behavior. Factors include spam complaint rates, bounce rates, engagement rates, blacklist status, and authentication compliance.
Sender reputation is the primary factor inbox providers use to determine inbox vs. spam placement. A damaged reputation can take weeks to recover and affects all email from your domain — transactional, marketing, and operational.
Spam complaint rate below 0.1% (Google threshold), bounce rate below 2%, consistent sending volume, high engagement rates.
Complaint rate above 0.3% (Google rejection threshold), high bounce rates, sudden volume spikes, or blacklist listings.
A real-time database of IP addresses and domains known or suspected to send spam. Mail servers query these lists during the SMTP connection to decide whether to accept, reject, or flag incoming email.
A blacklist listing causes immediate delivery failures or spam placement at any mail server that queries that list. Major blacklists (Spamhaus, Barracuda, SORBS) are checked by most enterprise mail servers.
Not listed on any major blacklists. Monitoring in place to detect new listings within hours.
Listed on Spamhaus ZEN, Barracuda, SORBS, or Microsoft SNDS — each requires a separate delisting request.
The practice of regularly removing invalid, inactive, or risky email addresses from your sending list. Includes removing hard bounces, spam trap addresses, role-based addresses, and disengaged contacts.
Email lists decay at roughly 22% per year. Sending to stale lists increases bounce rates, spam complaints, and spam trap hits — all of which damage sender reputation. Clean lists improve deliverability and reduce ESP costs.
Full list audit twice per year, real-time validation at sign-up, suppression of contacts with 6–12 months of no engagement.
No list cleaning in 12+ months, sending to purchased lists, no bounce suppression, or no unsubscribe mechanism.
The process of verifying in real-time or in bulk whether an email address is syntactically valid, belongs to a real domain, and has an active mailbox — before sending to it.
Sending to invalid addresses causes hard bounces, which damage sender reputation. Real-time validation at sign-up prevents bad addresses from entering your list in the first place.
Real-time MX and mailbox validation at point of entry, bulk validation before major campaigns, integration with ESP bounce handling.
No validation at sign-up, no bulk validation before campaigns, or relying solely on ESP bounce handling after the fact.
The process of gradually increasing sending volume from a new domain or IP address to build a positive reputation with inbox providers before sending at full scale.
Inbox providers are suspicious of new senders who immediately send high volumes — it is a pattern associated with spam. Skipping warmup is one of the most common reasons new email programs fail immediately.
Structured warmup plan: start with 50–100 emails/day to highly engaged contacts, double volume every 2–3 days over 4–6 weeks, monitor complaint and bounce rates throughout.
Sending full volume on day one, no warmup plan, or restarting sending at full volume after a long period of inactivity.
A service offered by inbox providers that notifies senders when a recipient marks their email as spam. Senders use FBL data to identify and suppress complainers from future sends.
Without FBL enrollment, you have no direct visibility into spam complaints. High complaint rates (above 0.1% at Google) trigger inbox placement penalties. FBL data allows you to suppress complainers before they damage your reputation.
FBL enrolled at all major providers that offer it (Yahoo, Comcast, AOL). Complaints automatically suppressed in your ESP.
No FBL enrollment, complaints not automatically suppressed, or FBL data not monitored.
A mechanism (defined in RFC 8058) that allows recipients to unsubscribe from a mailing list with a single click directly from the inbox interface, without visiting a landing page. Implemented via the List-Unsubscribe and List-Unsubscribe-Post headers.
Required by Google and Yahoo for bulk senders as of February 2024. Without one-click unsubscribe, bulk senders face rejection or spam placement at Gmail and Yahoo Mail. It also reduces spam complaints by giving recipients an easy alternative to the spam button.
List-Unsubscribe: <https://youresp.com/unsub?id=xxx> and List-Unsubscribe-Post: List-Unsubscribe=One-Click headers present on all bulk email.
Missing List-Unsubscribe header, or header present but List-Unsubscribe-Post missing (not one-click compliant).
The rua= tag in a DMARC record specifies where aggregate XML reports should be sent. These reports are generated by receiving mail servers and show authentication pass/fail rates, sending sources, and policy application for your domain.
DMARC aggregate reports are the primary tool for understanding who is sending email on behalf of your domain. Without rua= configured, you are flying blind — you cannot detect unauthorized senders, misconfigured services, or authentication failures.
rua=mailto:[email protected] pointing to a monitored address, or a DMARC reporting service (dmarcian, EasyDMARC, Valimail, Postmark).
No rua= tag, rua pointing to an unmonitored address, or reports never reviewed.
The ruf= tag in a DMARC record specifies where forensic (failure) reports should be sent. These reports contain individual message samples that failed DMARC authentication.
ruf= reports are rarely honored by major inbox providers (Gmail and Microsoft do not send them). They also contain message content that may include personal data, creating GDPR/CASL/PIPL compliance exposure. Most organizations should not configure ruf=.
ruf= omitted entirely. Use rua= aggregate reports for visibility instead.
ruf= configured and pointing to an address that stores message content without appropriate data handling controls.
A category of email security solutions that sit in front of or alongside Microsoft 365 and Google Workspace to provide advanced threat protection beyond what the native platform offers. Includes anti-phishing, DLP, encryption, journaling, and security awareness training.
Native M365 and Google Workspace security catches commodity threats but misses sophisticated BEC (Business Email Compromise), targeted phishing, and data exfiltration attempts. ICES solutions add the layers that enterprise email security requires.
ICES solution deployed in inline or API mode, covering inbound threat detection, outbound DLP, email encryption, and journaling for compliance.
Relying solely on native M365/Google Workspace security for regulated industries or organizations handling sensitive data.
35 checks across email authentication, DNS security, and web infrastructure. Free, typically under 30 seconds.
Score Your Domain — FreeWe use cookies to improve your experience. Essential cookies are always active. Learn more