Email authentication is part of your external attack surface

Email security is often treated as a mail-team responsibility, but from an attacker perspective it is part of the public attack surface. DNS records for SPF, DKIM, and DMARC tell receiving mail systems whether a message claiming to come from your domain should be trusted.

When those records are missing, weak, or inconsistent, attackers can send convincing phishing emails that appear to use your organization’s own domain. That does not require access to your mail server. It only requires that receiving systems have no strong policy telling them to reject unauthorized senders.

What each control does

  • SPF lists which mail servers are allowed to send email for a domain.
  • DKIM signs outgoing mail so recipients can verify that the message was authorized and not modified.
  • DMARC tells receivers what to do when SPF or DKIM alignment fails: monitor, quarantine, or reject.

Common weak configurations

  • No DMARC record: spoofed mail may be accepted even if SPF or DKIM fails.
  • DMARC policy set to p=none forever: useful for monitoring, but weak as a long-term policy.
  • Overly broad SPF: records that include too many third parties increase the number of systems trusted to send as your domain.
  • Broken DKIM rotation: old selectors remain active, or new sending platforms are added without signing.
  • Subdomain gaps: the root domain has DMARC, but subdomains do not inherit the intended protection cleanly.

A practical example

Assume a company uses example.com for customer communication, invoices, and support. If the domain has no DMARC enforcement, an attacker can send mail with a visible From address such as billing@example.com. Some recipients may still receive the message, especially if the target mailbox provider applies weak local filtering or the message looks operationally normal.

That single gap can turn a generic phishing campaign into a brand impersonation attack. The victim sees the organization’s domain, not an unfamiliar sender.

How to harden gradually

  1. Inventory every legitimate sender: mail platform, CRM, support desk, billing system, monitoring system, and marketing tool.
  2. Deploy SPF and DKIM for each authorized sender.
  3. Start DMARC at p=none and collect reports.
  4. Fix legitimate senders that fail alignment.
  5. Move to p=quarantine, then p=reject when confidence is high.
  6. Review subdomain policy with sp= so unused subdomains cannot be abused easily.

Where Front Screen helps today

Front Screen currently looks at external exposure around mail and identity signals. It checks for publicly reachable mail-related services such as SMTP/25, SMTPS/465, mail submission/587, POP3/110, IMAP/143, IMAPS/993, and POP3S/995. It also reports reverse DNS and identity context, BGP ASN and prefix information, TLS/certificate posture, and other internet-facing service exposure.

Those checks do not replace a full SPF, DKIM, and DMARC policy review, but they help answer an important related question: which mail-facing systems and identity signals are visible from the outside?

Bottom line

Email authentication records are small DNS entries with large security impact. If attackers can use your domain to send believable mail, your brand becomes part of the attack path. Treat SPF, DKIM, and DMARC as external security controls, not just mail configuration details.