Email security for a business means stopping attackers from spoofing your domain, filtering malicious messages before they reach inboxes, and training people to report what slips through. SPF, DKIM and DMARC carry the technical part, and the IETF has replaced the DMARC specification with a new standard, RFC 9989.
Quick Overview
What you will learn:
- What SPF, DKIM and DMARC each protect against, and what they do not
- Which DMARC details changed with the new standard
- How to move from monitoring to rejecting spoofed mail without breaking legitimate flows
- Where people fit in: roles, reporting and phishing simulations
Who this article is for:
- Mail and DNS administrators
- Security operations and incident response teams
- Managers who run security awareness programmes
Reading time: 7 minutes
Why email remains the easiest way in
SMTP was designed for a network where senders were trusted, so the visible “From” address can be set to anything. Spoofing a company, a supplier or a public authority is therefore cheap. CIS Control 9 on cisecurity.org, which covers email and web browser protections, puts it plainly: these channels let attackers manipulate human behaviour through direct engagement.
NIST’s guideline SP 800-177 Rev. 1, “Trustworthy Email”, available on csrc.nist.gov, is written for enterprise email administrators and security staff. It treats sender authentication (SPF, DKIM, DMARC), transport security with TLS and content protection such as S/MIME as separate layers. It is a useful map when you audit what your organisation already has in place.
How SPF, DKIM and DMARC work together
SPF (RFC 7208) is a DNS TXT record listing the servers allowed to send mail for a domain. It checks the SMTP envelope sender, not the header address users see, so on its own it does not stop display spoofing. You can inspect a record with dig txt example.com | grep 'v=spf1'; it should end with -all or ~all.
DKIM adds a cryptographic signature that receivers verify against a public key in DNS. RFC 8301 on www.rfc-editor.org requires signers to use rsa-sha256, forbids rsa-sha1, and sets a floor of 1024-bit RSA keys while recommending 2048 bits.
DMARC ties both to the domain in the visible “From” field. A message passes when SPF or DKIM succeeds and the authenticated domain is aligned with that “From” domain. The owner publishes a policy under _dmarc and asks for reports: p=none monitors, p=quarantine asks receivers to treat failures as suspicious, p=reject asks them to refuse the message. Check yours with dig +short txt _dmarc.example.com.
What changed in DMARC
RFC 9989 was published in May 2026 on the Standards Track and obsoletes RFC 7489 and RFC 9091; its text and status are on datatracker.ietf.org. Changes worth knowing:
- The
pcttag is gone. Applying a policy to a fraction of failing mail proved unreliable in practice. A test-mode tagttakes its place:t=ysignals that the published policy should not be fully applied yet. - A DNS Tree Walk replaces the Public Suffix List. Receivers find the organisational domain and the applicable policy record by querying upwards through the DNS hierarchy.
- The
nptag for non-existent subdomains, previously defined in the experimental RFC 9091, is now part of the core specification alongsidepandsp. - Reporting moved to companion documents: aggregate reports are defined in RFC 9990 and failure reports in RFC 9991.
Guides written before May 2026 describe the earlier model, so check your configuration against the current text on datatracker.ietf.org.
Rolling it out, and the people in the loop
Start with p=none and reporting switched on, then fix every service that sends mail on the company’s behalf (invoicing, marketing tools, help desk) before tightening to quarantine and finally reject. Jumping straight to enforcement tends to break business processes nobody remembered. Domains that never send email deserve a strict lock-down: an SPF record of v=spf1 -all and a DMARC policy of p=reject.
The mail administrator owns the configuration; DMARC reports and user reports of suspicious messages go to the incident response team. Employees are the last layer. A perfect DMARC setup does nothing against a look-alike domain the attacker registered, or a compromised supplier mailbox. That is where awareness work matters: a one-click way to report suspicious mail and regular phishing simulations followed by feedback rather than blame.
Read Also
- Phishing and social engineering: how to spot an attack — warning signs inside a message
- Running simulated phishing campaigns — a rollout plan for team managers
- Ransomware: preparing your company — what to do when a malicious email does get through
Build Your Skills
Two trainings build on this: Cyber Security Awareness Training and Social Engineering in Cyber Security. The first prepares staff to recognise phishing and manipulation, the second looks at phishing variants from the defender’s side. Get in touch to tailor the scope to your team.
Frequently Asked Questions (FAQ)
How do we protect information sent through company email?
Begin with the domain: publish SPF, sign outgoing mail with DKIM and set a DMARC policy with reporting. Then review inbound filtering and agree on how staff report a suspicious message. Finally, keep people trained, because some attacks will always get past the filters.
Are phishing simulations worth it if our mail is already filtered?
Yes. Filters and DMARC mainly stop spoofing of your own domain; they will not catch a look-alike domain or a hijacked supplier account. Simulations show how staff respond in exactly those cases and build the habit of reporting. What counts is the feedback after each campaign, not naming and shaming.
What does security awareness mean for email?
It is a programme that teaches staff to recognise social engineering and respond correctly. For email, that means checking the sender and links, treating unusual payment or data requests with caution, and reporting doubtful messages to the incident response team quickly.
What is social engineering and how do you spot it in an email?
Social engineering means manipulating people instead of breaking technical defences, and email is one of its main channels. The message tries to get you to click a link to a fake login page, open an attachment or make a payment. Typical signs are time pressure, an unusual request for money or a password, and a sender or web address that does not match the company name. Hover over the link before clicking and read where it really goes.