When I first started in IT, I was told DKIM wasn’t widely used and wasn’t something I needed to worry about very much.

DMARC rarely came up at all.

I also came across SPF records containing old vendors, old IP addresses, and services nobody seemed to recognize. As long as email continued to flow, cleaning them up didn’t always feel urgent.

That advice made sense in the environment I was working in at the time. Today, I would give someone starting in IT very different advice.

Email providers have become stricter about authentication, and phishing emails have become harder to recognize by appearance alone. The misspelled, poorly formatted messages we were taught to look for haven’t disappeared, but they’re no longer the only kind we see. With AI, someone can produce a polished payment request, password-reset message, or executive impersonation email in seconds.

SPF, DKIM, and DMARC won’t stop every phishing email. What they can do is help receiving mail systems determine whether a message was sent by a system authorized to use your domain.

The terminology makes these records sound more complicated than they are. I think of them as answering three questions:

  • SPF: Who is allowed to send?
  • DKIM: Was the message properly signed?
  • DMARC: Does everything match the address the recipient sees?

SPF: Who can send for your domain?

SPF stands for Sender Policy Framework. It’s a DNS record that lists the systems allowed to send email for a domain. If a company uses Microsoft 365, a ticketing platform, and a marketing service, those systems may all need to be included.

A basic Microsoft 365 SPF record might look like this:

v=spf1 include:spf.protection.outlook.com -all

That record is essentially telling receiving mail servers that Microsoft 365 is allowed to send email for the domain.

The problem is that SPF records tend to collect leftovers.

A company changes marketing platforms, but the old platform stays in SPF. A vendor relationship ends, but its include statement is never removed. Someone adds a second SPF record instead of updating the existing one. After a few years, nobody is completely sure which entries are still needed.

Old values aren’t just untidy. They can leave systems authorized longer than intended. Complicated records can also exceed SPF’s limit of ten DNS lookups, causing SPF to return an error even though a record is present.

Having an SPF record doesn’t mean you have a good SPF record.

SPF also doesn’t always check the address a user sees in Outlook or Gmail. It generally checks the envelope sender, which is often shown as the Return-Path in a message header. That address can be different from the visible From address.

This is normal when a company uses an outside mailing service, but it also means that seeing spf=pass isn’t enough by itself.

DKIM: Was the message signed?

DKIM stands for DomainKeys Identified Mail. The sending service adds a digital signature to the message using a private key. The domain publishes the matching public key in DNS, and the receiving mail server uses it to check the signature.

If DKIM passes, it shows that the message was signed by a system with access to the private key and that the signed parts of the message weren’t changed afterward.

DKIM doesn’t encrypt the email, and it doesn’t prove that the content is honest. A malicious email can still be properly signed if it was sent through a compromised account or an abused service.

A raw header may include a line like this:

DKIM-Signature: v=1; d=example.com; s=selector1;

The d= value is the domain that signed the message. The s= value is the selector used to locate the public key.

A selector is simply a name for a particular DKIM key. Organizations can use different selectors for Microsoft 365, marketing platforms, and other services. Selectors also allow keys to be rotated without replacing the entire DKIM configuration.

One mistake I’ve seen is assuming that the presence of a DKIM-Signature line means the message passed DKIM. It only means a signature was included. The result appears elsewhere in the header.

DMARC: Does it match the visible sender?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. The full name isn’t especially memorable. What matters is that DMARC connects SPF and DKIM to the domain in the visible From address.

This connection is called alignment.

Suppose a message displays:

From: Accounts Payable <payments@example.com>

SPF might pass for a completely different envelope-sender domain. DKIM might also pass using another signing domain. Those checks can be technically successful without confirming that example.com authorized the message.

DMARC asks whether the domain authenticated by SPF or DKIM aligns with example.com, the domain the recipient actually sees.

A message can pass DMARC when SPF passes and its domain aligns, or when DKIM passes and its signing domain aligns. Only one aligned method is required.

A simple DMARC record might look like this:

v=DMARC1; p=none;

The policy tells receiving systems what the domain owner wants done with messages that fail:

  • p=none monitors failures without requesting enforcement.
  • p=quarantine asks receiving systems to treat failures as suspicious.
  • p=reject asks receiving systems to reject failures.

Starting with p=none can make sense while an organization identifies everything legitimately sending email for the domain. Reports can uncover forgotten applications, printers, ticketing systems, marketing platforms, and other services.

The goal shouldn’t be to publish p=none and forget about it. Once legitimate senders are identified and alignment problems are corrected, the organization can work toward quarantine or reject.

Moving directly to reject without doing that work can block legitimate business email. DMARC should be treated as a project, not a five-minute DNS change.

Where AI fits into this

AI doesn’t bypass SPF, DKIM, or DMARC. It also doesn’t change how the records work.

What it changes is the quality and quantity of the messages attackers can create.

People have been taught to look for spelling mistakes, strange grammar, and awkward wording. Those clues are becoming less dependable. A convincing message can now be created quickly and tailored to a company, job role, or current event.

That makes it more important to have technical controls answering questions users can’t answer by looking at the wording: Was this server allowed to send for the domain? Was the message signed? Does that authentication line up with the sender shown to the recipient?

Email authentication still won’t prevent every threat. It won’t stop someone from registering a lookalike domain. It won’t protect a mailbox whose credentials have been stolen, and it doesn’t make every message with a passing result safe.

It’s one layer, but it’s an important one.

How I check a real message

MXToolbox and similar services are useful, but they show what’s published in DNS. A raw email header shows what happened to a specific message.

Depending on the mail client, the option may be called View source, View original, View message details, Show raw message, or Internet headers.

The first place I usually look is Authentication-Results:

Authentication-Results:
    spf=pass smtp.mailfrom=mailer.example.com;
    dkim=pass header.d=example.com;
    dmarc=pass header.from=example.com

Here’s how I read it:

  • spf=pass tells me the message passed SPF.
  • smtp.mailfrom= shows the domain used for that SPF check.
  • dkim=pass tells me the DKIM signature was validated.
  • header.d= shows the domain that signed the message.
  • dmarc=pass means SPF or DKIM passed with the required alignment.
  • header.from= shows the domain in the visible From address.

I don’t stop when I see three passes. I compare the domains.

The visible From field is what the recipient normally sees, but it shouldn’t be trusted by itself. The Return-Path is commonly connected to the envelope sender used for SPF. A different return path isn’t automatically suspicious because third-party services often use their own domains.

Received-SPF may contain more information about the SPF result, including the sending IP and evaluated domain. DKIM-Signature shows the signing domain and selector, while the Received lines help reconstruct the route a message took. When tracing that route, I generally read those lines from the bottom upward.

Headers can be messy. I don’t try to decode every line immediately. I start with the visible sender, return path, SPF result, DKIM signing domain, and DMARC result. If those don’t make sense together, I dig further.

When I use MXToolbox

I use tools such as MXToolbox to inspect what a domain has published publicly.

They can help show whether SPF and DMARC records exist, whether SPF has syntax or lookup-count problems, what DMARC policy is published, and whether a particular DKIM selector can be found.

What they can’t tell me is exactly what happened to the message sitting in front of me.

  • The DNS lookup shows what the domain currently publishes.
  • The raw header shows how one message was authenticated.

I usually want both.

One note of caution: raw headers can contain email addresses, IP addresses, internal hostnames, message IDs, and routing information. I wouldn’t paste a client’s complete header into a public tool without first reviewing and redacting it.

What a cleanup project actually looks like

Fixing email authentication starts with finding every legitimate sender. That can include much more than the main mail platform: marketing tools, ticketing systems, payroll services, monitoring platforms, scanners, applications, and outside vendors may all send email for the domain.

My general approach would be:

  1. Inventory the systems sending email.
  2. Review SPF and remove obsolete entries carefully.
  3. Check the SPF lookup count.
  4. Enable DKIM for supported sending platforms.
  5. Publish DMARC with reporting.
  6. Review actual messages and DMARC reports.
  7. Correct legitimate services that are failing alignment.
  8. Move toward quarantine or reject when the environment is ready.
  9. Review the records again whenever a sending service changes.

The technical changes aren’t always the hardest part. Finding the owners of old systems and confirming whether they’re still needed can take much longer.

That’s why these records need an owner. They shouldn’t be configured once and left untouched for years.

What changed for me

Early in my career, I thought of DKIM and DMARC as optional improvements. Now I see SPF, DKIM, and DMARC as part of the basic maintenance of a company’s domain.

I’m less interested in whether a record exists than whether it accurately represents the current environment.

Does SPF still list a vendor the company stopped using three years ago? Are legitimate services signing with DKIM? Does DMARC pass for real messages? Is the organization only monitoring, or is it working toward enforcement? Who reviews the configuration when a service is added or removed?

Those are operational questions as much as they are security questions.

Email authentication won’t solve phishing.
It will make your domain more difficult to misuse.

Further reading