Why Are Companies Still Not Using SPF, DKIM, and DMARC?

You open a support ticket. A client says their invoices are not arriving. The messages were quarantined as suspicious by your email security gateway. The sender is not a phishing attempt. They are a legitimate vendor. They just have not set up SPF, DKIM, or DMARC on their domain.

This is not rare. Sysadmins in email-heavy environments have stopped being surprised by it.

The question is why this keeps happening, and what you can actually do about it.

What SPF, DKIM, and DMARC actually do

Email was designed in an era when trust was assumed, not verified. No protocol built into the original email system checks whether the server sending a message is allowed to send on behalf of the claimed domain.

SPF, DKIM, and DMARC were added later to fix this gap.

SPF (Sender Policy Framework) lets a domain owner publish a list of servers authorized to send email for that domain. When a message arrives, the receiving server checks whether the sending server is on the approved list.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages. The receiving server uses a public key published in DNS to verify that the message was signed by an authorized server and that its content was not altered in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It defines a policy for what happens when a message fails authentication, and it provides a reporting channel so domain owners can see who is attempting to send mail using their domain.

All three are needed because they cover different attack vectors. SPF alone can be defeated by sending from an authorized third-party server. DKIM alone does not verify that the sending domain matches the From header. DMARC is what makes the other two enforceable.

What happens when a company skips them

The consequences are concrete, not theoretical.

Legitimate email gets blocked or quarantined. Email security gateways such as Proofpoint, Mimecast, and Ironmail flag or reject messages from domains with no SPF, DKIM, and DMARC records. This is the correct behavior. Without authentication, the gateway cannot distinguish legitimate mail from spoofed mail.

Whitelisting does not always override this. Many gateways apply authentication checks before whitelist logic. Adding a sender to an allow list does not bypass a missing SPF or DKIM record. This surprises people who expect approved senders to always get through.

A domain without DMARC has no visibility into who is sending as them. Without DMARC reports, a company cannot see when their domain is used in a spoofing campaign or when their own servers are misconfigured. They find out when customers report suspicious email, or when their reputation scores start dropping.

The effects cascade. A domain that frequently sends unauthenticated email can end up on blocklists. Even after fixing the problem, reputation recovery takes time.

Why the gap persists

The technical fix is not complicated. The reasons companies do not apply it are human.

Lack of awareness. Many small businesses do not know these protocols exist. They set up a Google Workspace account, configure MX records, and consider email done. No one tells them there is a second layer of configuration required for email authentication to work.

"Google handles security" assumption. Google Workspace and Microsoft 365 include email authentication features, but only if the domain is configured correctly. SPF is not enabled by default. DKIM signing is not automatic. DMARC monitoring is not set up at all. Many business owners assume the platform handles this, and it does not.

Complexity and risk perception. The fear that SPF or DKIM will break existing email flows is real. If a company uses multiple third-party services to send email (a CRM, a marketing platform, a billing system), getting SPF right requires listing every sending source in a single record. Multiple SPF records for the same domain cause authentication failures. The perception of complexity stops people from starting.

No immediate pain signal. Without DMARC reports, the problem is invisible. A company can have their domain spoofed in phishing campaigns and never know it, because no one is sending them the evidence.

No enforcement pressure. PCI compliance forces companies handling credit card data to meet security standards. HIPAA forces healthcare providers to protect patient data. No equivalent regulation forces most businesses to publish SPF, DKIM, or DMARC records. Email authentication is a best practice, not a compliance requirement, for most industries.

What IT admins can do when they encounter this

If you are on the receiving end of unauthenticated email, here is a practical path.

First, confirm the problem. Use a free DNS lookup tool to check whether the domain has SPF, DKIM, and DMARC records published. If SPF is missing, the domain has no authorized sending servers defined. If DKIM is missing, no cryptographic signature is applied. If DMARC is missing, there is no authentication policy and no reporting channel.

Diagnose the specific failure. If the domain has SPF but mail is still failing, check whether the sending server is included in the SPF record. If both SPF and DKIM are present but DMARC alignment is failing, the sending domain in the From header may not match the authenticated domain. Each failure mode has a specific cause.

Communicate the issue clearly. When reaching out to the non-technical contact at the sender, explain the specific problem in plain language. "Your domain does not have an SPF record, which means receiving servers cannot verify that your server is allowed to send email for your domain" is more useful than "your email authentication is not configured." Provide the exact DNS records they need to add. If they use Google Workspace, direct them to the correct admin panel sections.

Know what you cannot fix from your end. If the sender's email security gateway is blocking their mail because their domain lacks authentication, whitelisting the sender address does not bypass authentication checks. The sender has to publish the records.

How to set up SPF, DKIM, and DMARC the right way

If you are the company that needs to fix this, the sequence is: SPF first, then DKIM, then DMARC monitoring.

For SPF, identify every service that sends email using your domain and include all of them in a single SPF record. The most common mistake is using multiple SPF records for the same domain, which causes authentication failures. A correctly formed SPF record starts with "v=spf1" and lists every authorized server.

For DKIM, most major email providers generate a key pair and give you the public key to publish in DNS. Enable it for every domain you send from.

For DMARC, start with a monitoring-only policy (p=none) and review the aggregate reports for two to four weeks before moving to quarantine or reject. The reports reveal your legitimate email sources and any authentication failures you need to fix first.

DMARC aggregate reports arrive as XML files, which are not human-readable in raw form. Parsing them manually at scale is not practical. This is where DMARCFlow earns its place: it processes these reports automatically and surfaces authentication failures in a readable dashboard, making it easier to act on DMARC data without manual work.

DMARCFlow also tracks changes to your SPF and DKIM configuration over time, which matters because authentication failures often surface after a vendor migration or a change to your email infrastructure.

For teams without dedicated email security staff, this kind of monitoring is what makes the difference between catching authentication failures early and discovering them after a Business Email Compromise incident.

FAQ

How do I check if a company has SPF, DKIM, or DMARC?
Use a free DNS lookup tool and query the domain for TXT records (SPF), DKIM selector records (DKIM), and DMARC records (_dmarc subdomain). Several online tools run all three checks at once.

How long does it take to set up SPF, DKIM, and DMARC?
SPF and DKIM can be configured in under an hour for a single-domain setup with one sending service. DMARC monitoring can be running the same day. Moving from monitoring to enforcement typically takes two to four weeks of reviewing reports.

Will this break my existing email?
If SPF is configured correctly to include all sending sources, it will not break anything. Starting with a p=none DMARC policy before moving to quarantine or reject gives you time to fix failures without risking email loss.

My email is working fine. Why should I bother?
If you have never checked your DMARC reports, you do not know whether your domain is being used in spoofing campaigns or whether your legitimate mail is silently failing for some recipients. Without authentication records, you are flying blind.

What is the most common mistake when setting up SPF?
Using more than one SPF record for the same domain. Receiving servers process only the first SPF record they encounter, and subsequent records are ignored, which causes unpredictable authentication failures. If you need to include multiple sending services, add them all to a single SPF record.

Bottom line

SPF, DKIM, and DMARC are not optional for any business that sends email. They are the difference between a domain that receivers can trust and one that gets treated as suspicious by default. The gap persists because awareness is low, enforcement is absent, and the immediate pain signal is missing. Fixing it is not hard. Fixing it before it causes a business disruption is the part that keeps getting delayed.