Email Security guide

What Email Security checks

Receiving mail servers decide whether a message that claims to come from your domain is genuine by reading a handful of DNS records. Email Security reads all of them for one domain: SPF lists the servers allowed to send, DKIM publishes the keys that sign your mail, DMARC tells receivers what to do when both fail and where to report it, MTA-STS and TLS-RPT protect and monitor encryption between mail servers, and BIMI can show your logo once DMARC is enforced.

This guide replaces the separate SPF Checker and DMARC Checker guides: both tools are now part of Email Security, and their sections follow below.

How to use Email Security

1. Open Email Security and enter the domain from the From address, for example example.com. A pasted URL or email address is reduced to the domain.
2. Optionally enter a DKIM selector. It is the s= tag of the DKIM-Signature header in a message you sent; common selectors are always tried.
3. XGM resolves the SPF record with every include and redirect, looks up _dmarc (falling back to the parent domain) and checks up to three external report addresses for authorisation.
4. In parallel the XGM server tries the DKIM selectors, reads the MTA-STS, TLS-RPT and BIMI records and fetches the MTA-STS policy file over HTTPS.
5. Read the score and the table of areas, then work through the findings, most severe first. Findings with a fix show a record to copy into your DNS provider.
6. Share the result with the permalink (/tools/email-security?d=example.com), export it, or open the Full report tab for the scored server-side report with prioritised recommendations.

If a DNS lookup times out, the tool says so instead of reporting a missing record, and that area is left out of the score. Running the check again usually succeeds.

The score and the DMARC roadmap

Each area gets a status: pass earns its full weight, needs work earns half, and fail or not set up earns nothing. DMARC at p=none and MTA-STS in testing mode count as needs work, because they monitor rather than protect. The score is a quick orientation for comparing domains and tracking progress, not a certification.

Under the score, the DMARC roadmap shows where the domain stands on the usual path: publish p=none with a report address, move to p=quarantine once every legitimate sender aligns, then to p=reject. The p=none to p=reject guide walks through the rollout week by week.

What DMARC is

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) connects the two older email authentication methods to the address people actually see. SPF checks which servers may send for the envelope sender, and DKIM checks a cryptographic signature added by the sending system. Neither of them looks at the visible From header on its own.

DMARC closes that gap. A message passes DMARC when SPF or DKIM passes and the domain that passed is aligned with the From domain. The domain owner publishes a policy that tells receivers what to do when a message fails, and addresses that receive reports about all mail using the domain.

Receivers are not forced to follow the policy, and large mailbox providers combine it with their own spam signals. In practice p=reject is honoured by the major providers and is the strongest protection you can publish against direct spoofing of your domain.

Why DMARC matters

Without DMARC anyone can send mail with your domain in the From header, and you never find out. Phishing that impersonates invoices, password resets or executives relies on exactly that. A DMARC record also changes how your own mail is judged: authenticated, aligned mail is easier for receivers to trust.

Since February 2024 Google and Yahoo require bulk senders (roughly 5,000 or more messages a day to their users) to publish a DMARC record, with p=none as the minimum, alongside SPF and DKIM. Every domain that sends mail benefits from the same setup, and domains that never send mail should publish p=reject so they cannot be abused.

Reading every DMARC tag

A DMARC record is a list of tag=value pairs separated by semicolons. The record must start with v=DMARC1, and p is required; by convention it comes right after v. Unknown tags are ignored by receivers, which is why a typo silently disables a setting.

The DMARC working group at the IETF is revising the standard (often called DMARCbis). The revision adds tags such as np for non-existent subdomains and replaces pct with a testing flag t. XGM recognises these tags, so they are not reported as unknown.

Verdicts in the checker

Common DMARC mistakes and how to fix them

Two DMARC records

This usually happens when a new provider's setup wizard adds a record next to an old one. The fix is to merge them into one record; the checker's fix shows a clean starting point.

The record is published at the domain itself

A TXT record with v=DMARC1 at example.com does nothing. It must be at _dmarc.example.com. Some DNS panels add the zone name automatically, so enter only _dmarc as the host name there.

Reports to another domain are dropped

If rua=mailto:reports@dmarc-service.example.net points outside your domain, the receiving domain must publish a record that accepts your reports. Report services normally do this for their customers, but a self-hosted mailbox on another domain needs it added by hand.

example.com._report._dmarc.dmarc-service.example.net. IN TXT "v=DMARC1"

Staying at p=none for years

p=none is a measurement phase, not a destination. Once the aggregate reports show that your legitimate senders pass with alignment, move to quarantine and then reject. The p=none to p=reject guide walks through that in stages.

Weaker subdomain policy

p=reject; sp=none leaves every subdomain open to spoofing, and attackers use names like billing.example.com for exactly that reason. Remove sp or give it the same value as p unless a subdomain really needs a softer policy while you fix it.

Example DMARC records

Replace example.com and the report address with your own values. Keep rua in every stage: without reports you cannot tell what enforcement will block.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

When the checker suggests a next step for an existing record, it keeps every other tag you already publish, such as sp, ruf or fo, and only changes the policy.

What SPF is

Sender Policy Framework (RFC 7208) is a TXT record that starts with v=spf1 and lists who may send mail for a domain. When a server receives a message, it looks at the envelope sender, the address used in the SMTP MAIL FROM command, and checks whether the connecting IP is allowed by that domain's record. The result is pass, fail, softfail, neutral, none, temperror or permerror.

The envelope sender is often not the address people see. Newsletter and ticketing services commonly use their own bounce domain, so SPF passes for them while saying nothing about your From address. DMARC connects the two by requiring the SPF domain to be aligned with the From domain.

Reading an SPF record

A record is a list of mechanisms evaluated from left to right, each with an optional qualifier. The first mechanism that matches the sending IP decides the result, so order matters only for which qualifier applies. A record should end with all to decide what happens to everything not listed.

What the SPF findings mean

The lookup count warns at eight. That leaves room for the day a provider adds a nested include to its own record, which raises your count without any change on your side. The 10-lookup guide explains how to reduce it.

Which domain to check for SPF

SPF is evaluated for the envelope sender, so the right domain to check is the one in the Return-Path header of a delivered message. For mail sent directly from your mailbox provider it is usually your own domain. For newsletters, ticketing systems and invoicing tools it is often a bounce domain such as bounces.example.com or a domain belonging to the service.

Open a recent message from each system, look at Return-Path and Authentication-Results, and check each envelope domain in turn. The Email Header Analyzer shows both fields and the SPF result the receiver recorded. If the result is pass for a domain that is not yours, SPF is working for the service but does not count toward DMARC for you.

Receivers also check SPF for the HELO name of the connecting server when the envelope sender is empty, as in bounce messages. Mail server host names such as mail.example.com should therefore have a small SPF record of their own, for example v=spf1 a -all.

Common SPF mistakes

Adding a second record for a new provider

Setup instructions often say "add this TXT record", and a second v=spf1 record appears next to the first. Merge the new include into the existing record instead.

; wrong: two records
example.com. IN TXT "v=spf1 include:_spf.mail.example.net -all"
example.com. IN TXT "v=spf1 include:esp.example.net -all"

; right: one record
example.com. IN TXT "v=spf1 include:_spf.mail.example.net include:esp.example.net -all"

Typos that break everything

inlcude:, ip4:192.0.2.0/33 or a missing colon are syntax errors. Receivers return permerror for the entire record, not just the broken term, so one typo disables SPF for all your mail.

Relying on SPF alone

SPF fails when a message is forwarded, because the forwarding server is not in your record. Configure DKIM signing with your domain for every sender, so DMARC keeps passing. The DMARC guide explains how the two combine.

Forgetting domains that never send mail

Parked domains should publish v=spf1 -all together with a DMARC p=reject record. Without them, the domain is easy to use in spoofing because receivers have nothing to check against.

Authorising far more than you use

Large ranges such as a whole /16 copied from old documentation, or an include for an entire hosting provider, allow every customer of that network to pass SPF as you. List the narrowest ranges or the provider-specific include your service documents, and review them when you change hosting.

DKIM: finding the selector and judging the key

DKIM signs each message with a private key and publishes the public key in DNS under a selector: selector1._domainkey.example.com. Nothing in DNS lists the selectors a domain uses, so Email Security tries 24 names that large providers and sending services use (for example google, selector1, selector2, k1, s1 and mandrill) plus any selector you enter. A scan that finds nothing is not proof that DKIM is missing, so it counts as needs work rather than fail.

For every key found, the tool decodes the public key and reports its type and size. RFC 8301 forbids RSA keys shorter than 1024 bits and recommends 2048 bits; a 1024-bit key is a warning. The t=y flag marks a key in testing mode, which lets receivers ignore the signature, and an empty p= marks a revoked key after a rotation.

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

The DKIM selectors and key rotation guide explains how to publish 2048-bit keys that fit into DNS and how to rotate them without breaking signatures on mail in transit.

MTA-STS and TLS-RPT

Mail servers encrypt with STARTTLS only when both sides offer it, and an attacker on the network path can strip the offer. MTA-STS lets you declare that your mail servers always support TLS with a valid certificate. It has two parts: a TXT record at _mta-sts.example.com with an id, and a policy file served over HTTPS at mta-sts.example.com.

Email Security fetches the policy the way sending servers do: over HTTPS with certificate validation and without following redirects, as RFC 8461 §3.3 requires. It checks version, mode, max_age and whether every published MX host matches an mx line. In enforce mode an MX host that the policy does not cover is critical, because senders that honour MTA-STS will refuse to deliver to it.

version: STSv1
mode: testing
mx: mx1.example.com
mx: *.mail.example.com
max_age: 604800

TLS-RPT asks sending servers to report TLS failures daily to the address in _smtp._tls.example.com. Publish it before moving MTA-STS from testing to enforce, so you see problems before mail is refused. The MTA-STS and TLS-RPT guide covers the setup step by step.

BIMI

BIMI publishes a logo at default._bimi.example.com that some mailbox providers show next to authenticated mail. It is optional and carries the smallest weight in the score. Providers display the logo only when DMARC is enforced with p=quarantine or p=reject, the logo is an SVG Tiny PS file served over HTTPS, and, for Gmail and Apple Mail, a Verified Mark Certificate or Common Mark Certificate is listed in a=.

Email Security reports a missing record as a note, not a problem, and warns when a BIMI record exists while DMARC is not enforced. Whether the certificate cost is worth it is discussed in the BIMI and VMC guide.

FAQ

Sources

• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• Google: Email sender guidelines
• IETF DMARC working group (DMARCbis drafts)
• RFC 7208 §4.6.4: DNS lookup limits
• RFC 7489: DMARC identifier alignment
• RFC 5321: Simple Mail Transfer Protocol (MAIL FROM)
• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460: SMTP TLS Reporting
• RFC 8301: Cryptographic algorithm and key usage update to DKIM
• BIMI Group: implementation guide