Understand email security: mail routes, protection and first steps

A secure domain does not make every message safe

SPF, DKIM and DMARC check domain authorisation and its relationship to a message. They can make direct domain forgery harder. They do not check whether an invoice is authorised, an attachment contains malware or a real account is now being used by an attacker. Transport encryption protects a connection and makes no such content decision. RFC 9989, sections 1 and 2.2

Start with a specific question: are messages missing? Is your domain being forged? Does a newsletter service need to send correctly? Is the concern confidential content or a suspicious account? The answer determines the checking route. One overall score cannot replace these questions.

The route an email takes

1. Compose: A person or application creates a message with a visible From, recipients, subject and content.
2. Submit: The mail client or sending service hands it to a submission server. Defined routes include port 587 with STARTTLS and port 465 with implicit TLS; webmail or an API may use another internal entry point.
3. Prepare for sending: The system sets the SMTP reverse path and may sign the message with DKIM. Changes after signing can cause verification to fail.
4. Find the receiving target: The sending mail server obtains the recipient domain's MX records and attempts SMTP delivery, usually on port 25. Forwarding and gateways can add hops.
5. Check and decide: The receiving system may evaluate SPF, DKIM, DMARC, reputation, content and local rules. It decides on acceptance, rejection and further treatment.
6. Make available: An accepted message may reach a mailbox, spam or another processing stage. Acceptance proves neither inbox placement nor reading. Users access messages through webmail or IMAP, for example.

Sources: RFC 5598, Internet Mail Architecture, RFC 5321, RFC 6409, section 3.1, RFC 8314, section 3.3.

The visible address and technical identity are different

One successful aligned SPF or DKIM path suffices for DMARC: its authenticated domain must match the From domain under the chosen alignment mode. A bare spf=pass or dkim=pass without this relationship is insufficient. RFC 9989, section 4.4

For diagnosis, trust only the Authentication-Results from your trusted receiving system. An attacker can supply similarly named fields; position alone does not prove their origin. Interpreting header findings explains the distinction. RFC 8601, section 5

Which measure answers which question?

TLS between two servers may terminate at each intermediary. Plaintext processed there remains accessible to that intermediary. Conversely, encrypted content does not automatically protect metadata and endpoints. Plan according to the actual protection needed, rather than the number of enabled acronyms.

Who is responsible for what?

A DNS provider is not automatically your mail provider. Nor does a mailbox provider necessarily know every newsletter, CRM or form submission service in your organisation. RFC 5598, sections 2 and 4

The order in which to proceed

1. Inventory and responsibilities: Record domains, subdomains, receiving systems and every sending application. Include infrequent invoice or alert messages.
2. Check reception and accounts: Secure MX, the mailboxes actually used, administrative access, strong authentication and recovery routes. Do not postpone account protection until a DNS project ends.
3. Authenticate sending routes: Configure SPF authorisation and DKIM for each service; check your own messages at the recipient for results and alignment.
4. Observe DMARC: Maintain the reporting destination, publish a suitable monitoring policy and compare reports with the inventory. The domain check does not receive these reports.
5. Choose the policy deliberately: Resolve legitimate failures, assess forwarding and mailing lists, then tighten the policy. p=reject is not a mandatory target for every general-purpose mailbox domain. The new DMARC standard, RFC 9989 section 7.4, states explicit interoperability limits for this case.
6. Harden transport and DNS: Plan MTA-STS/TLS-RPT or DANE according to actual support; coordinate DNSSEC and certificate changes. Errors may delay or prevent delivery.
7. Continue operational maintenance: Include new sending services before they start, monitor reports and accounts, remove orphaned DNS references and practise response and recovery procedures.

DMARC enforcement describes policy changes. Alias strategy helps with deliberate allocation and replacement of addresses. Compliance and documentation places the technical contribution in its organisational and legal context.

Domains that should neither send nor receive

Consider the following combination only if no service actually sends with the domain and no reception is needed. This example is invented and has not been published:

example.net.        IN MX 0 .
example.net.        IN TXT "v=spf1 -all"
_dmarc.example.net. IN TXT "v=DMARC1; p=reject"

Null MX declares the absence of reception, SPF -all authorises no sending server, and DMARC requests treatment of failures. These are separate tasks. A custom DMARC record may also affect subdomains; check existing sending there first. Null MX must not coexist with normal MX records. It does not prohibit a web server under the same domain. RFC 7505, sections 3–4, RFC 7208, section 10.1.2

Why sender authentication alone is insufficient

An exact forged domain differs from a similarly spelt domain or a compromised real account. QR codes, calendar invitations and attachments also need content and behavioural checks. The email threats chapter explains these mechanisms, protection limits and useful steps when something is suspicious. The threat reports linked there each describe limited studies; they do not establish an individual attack rate.

The right starting point for your task

Targeted DKIM setup guides cover the general process, Google Workspace and Microsoft 365. Choose according to the sending route you actually use.

What the Email Security Check actually examines

The Email Security Check examines publicly accessible configuration and limited transport features as a snapshot. It is not an examination of a received message.

Content, attachments, QR codes, sign-in security, forwarding rules and DMARC XML reports are not analysed here. The check does not continuously monitor your domain. Read results and product weighting in the context of the data collected; a fixed runtime or score is not a security promise. Details: check scope.