What Are SPF, DKIM and DMARC? How Email Authentication Works

The email spoofing problem

Email was designed in 1971. The original protocol (SMTP) has no authentication built in — anyone can send an email claiming to be from ceo@yourcompany.com. This is email spoofing, and it's trivially easy without authentication controls in place.

Spoofed emails are the mechanism behind business email compromise (BEC), phishing, and invoice fraud — attacks that collectively cause billions in losses annually. SPF, DKIM and DMARC were developed specifically to address this gap, and major email providers (Google, Microsoft, Yahoo) now require DMARC for bulk senders and reject or quarantine unauthenticated email.

All three standards work entirely via DNS records. Configuring them correctly is not enough — because the records need to stay correct as your email infrastructure evolves.

SPF — Sender Policy Framework

SPF (RFC 7208) allows a domain owner to publish a list of IP addresses and mail servers authorised to send email from that domain. The receiving mail server checks this list during delivery and can reject or penalise email that comes from an unauthorised source.

SPF is published as a TXT record on the domain:

Reading this record from left to right:

• v=spf1 — declares this as an SPF record
• include:_spf.google.com — authorises all IPs listed in Google Workspace's SPF record (for @gmail.com or Google-hosted mail)
• include:sendgrid.net — authorises SendGrid's sending infrastructure (for transactional email)
• ip4:192.0.2.0/24 — explicitly authorises the /24 subnet of a custom mail server
• ~all — softfail: email from any other IP is suspicious but not rejected. -all is a hard fail (reject); ?all is neutral.

DKIM — DomainKeys Identified Mail

DKIM (RFC 6376) works differently to SPF. Instead of checking IP addresses, it adds a cryptographic signature to email messages. The receiving server verifies the signature using a public key published in DNS — if the signature is valid, the email was sent by someone in control of the domain.

How it works:

1. The sending mail server signs specific email headers and the body with a private key.
2. The signature is added to the email as a DKIM-Signature header.
3. The receiving server looks up the corresponding public key in DNS at: selector._domainkey.example.com
4. It verifies the signature. If it matches, the email was genuinely sent by the domain — and the signed content hasn't been tampered with in transit.

The selector prefix (e.g. google, selector1,mail) allows multiple DKIM keys for the same domain — useful when using different email providers simultaneously, or during key rotation.

A critical DKIM advantage over SPF: DKIM survives email forwarding. Because DKIM validates the signed content rather than the sending IP, a forwarded email retains a valid DKIM signature even after being relayed through a different mail server.

DMARC — policy and reporting

DMARC (RFC 7489) sits on top of SPF and DKIM. It does two things:

1. It specifies a policy — what the receiving server should do when an email fails both SPF and DKIM authentication.
2. It requests reports — aggregate and forensic data about emails claiming to be from your domain, sent back to an address you specify.

DMARC is also published as a TXT record:

The p= policy has three values:

DMARC alignment is the requirement that either SPF or DKIM must pass AND the domain used in the authentication must match the From: header domain. This prevents attackers from passing SPF check on a different domain and using that to evade DMARC.

MTA-STS and BIMI

Two further email security standards build on top of SPF/DKIM/DMARC:

• MTA-STS (Mail Transfer Agent Strict Transport Security) — publishes a policy that tells other mail servers your domain requires TLS for email delivery and the certificate must be valid. Prevents downgrade attacks where a connection starts TLS-encrypted but is stripped to plaintext.
• BIMI (Brand Indicators for Message Identification) — once DMARC is at p=quarantine or p=reject and SPF/DKIM are passing consistently, BIMI allows you to publish an SVG logo in DNS that major email clients (Gmail, Apple Mail, Yahoo) will display next to authenticated emails from your domain.

How they fail silently

What Aideworks monitors

Aideworks continuously monitors all email security records for every domain in your account:

• SPF presence and syntax — validates the record exists, parses correctly, and doesn't exceed the 10-lookup limit.
• DKIM key presence — checks configurable selectors to verify the public key record is present and correctly formatted.
• DMARC policy — verifies the record exists, the policy is configured, and the reporting address is present.
• MTA-STS policy — checks that the MTA-STS policy record and policy file are present and correctly formed.
• Change alerts for all records — any modification to SPF, DKIM, or DMARC records triggers an immediate alert.

For agencies and MSPs: read the full article on why email security monitoring matters for client domains.