The Short Version
If your business sends email from its own domain — and every business does — you need three DNS records configured correctly: SPF, DKIM, and DMARC. Without them, anyone on the internet can send email that appears to come from your domain. Your customers can receive convincing fraud emails that show your company name and address. And your own legitimate emails may land in spam. This guide explains what each record does, how they work together, and what happens when they’re misconfigured.
Why Email Authentication Matters
Email was designed in the 1970s with no built-in authentication. The “From” field in an email is, technically, just a string — any mail server can set it to anything. For decades, this worked fine because relatively few people sent email and abuse was rare. Today it’s the primary attack vector for business email compromise (BEC), which cost US businesses over $2.9 billion in 2023 according to the FBI’s Internet Crime Report.
SPF, DKIM, and DMARC are the three DNS-based standards that email providers use to verify that a message actually came from where it claims to have come from. Together, they give receiving mail servers the ability to reject or quarantine spoofed messages before they reach inboxes.
What SPF Does
Sender Policy Framework (SPF) is a DNS TXT record that lists all the IP addresses and mail servers authorized to send email from your domain. When a receiving mail server gets a message claiming to be from yourcompany.com, it looks up the SPF record for yourcompany.com in DNS and checks whether the sending server’s IP address appears in that list.
A typical SPF record looks like this:
v=spf1 include:spf.protection.outlook.com include:_spf.google.com -allThis says: “Accept email from Microsoft and Google on behalf of this domain. Reject everything else.” The -all at the end is the enforcement mechanism — it tells receiving servers to fail messages from unauthorized sources. Without this, the record is advisory only.
Common SPF mistakes: Using ~all (soft fail) instead of -all (hard fail) — which means spoofed messages still get delivered, just sometimes tagged. Having more than 10 DNS lookups in your SPF chain — which causes the record to fail to parse and makes all email appear unauthorized.
What DKIM Does
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing email. The sending mail server signs the message with a private key. The public key is published in DNS. When a receiving server gets the message, it looks up the public key and verifies that the signature matches — proving the message was not modified in transit and came from a server that holds the private key.
DKIM protects against man-in-the-middle modification — an attacker intercepting and altering an email in transit will break the signature. It also survives forwarding in ways that SPF doesn’t (SPF checks the sending server IP, which changes when email is forwarded).
DKIM requires your mail provider to generate the key pair and give you the public key to publish in DNS. Microsoft 365, Google Workspace, and most email platforms do this automatically, but you have to go into settings and enable it. Many businesses never do.
What DMARC Does
Domain-based Message Authentication, Reporting & Conformance (DMARC) is the policy layer that ties SPF and DKIM together. It tells receiving servers what to do when a message fails authentication, and it provides a reporting mechanism so you can see who is sending email claiming to be your domain.
A DMARC record specifies a policy: none (monitor only), quarantine (send to spam), or reject (refuse delivery). Most organizations start with none to gather reporting data without impacting mail flow, then move to quarantine and eventually reject once they’ve confirmed all legitimate senders are properly authenticated.
DMARC also introduces the concept of alignment: the domain in the “From” header must match the domain validated by SPF or DKIM. This closes the gap that allows attackers to pass SPF checks while still spoofing the visible From address.
The DMARC Gap Most Businesses Miss
Having a DMARC record at p=none is not protection — it’s monitoring. A policy of none means that even if a message fails all authentication checks, it still gets delivered to the inbox. The record exists, the reports flow in, but spoofed emails reach your customers unchanged.
Many organizations set DMARC to none during initial deployment and never revisit it. According to Valimail’s Email Fraud Landscape report, approximately 40% of domains with DMARC records are still at p=none. Those domains are not protected — they just have a monitoring policy that nobody is reading.
Moving to p=reject requires confidence that all legitimate email sending sources are captured in SPF and signed with DKIM. Marketing automation tools, third-party helpdesk platforms, CRM email, billing notifications, and partner relay systems all need to be inventoried and authenticated before enforcement.
MTA-STS and BIMI
Two newer standards build on DMARC enforcement:
MTA-STS (Mail Transfer Agent Strict Transport Security) requires that email servers encrypt the connection when delivering mail to your domain. It prevents downgrade attacks where an attacker tricks a mail server into sending email unencrypted. MTA-STS requires both a DNS record and a policy file hosted at a specific HTTPS URL on your domain.
BIMI (Brand Indicators for Message Identification) allows companies with a verified DMARC enforcement policy to display their logo next to emails in supporting email clients (Gmail, Apple Mail, Yahoo). It requires a DMARC policy of reject or quarantine and, for verified marks, a Verified Mark Certificate (VMC) from an approved authority. BIMI is primarily a trust-signaling mechanism — it tells recipients at a glance that the email is authenticated.
What a Bad Grade Actually Means
When you run an email security check and receive a poor score, the practical implications depend on which records are missing or misconfigured:
- No SPF record: Anyone can send email as your domain. No receiving server has any basis to reject it. Your customers, partners, and vendors may receive phishing emails that appear to come from you.
- SPF with
+all: This is worse than no SPF. It explicitly authorizes every server on the internet to send as your domain. - No DKIM: Messages may not be deliverable to strict receivers, and you have no protection against message tampering in transit.
- DMARC at
p=none: Monitoring only. No enforcement. Spoofed emails still reach inboxes. - No DMARC at all: Google and Yahoo now require DMARC records for bulk senders and are increasingly applying this requirement to all senders. Missing DMARC will increasingly result in deliverability problems.
Check Email Security Grader — Free
Enter your domain name and get an instant analysis of your SPF, DKIM, DMARC, and MTA-STS configuration. The grader checks each record for syntax errors, enforcement level, and alignment, then gives you a letter grade with specific remediation steps.
Nicholas Salem is the CEO of Boston Managed IT, a managed services provider serving professional services firms and small businesses across Greater Boston. BMIT helps clients build and operate security programs that meet Massachusetts compliance requirements.
